Så er bog-standen på STAReast åbnet. Så skal der handles. Det generelle EXPO-område åbner i morgen.
Ellers tester vi STAReast 2013 App'en - der er vist plads til forbedringer, eller er der tale om fejlplantning?
tirsdag den 30. april 2013
Mobile Applications Testing - Heldags Tutorial
En spændende dag. Test af mobile apps med hands-on øvelser.
mandag den 29. april 2013
Testing the Data Warehouse - STAReast - Tutorial - Geoff Horne
Så kom turen til mandagens anden halvdags tutorial - her var mit valg blevet 'test af datawarehouse', som jeg tidligere har arbejdet en del med - primært i den finansielle sektor. Jeg har fået nogle kommentarer via sms om min 'langsommelighed' med at opdatere min blog - husk venligst de 6 timers forskel i tiden - nu er kl. 16.55 her, og 22.55 hjemme i Danmark - så min dag/aften har fortsat mange timer - som jeg vil nyde her i selskab med mange interessante testkollegaer fra det meste af verdenen - dog var jeg den eneste ikke amerikaner til denne tutorial.
Geoff Horne startede sin tutorial med udgangspunkt i et af de hotte buzz-word i øjeblikket - BIG DATA. Det refererer det de gigantiske mængder af data - ofte på ustruktureret form - vi i dag har i forskellige systemer. Af disse ofte er i ustruktureret form giver selvfølgelig mening når man tænker på de mange forskellige kildesystemer og -former, herunder sociale medier, blogs m.m. En måde at få struktur på dem er 'selvfølgelig' via et datawarehouse.
Hvis du har behov for at blive opdateret med hensyn til BIG DATA - så har Sogeti's VINT-center udarbejdet en række skrifter om disse - tjek nedenstående link til et af disse skrifter:
BIG DATA
Det var gennemgående i tutorialen at test i datawarehouse er vigtigt - bl.a. med udgangspunkt i den ofte meget svingende kvalitet i kildedata, opsætning af ETL-regler og 'rensning' af data. Et af hans budskaber var da også en løbende måling af datakvaliteten i kildesystemerne, herunder udbedring af disse' klart skulle overvejes af alle FØR etablering af et datawarehouse.
Det er umiddelbart spændende at se på, hvilke færdigheder det kræver af testere i forhold til datawarehouse-test - altså udover de sædvanlige:
- kendskab til datawarehouse konceptet
- viden om både de tekniske emner og den forretningsmæssige brug
- kendskab til SQL, stored procedures, SQL-test
- kendskab til datamodellering, datamapping, ETL-tools, DBA-viden - nogle af disse til brug for review
- excel - specielt datanalyse-delen
- kendskab til sammenhæng mellem data og forretningsprocesser.
Test af datawarehouse er jo en meget 'data-nær-test' (mit eget begreb - ved ikke om det findes - men nu gør det ihvertfald).
Jeg kunne ikke lade være med at spørge til hvilke testdesignteknikker der var mest anvendelig, når det kommer til test af datawarehouse. Min umiddelbare - ikke særligt beskedne - holdning er nok, at jeg nok kunne lære ham og de øvrige ca. 40 deltagere, lidt....måske mere end lidt. Udover ækvivalensklasser, grænseværditest og parvis test, kunne beslutningstabeltest også finde anvendelse ved f.eks. test af mapping-regler.
Geoff Horne startede sin tutorial med udgangspunkt i et af de hotte buzz-word i øjeblikket - BIG DATA. Det refererer det de gigantiske mængder af data - ofte på ustruktureret form - vi i dag har i forskellige systemer. Af disse ofte er i ustruktureret form giver selvfølgelig mening når man tænker på de mange forskellige kildesystemer og -former, herunder sociale medier, blogs m.m. En måde at få struktur på dem er 'selvfølgelig' via et datawarehouse.
Hvis du har behov for at blive opdateret med hensyn til BIG DATA - så har Sogeti's VINT-center udarbejdet en række skrifter om disse - tjek nedenstående link til et af disse skrifter:
BIG DATA
Det var gennemgående i tutorialen at test i datawarehouse er vigtigt - bl.a. med udgangspunkt i den ofte meget svingende kvalitet i kildedata, opsætning af ETL-regler og 'rensning' af data. Et af hans budskaber var da også en løbende måling af datakvaliteten i kildesystemerne, herunder udbedring af disse' klart skulle overvejes af alle FØR etablering af et datawarehouse.
Det er umiddelbart spændende at se på, hvilke færdigheder det kræver af testere i forhold til datawarehouse-test - altså udover de sædvanlige:
- kendskab til datawarehouse konceptet
- viden om både de tekniske emner og den forretningsmæssige brug
- kendskab til SQL, stored procedures, SQL-test
- kendskab til datamodellering, datamapping, ETL-tools, DBA-viden - nogle af disse til brug for review
- excel - specielt datanalyse-delen
- kendskab til sammenhæng mellem data og forretningsprocesser.
Test af datawarehouse er jo en meget 'data-nær-test' (mit eget begreb - ved ikke om det findes - men nu gør det ihvertfald).
Jeg kunne ikke lade være med at spørge til hvilke testdesignteknikker der var mest anvendelig, når det kommer til test af datawarehouse. Min umiddelbare - ikke særligt beskedne - holdning er nok, at jeg nok kunne lære ham og de øvrige ca. 40 deltagere, lidt....måske mere end lidt. Udover ækvivalensklasser, grænseværditest og parvis test, kunne beslutningstabeltest også finde anvendelse ved f.eks. test af mapping-regler.
Rick Craig - bruger TPI, men også en masse om metrikker
Som nævnt har jeg tilbragt formiddagen i selskab med Rick Craig - og sikke en inspiration. Hans tutorial var over temaet 'Measurement and Metrics for Test Managers', men han kom også lige til at nævne, at han bruger TPI-modellen, og har gjort det i mange år. Lyder godt.
Men en god tutorial med en masse gode drøftelser og erfaringsudvekslinger mellem de ca. 70 deltagere.
Der var specielt mange diskussioner om brugen af DDP som metrik (Defect Detection Percentage) - fordele, ulemper, brug og misbrug og ikke mindst fælder ved brug af den. Diskussionerne gik også på, hvilket niveau man skulle være på. Her er der jo ganske enkelt ikke noget enkelt og entydigt svar. Hvis man arbejder i en branche, hvor time-to-market er en af de vigtige konkurrenceparametre kan en lavere DDP være relevant, mens det for virksomheder der arbejder med såkaldt sikkerhedskritisk software (pharma, flykontrol m.m.) kan det være relevant at have en DDP i den højere ende.
Men man skal jo altid være opmærksom på, hvad omkostningen er ved at stige i DDP - omkostningen ved at stige fra 50% til 51% er nok lavere end hvis det er fra 97% til 98%.
Et andet område der blev diskuteret var metrikker til kodedækning. Overraskende var den mest udbredte instruktionsdækning, og når man tænker på at det jo er det laveste niveau det giver mening af måle på - ja så er det lidt overraskende at de andre ikke rigtig anvendes.
Et andet godt point fra Rick var holdningen til metrikker - opfat alle metrikker som midlertidige - evaluer værdien af disse en gang om året, og fjern og erstat de som ikke giver værdi. På den måde kan det sikres, at vi ikke bare bruger denne eller hint metrik fordi det har vi altid gjort.
Gode tanker og ideer til mit fortsatte arbejde med testmetrikker.
Men en god tutorial med en masse gode drøftelser og erfaringsudvekslinger mellem de ca. 70 deltagere.
Der var specielt mange diskussioner om brugen af DDP som metrik (Defect Detection Percentage) - fordele, ulemper, brug og misbrug og ikke mindst fælder ved brug af den. Diskussionerne gik også på, hvilket niveau man skulle være på. Her er der jo ganske enkelt ikke noget enkelt og entydigt svar. Hvis man arbejder i en branche, hvor time-to-market er en af de vigtige konkurrenceparametre kan en lavere DDP være relevant, mens det for virksomheder der arbejder med såkaldt sikkerhedskritisk software (pharma, flykontrol m.m.) kan det være relevant at have en DDP i den højere ende.
Men man skal jo altid være opmærksom på, hvad omkostningen er ved at stige i DDP - omkostningen ved at stige fra 50% til 51% er nok lavere end hvis det er fra 97% til 98%.
Et andet område der blev diskuteret var metrikker til kodedækning. Overraskende var den mest udbredte instruktionsdækning, og når man tænker på at det jo er det laveste niveau det giver mening af måle på - ja så er det lidt overraskende at de andre ikke rigtig anvendes.
Et andet godt point fra Rick var holdningen til metrikker - opfat alle metrikker som midlertidige - evaluer værdien af disse en gang om året, og fjern og erstat de som ikke giver værdi. På den måde kan det sikres, at vi ikke bare bruger denne eller hint metrik fordi det har vi altid gjort.
Gode tanker og ideer til mit fortsatte arbejde med testmetrikker.
Så er det begyndt - 'Tune In to Innovative Testing' @ STAReast
Så er STAReast 2013 i gang med temaet 'Tune In to Innovative Testing'. Her til formiddag er jeg til en tutorial med Rick Craig om 'Measurement and Metrics for Test Managers'.
søndag den 28. april 2013
STAReast 2013 i Orlando
Så er jeg klar til STAReast 2013 der foregår på Rosen Shingle Creek Hotel & Conference Center i Orlando.
Konferencen foregår hele ugen - fra mandag til fredag - dog er der nogle der allerede er startet i dag søndag - idet der er nogle kursusmuligheder - herunder ISTQB Foundation Certificering, kravspecifikation m.m.
Mandag og tirsdag er der hel- og halvdags tutorials, hvor man kan fordybe sig specifikke emner. Onsdag og torsdag kører der 4-5 spor med forskellige indlæg samt keynotes morgen og sidst eftermiddag. Fredag er der test summit. Undervejs er EXPO-området også åbent med stande fra forskellige leverandører m.m.
Jeg vil i ugens løb opdatere min blog med forskellige indtryk, ideer, inspiration m.m.
Konferencen foregår hele ugen - fra mandag til fredag - dog er der nogle der allerede er startet i dag søndag - idet der er nogle kursusmuligheder - herunder ISTQB Foundation Certificering, kravspecifikation m.m.
Mandag og tirsdag er der hel- og halvdags tutorials, hvor man kan fordybe sig specifikke emner. Onsdag og torsdag kører der 4-5 spor med forskellige indlæg samt keynotes morgen og sidst eftermiddag. Fredag er der test summit. Undervejs er EXPO-området også åbent med stande fra forskellige leverandører m.m.
Jeg vil i ugens løb opdatere min blog med forskellige indtryk, ideer, inspiration m.m.
Abonner på:
Opslag (Atom)