En af de mere spændende - men også ofte svære ting - er målinger af test - inden for testprocesforbedring, rapportering af teststatus og -fremdrift og ikke mindst til brug for estimering af fremtidige testopgaver.
Jeg er ved at gennemgå og studere en masse forhold omkring testmetrikker og skal den 10/3 (København) og 11/3 (Århus) sammen med ATP's testchef Thomas Axen holde foredrag om emnet.
Følg med på denne blog for løbende opdatering af emnet.
mandag den 31. januar 2011
onsdag den 19. januar 2011
5 dage med nye spændende bøger om test
Så har jeg taget mig den frihed at bruge de næste 5 dage på at studere og læse en række nye bøger om test af software, som jeg har anskaffet mig. Det drejer sig i denne omgang om følgende:
- Testing Software and Systems (Proceedings fra ICTSS 2010 konferencen - ICTSS står for International Conference on Testing Software and Systems - og konferencen foregik i Natal i Brasilien i november 2010) og udgivet på Springer.
- Property Testing - Current Research and Surveys, Oded Goldreich (Ed.) og udgivet på Springer.
- The Testing Network - An Integral Approach to Test Activities in Large Software Projects, Pierre Henry. Udgivet på Springer.
- Testen in der Finanzwelt, Norbert Bochynek og Jose Diaz. Udgivet af Diaz Hilterscheid - bemærk venligst at bogen er på tysk inden I eventuelt får den bestilt.
- Becoming Agile in an imperfect world, Greg Smith og Ahmed Sidky. Udgivet af Manning.
- The Tester's Pocketbook. Udgivet af Paul Gerrard og The Tester's Press. Jeg fik den af Paul selv på EuroSTAR 2010 i København (Bella Center).
tirsdag den 18. januar 2011
7 Gode Vaner for Testere
Vane nr. 1 - Vær Proaktiv
En testers mål i et softwareprojekt er at sikre, at softwaren har en så høj kvalitet som muligt. Når projekter kører af sporet på grund af dårlig kvalitet kan man enten være proaktiv eller reaktiv, når årsagen skal findes. Den reaktive tester vil straks give andre personer eller omstændigheder skylden for problemerne. Den proaktive tester vil tage medansvar og forsøge at finde ud af, hvordan samme problemer ikke opstår i fremtiden.
Ved slutningen af et projekt bør testholdet lave en evaluering af projektforløbet. Her bør man både diskutere de ting, der gik godt, men også de ting, der gik mindre godt. Her er en række ideer til, hvordan man som tester kan være proaktiv.
A: Tag ansvar for en god kravspecifikation
Det kan ikke nytte noget at lænse sig tilbage og brokke sig over, at kravspecifikiationerne er for dårligt beskrevet. Tag i stedet og samarbejd med kravspecifikatørerne om at få kravene mere præcise, mere udførligt beskrevet og testbare.
B: Analyser sporbarheden
Lav en matrix for at øge sporbarheden i sammenhængen mellem testcases og krav. Det giver bedre mulighed for at analysere, hvor meget dine testcases dækker, hvor langt du er nået og hvor nem softwaren er at teste. Hold møder med dit team, hvor I gennemgår dine testcases for at sikre at kravene er forstået rigtigt og at testen har den rigtige dækningsgrad. Lad udviklerne læse og give review på dine testcases, før de går i gang med at udvikle. Det giver færre rettelser og der bliver brugt mindre tid på QA i sidste ende.
C: Kommuniker effektivt.
Under testen er det vigtigt, at alle kender status på testarbejdet. Kommuniker dagligt via mail eller online diskussionsfora. Her er det vigtigt at give information i målbare størrelser som eksempelvis antallet af defects, hvor stor dækningsgraden er i forhold til kravspecifikationerne eller hvor mange testcases, der er blevet afviklet.
D: Beskriv fejl udførligt.
Når du har fundet en fejl og skal beskrive den, så gør det grundigt og udførligt. Brug tid på at lave en god beskrivelse- Beskrivelsen skal indeholde de skridt man skal udføre for at reproducere fejlen og screen shots bør også vedlægges som dokumentation.
Vane nr. 2 - Fokuser på slutresultatet
Dit mål i et softwareprojekt bør være at levere software af en høj kvalitet, som samtidig opfylder kundens behov. Før den første kodelinje bliver skrevet, bør projektets succeskriterier være nedfædet. Det kan eksempelvis være at softwaren fungerer efter specifikationerne, eller at der ikke må afleveres et produkt med kente fejl. Det gør det nemmere senere hen at vurdere om projektet har været en succes.
Vane nr. 3 - Start med det vigtigste
Det er vigtigt at prioritere arbejdet efter hvor vigtigt det er. Eksempelvis kan vi sikkert alle blive enige om, at negative tests er vigtige for at sikre, at softwaren kan håndtere utænkte situationer på uden at gå helt i brædderne. Men det er ikke vigtigere end at teste om softwaren er i stand til at udføre den opgave den bliver bygget til. Derfor bør man begynde at teste om softwaren kan det den skal.
Eftefølgende kan man lave de negative test og se om man kan få systemet til at brase sammen. Det kan eksempelvis være test med invalide data eller grænseværdi-tests.
Vane nr. 4 - Se det som et vinderspil
I mange organisationer forsøger testere og udviklere at skubbe aben over til hinanden, når der opstår problemer. Det kan være meget ødelæggende for udviklingsprocessen.
Udviklere og testere bør have samme mål - at sikre at softwaren får en høj kvalitet. Når man har det som fælles mål giver det langt mere mening for alle deltagere at hjælpe hinanden.
Vane nr. 5 - Forstå først og bliv forstået bagefter
Mange har den dårlige vane, at de ikke lytter ordentlig med på diskussionerne, fordi de er så opsatte på selv at få fortalt deres eget syn på sagen. Alle i et projekt deltager med forskellig erfaringsbaggrund og har forskellige perspekiver på processerne.
Før man kan løse et problem er det vigtigt at lytte grundigt til, hvad projektdeltagerene har at sige for at kunne forstå problematikken til bunds. Efter alle har sagt det, de ville er det tid til at opstille flere mulige løsninger på problemet. Flere løsningsmodeller giver mulighed for at diskutere problematikken bedre igennem, og det giver projektdeltagerne mulighed for at komme frem til bedre løsninger, der rækker længere end den første indskydelse.
Hvis man er uenig om løsningen er det vigtigt ikke at virke aggressiv overfor den person, der har stillet løsningsforslaget. Forklar i stedet for, hvorfor du synes løsningen er knap så god.
Vane nr. 6 - Skab synergi
Hold-arbjede er nøglen til at skabe synergi. Et team med synergipotentiale består af forskellige typer, der har forskellige styrker, baggrunde og perspektiver. Sørg for at forskellighederne kommer i spil på bedst mulige måde.
Man er mere effektiv, når man ved, hvad ens teammedlemmer er ved at lave. Derfor er teams mere effektive, når de kommunikerer med hinanden. Det kan eksempelvis være at man deler et fælles dokumentbibliotek, der beskriver best practice indenfor det pågældende arbejdsområde.
Vane nr. 7 - Skærp kniven
Den vane kan beskrives ganske kort. De testere, der vedligeholder og uddyber deres evner er også bedst til at levere det bedste stykke arbejde.
De fokuserer på at gøre deres arbejde bedre og nemmere ved eksempelvis at automatisere testcases og gennemføre best practices.
Det er ikke mig, der har fundet på de syv gode vaner for testere. Det er amerikaneren Steve Miller fra Pragmatic Software. Han er til gengæld blevet inspireret af Stephen R. Covey der i 1989 udgav bogen The Seven Habits of Highly Effective People.
En testers mål i et softwareprojekt er at sikre, at softwaren har en så høj kvalitet som muligt. Når projekter kører af sporet på grund af dårlig kvalitet kan man enten være proaktiv eller reaktiv, når årsagen skal findes. Den reaktive tester vil straks give andre personer eller omstændigheder skylden for problemerne. Den proaktive tester vil tage medansvar og forsøge at finde ud af, hvordan samme problemer ikke opstår i fremtiden.
Ved slutningen af et projekt bør testholdet lave en evaluering af projektforløbet. Her bør man både diskutere de ting, der gik godt, men også de ting, der gik mindre godt. Her er en række ideer til, hvordan man som tester kan være proaktiv.
A: Tag ansvar for en god kravspecifikation
Det kan ikke nytte noget at lænse sig tilbage og brokke sig over, at kravspecifikiationerne er for dårligt beskrevet. Tag i stedet og samarbejd med kravspecifikatørerne om at få kravene mere præcise, mere udførligt beskrevet og testbare.
B: Analyser sporbarheden
Lav en matrix for at øge sporbarheden i sammenhængen mellem testcases og krav. Det giver bedre mulighed for at analysere, hvor meget dine testcases dækker, hvor langt du er nået og hvor nem softwaren er at teste. Hold møder med dit team, hvor I gennemgår dine testcases for at sikre at kravene er forstået rigtigt og at testen har den rigtige dækningsgrad. Lad udviklerne læse og give review på dine testcases, før de går i gang med at udvikle. Det giver færre rettelser og der bliver brugt mindre tid på QA i sidste ende.
C: Kommuniker effektivt.
Under testen er det vigtigt, at alle kender status på testarbejdet. Kommuniker dagligt via mail eller online diskussionsfora. Her er det vigtigt at give information i målbare størrelser som eksempelvis antallet af defects, hvor stor dækningsgraden er i forhold til kravspecifikationerne eller hvor mange testcases, der er blevet afviklet.
D: Beskriv fejl udførligt.
Når du har fundet en fejl og skal beskrive den, så gør det grundigt og udførligt. Brug tid på at lave en god beskrivelse- Beskrivelsen skal indeholde de skridt man skal udføre for at reproducere fejlen og screen shots bør også vedlægges som dokumentation.
Vane nr. 2 - Fokuser på slutresultatet
Dit mål i et softwareprojekt bør være at levere software af en høj kvalitet, som samtidig opfylder kundens behov. Før den første kodelinje bliver skrevet, bør projektets succeskriterier være nedfædet. Det kan eksempelvis være at softwaren fungerer efter specifikationerne, eller at der ikke må afleveres et produkt med kente fejl. Det gør det nemmere senere hen at vurdere om projektet har været en succes.
Vane nr. 3 - Start med det vigtigste
Det er vigtigt at prioritere arbejdet efter hvor vigtigt det er. Eksempelvis kan vi sikkert alle blive enige om, at negative tests er vigtige for at sikre, at softwaren kan håndtere utænkte situationer på uden at gå helt i brædderne. Men det er ikke vigtigere end at teste om softwaren er i stand til at udføre den opgave den bliver bygget til. Derfor bør man begynde at teste om softwaren kan det den skal.
Eftefølgende kan man lave de negative test og se om man kan få systemet til at brase sammen. Det kan eksempelvis være test med invalide data eller grænseværdi-tests.
Vane nr. 4 - Se det som et vinderspil
I mange organisationer forsøger testere og udviklere at skubbe aben over til hinanden, når der opstår problemer. Det kan være meget ødelæggende for udviklingsprocessen.
Udviklere og testere bør have samme mål - at sikre at softwaren får en høj kvalitet. Når man har det som fælles mål giver det langt mere mening for alle deltagere at hjælpe hinanden.
Vane nr. 5 - Forstå først og bliv forstået bagefter
Mange har den dårlige vane, at de ikke lytter ordentlig med på diskussionerne, fordi de er så opsatte på selv at få fortalt deres eget syn på sagen. Alle i et projekt deltager med forskellig erfaringsbaggrund og har forskellige perspekiver på processerne.
Før man kan løse et problem er det vigtigt at lytte grundigt til, hvad projektdeltagerene har at sige for at kunne forstå problematikken til bunds. Efter alle har sagt det, de ville er det tid til at opstille flere mulige løsninger på problemet. Flere løsningsmodeller giver mulighed for at diskutere problematikken bedre igennem, og det giver projektdeltagerne mulighed for at komme frem til bedre løsninger, der rækker længere end den første indskydelse.
Hvis man er uenig om løsningen er det vigtigt ikke at virke aggressiv overfor den person, der har stillet løsningsforslaget. Forklar i stedet for, hvorfor du synes løsningen er knap så god.
Vane nr. 6 - Skab synergi
Hold-arbjede er nøglen til at skabe synergi. Et team med synergipotentiale består af forskellige typer, der har forskellige styrker, baggrunde og perspektiver. Sørg for at forskellighederne kommer i spil på bedst mulige måde.
Man er mere effektiv, når man ved, hvad ens teammedlemmer er ved at lave. Derfor er teams mere effektive, når de kommunikerer med hinanden. Det kan eksempelvis være at man deler et fælles dokumentbibliotek, der beskriver best practice indenfor det pågældende arbejdsområde.
Vane nr. 7 - Skærp kniven
Den vane kan beskrives ganske kort. De testere, der vedligeholder og uddyber deres evner er også bedst til at levere det bedste stykke arbejde.
De fokuserer på at gøre deres arbejde bedre og nemmere ved eksempelvis at automatisere testcases og gennemføre best practices.
Det er ikke mig, der har fundet på de syv gode vaner for testere. Det er amerikaneren Steve Miller fra Pragmatic Software. Han er til gengæld blevet inspireret af Stephen R. Covey der i 1989 udgav bogen The Seven Habits of Highly Effective People.
World Quality Report - Sogeti
Før i tiden var en tester typisk en tidligere udvikler, som havde skiftet en karriere med mere fokus på test og kvalitetssikring. I dag efterspørges testere, der kan mere end bare have erfaring med udvikling af software.
Det skyldes ikke mindst den stigende integration mellem IT og virksomhedens forretningsmæssige mål. Derfor efterspørger virksomheder i dag testere, der både har stærke tekniske færdigheder samtidig med at de besidder relevant forretnings og domæneviden.
Det kan man læse i 2010 World Quality Report, der er udarbejdet af Sogeti og HP i fællesskab.
Rapporten tager udgangspunkt i et spørgeskema, der er sendt til over 30.000 direktører, IT direktører, QA managers og ingeniører i forskellige virksomheder verden over.
Her er ønskelisten
Af svarene i rapporten fremgår følgende:
31 procent af virksomhederne ønsker deres testressourcer besidder evner inden for QA.
22 procent ønsker at deres testere har domæneviden.
14 procent ser gerne, at testerne har databasefærdigheder.
10 procent vil gerne have testere, der kan et eller flere script-sprog som Perl, Python m.fl.
9 procent efterspørger testere der mestrer et programmeringssprog som eksempelvis Java og C++
Længere nede på listen kommer evner inden for it-sikkerhed, mainframe og netværk.
Et våben i kampen mod stigende kompleksitet
Ifølge rapporten skal fremtidens tester favne både forretningsviden og have tekniske evner. QA er på vej til at blive en mere professionel karrierevej, hvor virksomheder forventer at have en mindre men mere kvalificeret og højt udviklet gruppe af medarbejdere der har en tilbundsgående forretningsviden.
I takt med at kompleksiteten i software øges, vil time-to-market udfordringerne kræve, at testere har domæneviden, viden om softwaren og den anvendte teknologi for hurtigt at kunne dissekere fundne fejl og hurtigt give viden videre til virksomhedens udviklere.
Hele rapporten kan hentes her
Det skyldes ikke mindst den stigende integration mellem IT og virksomhedens forretningsmæssige mål. Derfor efterspørger virksomheder i dag testere, der både har stærke tekniske færdigheder samtidig med at de besidder relevant forretnings og domæneviden.
Det kan man læse i 2010 World Quality Report, der er udarbejdet af Sogeti og HP i fællesskab.
Rapporten tager udgangspunkt i et spørgeskema, der er sendt til over 30.000 direktører, IT direktører, QA managers og ingeniører i forskellige virksomheder verden over.
Her er ønskelisten
Af svarene i rapporten fremgår følgende:
31 procent af virksomhederne ønsker deres testressourcer besidder evner inden for QA.
22 procent ønsker at deres testere har domæneviden.
14 procent ser gerne, at testerne har databasefærdigheder.
10 procent vil gerne have testere, der kan et eller flere script-sprog som Perl, Python m.fl.
9 procent efterspørger testere der mestrer et programmeringssprog som eksempelvis Java og C++
Længere nede på listen kommer evner inden for it-sikkerhed, mainframe og netværk.
Et våben i kampen mod stigende kompleksitet
Ifølge rapporten skal fremtidens tester favne både forretningsviden og have tekniske evner. QA er på vej til at blive en mere professionel karrierevej, hvor virksomheder forventer at have en mindre men mere kvalificeret og højt udviklet gruppe af medarbejdere der har en tilbundsgående forretningsviden.
I takt med at kompleksiteten i software øges, vil time-to-market udfordringerne kræve, at testere har domæneviden, viden om softwaren og den anvendte teknologi for hurtigt at kunne dissekere fundne fejl og hurtigt give viden videre til virksomhedens udviklere.
Hele rapporten kan hentes her
ISTQB Certified Tester
Gennem de sidste mange år er softwaretest skiftet fra at være en disciplin som 'alle kan' til en disciplin som er 'anerkendt og accepteret'. En vigtig del af vejen er uddannelse af de udførende testere - herunder certificering. I dag er det mest anvendte rammeværk til certificering ISTQB (International Software Testing Qualifications Board), som har forskellige niveauer - Foundation, Advanced og Expert.
Foundation henviser jeg til:
http://www.mannaz.com/da/kursusbeskrivelser/15852.htm
Advanced henviser jeg til:
http://www.mannaz.com/da/kursusbeskrivelser/21083.htm
Foundation henviser jeg til:
http://www.mannaz.com/da/kursusbeskrivelser/15852.htm
Advanced henviser jeg til:
http://www.mannaz.com/da/kursusbeskrivelser/21083.htm
Test Process Improvement - Improved
De sidste mange år har jeg arbejdet meget med procesforbedring - jeg kan stærkt anbefale at kigge på www.tpinext.com som en model til dette arbejde.
Eksempel i DK........problemer i offentllig IT
IT-fejl giver for stor børnecheck
18. jan. 2011 14.00 Penge Omkring 50.000 af landets børnefamilier vil inden længe få udbetalt et for højt beløb i børne- og ungeydelse.De kan samtidig se frem til et brev fra Skat, der opfordrer til at lægge penge til side.
For det overskydende beløb vil blive modregnet med lavere satser de kommende tre kvartaler.
Smutter hos IT-leverandør
Problemet skyldes ifølge Skat en it-brist, idet selskabet KMD ikke har kunnet nå at lave de nødvendige ændringer i it-systemerne. Derfor kan systemerne ikke tage højde for nye regler, der sætter et loft over, hvor meget man kan få på denne ydelse.
Alle familier, som i januar får udbetalt mere end 8750 kroner, har fået mere udbetalt, end de er berettiget til. De penge vil Skat hente ind i årets sidste tre kvartaler.
En familie kan i værste fald skulle lægge 3000 kroner til side til senere.
Skat beklager
- Set hen over hele året får det her ingen økonomiske konsekvenser for familierne, men ikke desto mindre er vi rigtig kede af it-fejlen, siger koncerndirektør i Skatteministeriet Jesper Skovhus Poulsen til Ritzau.
Kun modtagere med mindst tre børn vil blive omfattet af loftet over ydelsen.
- Det er utrolig uheldigt og alt andet end tilfredsstillende. Ny lovgivning kan i forvejen skabe uklarhed, og når der så er fejl i udbetalingerne, er vi med til at mudre billedet for borgerne. Det er ganske enkelt ikke godt nok, og det taler vi med KMD om, siger Jesper Skovhus Poulsen.
søndag den 16. januar 2011
Ny spændende bog - til ISTQB Advanced Test Management
Jeg kan specielt godt lide bogens struktur, dets fokus og ikke mindst anvendeligheden som opslagsværk.
Abonner på:
Opslag (Atom)