Innehåll

• Certifiering steg för steg
1. Certifieringskrav
2. Studera
3. Boka examen
4. Ta examen
5. Underhåll certifieringen
• Advanced Level Syllabus - Test Manager
1. Testprocessen
2. Testledning
3. Granskningar
4. Defekthantering
5. Förbättra testprocessen
6. Testverktyg och -automatisering
7. Testkunskaper och lagarbete
• Expert Level Syllabus - Test Manager
1. Förbättra testprocessen
2. Modellbaserade förbättringar
3. Analysbaserade förbättringar
4. Välja rätt ansats för testförbättringar
5. Genomföra testförbättringar
6. Organisation, roller och färdigheter
7. Hantera förändring
8. Kritiska framgångsfaktorer
9. Anpassning till olika livscykelmodeller
• The Expert Test Manager
• Quality Center / ALM
1. Översikt
2. Förbered ALM
3. Arbeta i ALM
4. Exportera testfall från QC till Excel
5. Mejl från QC
6. ALM Site Administrator
7. Tips om ALM
• The Quality Dilemma
1. The Quality Concept
2. The Requirements
3. Quality vs Time and Cost
4. The Quality Dilemma
5. The Ten Tester Commandments
• Kvalitet i agila projekt
• Learning by Gaming
• Testing Methodology Applied to Games
1. The Test Process
2. Planning and Control
3. Analysis
4. Design
5. Implementation
6. Execution
7. Evaluation and Closure
• Testification - Learn Testing through Gamification (Abstract)
• Testification - Learn Testing through Gamification (Full text)
1. Know Thyself
2. Don't Learn how to Do, Learn how to Think
3. Encourage Creative Thinking
4. Represent Test through Games
5. Find the Bug!
6. Find the Bug! Agile
7. Learn the Experience of a Tester
8. Plan with the End in Mind
9. Analyze with a Quality Mindset
10. Test the Right Things and Test Things Right
11. Execute as Planned and Replan Execution
12. Close when Everything is Properly Packed
13. Conclusion

Nytt år och ny certifiering. I fjol certifierade jag mig inom PMP och i år tänkte jag ge mig på ISTQB Expert Level Test Manager.

ISTQB står för International Software Testing Qualifications Board, en ideell organisation som syftar till att definiera och samla kunskap om test, certifiera testare baserat på best practices, knyta samman testare världen över samt uppmuntra forskning och utveckling. ISTQB är en välkänd organisation och en certifiering på CV:t närmast ett måste för den som vill göra karriär inom test.

Det bör påpekas att test är ett svagt definierat område med få etablerade standarder och att du inte bara kan ta med dig din verktygslåda till en ny kund och börja testa. Det hjälper inte att vara expert på ett område om du inte kan förstå och göra dig förstådd i resten av projektet. Som konsult har jag behövt lära mig varje ny kunds syn på test och "översätta" deras vokabulär till min egen för att kunna prestera. Lyhördhet, tydlighet och pragmatism är tre nyckelord för att lyckas.

Därmed inte sagt att en certifiering är meningslös. Tvärtom ger den dig många nya insikter och idéer som, om du lyckas integrera dem i ditt testarbete, gör dig till en ännu bättre testare. Precis som jag gjorde när jag studerade till PMP ämnar jag därför knyta samman teori och praktik och relatera det jag lär mig till det jag gör (eller borde ha gjort). Men låt oss börja från början.

Certifiering steg för steg

Certifieringskrav

För en certifiering som ISTQB Expert Level Test Manager krävs följande:

• ISTQB Foundations-certifiering
• ISTQB Advanced-certifiering (test manager)
• Minst 75% rätt på examen
• 5 års erfarenhet av test (kan tas efter examen)
• 2 års erfarenhet av testledning (kan tas efter examen)
• Minst en publikation eller en presentation på en testkonferens om testledning (kan tas efter examen)

Se ISTQB:s hemsida för detaljer.

Studera

För att studera till examen rekommenderas följande böcker. De uppdateras regelbundet så var noga med att studera de allra senaste utgåvorna.

• Expert Level Syllabus - Test Management: ISTQB:s officiella kvalificeringskrav för certifieringen, en detaljerad sammanställning men utan verklighetsnära exempel
• Advanced Level Syllabus - Test Manager: Kvalificeringskrav för nivån under Expert (särskilt kapitel 8 om standarder och testförbättringar)
• Foundation Level Syllabus: Kvalificeringskrav för nivån under Advanced
• The Expert Test Manager av Rex Black och Debra Friedenberg: En av (än så länge) få böcker om expertnivån med 500 sidor teori, övningar och exempelfrågor

Det är dessa böcker som jag nedan kommer att sammanfatta och reflektera över.

Boka examen

Examen kan bokas antingen hos SSTB eller hos någon som erbjuder kursen. (Examen kan tas i samband med kurs eller med enbart självstudier.)

Ta examen

Examen består av två delar:

• En flervalssektion om 20 frågor. Skrivtiden är en timme. Denna del mäter de så kallade K-nivåerna 1-4 (komma ihåg, förstå, praktisera och analysera).
• En essädel om 5 frågor, varav 4 väljs. Du får läsa en fallbeskrivning i 30 minuter och sedan skriva essäer i 2 timmar. Denna del mäter de så kallade K-nivåerna 5-6 (utvärdera och skapa)

Underhåll certifieringen

Certifieringen gäller i fem år. Efter denna tid måste du antingen ta en ny examen eller uppnå minst 200 så kallade CEC (Certification Extension Credits). CEC kan erhållas lite som PMI-certifieringens PDU, alltså genom att arbeta som testledare, delta i testkurser eller själv hålla i testkurser. Bevis på CEC måste skickas till The Certification Extension Program hos ISTQB men i skrivande stund är denna process inte fastställd ännu.

Advanced Level Syllabus - Test Manager

Låt oss börja med att repetera Advanced Level Syllabus - Test Manager. Observera att det finns tre spår på Advanced-nivån och att Test Manager har en egen Syllabus fr o m 2012. Tidigare (2007) fanns det bara en Syllabus där de tre spåren omfattade olika kapitel. Om du, liksom jag, studerade den gamla versionen när du tog Advanced-certifieringen så bör du läsa igenom den nya versionen till din Expert-certfiering.

1. Testprocessen

Advanced Level Syllabus börjar med en översikt över de grundläggande testaktiviteterna:

• Planering och kontroll:
• Planering
• Identifiera aktiviteter och resurser för att nå teststrategins mål
• Identifiera metoder för att samla in mätetal
• Bestäm testansats, testnivåer och testtekniker
• Förstå relation mellan testbas (krav), testvillkor och testfall
• Bestäm vad som ingår och inte ingår i testscope
• Specificera testmiljö och identifiera resursbehov/-begränsningar
• Identifiera externa beroenden
• Kontroll
• Ta fram testschema med milstolpar att mäta mot
• Anpassa rapportering av mätetal till intressenters behov
• Jämför utfall mot plan och agera vid behov
• Analys: Definiera vad som ska testas (testvillkor)
• Basera på testbas, testmål eller produktrisk
• Spåra bakåt till testbas och framåt till testfall
• Bestäm detaljnivå baserat på testnivå, systemkomplexitet, verktyg etc.
• Balansera nytta mot tidsåtgång
• Design: Definiera hur du ska testa (testfall)
• Implementering: Organisera och prioritera tester
• Definiera testfall (indata och förväntat resultat) och testprocesser (teststeg)
• Verifiera testförutsättningar (miljö, data, inträdeskriterier etc.)
• Identifiera beroenden och ta fram schema för testexekvering
• Exekvering:
• Testare utför tester enligt testfall (samt ev. fria tester)
• Testledare vägleder testare och följer upp utförandet
• Utvärdering och rapportering: Säkra effektiva processer för insamling och rapportering av information
• Avslut:
• Kontrollera att alla testaktiviteter är klara
• Överlämna testmaterial (defektlistor, testmiljöer, testfall etc.)
• Håll utvärderingsmöten och identifiera förbättringsmöjligheter
• Arkivera resultat, planer och rapporter

Det här kapitlet utvecklar testaktiviteterna från Foundation-nivån såtillvida att Analys och Design har blivit två separata aktiviteter och så också Implementering och Exekvering. Innehållet i aktiviteterna är dock vanligt förekommande på alla testprojekt. Jag har inte lett något testprojekt där jag INTE utfört allt detta så kapitlet är bra som en checklista inför ett nytt testprojekt. Den viktigaste aktiviteten för en testledare är planeringen, som lägger grunden för framgångsrika tester, och den får därför en egen del i kapitel 2.

2. Testledning

2.2 Testsammanhang

Kapitel två inleds med en översikt över det sammanhang som en testledare verkar i:

• Intressenter: Utvecklare (rättar defekter), chefer (ställer krav), projektledare (styr resurser), support (beroende av kvalitet), användare (beroende av system) etc.
• Projekt: Krav (styr testfall), projektledning (styr resurser), konfiguration och utveckling (styr tidplan), support (påverkas av defekter) etc.
• Metodik: Sekventiell (test av helhet), inkrementell (test av iterationer), agil (test parallellt med utveckling), spiral (test av prototyper) etc.

Sammanhanget styr också behovet av testnivåer, såsom de vanliga enhets-, integrations-, system- och acceptanstesterna men också tester av hårdvara, interaktion mellan funktioner och integration med kundprodukter. För varje testnivå bör följande definieras:

• Testmål (hur definieras framgång?)
• Testinnehåll (vad ska testas?)
• Testbas (vad ska testerna mätas mot?)
• In- och utträdeskriterier (när börjar och slutar test?)
• Testleverabler (vilka rapporter och andra dokument ska produceras?)
• Testtekniker (hur ska testerna utföras?)
• Mätetal (hur ska testtäckning och -framgång mätas?)
• Testverktyg (vilka verktyg ska användas och hur?)
• Resurser (vilka resurser ska användas, både testare och testmiljö?)
• Ansvariga (inom och utom testteamet)
• Uppfyllande av krav och regler (inom och utom projektet)

Översikten avslutas med en diskussion kring alternativa tester:

• Icke-funktionella tester: Kostnader behöver vägas mot nytta
• Erfarenhetsbaserade ("fria") tester: Behöver kontrolleras så att täckning och repeterbarhet säkras, t ex särskilda sessioner med uppföljning

Kapitlet fångar det som är både utmanande och stimulerande med att vara testledare: att få arbeta i ett omfattande kontaktnät med många beroenden. Listorna ovan kan med fördel användas som checklistor för de saker som du som testledare bör förstå så tidigt som möjligt i ditt projekt. Om något skulle saknas är det än viktigare att du förstår vilka konsekvenser det får. Jag har t ex jobbat med tester där en tydlig testbas saknas. Det är då viktigt att engagera såväl utvecklare (för att förstå systemet och bygga testfall därefter) som användare (för att förstå förväntningar och bygga förväntade utfall därefter).

2.3 Riskbaserade tester

Nästa del av kapitlet diskuterar utmaningen i att prioritera tester. En ansats är riskbaserade tester, som fokuserar på produktrisker (snarare än projektrisker) genom följande aktiviteter:

• Riskidentifiering: Intervjuer, workshops, checklistor etc.
• Riskutvärdering:
• Sannolikhet för risk: Teknisk komplexitet, resursbegränsningar, ny lösning etc.
• Påverkan av risk: Affärsmässiga förluster, lagliga sanktioner, säkerhet etc.
• Riskmitigering: Ju högre risk, desto noggrannare test, kravgranskning etc.
• Riskhantering: Risker hanteras genom hela projektcykeln

Till de informella riskbaserade testerna hör utforskande tester, där testaren analyserar risker. Dessa riskerar dock att fokusera mer på sannolikhet än påverkan och på testarens kunskap snarare än övriga intressenters. Bättre är då de så kallade lättviktstekniker som kombinerar informella fördelar (flexibilitet) med formella fördelar (konsensus). Till dessa hör PRAM (Pragmatic Risk Analysis and Management), SST (Systematic Software Testing (SST) och PRisMa (Product Risk Management) med följande typiska egenskaper:

• Baserade på branscherfarenhet
• Involverar intressenter både från verksamhet och teknik
• Introducerade tidigt i projektet
• Riskanalys grund för testplan och testvillkor
• Använder endast sannolikhet och påverkan samt kvalitativa bedömningar

Till så kallade tungviktstekniker hör följande:

• "Hazard analysis": Identifierar underliggande orsaker till risker
• "Cost of exposure": Baserar riskutvärdering på sannolikhet, kostnad vid fel och kostnad för test
• "Failure Mode and Effect Analysis" (FMEA): Identifierar risker, orsaker och effekter
• "Quality Function Deployment" (QFD): Fokuserar på brister i förståelse för kundens krav
• "Fault Tree Analysis" (FTA): Analyserar grundorsaken till upptäckta eller tänkbara defekter

Riskbaserade testers framgång baseras på följande:

• Fler viktiga än oviktiga defekter hittade
• De flesta av de viktiga defekterna hittade tidigt
• Testresultat förklarade för intressenter i termer av risk
• Bortprioriterade tester kopplade till lägre risk än utförda tester

Utöver risk finns det andra kriterier för prioritering av tester:

• Kravbaserade tester:
• Granska och eliminera tvetydigheter
• Bryta ned krav i testvillkor
• Orsak-verkan-grafer för att täcka kombinationer av testvillkor
• Användarprofiler med blandning av användarfall, användare, input och output
• Checklistor för vad som ska testas och i vilken ordning
• Reaktiv testning där prioritering görs dynamiskt under test

Jag ska erkänna att jag är lite tveksam till riskbaserade tester. Konceptet låter bra men min erfarenhet är att kravbaserade tester med väl formulerade och prioriterade krav gör riskbaserade tester överflödiga. Om det finns risker som INTE är täckta av kraven så är det väl kraven det är fel på?

Däremot tror jag att själva risktänkandet är viktigt att ta med sig in i varje nytt projekt. Vilka risker står kunden inför? Den frågan kan enkla modeller som Porter's femkraftsmodell svara på. Vilka av dessa risker syftar det nya systemet till att bemöta? Svaren på den frågan underlättar kontakterna med intressenterna. Hur väl täcker systemkraven systemets syfte? Ta med dig den frågan till din kravgranskning. Du kommer att finna att testarbetet sedan inte bara blir lättare utan också roligare då du förstår mer om det sammanhang du tester i.

2.4 Testleverabler

ISTQB definierar sex huvudsakliga testdokument:

• Testpolicy: Organisationens mål för test, inklusive testprocess och testförbättringar
• Teststrategi: Organisationens metoder för test
• Analytisk: T ex riskbaserade tester
• Modellbaserad: T ex operationell profilering (modell av verkligheten)
• Metodisk: T ex egenskapsbaserade tester (förutbestsämda testvillkor, checklistor etc.)
• Process: T ex tester enligt regelverk
• Reaktiv: T ex utforskande tester där tester designas under exekvering
• Konsultativ: T ex användarstyrda tester där intressenter tillhandahåller testvillkor
• Regressionsundvikande: T ex automatiserade tester
• Projekttestplan: Implementering av teststrategi för ett specifikt projekt
• Testinnehåll (vad ska testas och inte testas)
• Testschema (tid och resurser)
• Testcykler (relaterade till systemleveranser)
• Leverabler (relaterade till andra delar av projektet)
• In- och utträdeskriterier
• Risker
• Styrning
• Ansvar
• In- och utdata för varje testnivå
• Nivåtestplan: Testaktiviteter för en specifik testnivå (systemtest etc.)
• Riskhantering: Hantering av testspecifika risker som tillgång till miljö, testare och metoder
• Mitigering: Minskar sannolikhet för risk
• Beredskap ("contingency"): Minskar påverkan av risk
• Transferering: Överföring av risk till någon annan
• Acceptering: Hantering av konsekvenser
• Övrigt: Testfall etc. som skapas av testanalytiker men kontrolleras av testledaren
• Etablera mätetal för att kontrollera kvalitet
• Arbeta med testanalytiker för att välja lämpliga mallar
• Arbeta med testanalytiker för att etablera standarder
• Granska testprodukter tillsammans med intressenter

För certifieringsexamen är det viktigt att kunna skilja på ovanstående dokument. I verkligheten är det dock viktigare att förstå vilka dokument och vilket innehåll som förväntas. Konsultbolag har ofta egna mallar att utgå från men inte ens mina kolleger känner igen dem utan har egna uppfattningar om hur de bör se ut och det gäller förstås i än högre grad kunden. Därmed inte sagt att man ska ignorera egna mallar utan använd dem som checklista och förbättra de föreslagna mallarna vid behov. Det finns ingen mall som täcker alla tänkbara behov så egna initiativ är alltid uppskattade.

2.5-2.6 Estimering och mätetal

Estimering är svårt och det gäller inte minst test med alla dess beroenden:

• Önskad kvalitetsnivå på systemet
• Storlek på systemet
• Statistik från tidigare tester
• Processfaktorer som teststrategi, testmognad etc.
• Materiella faktorer som testverktyg, testmiljö etc.
• Mänskliga faktorer som ledarskap, erfarenhet etc.
• Komplexitet i processer, teknik, organisation etc.
• Uppstarts- och träningsbehov
• Utveckling av nya tekniker och verktyg
• Krav på detaljerad testspecifikation
• Känslig testdata (t ex tidskänslig)

Metoder för estimering inkluderar intuition, nedbrytning (WBS), standarder, historik och relationer till andra nyckeltal (projekttid, antal utvecklare etc.).

Vad gäller mätning av test så anger ISTQB fyra kategorier:

• Projekt: Utfall mot projektets utträdeskriterier
• Produkt: Testtäckning, defektdensitet etc.
• Process: Andel defekter upptäckta under test etc.
• Människor: Färdigställande av testfall etc.

För testledaren gäller det att definiera, fånga upp, validera och rapportera mätetal på ett sätt som är effektivt och rättvisande. Förutom rapportering så används mätetalen också till analys av trender och kontroll av korrigeringar.

Mätetalen kan spegla fem huvudsakliga dimensioner:

• Produktrisk: Andel risker täckta av godkända test etc.
• Defekter: Antal funna och rättade defekter etc.
• Test: Godkända och underkända testfall etc.
• Täckning: Andel av testfall täckta krav, risker etc.
• Förtroende: Mäts genom enkäter eller subjektiva bedömningar

I tillägg till dessa kan mätetal också knytas till testaktivitet, t ex mått av kravtäckning under testplanering antal testvillkor identifierade under testanalys.

Att estimera test motsätter lite syftet med test. I den perfekta av världar ska ju test utföras till kvalitetskraven uppnås, inte tills tiden tar slut. Men världen är ju som sagt inte perfekt och tid är ofta en orubblig begränsning. I mina estimeringar försöker jag utgå från systemets komplexitet, bryta ned det i testbara delar och väga in komplexitet. Här är dialogen med utvecklarna oerhört viktig då de inledningsvis vet mest om systemet. Därefter kan övriga "mjuka" faktorer på ISTQB:s lista vägas in. För att lyckas med detta är förväntningar oerhört viktiga, både dina (t ex på resurser och testmiljö) och andras (t ex krav på testdokumentation och stöd i andra delar av projektet). Se till att få dessa dokumenterade och godkända! Det svåraste att estimera, och som av någon anledning inte nämns av ISTQB, är kvaliteten på det som ska testas. Det hjälper inte hur bra testerna är planerade om de blockeras gång på gång p g a dålig kvalitet. Tyvärr är kvaliteten svår att estimera så räkna med att behöva testa i minst tre rundor (med en rejäl ledtid för initiala problem innan testerna kommer igång ordentligt) och lär av erfarenheterna till nästa testcykel.

Vad mätetal beträffar så är det viktigt att också förväntningarna på dessa klargörs. Om inga förväntningar finns (vilket är så vanligt att jag ofta undrar om någon läser min testrapport) så välj ut några som ger dig som testledare en bra bild av testerna. Se senare beskrivning av testverktyg för mina favoritmätetal och hur jag fångar dem under test. Mätetalens syfte är trots allt inte att göra snygga grafer efter testerna utan att analysera och reagera på under testerna.

2.7-2.9 Värde av test

De sista delkapitlen i kapitel 2 diskuterar värdet av test, såväl det kvantitativa (hitta eller åtminstone identifiera defekter före driftsättning) som det kvalitativa (förbättrat rykte, minskade risker etc.). Ett begrepp i sammanhanget är kvalitetskostnad:

• Kostnad för förebyggande: Träning av utvecklare etc.
• Kostnad för upptäckande: Tid för kravgranskning, testfallsskrivande etc.
• Kostnad för internt misslyckande: Defekträttning etc. före driftsättning
• Kostnad för externt misslyckande: Supportkostnad etc. efter driftsättning

Om kostnaden för externt misslyckande är högre än de för upptäckande och internt misslyckande (typiska testkostnader) så kan test påvisas vara lönsamt.

Delkapitlen fortsätter med att diskutera distribuerade tester (test av anställda på olika platser), utlokaliserade tester (test av utomstående på olika platser) och inlokaliserade tester (test av utomstående på samma plats som projektet). För att lyckas med dylika tester krävs väldefinierad kommunikation, samordning av metodologi, tydliga förväntningar samt ömsesidigt förtroende.

Delkapitlen avslutas med en översikt över standarder som en testledare bör känna till:

• Internationella: ISO (International Organization for Standardization), IEEE (Institute of Electrical and Electronics Engineers) etc.
• Nationella: BS 7925-2 (brittisk standard för systemutveckling)
• Domänspecifika: DO-178B/ED 12B (USA:s respektive EU:s standarder för mjukvara i flygindustrin)

Test kan också påverkas av standarder inom mjukvarutveckling (t ex CMMI:s processområden verifiering och validering) eller projektledning (t ex PMI, PMBOK och PRINCE2).

3. Granskningar

Kapitel tre tar upp granskningar, en typ av statisk test i syfte att eliminera fel innan de implementeras och når de dynamiska testerna.

• Informella granskningar
• Genomgångar
• Tekniska granskningar
• Inspektioner
• Ledningsgranskningar (uppföljning mot plan)
• Revisioner (granskning av regeluppfyllande)

Granskningar utförs lämpligen i samband med milstenar, t ex färdigställande av krav. Planeringen bör omfatta vad som ska granskas, av vem samt vilka risker som ska täckas. Insatsen för granskningar kan vägas mot kostnaden för att avstå (se kvalitetskostnad ovan). Mätetal kan användas för att utvärdera det granskade objektets kvalitet samt kostnader och fördelar med granskningen. För mer formella granskningar används definierade in- och utträdeskriterier, checklistor, överenskomna leverabler samt mätetal - som den typiska testprocessen alltså.

Jag håller inte riktigt med om att granskningar ska utföras i samband med milstenar eftersom felen då hittas försent. Som testare vill jag inte vänta ytterligare på kraven tills granskningarna genomförts. Bättre då att bygga in löpande granskningar allt eftersom kraven fastställts. Vad formella granskningar beträffar så har alla jag varit med om slutat på samma sätt - jag presenterar hur mina tester dokumentation och hör sedan aldrig av granskarna igen. Förhoppningsvis betyder det att de varit nöjda men det vore trevligt att få återkoppling och använda granskningsresultaten så som de är tänkta att användas - till förbättringar.

4. Defekthantering

Kapitel fyra diskuterar hanteringen av avvikelser, när de väl upptäckts. En skillnad görs mellan "falsk-positiva" felrapporter (som visar sig inte vara defekter) och "falsk-negativa" (defekter som aldrig blir felrapporterade). De förra påverkar testeffektiviteten medan de senare påverkar upptäcktseffektiviteten och försök att minska den ena ökar i regel den andra.

• Initialt: Testare samlar in information om avvikelsen för rapportering
• Återlämnande: Testare ombeds lämna mer information om avvikelsen
• Bekräftelse: Testare ombeds testa om avvikelsen

En defektrapport bör ge information för hantering av defekten, utvärdering av projektstatus (produktkvalitet, testpåverkan etc.) samt utvärdering av processförmåga (förmåga att förbättra test- och rättningsprocess etc.)

• Upptäckare och roll (testare, utvecklare etc.)
• Ägare
• Projekt och produkt
• Testtyp (systemtest, prestandatest, regressionstest etc.)
• Beskrivning av defekt (sammanfattande och detaljerad)
• Steg för att återskapa defekten
• Den livscykel som defekten introducerats, upptäckts och åtgärdats i
• Den leverabel eller komponent som felet introducerats i (för orsaksanalys)
• Allvarlighetsgrad (teknisk påverkan) och prioritet (affärspåverkan)
• Identifieringsmetod (granskning, dynamisk test, drift etc.)
• Påverkan på kvalitetsegenskaper och intressenter
• Testmiljö
• Slutsats (beslut om rättning, alternativkostnad för att avstå etc.)
• Beskrivning av lösning
• Historik för defektens hantering i defektcykeln

Informationen i defektrapporterna kan användas för att förbättra testprocessen enligt följande:

• Introduktion för att effektivisera upptäckt och rättning i varje fas
• Introduktion för riktade åtgärder mot de mest defekttäta områdena
• Orsaksanalys för att förbättra processer
• Introduktion för att göra kvalitetsanalyser
• Defektanalys för att förstå tekniska risker (som grund för riskbaserade tester)

En bra defektprocess kräver såväl ett bra testverktyg (t ex ALM) som välinformerade användare (såväl testare som tekniker). SISU ("skit in skit ut") gäller i högsta grad defektstatistik så fundera före testerna vilken statistik du vill ha och skapa defektparametrarna därefter. Gör också en avvägning mellan de olika parametrarna och välj ut de viktigaste. Det är bättre att du får några väl ifyllda mätetal än många slarviga. Lyckas du med detta kan du få ut mer av defektprocessen än att "bara" rätta defekter.

5. Förbättra testprocessen

Mycket i det här kapitlet gås igenom i detalj i Expert Syllabus. Nivåmodeller som TMMi (Test Maturity Model Integration) och TPI Next jämförs med kontinuerliga modeller som STEP (Systematic Test and Evaluation Process) och CTP (Critical Testing Processes) De förra är processreferensmodeller, som inkluderar mognadsutvärderingar, medan de senare är innehållsreferensmodeller, som fokuserar på affärsdrivna utvärderingar.

• TMMi: 5 mognadsnivåer (Initial, Styrd, Definierad, Mätt, Optimerad)
• TPI Next: 4 mognadsnivåer (Initial, Kontrollerad, Effektiv, Optimerande
• CTP: 12 kritiska testprocesser som prioriteras enligt organisationens utmaningar
• STEP: Kravbaserade tester som inleds i början av projektcykeln och utförs med utvecklarna

Förbättringar grundar sig på Demings planeringscykel Planera-Gör-Kontrollera-Agera (Plan-Do-Check-Act). Mer specificerad är IDEAL-modellens cykel Initiera-Diagnosticera- Etablera-Agera-Lär.

Jag brukar inta en avslappnad attityd till metoder eftersom de är lite grann som trafikregler, det hjälper inte att du följer dem om ingen annan gör det. I stället använder jag dem som checklistor och inspirationskällor. Se till att du känner till begreppen, både till examen och i diskussioner med andra testledare, men låt dem inte fördunkla ditt eget omdöme. Dock har jag nyligen blivit medlem 1847 i TMMi Foundation så kanske ändrar jag uppfattning inom kort...

6. Testverktyg och -automatisering

Till testledarens uppgifter hör att välja ut testverktyg.

Precis som alla investeringar bör val av testverktyg baserat på en avkastningsanalys (ROI):

• Engångskostnader (inköp, integrering etc.)
• Återkommande kostnader (licens, underhåll etc.)
• Alternativkostnader (resurser som tas från test)
• Risker (organisationens mognad etc.)
• Fördelar (minskad exekveringstid, nya testområden som prestandatest etc.)

För valet bör testledaren beakta följande egenskaper:

• Analys: Kan verktyget användas enligt syftet?
• Design: Kan verktyget skapa testfall och testdata automatiskt?
• Data- och testval: Hur väljer verktyget testfall och testdata att köra?
• Exekvering: Kan verktyget köra testfall helt eller delvis automatiserat?
• Utvärdering: Hur utvärderar och rapporterar verktyget utfallet?

Vidare måste testledaren hantera alla faser i verktygets livscykel, d v s införskaffande, underhåll, vidareutveckling och utfasning. Avslutningsvis ska testledaren naturligtvis se till att verktyget utnyttjas fullt ut, inte minst vad gäller de mätetal som verktyget kan fånga upp.

Det här kapitlet är nog mer relevant för permanenta testledare än för konsulter som jag. De flesta organisationer man kommer till som konsult har redan ett testverktyg (företrädesvis ALM) som man får förhålla sig till. Det viktiga är då inte att välja utan att anpassa det som finns. Se till (kräv!) att få administratörsrättigheter och våga föreslå arbetssätt som utnyttjar verktyget till fullo.

7. Testkunskaper och lagarbete

Det avslutande kapitlet tar upp testledarens medarbete - testarna. Följande färdigheter bör bedömas vid valet av testare:

• Användning av systemet
• Kunskap om verksamheten
• Erfarenhet av systemutvecklingsprocessen
• Erfarenhet av testaktiviteter

Utöver ovanstående tekniska färdigheter är interpersonliga färdigheter (kommunikation, samarbete etc.) viktiga för testarna. För testledaren tillkommer projektledningsfärdigheter (planering, rapportering etc.). För teamet som helhet gäller att färdigheterna matchar det specifika testprojektets behov samt att individuella styrkor och svagheter balanseras mot varandra. En utvärderingsmatris kan användas för att utvärdera medarbetarnas färdighetsnivå inom olika områden.

Kapitlet fortsätter med en genomgång av själva testfunktionens olika beroendenivåer:

Till en testledares uppgifter hör också att motivara testarna:

• Uppskattning av utfört jobb
• Erkännande av ledningen
• Respekt från team
• Ökat ansvar och självständighet
• Adekvata belöningar

Då test är beroende av så många andra delar av projektet är det viktigt att prestationerna mäts inte av projektets framgång utan att testspecifika mätetal. Det är därför viktigt att testledaren förmår motivera testarna även om projektet i stort har problem.

Avslutningsvis tar Advanced Syllabus upp vikten av god kommunikation:

• Dokumentation av testprodukter
• Återkoppling på granskade dokument
• Interaktion inom testteam och projekt

Diplomati och objektivitet är viktiga egenskaper i kommunikationen. Vidare måste kommunikationen vara effektiv (anpassad till målgruppen) och hänsyn tas till hur kommunikationen uppfattas.

Kapitlet tar upp viktiga aspekter av teamarbete som inte är specifika för test. Jag skulle vilja lägga till vikten av att förstå intressenters förväntningar också. Jag har nämligen jobbat med att sätta ihop testteam från CV:n och intervjuer där jag vinnlagt mig om att hitta en bra blandning av just tekniska färdigheter (funktionella, tekniska, manuella och automatiserade tester) som personliga (pådrivare, motiverare, utförare och granskare). När jag var klar tyckte jag att jag hade ett välbalanserat team, varpå kundens representant ändrade kraven så att jag fick börja om från början. Först senare förstod jag att orsaken var en dold agenda där representanten bevakade sina egna intressen och därför inte ville ha in testare från mitt företag.

Ett annat exempel på vikten av att förstå förväntningar utgjorde ett projekt där det interna teamet (utvecklare och projektledare) förväntade sig halvfärdiga komponenter efter varje iteration medan det externa teamet (kundrepresentanter) förväntade sig färdiga delar. De senare reagerade därför på de uppriktigt rapporterade defekterna och gav upphov till en hel del förtroendeproblem som hade kunnat undvikas om förväntningarna först jämkats ordentligt.

Expert Level Syllabus - Test Manager

Låt oss fortsätta med att studera Expert Level Syllabus - Test Manager.

2. Förbättra testprocessen

Kapitel två diskuterar vikten av att förbättra testprocessen i tre sammanhang:

• Affärsmässiga och organisationella utmaningar: Kortare ledtider, kostnadspress, högre kvalitetskrav, utlokalisering etc. fordrar effektiv testning
• Underhåll av befintliga system: Mjukvaruystem ingår i helhet som omfattar t ex hårdvara och processer, vilket fordrar mer omfattande testning
• Test- och kvalitetsutmaningar: Kvalitetskrav är inte begränsade till mjukvarusystem och köpare förväntar sig kringtjänster, vilket fordrar en bredare syn på test och kvalitet

Det här är inga nyheter för mig som är van vid att test kläms mellan förseningar i föregående projektfaser och krav på att ändå leverera i tid. Det har också förekommit att jag tagit med mig den kunskap om systemet jag byggt upp under testerna för att ge förvaltningen stöd och då sett vådan av att inte tänka på det sammanhang som systemet ska fungera i. Det bästa råd jag kan ge är att hålla på integriteten och ständigt lyfta fram faran med att "ta sig genom en tunnel så snabbt som möjligt" men var beredd på att du måste stånga dig blodig för att lyckas med det.

Hur ska man då förbättra testprocessen? ISTQB talar om Software Process Improvement (SPI). Detta handlar just om att förbättringar av testprocessen måste omfatta mer än bara test, t ex infrastruktur, utbildning och andra projektfaser, såsom kravställande och utveckling.

Vidare diskuterar ISTQB fem typer av kvalitet: Produkt, Tillverkning, Användare, Värde och Överskridande ("Product", "Manufacturing", "User", "Value", "Transcendent"). Vilken typ av kvalitet som är viktigast beror på sammanhanget - säkerhetskritiska branscher föredrar produkt - och tillverkningskvalitet medan nöjesbranscher värderar användarmässiga och överskridande egenskaper högre.

Hur uppnår man då kvalitet? Ett svar som ISTQB ger är Deming-cykelns kontinuerliga förbättring i fem steg: Planera, Utföra, Kontrollera och Agera ("Plan", "Do", "Check", "Act"). En praktisering av detta är förbättringsramverket IDEAL (Initiera, Diagnosticera, Etablera, Agera, Lär). En annan är The Fundamental Concept of Excellence, som listar nio kriterier för kvalitet:

• Resultatorientering ("Results Orientation")
• Kundfokus ("Customer Focus")
• Ledarskap ("Leadership & Constancy of Purpose")
• Processer ("Management by Processes & Facts")
• Personalengagemang ("People Development & Processes")
• Kontinuerlig förbättring ("Continuous Learning")
• Ömsesidiga relationer ("Partnership Development")
• Socialt engagemang ("Corporate Social Responsibility")

Ytterligare begrepp som tas upp är Six Sigma (låg tolerans mot kvalitetsbrister), Balanced Scorecard (mätetal för helhetssyn) och CMMI eller Capability Maturity Model Integration (guide för systemförbättring). Du behöver inte kunna allt detta utantill utan det räcker att du känner till begreppen. De ligger sedan till grund för testspecifika modeller, såsom processmodellerna TMMi (Test Maturity Model Integrated) och TPI Next (Test Process Improvement) samt innehållsmodellerna STEP (The Systematic Test and Evalution Process) och CTP (Critical Testing Process). Dessa modeller gås igenom i detalj i kapitel 3.

Medan de modellbaserade ansatserna fokuserar på HUR man ska förbättra testprocessen så handlar analysbaserade ansatser om VAR man ska förbättra testprocessen. GQM (Goal-Question-Metric) är ett sådant exemple och flera gås igenom i detalj i kapitel 4.

Kapitlet avslutas med en uppräkning av konkreta exempel på testförbättrande åtgärder. Fundera gärna över exempel från din egen testvardag.

• Kunskaper: Vilka kunskaper har dina testare och vilka ytterligare behöver de? Jag har jobbat såväl med erfarna testare (som behöver kunskap om systemet och affärsprocesserna) som verksamhetsexperter (som behöver förståelse för testmetodik).
• Verktyg: Vilka testverktyg använder du och hur? Rätt använt kan ett testverktyg som ALM spara mycket tid. Om dina testare alltid kan se vad de ska göra och du alltid se hur det går kan möten ägnas åt viktigare saker än att gå igenom arbetsfördelning och status.
• Erfarenheter: Blev testerna perfekta? Antagligen inte så var ödmjuk och uppmuntra självkritik så att ni kan lära er testa ännu bättre nästa gång.
• Standarder: Vilka standarder berör testerna? Det behöver inte bara vara regelverk utan också t ex gemensamma processer och mallar. Projektet består antagligen av personer från många olika företag med olika "språk" men om ni följer ett gemensamt ramverk så underlättas kommunikationen.
• Resurser: Vilka resurser behövs för testerna. Finns det en konfigurationshanteringsplan för testmiljön? Finns det tydliga krav och specifikationer för testdata? Behöver specialister utanför testteamet konsulteras för att validera utfall? Sådana frågor måste ställas och besvaras i god tid.

3. Modellbaserade förbättringar

Syftet med processmodeller är att identifiera mognadsnivåer och peka ut vägen dit. En mognadsnivå kan antingen vara stegvis ("staged") eller kontinuerlig ("continuous"). Ett exempel på den förra är TMMi (Test Maturity Model Integrated) som anger kritierier som alla måste vara uppfyllda för att en mognadsnivå ska anses uppnådd. De fem mognadsnivåerna är Initial, Managed, Defined, Management and Measurement och Optimization. Ett exempel på den senare TPI Next (Test Process Improvement) där enskilda kriterier kan väljas ut och olika mognadsnivåer i olika områden därmed uppnås.

Syftet med innehållsmodeller är att förbättra test genom best practices. Modellen STEP (Systematic Test and Evaluation Process) bygger på idén att test genomsyrar hela projektcykeln och i likhet med TPI Next kan enskilda projektfaser väljas ut och förbättras. CTP (Critical Testing Process) å andra sidan påminner mer om TMMi såtillvida att kritiska testprocesser identifieras och prioriterade rekommendationer för förbättringar ges. Såväl kvalitativa som kvantitativa nyckeltal är viktiga i denna modell.

Modeller och mognadsnivåer i all ära men de är svåra att använda i verkligheten. Jag har sett projekt där ambitiösa utvärderingar gjorts men sedan runnit ut i sanden eftersom mottagarna inte förmått ta till sig dem. Kanske beror det på att test fortfarande är en lite eftersatt disciplin inom systemutveckling och att testare kallas in först när det är dags att testa och alltså försent för att införa långsiktiga förbättringar? Däremot är testmodellerna, som så många andra modeller, bra att ha med sig som "verktygslådor" som man kan välja och vraka ur för att hitta dem som passar bäst till det specifika projektet.

ISTQB refererar till många standarder från IEEE som kan vara bra att hämta inspiration från. (De är dock inte gratis.)

• IEEE829: IEEE Standard for Software and System Test Documentation
• IEEE1044: IEEE Standard Classification for Software Anomalies

För förbättringar kopplade till verkliga problem är analyser lämpligare och om detta handlar nästa kapitel.

4. Analysbaserade förbättringar

Analysbaserade förbättringar skiljer sig mot föregående kapitels modellbaserade förbättringar genom att de baseras på verkliga problem snarare än generiska processmodeller. Däremot kan de kompletteras med innehållsmodeller för att utvärdera förbättringarna.

Ett exempel på en analys är orsaksanalysen, som syftar till att identifiera grundproblemet snarare än symptomet.

• Orsak-effekt-diagram (Shikawa, "fiskben"): Effekterna skrivs till höger i diagrammet, varvid brainstorming används för att ange orsaker till vänster.
• Inspektion: En faciliterad diskussion hålls för att analysera utvalda defekter och identifiera övergripande trender. Varje defekt förses med följande:
• Defektbeskrivning: Beskrivning av defekten (inte symptomet)
• Orsakskategori: T ex kommunikation, förbiseende, kunskap, process etc.
• Orsaksbeskrivning: Beskrivning av orsak och ev. kedja av orsaker
• Grundorsak: Det moment där defekten uppstod (inte upptäcktes)
• Förslag för att eliminera orsaken: Dessa måste vara specifika och nåbara
• Standardklassificering av anomalier: Organisationsomfattande klassificering för att få fram statistik om var fel uppstår kontra var det upptäcks ("defektläckage") samt kostnaden för felet och rättningen.

En sådan här orsaksanalys kan vara ett mycket kraftfullt verktyg för att hitta och eliminera fel så tidigt som möjligt i ett projekt. Jag har dock stött på flera exempel där det missbrukas och avråder från följande:

• Övertydlighet: Defekter som ska rättas behöver bara förstås av utvecklaren, inte av andra intressenter. Ibland är dessutom utvecklaren bättre än testaren på att förstå en defekt utifrån ett symptom. Lägg därför hellre energi på att först upptäcka och rätta så många defekter som möjligt och sedan, när testomgången är över, detaljera utestående defekter och analysera utvalda defekter.
• Överanalys: I början av ett projekt är det naturligt med barnsjukdomar som alla är medvetna om. Att då analysera varje liten defekt är bara att slösa med tid och slå in öppna dörrar. Lägg hellre energi på att förankra bra grundprocesser för att sedan hitta de fall som processerna inte täcker.
• Pajkastning: Orsaksanalyser kan lätt användas till att ge andra skulden, i synnerhet om projektet består av aktörer från flera olika företag. Var därför ödmjuk och diplomatisk när du rapporterar orsaker och tänk på att orsaker ofta är en kombination av flera faktorer och ansvaret för dem därför delat.
• Revolution: Det ligger i projekts unika natur att det tar ett tag innan processer blir effektiva. Föreslå därför inte revolutionerande åtgärder som förstör mer än de förbättrar utan håll dig till just specifika och nåbara saker. (Om projektet verkligen skulle behöva en revolution - ja, då är det dåligt planerat från början och bör hellre läggas ned och planeras om från grunden.)

En annan analys är GQM (Goal-Question-Metric). Den bygger på att man utifrån bestämda mål (konceptuell nivå) härleder frågor (operationell nivå) som svarar på hur målen nås och nyckeltal (kvantitativ nivå) som ger svar på frågorna.

Som stöd för analysen föreslås flera nyckeltal:

• Testeffektivitet (Test Effectiveness)
• Upptäcktsgrad (DDP eller Defect Detection Percentage): Antal defekter / kända defekter
• Defektkvot efter driftsättning (Post-release Defect Rate): Antal defekter / kodrader i tusental
• Testkostnad (Test Efficiency / Cost)
• Kvalitetskostnad (Organizational Cost of Quality): Kostnad för test jämfört med kostnad för fel
• Kvalitetskvot (Cost of Quality Ratio): Kostnad för statisk test / kostnad för dynamisk test
• Tidig upptäckt (Early Defect Detection): Defekter upptäckta under enhets- och integrationstest / defekter upptäckta under system- och acceptanstest
• Relativ testkostnad (Relative Test Effort): Testkostnad / Projektkostnad
• Testeffektivitet (Test Efficiency): Defekters antal och allvarlighetsgrad / testkostnad
• Automationsnivå (Automation Level): Automatiserade testfall / totala testfall
• Testsproduktivitet (Test Productivity): Testfall / testkostnad
• Ledtider (Lead-time): Testtid för specifika faser
• Förutsägbarhet (Predictability):
• Förskjutningar i ledtid (Test Execution Lead-time Slippage): Skillnad mellan verklig och planerad testtid
• Förskjutningar i kostnad (Effort Slip): Skillnad mellan verkliga och planerade kostnader
• Förskjutningar i testfall (Test Case Slip): Skillnad mellan verkliga och planerade testfall
• Produktkvalitet (Product Quality):
• Kvalitetsattribut (Quality Attributes): Funktionalitet, reliabilitet, användbarhet, effektivitet, driftsmässighet, portabilitet etc.
• Täckningsindikatorer (Coverage Indicators): Testade krav / Totala krav
• Testmognad (Test Maturity): Mognadsnivå enligt modeller som TMMi eller TPI Next (se ovan)

5. Välja rätt ansats för testförbättringar

Kapitel 5 fortsätter diskussionen om förbättringar med riktlinjer för vilka man ska välja:

Blandade ansatser kan också komma i fråga, t ex orsaksanalys för att uppnå en mognadsnivå enligt TMMi.

Som konsult gäller det att vara mycket lyhörd inför kundens krav och förutsättningar för att välja rätt i djungeln av förbättringsansatser. På ett projekt så hade ledningen idéer om standardiserade testprocesser medan mellancheferna såg mer till affärsnyttan för sitt område och användarna var fullt upptagna av sina omedelbara problem. Att jämka samman så olika förväntningar kräver ett stort mått av diplomati, pragmatism och tålamod.

6. Genomföra testförbättringar

Kapitel 6 baseras på IDEAL-ramverket som introducerades i kapitel 2.

Initiera förbättringsprocessen

Initiera förbättringsprocessen består av följande moment:

1. Etablera behov: Vilka behov har olika intressenter (ledning, användare, utvecklare, testare, förvaltning etc.)?
2. Sätt mål: Etablera vision, sätt specifika mål och koppla förbättringar till affärsmål
3. Sätt scope: Generella processer, testprocesser, testnivåer, projekt- eller organisationscentrerad
4. Välj strategi: Se kapitel 5
5. Påverka kultur: Ta hänsyn till kunskap, kultur och förändringsvilja (se vidare kapitel 7 och framåt)

(De olika momenten är beroende av val av ansats för testförbättringar, se kapitel 5.)

Diagnosticera nuläge

Diagnosticera nuläge består av följande moment:

1. Planera utvärdering: Planera och schemalägg förberedelser, intervjuer, områden och återkoppling
2. Förbered utvärdering: Analysera testdokument för att förstå nuläge och granska formalia
3. Genomför intervjuer: Intervjua i positiv anda (se kapitel 7)
4. Ge återkoppling: Bekräfta och ge överblick över erhållna svar
5. Analysera resultat: Analysera resultatet enligt vald ansats
• Analytisk ansats:
• Systematiskt tänkande: Analysera relationer mellan system och processer för att identifiera stabila och förstärkande (positiva eller negativa) loopar
• Vändpunkter: Identifiera punktinsatser som kan bryta onda cirklar eller ge positiva kedjereaktioner
• Modellbaserad ansats: Jämför nuläge med målläge
6. Analysera lösningsförslag (konsekvenser, begränsningar, prioriteringar etc.):
• Förutfattade meningar: Analys behövs ej men risk att missa grundorsaken
• Rekommenderade lösningar: Best practice men risk att missa grundorsaken
• Krav från intressenter: Tydligt fokus men risk att missa förbättring uteblir
• Lösningsanalys: Avvägning av för- och nackdelar men resurskrävande
7. Rekommendera åtgärder: Vision, mål och slutsater (vad fungerar bra, vad kan förbättras?)
• Unik identifierare (för spårbarhet)
• Rekommendationens påverkan på mål
• Estimerad kostnad och nytta
• Tidplan
• Risker (t ex motstånd)
• Beroenden och antaganden

Etablera testförbättringsplan

Etablera testförbättringsplan består av följande moment:

• Sätt prioriteringar: Balansera kort- och långsiktiga förbättringar, ta hänsyn till risker och länka till mål
• Ta fram ansats för implementering:
• Top-down: Större scope, kräver att förväntningar hanteras
• Bottom-up: Mindre scope, ägarskap hos enskilda projektteam
• Planera förbättringar: Etablera nyckeltal, kombinera förbättringar, bestäm tidplan och resurser etc.

IDEAL-modellen skiljer på en långsiktig strategisk plan som integrerar testprocessförbättringar med övriga mjukvaruprocessförbättringar och en kortsiktig taktisk plan som fokuserar på test.

Agera för att implementera förbättringar

Agera för att implementera förbättringar består av följande moment:

• Välj och exekvera pilot: Ta hänsyn till realism, skalbarhet, påverkan på verksamhet och risker vid misslyckande
• Led och kontrollera förändringen: Mät nyckeltal mot mål och besluta om implementering

Lär från förbättringsprogram

Lär från förbättringsprogram består av följande moment:

• Analysera och validera (tillsammans med intressenter)
• Föreslå framtida lösningar (baserade på erfarenheter)

Ett exempel på hur det kan gå när IDEAL-modellen inte följs utgör ett projekt jag deltog i där ett strategiskt beslut om utlokalisering fattats över verksamhetens huvuden. Det första steget, initiering, hoppades därmed över i och med att det varken fanns behov av eller stöd för förbättringen och därmed inte heller någon organisation utöver projektet. Trots det gick vi vidare med diagnosticering och kunde då konstatera att verksamhetens mognadsnivå inte var tillräcklig för utlokalisering av testtjänster. Däremot kunde vi rikta in oss på ett specifikt behov av testautomatisering och styra in projektet på detta mer avgränsade men också mer accepterade spår.

Det säger sig självt att det inte fanns mycket att lära av detta men alla blev ändå nöjda: kundens strategiska beslut förverkligades, fler konsulttjänster såldes in och testarna fick erfarenheter, om än annorlunda sådana. Om inte annat så fanns det nu ett förbättringsbehov men då hade jag redan lämnat projektet...

7. Organisation, roller och färdigheter

Kapitel 7 introducerar begreppet testprocessgrupp, en permanent grupp bestående av specialister som förbättrar och följer upp problemområden i hela organisationen. IDEAL-modellen kompletterar med beskrivningar av hur grupper etableras på strategisk nivå ("Executive Council"), taktiskt nivå ("Management Steering Group") och problemspecifik nivå ("Technical Working Group"). För distribuerade organisationer är det viktigt att alla parter får information och möjlighet att återkoppla samt att hinder p g a kultur, tidszon etc. övervinns.

Kapitlet fortsätter med en uppräkning av de färdigheter som de två rollerna testprocessförbättrare och utvärdere behöver:

• Intervjuteknik (öppna, fråga lyssna, summera, kontrollera, stäng), som i sin tur kräver
• Emotionell intelligens (känna, utnyttja, förstå och hantera känslor)
• Transaktionsanalys (teorin om att människor är uppdelade i tre effektiva och tre ineffektiva människotyper)
• Naturligt barn: Spontana, behöver erkännande
• Vuxen: Logisk, arbetar med fakta
• Förälder: Bestämd men förstående
• Kritisk förälder: Sätter folk på plats, verbalt och icke-verbalt
• Upproriskt barn: Negativ, motarbetande
• Lydigt barn: Försiktig, ger sig själv skulden
• Samberoende beteende (teorin om att folks vilja att göra sitt bästa döljer långsiktiga problem)
• Förmåga att lyssna
• Presentationsteknik (vinna stöd, visa resultat, föreslå förbättringar)
• Välj ut nyckelidéer
• Visa konkret hur idéer förverkligas
• Ha realistiska tidplaner
• Tala chefernas språk
• Förutse frågor
• Analytisk förmåga (sammanfatta, se mönster, omvandla information, skilja på orsak och verkan)
• Anteckningsteknik (mindmaps, nyckelord, diagram etc.)
• Övertalningsförmåga
• Sätt mål
• Välj målgrupp
• Välj ansats
• Fånga uppmärksamhet
• Känn ämnet
• Fråga om nästa steg
• Ledarskap (planering, estimering, beslutsfattande, riskhantering etc.)

Mycket av det som tas upp i det här kapitlet är nog självklart för de flesta med lite erfarenhet medan det för andra är för ytligt för att egentligen ge något stöd i det dagliga arbetet. Det jag ändå fäste mig mest vid var teorin om samberoende beteende. Hur ofta har jag inte själv befunnit mig i den situation som tas upp som exempel: att hantera orimliga testförutsättningar genom ett pragmatiskt förhållningssätt och helt enkelt testa så bra som möjligt.

Tyvärr ger kapitlet bara tips på hur man upptäcker samberoende beteende hos andra (svar som "Jag gör mitt bästa", "Det finns ingen risk", "Det här är normalt"), inte på vad man gör när man själv tvingas till det beteendet. Min erfarenhet är att det gäller att balansera den integritet mot pragmatism och lyfta fram långsiktiga risker utan att för den sakens skull framstå som en bromskloss. Själva testexekveringen kommer alltid att befinna sig sent i projektcykeln och du kan inte räkna med att få testa under ideala förutsättningar.

8. Hantera förändring

Kapitel 8 diskuterar utmaningen att hantera en förändring. Den grundläggande förändringsprocessen består av åtta steg som kan appliceras också på testförändringar:

1. Skapa en känsla av brådska: Etablera förändringsbehov och tydliggör förändringar och tidplaner
2. Sätt ihop ett vägledande team: Engagera entusiaster som "multiplicerare" (personer som först får kunskap och motiverar andra)
3. Utveckla förändringsvision: Hantera förväntningar och etablera strategi
4. Kommunicera: Informera, åskådliggör och motivera
5. Bemyndiga andra: Ge stöd för förändringar och och möjlighet till återkopplingar för dem som påverkas
6. Skapa kortsiktiga fördelar: Implementera och använd som motivering
7. Ge inte upp: Låt förbättringsteam stödja strategier
8. Skapa ny kultur: Förändra gradvis, publicera framgångar och följ upp problem

Kapitlet fortsätter med de mänskliga faktorerna i förändringsprocessen och beskriver två modeller som följer "forming-storming-norming-performing"-modellen (idén att förändringar genomgår kaos innan förbättringar uppnås:

• Satir: Gammalt status quo-Främmande element-Kaos-Transformering av idéer-Integration-Nytt status quo
• Kübler-Ross: Lättnad-Chock-Förnekelse-Ilska-Köpslagan-Depression-Acceptans-Experiment-Upptäckt

Avslutningsvis listas ett antal faktorer att ta hänsyn till för att hantera emotionella reaktioner på förändringar:

• Individuella förutsättningar
• Motivation till förändring
• Attityd till förändring
• Föregångare eller efterförljare ("early adopter" eller "late adopter")
• Acceptans för experiment och misslyckanden på vägen
• Inlärningsstil
• Preferens för beprövade eller nya metoder

Inte heller detta kapitel torde innehålla så många nyheter. Det finns dock många exempel på hur också de bästa intentionerna misslyckas därför att förändringarna inte hanterats rätt så vikten av detta kan inte nog betonas.

Som testare har man ofta en unik position nära såväl leverantören av ett system som mottagaren av detsamma och därmed möjlighet att fånga upp brister i förändringshanteringen. I ett av mina första testprojekt befann jag mig i en sådan position där systemutvecklarna kämpade för att få ett supportsystem att fungera rent tekniskt medan processutvecklarna ritade diagram på en alldeles för hög nivå. Den första versionen till användarna var således ett system där de förväntades faxa (!) supportuppgifter utan någon rutin för hur supportärendet skulle behandlas. Redan då försökte jag hålla på min integritet och lyfta fram de brister jag såg, inte så mycket i system och process som i hur de stackars användarna behandlades. Tyvärr var jag för junior för att få gehör men jag kan åtminstone känna stolthet över att jag försökte.

9. Kritiska framgångsfaktorer

I tillägg till förändringshantering finns det ytterligare två nyckelfaktorer för att lyckas med testförbättring: att börja och att sluta.

Att börja innebär att man ska ha tydliga mål, stöd från ledningen, formell projektorganisation, dedikerade resurser, ambitioner mappade till organisationens mognad samt den tidigare nämnda förändringsprocessen.

Att sluta innebär att man ska ha förutsättningar för att uppfylla målen (min kategorisering):

• Cykler: Cykler för förbättringar, återkopplingar och mätningar
• Kontroll: Processägarskap och uppföljning av alla steg i förändringsprocessen
• Kunskap: Engagemang av testexperter samt vid behov intressenter med kunskap utanför test
• Organisation: Stabila projektteam och hantering av ovilja mot förändring
• Verktyg: Systemstöd, existerande processer, standarder etc.
• Samordning: Samordning mellan förbättringsinitiativ och synkronisering av mognadsnivåer
• Publicering: Demonstrering av framgång och godkännande av förbättringar

Kapitlet fortsätter med en genomgång av de kulturella sammanhang som behöver beaktas:

• Ledningskultur (kontrollerande, konsultativ eller team-driven)
• Nationell kultur
• Mål, strategi och attityd till förbättring
• Relationer mellan avdelningar
• Livscykelmodell (sekventiell, iterativ, agil, anpassad, ingen process)
• Testansats (automatisering, manuell, skriptad, utforskande, blandad, ad hoc)

Som exempel på testansats anförs det agila manifestet:

• Flexibilitet framför detaljerade processer
• Best practices framför mallar
• Implementeringsorientering framför processorientering
• Interna granskningar ("peer review") framför kvalitetsgranskningar ("Quality Assurance")
• Affärsdriven framför modelldriven

Som ISTQB mycket riktigt anger så kan en agil ansats vara svår att sälja in i "konservativ" organisation van vid detaljerade processer. Jag upplevde ett sådant projekt där förutsättningarna (avsaknad av krav, regelverk under utveckling, ny teknisk lösning) framtvingade en agil ansats i nära samarbete med verksamhetsexperter, såväl i utveckling som i test. Testfallen fick således fokusera på att kontrollera att data flödade genom lösningen medan utfallet fick bekräftas av dessa experter. På lägre nivåer fungerade detta alldeles utmärkt men ju högre upp i organisationen man kom, desto mindre var förståelsen för detta och vi fick kämpa mot krav på V-modellens dokumenterade design och mätbara tester och den mur som ständigt byggdes upp mellan projekt och verksamhet. Utmaningen här låg alltså inte i att sprida ledningens vision om förbättringar till verksamheten utan att få ledningen att förstå verksamhetens förbättringsbehov!

10. Anpassning till olika livscykelmodeller

Det avslutande kapitlet diskuterar hur kulturella sammanhang (se föregående kapitel) påverkar val av förändringsmetod. Ledningskultur påverkar acceptans för ansats, livscykelmodell påverkar acceptans för förändringsfrekvens och testansats påverkar acceptans för förändringstyp. Det betyder dock inte att t ex agilt arbetssätt krockar med modellbaserade ansatser utan alla ansatser kan används som referenspunkter. Det viktiga är att förbättringen fokuserar på följande:

• Identifiera om livscykelmodellen rekommenderar en särskild förbättringsprocess
• Identifiera vilken förbättringsprocess som passar bäst i sammanhanget
• Identifiera vilken testansats som passar bäst i sammanhanget

Vad kapitlet alltså säger är att man ska anpassa teori till verklighet, vilket inte är en revolutionerande tanke. Den som har erfarenhet av systemutveckling vet att ingen metod utesluter idéer från andra metoder. Kapitlet pekar också på hur t ex V-modellens verifieringar och valideringar mellan faser påminner om SCRUMS retrospektiva möten genom att båda syftar till att identifiera förbättringar.

Jag har mest jobbat med V-modellen men ytterst sällan upplevt att en fas är helt avslutat innan nästa tar vid. Jag har därför fått jobba agilt med det som gått att jobba med och sedan återvänt och justerat i takt med att krav och design justeras. Projekt är av naturen föränderliga och lika viktigt som det är att mottagarna förmår hantera förändringar, lika viktigt är det att de som levererar gör det.

The Expert Test Manager

Denna bok publiceras i april 2013 och jag hoppas kunna köpa och börja läsa den så snart som möjligt.

Quality Center / ALM

Säg testverktyg och de flesta testledare tänker nog på Quality Center, eller ALM (Application Life Cycle Management) som det numera heter. Syftet med denna sida är inte att berätta ALLT om ALM (det gör användarmanualen bättre) utan att ge tips om hur jag använder verktyget i mitt arbete. Förhoppningsvis hittar du något som hjälper också dig i ditt arbete.

Översikt

Quallity Center är i första hand ett administrativt verktyg som håller ordning på alla testdokument, deras inbördes relationer och status. Om du t ex vill skapa ett testfall så kan du göra följande:

• Skapa testfall och följa upp status (Test Plan/Details)
• Lägga till steg med handling och förväntat resultat (Test Plan/Design Steps)
• Lägga till parametrar (Test Plan/Parameters)
• Lägga till bilagor, t ex testdata (Test Plan/Attachments)
• Koppla till krav i Requirements (Test Plan/Req Coverage)
• Köra hur många gånger du vill (Test Lab)
• Följa upp testkörningar (Test Plan/Test Configurations)
• Skapa defekter (Defects)
• Koppla till defekter (Test Plan/Linked Defects)
• Granska i rapporter och diagram (Dashboard/Analysis View)

Bilden nedan ger en översikt över hur de olika delarna hänger ihop:

Hur gör man då för att få ihop alla dessa delar? Om detta handlar nästa kapitel.

Förbered ALM

När jag börjar på ett nytt testprojekt brukar jag sätta upp ALM enligt följande:

1. Bestäm filstruktur

ALM organiserar testdokument i mappar och filer precis som Filhanteraren i OS X eller Windows Explorer i Windows. Fundera därför på hur ditt testprojekt bäst bryts ned i logiska delar och organisera mapparna därefter. Somliga föredrar enhetliga filstrukturer genom hela ALM så att testarna alltid ska känna igen sig när man navigerar. Jag föredrar dock att också andra än testarna ska känna igen sina delar och organiserar enligt följande:

• Requirements (affärsstruktur): Mappar för kravområden och krav för enskilda krav. Om testvillkor används kan dessa skapas som underkrav. Numrera kraven så som de numreras i underliggande kravdokumentation och överväg att importera dem till ALM.
• Test Plan (systemstruktur): Mappar för systemområden och testfall för enskilda komponenter eller moduler. Numrera testfallen så som de numreras i underliggande designdokumentation.
• Test Lab (teststruktur): Mappar för testfaser och test set för testscenarier, till vilka enskilda testfall kopplas. Numrera varje testset så som de numreras i testplaner.

En sådan filstruktur kan se ut enligt följande:

• Requirements: Ekonomi, Försäljning, IT etc.
• Test Plan: ETL-jobb, Beräkningar, Rapporter etc.
• Test Lab: Systemtest / Iteration 1, Systemtest / Iteration 2 etc.

2. Förbered för mätetal

Välj vilka mätetal du vill ha och gör vad som krävs för att få underlag till dessa mätetal. ALM har många olika kolumner som kan användas (och anpassas i Tools / Customize / Project Lists). Välj inte för många mätetal - ingen användare blir glad av att ange femtioelva parametrar varje gång något ska registreras och ju fler parametrar som missas, desto sämre blir dina mätetal.

Här är några mätetal jag ofta använder med tillhörande parametrar i ALM. Bryt gärna ner dem ytterligare på funktionellt område etc. så att du lättare kan rikta in förebyggande och/eller förbättrande åtgärder.

För att sedan fånga upp dessa mätetal brukar jag använda mig av grafer:

3. Informera användarna

Hur perfekt uppsatt ditt ALM än är så hjälper det inte om det bara är du som vet det. Se till att dina användare (såväl testare som utvecklare) vet vilka som ska användas och hur. Jag är en vän av processbilder kompletterade med skärmdumpar som visar ett testfalls väg från skapande via defekträttning till godkänt. Var särskilt noga med att klargöra överlämningspunkter mellan test och utveckling (tilldelning av ärenden, beskrivning av defekter och rättning, ändring av status etc.) så att inget faller mellan stolarna. En test- och defektprocess bör innehålla följande steg (men tänk på att anpassa den till ditt specifika projekts processer):

1. Testledare lägger in krav i Requirements
2. Testare tilldelas krav och skriver testfall i Test Plan
3. Testledare granskar testfall och godkänner dem i Test Plan
4. Testledare organiserar testfall i Test Lab
5. Testare tilldelas tester och kör dem i Test Lab
6. Testare loggar defekter i Test Lab och tilldelar dem till utvecklare
7. Utvecklare uppdaterar status och information i Defects, rättar defekter och returnerar dem till testare
8. Testare kör om testerna i Test Lab och stänger defekten i Defects
9. Testledaren följer upp och rapporterar testerna med hjälp av statistik i Dashboard

Ett exempel på enkla skärmdumpar finns i bifogad fil.

Arbeta i ALM

Nu när både ALM och användare är förberedda är det bara att köra. Vi börjar med Requirements och arbetar oss genom alla moduler.

1. Requirements: Arbeta parallellt med krav och testfall

Ett krav i Requirements är i princip en beskrivning, med möjlighet att bifoga bilder och dokument vid behov. För rent kravarbete så finns det bättre verktyg - det är kopplingen till testfall som gör ALM bra. Det är alltså inte omöjligt att kraven måste importeras till ALM.

Om du har ett "perfekt" projekt där krav- och testarbete görs i rätt ordning och alla krav har frysts när testfallen börjar skrivas så kan du gratulera dig till din lycka. Om inte så se till att använda statusfält både för krav och testfall och länka samman dem allt eftersom de läggs upp i ALM. På så vis kan du löpande följa upp att alla krav täcks av testfall och vice versa. Lägg gärna upp "tomma" testfall (utan teststeg) i början och komplettera dem löpande. På så vis får du tidigt en uppfattning om testomfattningen och kan följa upp hur mycket jobb som återstår. Först när ett testfall försetts med teststeg och kopplats till ett fryst testfall bör du anse dess status vara "Klart".

Din roll som testledare i kravprocessen är att se till att kraven är testbara och sedan fördela dem till din testare så att de kan skriva testfall.

2. Test Plan: Skriv effektiva testfall

Ett testfall i Test Plan består av ett antal steg med en beskrivning av vad som ska utföras och en beskrivning av det förväntade resultatet. ALM är inte gjort för snabb ordbehandling så det kan bli aktuellt att skriva dem i andra program och importera dem.

Klipp och klistra är vanliga kommandon i ALM men det finns ingen anledning att göra det mer än nödvändigt. Om du har aktiviteter som återkommer i testerna så lägg dem i separata testfall eller skapa testmallar som man kan utgå från. I ett av mina testprojekt fanns det jobb som skapade dimensionsnycklar och som återkom i flöde efter flöde. Genom att lägga dessa testfall i en egen mapp i Test Plan och sedan koppla samma testfall till flera flöden så behövde jag bara skriva testfallet en gång och när testfallet behövde uppdateras så behövde jag bara göra det på ett ställe.

Vad gör du om du har testfall som är nästan återkommande men skiljer sig på några detaljer? Lösningen heter parametrar. Om du t ex vill testa olika rapporter som skrivs ut på samma sätt så kan du skriva ett testfall med en parameter för rapportens namn. Du kan sedan i Test Lab koppla testfallet till flera flöden och i varje koppling ange olika rapportnamn i parametern. Observera dock att det i vissa tidiga versioner av ALM inte är möjligt att uppdatera testfall med parametrar under pågående körning (se nedan), en nackdel som jag tyvärr tycker överväger fördelen med parametrar.

Din roll som testledare i testfallsprocessen är att stötta dina testare i att skriva så bra testfall att de kan återanvändas eller utföras av andra testare.

3. Test Lab: Utför tester med spårbarhet

Ett testset i Test Lab är en logisk gruppering av testfall. Fördelen med Test Lab är att ett testfall kan köras hur många gånger som helst (det är den sista körningen som "avgör" om testet är godkänt) och även återanvändas i andra testset. När ett testfall körs tillkommer fältet Actual där utfallet av varje teststeg kan skrivas.

En sak jag brukar betona när man kör tester i Test Lab är att alltid skapa defekter under pågående körning (med knappen "New Defect"). På så vis skapas automatiskt en länk mellan defekten och testfallet och därmed också kravet (för du länkade väl varje testfall till ett krav?). Om du glömmer det kan du alltid gå in i testfallet på nytt med knappvalet "Continue Manual Run" ("Run" startar en helt ny körning. En annan fördel är att såväl testfallets beskrivning som utfall kopieras till defekten, vilket gör det lättare att skriva en bra defektbeskrivning.

En annan viktig sak är att inte slentrianmässigt godkänna testfall utan också notera utfallet. Ofta är det så att ett utgående värde i ett testfall behövs som ingående värde i nästa testfall och då är det bra att kunna gå tillbaka och se vilka värden som använts, i synnerhet om du behöver gå tillbaka till gamla körningar.

Din roll som testledare inför och under testkörningen är att se till att testerna organiseras så effektivt som möjligt så att saker körs i rätt ordning, onödiga dubbeltester undviks och stopp i testerna hanteras så snart som möjligt.

4. Defects: Följ upp defekter

Defects påmininer om Excel med en rad per defekt och en mängd olika kolumner för beskrivningar och parametrar. Defekter kan skapas direkt i Defects men jag föredrar som sagt att skapa dem i Test Lab för att få spårbarhet.

Varje kolumn i Defects är sökbar, vilket gör det ganska enkelt att söka specifika defekter, så tveka inte att komplettera defekter om de ursprungliga felbeskrivningarna visar sig bristfälliga. Tyvärr går det inte att söka i beskrivningsfältet men defekter kan vid behov exporteras till Excel och sökas där.

Den flexibilitet som finns i Defects är dock tveeggad, det är lätt att radera information. Se därför till att använda kommentarsfältet för uppdateringar i första hand.

Din roll som testledare är att se till att defekter blir väl beskrivna och inte blir liggande. Var särskilt aktsam på defekter som bollas fram och tillbaka eller innehåller långa ordväxlingar - ett tydligt tecken på att defekten behöver genomlysas på ett möte eller i värsta fall eskaleras.

5. Dashboard

Det är i Dashboard som du som testledare får din belöning för ett väl uppsatt ALM. Här kan du ta fram grafer och rapporter som visar hur dina tester går. Verktyget är inte fullt så flexibelt som man kan önska men standardgraferna räcker ganska långt. För mer komplicerade grafer brukar jag helt enkelt mata in siffrorna i Excel. Observera att några av graferna använder korsfilter där data hämtas från en flik men enligt filter i en annan flik. På så vis kan jag till exempel få statistik för testfall från Test Plan knutna till en specifik testkörning i Test Lab.

I planeringsfasen

1. Test Case Development Trend: Visar designstatus för alla testfall i aktuell mapp i Test Plan och används för att följa upp att testfallen skrivs enligt plan
• Entity: Tests
• Sub Type: Progress Graph
• Grouped By: Status
• Filter: Subject \ Folder
• View: Show Total Values
2. Requirement Coverage: Visar exekveringsstatus för alla krav i aktuell release i Requirements och används för att följa upp dels att kraven är täckta av testfall och dels att dessa testfall godkänns
• Entity: Requirements
• Sub Type: Summary Graph
• Grouped By:
• Filter: Target Release

I exekveringsfasen

1. Test Case Execution Trend: Visar exekveringsstatus för alla testfall och används för att följa upp exekvering mot plan (exporteras till Excel och kombineras med planerad exekvering - ALM ger inte stöd för att visa planerade testfall i progressgrafer)
• Entity: Test Instances
• Sub Type: Progress Graph
• Grouped By: Status
• Filter: Status[Not "No Run"]
• Cross Filter: Test Set Folder
• Group By Categories: Executed = Passed + Failed
2. Test Case Planned vs Execution Trend: Samma som Test Case Execution Trend med det tillägget att också planerat exekveringsdatum visas, fungerar dock endast som summeringsgraf
• Entity: Test Instances
• Sub Type: Summary Graph
• X-Axis: Open Date eller Closed Date (Planned Execution Date kan ej väljas)
• Grouped By: Status
• Cross Filter: Test Set Folder
• Group By Categories: Executed = Passed + Failed, Planned = No Run + Not Completed
3. Test Case Pass Trend: Samma som Test Case Execution Trend med den skillnaden att godkända (istället för exekverade) testfall visas
• Entity: Test Instances
• Sub Type: Progress Graph
• Grouped By: Status
• Filter: Status[=Passed]
• Cross Filter: Test Set Folder
• View: Visa endast Passed
4. Defect to Test Case Trend: Visar antal upptäckta defekter och används för jämförelser med antal körda testfall (exporteras till Excel och kombineras med Test Case Execution Trend - ALM ger inte stöd för två olika kurvor i samma graf)
• Entity: Defects
• Sub Type: Progress Graph
• Grouped By: Status
• Filter: Detected in Cycle
• Group By Category: Defects = All defects
5. Quality Risk: Visar exekveringsstatus för alla krav och används för att bedöma lösningens kvalitet
• Entity: Requirements
• Sub Type: Progress Graph
• Grouped By: Direct Cover Status
• Cross Filter: Subject \ Test Folder
6. Defect Backlog Trend: Visar defekters status och används för att följa upp "defektköer"
• Entity: Defects
• Sub Type: Progress Graph
• Grouped By: Status
• Filter: Detected in Cycle
7. Defect Closure Trend: Samma som Defect Backlog Trend men grupperar status efter öppna och stängda defekter och används för att följa upp att defekter stängs i acceptabel takt
• Entity: Defects
• Sub Type: Progress Graph
• Grouped By: Status
• Filter: Detected in Cycle
• Group By Categories: Closed och Open
8. Defect Age: Visar hur länge defekter varit öppna och används för att följa upp defekter som varit öppna för länge
• Entity: Defects
• Sub Type: Age Graph
• Grouped By: Severity
• Filter: Detected in Cycle; Status[Not Closed]

I avslutningsfasen

1. Defect Analysis by Area/Severity etc.: Visar defekter grupperade i olika områden och används för att analysera defekter (var uppstod de, hur allvarliga var de etc.?)
• Entity: Defects
• Sub Type: Summary Graph
• X-Axis: Area, Severity etc.
• Grouped By: Status
• Filter: Detected in Cycle

Mellan projekten (för kontinuerliga förbättringar)

1. Defect Removal Effectiveness: Visar var i projektetlivscykeln defekter uppstått (förutsatt att defekter loggats genom hela projektet) och används för att följa upp att defekter upptäcks så tidigt som möjligt (ju större andel som upptäcks i acceptanstest, desto sämre)
• Entity: Defects
• Sub Type: Summary Graph
• X-Axis: Detected in Cycle
• Grouped By: Status
2. Root Cause Analysis: Visar grundorsaken till defekter och används för att identifiera förbättringsområden, jämförs med fördel med Defect Removal Effectiveness som upptäcks i en projektfas också har sitt ursprung i den fasen
• Entity: Defects
• Sub Type: Summary Graph
• X-Axis: Root Cause
• Grouped By: Status

Övriga intressanta grafer

1. Defect In- and Outflow: Visar datum för öppning och stängning av defekter (eller för att vara exakt, det datum då defekter fick status öppen och stängd)
• Entity: Defects
• Sub Type: Trend Graph
• Grouped By: Status
• Filter: Status[not Closed]
• Group By Categoreis: Open, Closed
2. Opened Defects: Visar hur många defekter som var öppna ett visst datum, kombineras med fördel med Defect In- and Outflow ovan
• Entity: Defects
• Sub Type: Progress Graph
• Grouped By: Status
• Filter: Status[not Closed]
• Group By Categories: Open
3. Defect Severity over Time: Samma som Opened Defects men en för varje grad av Severity som sedan exporteras till Excel och kombineras i en areagraf
   

Se ovan för exempel på mätetal som dessa grafer kan användas till.

Exportera testfall från QC till Excel

QC har standardfunktionalitet för att exportera data till HTML, PDF och Word. Det går även att exportera data till Excel men kräver lite kodning.

1. Navigera till Test Plan och ta fram Subject ID för den översta mappen för de testfall som ska exporteras. För att göra detta måste du först ta fram Test ID för ett testfall i denna mapp. (Lägg upp ett dummy testfall med dummy teststeg om nödvändigt.)


 
2. Navigera till Analysis View / Public / Excel Reports och kopiera en befintlig rapport. Döp den till Test Cases och ändra beskrivningen.


 
3. Klicka på tabben ”Configuration” och klistra in koden nedan.
   
   SELECT
    ALL_LISTS.AL_ABSOLUTE_PATH as "Path", /*Test.Top Folder*/
    ALL_LISTS.AL_DESCRIPTION as "Mapp", /*Test.Folder*/
    TEST.TS_TEST_ID as "Test ID", /*Test.Test ID*/
    TEST.TS_NAME as "Test Name", /*Test.Test Name*/
    TEST.TS_DESCRIPTION as "Test Desc.", /*Test.Description*/
    DESSTEPS.DS_STEP_NAME as "Step Name", /*Design Step.Step Name*/
    DESSTEPS.DS_DESCRIPTION as "Step Desc.", /*Design Step.Description*/
    DESSTEPS.DS_EXPECTED as "Expected Result" /*Design Step.Expected Result*/
    
   FROM
    Test
    
   JOIN ALL_LISTS ON TEST.TS_SUBJECT = ALL_LISTS.AL_ITEM_ID
   JOIN DESSTEPS ON TEST.TS_TEST_ID=DESSTEPS.DS_TEST_ID
   
   WHERE TS_TEST_ID = XXXX
   /*WHERE ALL_LISTS.AL_ABSOLUTE_PATH LIKE 'YYY%'*/
   
   ORDER BY TEST.TS_NAME, DESSTEPS.DS_STEP_ORDER


 
4. Ändra koden AND TS_TEST_ID = XXXX till det Test ID du tog fram i steg 1, t ex AND TS_TEST_ID = 6800. Tryck sedan på Generate och spara Excelfilen.


 
5. Excelfilen visar den Path som behövs för att söka fram alla testfall.


 
6. Gå tillbaka till Analysis View och tabben ”Configuration” och ändra koden enligt nedan (kommentera bort raden med Test ID och ersätt i raden med Path ”YYY” med din egen Path). Tryck sedan på Generate och spara Excelfilen.
   SELECT
    ALL_LISTS.AL_ABSOLUTE_PATH as "Path", /*Test.Top Folder*/
    ALL_LISTS.AL_DESCRIPTION as "Mapp", /*Test.Folder*/
    TEST.TS_TEST_ID as "Test ID", /*Test.Test ID*/
    TEST.TS_NAME as "Test Name", /*Test.Test Name*/
    TEST.TS_DESCRIPTION as "Test Desc.", /*Test.Description*/
    DESSTEPS.DS_STEP_NAME as "Step Name", /*Design Step.Step Name*/
    DESSTEPS.DS_DESCRIPTION as "Step Desc.", /*Design Step.Description*/
    DESSTEPS.DS_EXPECTED as "Expected Result" /*Design Step.Expected Result*/
    
   FROM
    Test
    
   JOIN ALL_LISTS ON TEST.TS_SUBJECT = ALL_LISTS.AL_ITEM_ID
   JOIN DESSTEPS ON TEST.TS_TEST_ID=DESSTEPS.DS_TEST_ID
    
   /*WHERE TS_TEST_ID = 6800*/
   WHERE ALL_LISTS.AL_ABSOLUTE_PATH LIKE 'AAAAAYAABAAAAAPAAG%'
    
   ORDER BY TEST.TS_NAME, DESSTEPS.DS_STEP_ORDER


 
7. En excelfil har skapats med testfallen sorterade efter mappnamn, testfallsnamn och testfallssteg. Observera att rapporten inte kan sortera på övermappar så om en komplex hierarki behöver exporteras kan det vara bättre att exportera varje övermapp separat.

Exportera testresultat från QC till Excel

Med lite mer avancerad kodning kan du exportera testresultatet per teststeg från QC till Excel, inklusive teststegens beskrivning och förväntade resultat.

1. Navigera till Test Plan och ta fram Subject ID för den översta mappen för de testfall som ska exporteras. För att göra detta måste du först ta fram Test ID för ett testfall i denna mapp. (Lägg upp ett dummy testfall med dummy teststeg om nödvändigt.)


 
2. Navigera till Analysis View / Public / Excel Reports och kopiera en befintlig rapport. Döp den till Test Results och ändra beskrivningen.


 
3. Klicka på tabben ”Configuration” och klistra in koden nedan.
   
   SELECT
    ALL_LISTS.AL_ABSOLUTE_PATH as "Path", /*Test.Top Folder*/
    ALL_LISTS.AL_DESCRIPTION as "Mapp", /*Test.Folder*/
    TS_NAME as "Test Case Name",
    TS_DESCRIPTION as "Test Case Description",
    DS_STEP_NAME as "Test Step Name",
    ST_STATUS as "Test Step Status",
    DS_DESCRIPTION as "Test Step Description",
    DS_EXPECTED as "Test Step Expected",
    ST_ACTUAL as "Test Step Actual",
    ST_RUN_ID as "Run ID",
    ST_DESSTEP_ID as "Step ID"
   FROM Test
   
   JOIN ALL_LISTS ON TEST.TS_SUBJECT = ALL_LISTS.AL_ITEM_ID
   LEFT OUTER JOIN DESSTEPS ON TEST.TS_TEST_ID=DESSTEPS.DS_TEST_ID
   LEFT OUTER JOIN STEP ON ST_TEST_ID=DESSTEPS.DS_TEST_ID AND ST_STEP_ORDER = DS_STEP_ORDER
   
   WHERE (STEP.ST_RUN_ID IS NULL
    OR
    ST_RUN_ID IN (SELECT MAX(ST_RUN_ID)
    FROM STEP
    GROUP BY ST_TEST_ID)
    ) AND
    TS_TEST_ID = XXXX
    */ ALL_LISTS.AL_ABSOLUTE_PATH LIKE 'AAAAAYAAFAAG%' */
    ORDER BY AL_DESCRIPTION, TS_NAME, DS_STEP_NAME ASC, ST_RUN_ID
   


 
4. Ändra koden TS_TEST_ID = XXXX till det Test ID du tog fram i steg 1, t ex TS_TEST_ID = 6800. Tryck sedan på Generate och spara Excelfilen.


 
5. Excelfilen visar den Path som behövs för att söka fram alla testfall.


 
6. Gå tillbaka till Analysis View och tabben ”Configuration” och ändra koden enligt nedan (kommentera bort raden med Test ID och ersätt i raden med Path ”YYY” med din egen Path). Tryck sedan på Generate och spara Excelfilen.
   SELECT
    ALL_LISTS.AL_ABSOLUTE_PATH as "Path", /*Test.Top Folder*/
    ALL_LISTS.AL_DESCRIPTION as "Mapp", /*Test.Folder*/
    TS_NAME as "Test Case Name",
    TS_DESCRIPTION as "Test Case Description",
    DS_STEP_NAME as "Test Step Name",
    ST_STATUS as "Test Step Status",
    DS_DESCRIPTION as "Test Step Description",
    DS_EXPECTED as "Test Step Expected",
    ST_ACTUAL as "Test Step Actual",
    ST_RUN_ID as "Run ID",
    ST_DESSTEP_ID as "Step ID"
   FROM Test
   
   JOIN ALL_LISTS ON TEST.TS_SUBJECT = ALL_LISTS.AL_ITEM_ID
   LEFT OUTER JOIN DESSTEPS ON TEST.TS_TEST_ID=DESSTEPS.DS_TEST_ID
   LEFT OUTER JOIN STEP ON ST_TEST_ID=DESSTEPS.DS_TEST_ID AND ST_STEP_ORDER = DS_STEP_ORDER
   
   WHERE (STEP.ST_RUN_ID IS NULL
    OR
    ST_RUN_ID IN (SELECT MAX(ST_RUN_ID)
    FROM STEP
    GROUP BY ST_TEST_ID)
    )
    AND
   /* TS_TEST_ID = XXXX */
    ALL_LISTS.AL_ABSOLUTE_PATH LIKE 'AAAAAYAAFAAG%'
    ORDER BY AL_DESCRIPTION, TS_NAME, DS_STEP_NAME ASC, ST_RUN_ID
   


 
7. En excelfil har skapats med testfallen sorterade efter mappnamn, testfallsnamn och testfallssteg. Observera att rapporten inte kan sortera på övermappar så om en komplex hierarki behöver exporteras kan det vara bättre att exportera varje övermapp separat.

Mejl från QC

QC kan skicka automatiska mejl vid ändringar i QC. Inställningarna kan göras i QC-gränssnittet för Defects men måste göras i skripten för övriga delar.

1. Logga in till QC Admin och navigera till Site Projects / [Ditt projekt] / Project Details och klicka i ”Send Mail Automatically”.


 
2. Navigera till ”Kugghjulet” / Automail / Send mail about change och välj i Selected Defect Fields vilka fältförändringar som du vill få mejl om.


 
3. Välj i samma fönster vilka användare som ska få mejl.


 
4. Navigera till ”Kugghjulet” / Workflow / Script Editor / Requirements module script / Req_AfterPost och lägg till rader enligt följande:
     Sub Req_AfterPost  On Error Resume Next
    
     set rs = TDConnection.ReqFactory
     set rst = rs.Item(Req_Fields.Field("RQ_REQ_ID").Value)
     rst.Mail "användare1", "", 0, "Krav " & rst.name & " har skapats"
     rst.Mail "användare2", "", 0, "Krav " & rst.name & " har skapats"
    
    On Error GoTo 0
   End Sub


 
5. Navigera till ”Kugghjulet” / Workflow / Script Editor / Requirements module script / Req_FieldChange och lägg till rader enligt följande:
    
   Sub Req_FieldChange(FieldName)
    On Error Resume Next
    
    On Error GoTo 0
   End Sub
    
   Sub Requirements_Req_FieldChange(FieldName)
    On Error Resume Next
    
     if FieldName= "RQ_REQ_STATUS" then
    
      set rs = TDConnection.ReqFactory
      set rst = rs.Item(Req_Fields.Field("RQ_REQ_ID").Value)
      rst.Mail "användare1", "", 0, "Krav " & rst.name & " har ändrats"
      rst.Mail "användare2", "", 0, "Krav " & rst.name & " har ändrats"
    
     end if
    
    On Error GoTo 0
   End Sub


 
6. Gör motsvarande för andra fält än RQ_REQ_STATUS vid behov.

ALM Site Administrator

Allmänt om ALM Site Administrator

ALM Site Administrator är ett administrationsverktyg som används för att skapa projekt och användare. Den kanske vanligaste åtgärden där är dock att avsluta sessioner för användare som blivit ofrivilligt utloggade ur ALM och låst den post de senast hade markerad.

För den som kan SQL går det också att köra SQL-frågor direkt mot de olika projektdatabaserna. Markera helt enkelt valfri tabell i databaslistan, skriv i SQL-fönstret och klicka på "Execute Query". För statistik är det visserligen lättare att arbeta i respektive projekt än i administrationsverktyget men ibland är det ovärderligt, till exempel när jag behövde radera en post med specialtecken som låste ALM så fort man markerade den posten.

Däremot kan man inte köra SQL-frågor mot själva ALM-databasen, där användarstatistik och annat intressant finns. Åtminstone trodde jag det tills jag upptäckte QCSITEADMIN_DB...

QCSITEADMIN_DB

Genom att ställa sig i vilket SQL-fönster som helst och använda QCSITEADMIN_DB.td som prefix för varje tabell i sökningen så kan man köra SQL-frågor direkt mot ALM-databasen. Till exempel kan nedanstående fråga användas för att ta fram statistik om hur många gånger användare loggat in i respektive projekt.

SELECT sh.USER_NAME as "User Name",
PROJECT_NAME as "Project",
MAX(START_TIME) as "Last Login Date and Time",
COUNT(sh.USER_NAME) as "Total Login Count",
EMAIL
FROM QCSITEADMIN12_55_DB.td.SESSIONS_HISTORY sh
  LEFT OUTER JOIN QCSITEADMIN12_55_DB.td.USERS
  on sh.USER_NAME=QCSITEADMIN12_55_DB.td.USERS.USER_NAME
 WHERE START_TIME>'2018-01-01'
GROUP BY sh.USER_NAME, PROJECT_NAME, EMAIL
ORDER BY "Total Login Count" desc, sh.USER_NAME

Tips om ALM

Avslutningsvis några tips hur jag jobbar effektivt i ALM:

1. Requirements

1. Skapa underkrav: Om de krav du ska testa är omfattande kan du dela upp dem i mindre delar ("minsta testbara nämnare") eller så kallade test conditions. Genom att skapa ett underkrav för varje test condition och länka varje testfall till respektive test condition så minskas risken för att du ska missa några viktiga tester.

2. Test Plan

1. Hitta testkörningar från Test Plan: Testkörningar lagras i Test Lab men du kan faktiskt komma åt dem också från Test Plan. Gå till fliken Test Configurations och högerklicka. Du får då upp kommandot "Go To Configuration in Test Set" som låter dig navigera till de olika testkörningar som finns.

3. Test Lab

1. Ändra testfall under pågående körning: Du kan ändra, lägga till och ta bort teststeg under pågående körning. Efteråt får du en fråga om du vill spara ändringarna och de sparas då i Test Plan och återkommer i alla framtida körningar. Tyvärr kan du inte ändra ordningen på stegen under körning utan det måste göras efteråt i Test Plan.
2. Gå från testkörning till defekt: Defekter skapade under körning länkas automatiskt till körningen. På defekten syns detta med en länksymbol men inte på körningen. Varför inte? Svaret är att länken görs från körningssteget så för att hitta den måste du gå via Test Lab / Execution Grid / Dubbelklick / Runs / Dubbelklick / Steps.

4. Defects

1. Favoriter: Skapa personliga favoriter för de filter eller grupperingar av defekter du använder ofta. Följande använder jag själv ofta:
• Defekter klara för test i mitt projekt: För omedelbara arbetsuppgifter
• Öppna defekter i mitt projekt: För daglig uppföljning av öppna defekter
• Mina öppna defekter oavsett projekt: För kontroll att defekter på mig ligger rätt
• Mitt teams öppna defekter oavsett projekt: För kontroll att mitt teams defekter är rätt registrerade
• Gruppering på prioritet, feltyp m m: För olika nedbrytningar av defektstatistik

5. Dashboard

1. Har du fler kategorier än du behöver för din statistik? Knappen "Edit Categories" låter dig gruppera kategorier i mer logiska grupper, t ex begränsa defekters status till endast Öppen eller Stängd.

6. Övrigt

1. Ingen sparaknapp: Ändringar i ALM sparas direkt när du lämnar en post, vilket är bra ibland men kan ge oväntade problem:
• Om du klistrar in en text med ogiltiga tecken i t ex ett testfallsnamn så kan du inte lämna fältet förrän du tar bort tecknet (om du nu vet vilket det är). Någon Ångra-knapp finn ej men Esc-tangenten återställer den gamla texten och låter dig lämna fältet.
• Om du ändrar rubrik och innehåll i t ex ett testfall så är risken stor att endast innehållsändringen sparas. Du måste först ändra rubriken, sedan lämna posten helt och först därefter gå tillbaka till innehållet och ändra det.

The Quality Dilemma - How poor quality arises and what we testers can do about it

(Denna text skrev på engelska för publicering på engelskspråkigt testforum.)

1. The Quality Concept

2. The Requirements

3. Quality vs Time and Cost

4. The Quality Dilemma

5. The Ten Tester Commandments

Kvalitet i agila projekt

Learning by Gaming

(Denna text skrev på engelska för publicering på LinkedIn.)

Does gaming facilitate learning? Well, as a gamer, teacher and tester, there is only one way to find out: test by designing a game that teaches testing. But let us start from the beginning.

My name is Nicholas Hjelmberg and among my many labels are tester and game designer. I have over 10 years of experience in the testing and quality field and have developed more than 10 board games. The idea of a test game was born when I gave test lectures to newly hired colleagues. Many IT professionals have a perception of testing as a simple and straight-forward task where technical knowledge of the solution is enough to test it. The exercies used in my corporate training did nothing to correct this perception. Instead, they focuesed on mechanic memorizing of concepts and rewriting requirements and design specifications into actions and expected results. Where was the curiosity and creativity? Where was the passion for quality?

To become a good tester, you need to have a quality mindset:

1. Testing is not about using a solution, it is about understanding a solution
2. Testing is not about confirming a solution, it is about establishing confidence in a solution
3. Testing is not limited to the solution only, it is covering all project activities leading to the solution

Obviously, a quality mindset is nothing that is created over a day but something that requires experience, own or others. Nevertheless, with the right pedagogical tools, the foundation of a quality mindset can be set and this where gaming comes into the picture. There are many reasons why games are great for teaching:

1. Games are fun and spark motivation
2. Games are social and create bonds outside the game
3. Games make abstract concepts more concrete
4. Games encourage players to ask questions and find answers
5. Games provide practice and feedback in a safe environment
6. Games are memorable and provide a context for what is being taught
7. Games provide rewards that reinforce the learning

One recent example of a successful IT teaching game is Robot Turtles a game introducing programming concepts to children. Testing concepts are just as important! If programming concepts can be learnt from a game, can testing concepts be that as well? Of course! After all, testing is not very different from gaming with a hidden objective (unknown bugs) and different ways to achieve it (test strategy).

The idea of a test game was thus born but it had to be nurtured and raised before it could mature. My continuous work with junior testers helped me identify knowledge gaps and my work with Nova Suecia Games helped me develop various game mechanisms that might be used to bridge those gaps. Finally I had everything I needed to design a test game: Find the Bug!

Find the bug! is a board game for players of all ages who want to learn IT testing in a fun way. Children will enjoy the thrill of picking tiles and see whether they contain a bug or not. Students will learn to analyze a system and plan their testing accordingly. Teachers will have concrete examples of testing concepts such as risk-based testing and regression testing. All of them will learn that testing is fun!

Find the Bug applies several testing concepts. The players represent test leads, responsible for assigning testers to analysis, design, test and automation tasks. The game board simulates a multitier architecture with 3 tiers and 3 modules. Using the principles of risk-based testing, the players must assess the business criticality and technial complexity of the solution and plan the tasks accordingly to find as many bugs as possible. In just half an hour, the players will have experienced an entire test project!

Find the Bug! does not claim to cover the entire testing area. There are many more things to learn and even the most experienced tester will still find new things to learn. However, used in a training context it may help students to understand the meaning of basic test terms and how they apply in a real test project. Hopefully they will have fun as well!

Find the Bug! is my way of giving something back to the testing community and help building and developing our profession. If you believe in the idea of learning testing by gaming, you are more than welcome to contribute to the journey, either by giving advice on the way or by backing the crowdfunding campaign at FundedByMe. You may also follow the progress at Twitter at #NovaSuecia. Remember that this is game is designed for you and as a tester, I want to make everything possible to satisfy your requirements. If this first "test" is successful, there are many more testing concepts waiting to be turned into games!

Recommended further reading:

• Nova Suecia Games
• Find the Bug! shop page
• North American Simulating and Gaming Association
• PaxSims
• Robot Turtles

Testing Methodology Applied to Games

(Denna text skrev på engelska för publicering på LinkedIn.)

Can software testing methodology be applied to games? That was the question that inspired me to start designing games under Nova Suecia Games. After all, testing is more than verifying and validating a product or a service, it is an ongoing quality effort covering all parts of a project from start to end.

The Test Process

Let us move into the general test process and see how a game project would fit into it:

1. Planning and Control: Identify what you need to test and how to measure it
2. Analysis: Define what to test
3. Design: Define how to test
4. Implementation: Prepare tests
5. Execution: Execute tests
6. Evaluation: Evaluate tests
7. Closure: Archive test documentation

1. Planning and Control

When you start designing a game, you probably have grand plans about everything you would like to include in it. But how do you verify that the parts are good? And how do you verify that the whole is good? Do you even know what will make your game good?

This is where an understanding of quality gets important. The PMI definition of quality is "how well the characteristics match requirements". To design a good game, you need to fulfil the game's requirements, and to keep you on the right track, you need to plan what to test and how to test.

So what are the requirements of your game then? To be fun of course - we play games to be entertained. But how do you test if a game is "fun"? The perception of fun is not only dependent on individual preferences but may also vary with time, place and other circumstances. Nevertheless, there are things you can do to break down your game's fun factor into concrete and testable requirements.

First, there are several objective criteria that are generally acknowledged. Wolfgang Kramer, designer of games like El Grande, lists the following:

1. Originality: The game has elements that, individually or combined, never been part of a game before
2. Replayability: The game is different each time it is played
3. Surprise: The game is not repetitive
4. Equal opportunity: At start, each player has an equal chance of winning
5. Winning chances: At the end, each player still has a chance of winning
6. No "kingmaker" effect: A player without hope of winning cannot determine the winner
7. No early elimination: All players are involved in the game to the end
8. Reasonable waiting times: There is no inactivity between turns
9. Creative control: The players has the opportunity to affect the game's progress
10. Uniformity: Title, theme, format and graphics give a unified impression
11. Quality of components: Game components are durable, functional and visually appealing
12. Target groups and consistency of elements: The elements are adapted to the game's target group
13. Tension: The tension is high throughout the game
14. Learning and mastering a game: The game takes short time to learn and long time to master
15. Complexity and influence: The more influence the players have, the more complexity in the game is tolerated

Second, there are objective criteria which depend on the game style.

1. Players: Solitaire, two players, players individually against each other, players teaming up against each other, players teaming up against the game etc.
2. Objectives: Capture, control, collect, solve, chase, build etc.
3. Information: Public to all, private to individuals, hidden to all etc.
4. Sequencing: Turn-based, simultaneous, real-time etc.
5. Interaction: Conflict, negotiation, trading, information sharing etc.
6. Theme: Abstract, narrative etc.

There is no right or wrong here. Generally, a game should be consistent but there are also exceptions where a good balance between contradicting criteria works. A no-luck game like chess would be a worse game with a random pawn promotion. Backgammon on the other hand combines the random dice roll with the strategic decision.

Third, there are also subjective criteria that contribute to make a game fun. Different games invoke different feelings in players and this is what truly makes a game unique. Chess and Trivial Pursuit are two popular games that satisfy most of the objective criteria and yet are completely different in terms of feelings. The objective of my games is to invoke the following feelings:

1. "I quickly understand the game objective and how to accomplish it"
2. "The game tells a story and I'm part of it"
3. "The gameplay is new and inventive"
4. "I need to cooperate directly or indirectly with the other players"
5. "I need to pay attention not only to my own play but also to the other players' play"
6. "I am master of my own destiny and don't rely on luck"
7. "The game keeps me veering between hope and despair"
8. "The game is open until the very end"
9. "Each new session is a new game"
10. "I want to play again!"

As a designer, you need to set a plan for the criteria of your game and design with those in mind. As a tester, you need to test how each element of the game satisfy the criteria of the game.

In my game Find the Bug!, I wanted to make the players feel they were test leads in a real project. The "fun" factor would mainly come from the relation between applying test techniques and finding bugs. However, the game must not be too complex but easy to learn and quick to play. By stipulating those and other criteria, I came up with a "mental checklist" for the game.

To summarize with Wolfgang Kramer's words: a good game will stay with us all our lives and make us long to play it again. Make sure that you understand the criteria that make your game good!

2. Analysis

When you understand your game's unique quality, it is time to analyse the specific criteria to test. Each criterion should be broken down to the smallest testable element possible. This may seem unnecessary or even counterproductive, as a game's quality is determined by how well all its parts work together as a whole. However, the analysis activity will help you understand why your game doesn't work and to tweak and tune all bits and pieces into perfection.

In my very first game test, I observed several areas of improvement but could not trace them back to the quality criteria of the game. The result was that I modified the game rather aimlessly and several iterations were required to get the game back on track. A proper analysis before the test would have helped me to do a proper root-cause-analysis afterwards.

The analysis is a dual activity where you in your designer role drive towards new exciting ideas and in your tester role checks the map to ensure that you are not losing the way. This is a critical phase of your game design because if you deviate from your game's unique quality now, it will be very difficult to return to it. Another good game designer, Reiner Knizia, designer of good games like Tigris & Euphrates, is of the opinion that "many people think that a game is finished when there is nothing more to be added. I believe a game is finished when there is nothing more that can be taken away and still leave a good game". In project methodology, this opinion is similar to the recommendation against "gold plating", where features are added that are not requested by the customers (your future players) and are not in the scope. An inventive battle system has nothing to do in an economic game and a stunning futuristic art would be completely wrong in a medieval game. No matter how much the designer in you like an idea, the tester in you must keep it out of the game. If the idea really begs for a game, put it on the shelf until you have a game that will make justice to it.

The outcome of the analysis should be an understanding of what elements to include (and exclude) in the game and what to test in each element. This may be a list of alternative game strategies to be tested for balance, of components to be tested for the physical use in the game or of art to be tested for consistency. Do not worry about a detailed list of elements at this stage, game design is an iterative process where you have to return and reevaluate your ideas. The important thing is that you know why you design the game in a certain way and why a certain test is necessary.

Returning to my game Find the Bug! as an example, one of my criteria was to replicate the daily work of a test lead. Of the many different tasks, I focused on that of finding bugs. As a tester cannot know where the bugs are but, using risk-based testing, may assess where they are likely to be, I needed a mechanism that could increase the odds of finding bugs. The test in this case would be to check the expected result of the different test strategies (ad-hoc testing and risk-based testing) and ensure that a risk assessment would give a reasonable pay-off (not too low but not too high either).

3. Design

If you know what to test in your game, it is now time to find out how to test it. Testing a game is much more than just playing it and the software testing methodology offers plenty of test types to choose from.

1. Functional vs Non-functional: "What" the game does vs "how" the game does it
2. White box vs Black box: Player perspective vs game perspective
3. Static vs Dynamic: Reviewing the game vs playing the game
4. Positive vs Negative: Playing the game vs breaking the game

Functional vs Non-functional testing

Functional testing covers everything that defines the game, that is how the players interact with the game and with each other. Which actions can a player take? What does she need to be able to take the action. What will happen after the action? Those are the kind of questions your design needs to answer and your testing to verify. The testing is independent of physical game components - it is only the "spirit" of the game that is tested. The purpose of the testing is to ensure that the game theoretically plays as expected.

Non-functional testing covers everything that is required for the game to be physically played. Which components are needed? How are they to be handled? Are they open or hidden to the players? Each component of the game must be designed with its purpose in mind and this purpose must be understood when testing.

A test that covers both functional and non-functional tests of a game is scalability: Does your game mechanisms work with more or less players (functional) and will more/less components be required (non-functional)? An iterative process is usually required where you design and test with different number of players to assess how many players the game can be played with and if the game needs modifications for different number of players.

One of the ways the players interact with Find the Bug! is to place pawns on the game board, either to check the probability of bugs or to try to find them. To design this, not only did I have to set the density and severity of bugs to balance the player strategies but also come up with a way for the players to get information about the probability of bugs without revealing the actual location of the bugs.

The functional test in this case was to test that the expected value of bugs from checking the density would be equal to the expected value of bugs of checking the severity. In addition, both strategies should have a higher expected value than the ad-hoc strategy of not checking at all.

The non-functional test on the other hand was to test the various ideas for physical representations of bugs, density and severity. Would the representation be transparent to the players? Would it keep the location of the bugs hidden? Would it be easy to set up and handle during the game? Without a pass on all those non-functional tests, this particular part of the game would not work!

White box vs Black box testing

In software testing, white box testing refers to to internal structures (how the software does it) and black box testing refers to functionality (what the software does) and. For game testing, I would like to transform this into testing from the game perspective and testing from the player perspective.

The game perspective (the white box) would be to identify different paths that the game may follow and calculate statistics for them. What is the average, minimum and maximum of a certain path? Are the paths balanced? Are there any dead ends? Will the components be enough? Those are questions that white box testing may answer for games.

The player perspective would be what you typically may think of when it comes to test: a live player session. However, you can and should do own player testing first by setting up various strategies and simulate them in action. This will help you understand what takes place in the mind of the players while playing your game.

For Find the Bug!, I relied heavily on spreadsheets for my white box and black box testing. The first image below shows a sample white box test case. In the game, testing is done by drawing 1 tier tile and 1 module tile from bags and if both tiles contain a bug, a bug is found. The test case simply calculates expected bugs for different levels of density and severity.

White box test case: Expected result per density and severity level

The second image shows a sample black box test case. In the game, players do not know the exact location of the bugs but may do analyses to get to know how many bug tiles there are in a bag and and draw conclusions about the probability. The test case simply keeps track of the players' scores for different analysis strategies.

Black box test case: Simulated result per strategy

Static vs Dynamic testing

Dynamic testing refers to all testing where you play out parts or the whole of the game. Static testing is the opposite and typically refers to reviews of components. It may be perceived as a daunting task but is nevertheless important. No matter how great your game idea is, poor static testing will prevent other players from realizing it or even render the game unplayable. As a designer, it is easy to become blind to details so make sure to document every design detail, no matter how small. Use the documentation as checklists and go through them carefully. Rule language, game examples, color codes, font sizes, position of images and overall consistency in the layout are among the things that belong to the list.

Positive vs Negative testing

Positive testing is all the testing that proves that your game works but what about negative testing? Negative testing refers to all attempts to break the game, intentionally or unintentionally. Are there loops which will prevent the game from progressing or dead ends that will prevent it from ending? Even classic games like go and chess have those issues that must be handled by special rules. ("Ko" prevents recurring positions in go and stalemates in chess ends in a draw). What if a player plays against the intentions of the game or even try to cheat? Or if a player deliberately attempts to sabotage the game to prevent the other players for winning? Or if a player promotes another player's victory (known as the "kingmaker" effect)? Depending on the style of the game, other negative scenarios may include bad starts (making the game boring for that particular player), unstoppable leaders (making the game boring for all other players) or too random victory conditions in the end (making the game towards the end uninteresting). Everything that may work against your game's unique quality constitutes a negative test scenario that must be tested.

One important negative test of Find the Bug! was to ensure that no player would know the location of the bugs, neither during setup, nor during gameplay. If this test would fail, the game would have no challenge. Another important test was to ensure that players doing analysis tasks would keep the information for themselves. Otherwise, an analysis would only benefit the players next in turn. I also had to ensure that a player could not lose the game for all the other players by deliberately failing to find bugs.

4. Implementation

By now you have a number of test cases for your game to ensure its quality. But how do you decide when to run all those test cases? The software testing methodology answer to this is the implementation phase. This is when you organize, prioritize and schedule your testing. One good starting point is to group them by test levels.

1. Unit test: Test of individual game elements
2. Integration test: Test of interactions between game elements
3. System test: Test of the game as a whole
4. Acceptance test: Test of the game with external players

As you can see from the above list, testing is a bottom-up process, where you first test the smallest parts of the game to make sure that they work before you test them together. This will help you isolate problems and trace them back to the source. However, it does not mean that testing is a one-way process. You will need to move back and forth between the test levels as you test and improve your game. Art is typically something that you go back and retest once the rest of the game works. The main benefit of grouping your testing in test levels is that it helps you test the right thing at the right time. Let us look at them more in detail.

Unit test

Unit test ensures that the smallest elements of the game works according to your quality criteria as discussed in the beginning of the article. This may refer to a certain component or a specific mechanism of your game that can be tested in isolation. Testing in isolation does not mean that you design in isolation - you should know the purpose of the element in the game but still only test the element itself.

A functional unit test in Find the Bug! was the expected value of bugs from different density and severity levels as described in Design. A non-functional unit test was to check the color codes of all green and black tiles.

Integration test

Integration test ensures that the elements of the game work together. However, while software systems are often modular, game elements are often so interrelated that it is difficult to test single relations. Instead, try to look at the flow of the game and identify events that need to work smoothly for a good flow. Allocation of resources, track of victory points and transactions between players are examples of events to test during integration test.

A functional integration test in Find the Bug! was that the different tasks of the game (analysis, test, retest) could be done on the game board at the same time. A non-functional integration test was to check that the tiles fit the squares on the game board.

System test

System test is when you actually play the game from start to end. The first system tests may be simulated but you should also produce a prototype at some stage. The prototype does not need to be fancy as you will likely have to rework and retest the game several times. System test is your chance to tick off as many quality criteria as possible before you invite other players to your test so try to simulate as many different player styles and scenarios as possible. Once all your quality criteria has been checked, you are ready for acceptance test.

Find the Bug! was simulated in spreadsheets several times before a prototype was ordered from The Game Crafter.

Acceptance test

Do you think your game is perfect now? Good, then it is time to see if external players share your opinion. Acceptance test is critical as this is the first time someone else than you plays the complete game. You should of course discuss game details with other designers during your work and perhaps even play early prototypes with them but at some point you will be needing input from players who have never seen the game before and can play it without any preconceptions.

Acceptance test should reflect an ordinary game session where the players (the testers) play your game as they would have played any other game and you (the test lead) act as an invisible observer. Ideally, this means that they should read the rules themselves and discuss any concerns among themselves without consulting you. Make sure to set the expectations so that they understand this - once your game is published, you will not be there to guide new players. (With less experienced players, you may consider acting as a game master; setting up the game, explaining the rules and supporting the game progress; but you should not let this be your only acceptance test.)

Prepare yourself for the acceptance test with the same checklist used in the system test and a journal where you can make notes of events and actions during the game. In addition, prepare a questionnaire to capture lessons learnt from the game. It is important to capture both good and bad things. Examples of questions include:

1. Which was your favorite/least favorite part?
2. Were any parts too long/too short?
3. What was easy/difficult to understand?
4. Was something missing/unnecessary?
5. Did the game engage you?
6. Did you feel that you could affect your progress?
7. Did you understand how to win?
8. Did the right player win?
9. Was it fun?
10. Do you want to play again?

For the first acceptance tests of Find the Bug!, test colleagues at work were invited and the above checklists and questionnaires prepared. Since the game may be played both with a teacher and by students on their own, I took on the role of a game master and prepared everything so that they could focus on the game experience. For later acceptance tests, I acted as an observer.

5. Execution

Now that you know what to test, how to test and when to test, it is finally time to actually execute the test. If you have followed the methodology so far, you are well on your way to ensure quality but the most important remains: documentation and investigation.

Whatever test type and test level you use, you should document the test, the expected outcome and the actual outcome. Also document information about the test environment, such as date, version and number of players. This will help you follow up issues afterwards. If possible, try to complete the test first instead of immediately trying to fix issues. Otherwise, you may fix only the symptoms, not the actual problems. Or worse, you may change things that actually work. Instead, collect as much information that you can and then apply a holistic perspective on them. The following questions should be answered:

1. Is it one issue or several in combination?
2. What is the root cause of the issue?
3. Which quality criteria are affected by the issue?
4. Could a similar issue be present elsewhere?
5. How can I fix the issue?
6. If I fix the issue, which other quality criteria may be affected?
7. How can I prevent this issue in the future?

Issues on lower test levels, such as the color of a component, may not require the full process above but you should nevertheless document and investigate them as well. Perhaps you need a better template? Perhaps other components have wrong color as well? What if you accidentally included components from an old version and your entire game needs to be reworked? A good documentation and investigation will help you avoid the issues in the future.

The early testing of Find the Bug! was much about finding a balance. The tables below show two excerpts of the test documentation. In test case 1 (early version), players would have 50% chance of finding bugs without analysis and only marginally better with analysis, making the pay-off time for letting a pawn analyse instead of test too small. Test case 2 (final version with less bugs) resulted in a better balance.

The higher the test level, the more important it is that you document and investigate issues, particularly if they are discovered by external players that may not be available when you start fixing them. Using the checklists and questionnaires above, facilitate a discussion where you elaborate on the game experience and brainstorm potential changes to the game. As a game designer, you must balance humbleness with integrity - do not be overly protective against criticism but do not blindly accept proposals either. You may have personal feelings for your game but you also know the reasoning behind certain elements and should share this knowledge with the other testers. It may be the case that the game's learning curve is too steep for only one session (which, depending on your quality criteria, may be another issue...).

My very first game acceptance test was a good example of bad practice: I participated myself, took in all the testers' opinions, without any discretion or any tracing back to the root cause, and ended up with a game far inferior to the game that entered the test.

For Find the Bug!, I had learned my lesson and did not participate in the game myself but acted as an observer and documented what I saw. One interesting observation was that they placed 2-3 testers on analysis tasks instead of the optimal 1. As expected, this resulted in low scores and all players actually finished on the same bug value: 2. I did explain how the game concepts related to test concepts but left the discussion to after the game. Some suggestions were given about placing the tiles on the board instead of in bags but when I explained the reasoning behind the setup (the relation between the color of the stone and the number of bugs), it was accepted. The most important test passed: they all wanted to play again!

6. Evaluation and Closure

With all the testing completed and the "perfect" game ready, what is the next step? Forget about all the hard work behind it and just let the game stand on its own? No, a game is tested every time it is played so it is important that you archive all your documentation for future reference. A FAQ could be created or strategy articles written. Other players may discover something that you missed or come up with ideas that you never thought of. You may consider designing new editions or expansions. In addition, you should take time to reflect back upon your work and think of the lessons you learned. For all this and much more, a good quality documentation of everything that went into your game and made it unique will be invaluable.

The following are some questions that a quality documentation may help answering:

1. How do you best learn/teach the game?
2. Would this strategy work/break the game?
3. If I add/remove this element, what may happen?
4. Which elements would benefit/suffer from changed components?
5. Can I prove my rights to copyrighted material (if any)?
6. If a player dislikes the game, is it because of the game itself or the player preferences?
7. Can/should the game be adapted to another audience?
8. Which game-defining elements are there that could be used in marketing?
9. Could elements included/excluded be applied to new games?
10. What should I keep doing/doing differently next time?

Although Find the Bug! was released only recently, the quality documentation has already come to use. Most noticeably, the children's game Find the Treasure! was built on some simplified mechanisms (the bugs were replaced by a hidden treasure) and some changed mechanisms (the permanently placed testers were replaced by moving pirates). I had no intentions to create such a game while working on Find the Bug! but during the lessons learned sessions with the testers, those mechanisms just begged to be used once more.

This concludes my ambition to apply software testing methodology to games. The key message here is that quality must be a red thread throughout the entire game design process. Understand what quality means for your particular game and ensure that you test the right thing at the right time and in the right way. This will not ensure the perfect game but hopefully help you recognize it when you see it.

All comments on this article or on the topic of how we game designers can bring quality to our games are welcome. Thank you for your interest and good luck with your own games!

Testification - Learn Testing through Gamification (Abstract)

(Denna text skrev på engelska för publicering på LinkedIn.)

Learning by Gaming has always been close to my heart and I have now been given an opportunity to share my thoughts on this topic. At the EuroSTAR Software Testing Conference in October-November 2016, I will give a speech on Testification - Learn Testing through Gamification. Below you will find a short introduction to my speech. If you would like to learn more, please feel free to use the discount code above to get 10% off your ticket price. (See below for full text.)

Key Messages

• Games make abstract concepts concrete
• Play testers to learn basic test concepts
• Play scrum masters to learn agile test concepts
• Play test leads to practice real challenges in a safe environment

Introduction

Gamification and board games are two emergent trends. Both appeal to the human curiousity to explore and discover. Testing is also about exploring and discovering so the game is an excellent medium to learn testing skills.

In this speech, I would like to describe how games can be used in the testing community, using three concrete examples that have been successfully applied at SQS.

• Find the Bug! lets the players analyze a system, identify risk areas and literally find the bug.
• Find the Bug – Agile! lets the players practice test-driven development by creating test cases and execute them.
• SQS Test Lead School lets the players take on the roles of test leads and be rewarded based on how well they plan their work and responds to challenges.

Speech Synopsis

Why are games great for learning?

1. Games are fun and spark motivation
2. Games are social and create bonds outside the game
3. Games make abstract concepts more concrete
4. Games encourage players to ask questions and find answers
5. Games provide practice and feedback in a safe environment
6. Games are memorable and provide a context for what is being taught
7. Games provide rewards that reinforce the learning

“When you know a solution to a given puzzle, it’s hard to find another one. When you don’t know the solution, you’re much more likely to find your own. Not knowing others’ solutions helps keep your own ideas fresh.”(Reiner Knizia, game designer)

Basic testing – Case study of Find the Bug!

1. Context: Players=testers, game components=test environment, actions=test activities
2. Goal: Find defects
3. Gameplay: Choose activities to maximize the number of found defects

Agile testing – Case study of Find the Bug – Agile!

1. Context: Players=scrum masters, game components=user stories, test cases and code, actions=iterative test and development
2. Goal: Build module through continuous integration
3. Gameplay: Design test cases, run tests, lay a puzzle where tested components fit together

Test management – Case study of SQS Test Lead School

1. Context: Players=test leads, game components=input to test plan, test environment simulator, unplanned events, actions=plan test, execute test, respond to test result and events
2. Goal: Utilize test resources optimally to deliver the highest quality
3. Gameplay: Role play test activities under supervision of teacher and get instant feedback

Conclusions

1. Test games provide visual cues to aid the learning of abstract concepts
2. Test games provide a clear link between test activities and test goals
3. Test games challenge the players to think and act like real testers

This speech is a compilation of the following previously held speeches:

Testification - Learn Testing through Gamification (Full text)

Learning by Gaming has always been close to my heart and I have now been given an opportunity to share my thoughts on this topic. At the EuroSTAR Software Testing Conference in October-November 2016, I will give a speech on Testification - Learn Testing through Gamification. Below you will find a short introduction to my speech. If you would like to learn more, please feel free to use the discount code above to get 10% off your ticket price.

Know Thyself

Let us start with a philosophical question that all of us are used to from our near and dear:

What do you do?

Perhaps you answer “testing”. If you have met another tester, you will probably have enough to talk about for the rest of the evening, but what if you talk to a non-tester? Do they smile politely and change the subject to conceal their ignorance of what you do? Do their eyes roll as they try to process the meaning of what do you do? Or do they follow up with more questions to learn more of what you do?

I typically get the first reaction from people I meet for the first time and the second reaction from my spouse. But what if you meet a curious person who asks good questions and challenges me for good answers, such as a three-year-old child?

Where is your goal?
Why is it difficult?
How do you reach it?

Would you be able to answer those questions? You probably know your work so well that you never reflect on those questions. But if you are unable to tell another person what you do, how can you train another person to do what you do? This is the major challenge for all trainers, yet the solution was elegantly formulated already by the Ancient Greeks:

Know thyself

Don't Learn how to Do, Learn how to Think

Now that you know yourself and know what you do, it is time to examine how you can enlighten other people. If we return to our clever three-year-old child, he or she learns by observing how adults do and does the same.

This works well for basic learnings, such as reading and writing, but how about more advanced learnings, such as reviewing a book or writing one yourself? Knowledge of other authors’ books may certainly help you avoid repeating other authors’ mistakes but will it help you writing a book of your own? Or will it steer you towards already known paths and restrict your own creativity? It is no coincidence that the words “create” and “creativity” have the same origin.

The same applies to testing. Knowledge of testing methodology, such as the ISTQB Syllabus, may certainly help us find the expected defects but it is the unexpected defects that are hard to find. The less open-minded we are, the harder it is to find those.

This challenge has been very well expressed by a famous Doctor in Mathematics, Reiner Knizia. He stated that “when you know a solution to a given puzzle, it’s hard to find another one. When you don’t know the solution, you’re much more likely to find your own. Not knowing others’ solutions helps keep your own ideas fresh.” Basically, he told us not to learn how to do but to learn how to think.

Encourage Creative Thinking

Now that we know the learning objective, we are ready to move on to the question on how to get there. How do we teach the students to think like testers? How do we stimulate their imagination and creativity? How do we ensure that the learning experience is engaging and memorable?

There is no single answer but rather several attributes that together help forming a good learning atmosphere.

Motivation

Motivated students are good students. If they learn through fun and engaging activities, they are more likely to participate whole-heartedly and remember what they learned afterwards. A typical example is team-building activities, where the students practice team-building first and discusses characteristics of good teams afterwards.

Context

Students that understand the big picture are more likely to understand the small details. To them, the learning “makes more sense” and they will remember common situations where it is applicable. A typical example is case studies, where students learn to find solutions in real life examples.

Concrete

Learning together with others’ let the students share ideas and see things from new perspectives. In addition, it also creates bonds that last beyond the learning session. A typical example is group work, where the students cooperate to deliver.

Answers

A good way to learn is to ask questions and get answers. The proverb “there are no stupid questions, only stupid answers” may have become a cliché but it is important that teachers create an atmosphere that encourages students to ask questions. A typical example is the Q&A session that usually follows lectures.

Feedback

Feedback serves a receipt that the students actually achieved something. More importantly, feedback also allows the students to “fail” in a safe environment and learn how to do better next time. A typical example is the school grades.

Rewards

You do not need to be an expert in behavioral psychology to understand that rewards encourages learning. Learning may be a reward in itself but additional rewards never hurt. A typical example is the graduation party.

This is a long list of attributes indeed. Is there really a setting that captures all of them? As a matter of fact, there is. This list is actually a list of attributes commonly found in modern board games!

• Motivation: Games are fun and encourage players to do their best.
• Context: Games provide a context for the players’ actions.
• Concrete: Games take abstract concepts and turn them into concrete actions.
• Social: Games let players interact with each other.
• Questions: Games provide answers to “what if” questions.
• Feedback: Games provide a safe environment to try different actions.
• Rewards: Games end with the players having accomplished something.

Represent Test through Games

Can test really be represented by a game you might be wondering. The idea is not far-fetched at all. Games have represented life throughout the History of Man. The Mancala game symbolizes sowing and harvesting while the military plans of Chinese warlords are said to have been the origin of the game of Go.

More modern examples include the game Robot Turtles, invented by the software entrepreneur Dan Shapiro to teach his 4-year old twins programming. Basically, the players play cards to program their turtles to find crystals on a board. Robot Turtles was a huge Kickstarter success with $630,000 raised and 25,000 games shipped.

Do you still wonder if test can be represented by a game? If not, let us return to our initial question about what we do as testers and see how a game can help us answer.

• A game should put you in a testing role
• A game should give you a testing goal
• A game should let you face typical testing challenges
• A game should offer you meaningful testing decisions

If our game can answer those questions, it will also teach us to think as testers. Our friend Doctor Reiner Knizia has expressed this very well by stating that ”it is the goal that is important, not the winning”. As you may have guessed, the good Doctor is also a designer of many good games.

Now let us start designing our test game!

Find the Bug!

For our test game, the two first questions are easy to answer. Your role is a test lead and your goal is to find bugs. To ”gamify” those concepts, we convert them into game components by letting our testers be represented by game pieces and our test environment be represented by a game board. To play the game, simply place a tester on a square and draw a tile to see if you find a bug.

So far, so good, but how about the other two questions? Where is the testing challenge and where are the meaningful testing decisions? As testers, we know that we never have enough time and resources for our testing, and our game must capture and convey this knowledge.

What if we limit the number of testers each player has? Then there will not be enough testers to place on all squares and hence not enough testers to find all the bugs. This is a bit better but now the number of bugs found is dependent on luck. We all know that good testers find more bugs, don’t we? We also know that the difference between a good tester and a bad tester lies in the decisions taken. Clearly, our game must answer the fourth question about meaningful decisions as well.

Now go back to your own everyday work and ask yourself how you test. Do you prioritize test areas where bugs are not likely to be found or to be critical? No, you probably apply some kind of risk-based testing and prioritize functionally complex or business critical areas. Why not let our players do the same?

What if we let our players use a tester not for testing but for analyzing the board and learning which areas are defect-prone? And what if we let them save a tester for retest or even automatic tests, covering several squares at the same time?

Our game now lets the players face several testing decisions, they must think like testers!

Find the Bug! deals with traditional V-model testing but how about modern agile testing? Can that be gamified as well? Of course!

Find the Bug! Agile

Our agile test game should answer the same questions as before about role, goal, challenges and decisions. Since agile testing activities are closely linked to development activities, let us put our players in the roles of scrum masters with the goal of coding components through test driven development and continuous integration. The code is represented by colored cubes and the components by tiles illustrating input codes and output codes.

The challenge for the players is to ”develop code” (acquire cubes) and ”test components” (place cubes) until the user story can be considered ”done” (the input codes placed on the components match the input codes required by the user story).

The decisions for the players are all about testing effectively (test so that you always have the code necessary to continue testing) and efficiently (test so that you pass as soon as possible).

Again, our players must learn how to think to ensure the early and continuous delivery of the Agile Manifesto.

Learn the Experience of a Tester

Find the Bug! and Find the Bug! Agile are only two of many examples of how game elements can be turned into testing exercises. As we have seen, games can teach students how to think like testers by letting accessible and memorable games represent test concepts. But testing is not only about creative thinking, it is also about experience and gut feeling, about the ability to expect the unexpected. Can games be used for that as well? They sure can!

Newly graduated students typically have a strong foundation of general skills, upon which specialized testing skills can be built. We are now ready to move on to the next skill step, that of experience, and this time we will do it the other way around by turning testing exercises into game elements.

Our journey will start with the fundamental test process of Plan-Analyze-Design-Execute-Close. For each of those activities we add game elements to strengthen the learning:

• Motivation: The students take the roles of experienced testers
• Context: The students work in a realistic project
• Concrete: The students get real testing tasks
• Social: The students work together in a project team
• Answers: The students get to search for answers themselves
• Feedback: The students get ”game benefits” for well executed tasks
• Rewards: The students get to use their ”game benefits” to execute tasks better

Plan with the End in Mind

In the planning activity, a role play is set up where the teachers play stakeholders that the students interview to collect information. The better the students perform, the more artefacts do they receive. The artefacts are typical documents that we testers manage on a daily basis, such as requirements, design specifications etc.

Using those artefacts, the students write a test plan and get it graded based on how well it covers test activities as well as the project risks. The grades come in the form of ”mitigation cards” that the students may play later during the project when they encounter typical test issues. We will come back to those in the Execute activity.

The key learning points include:

• Which key stakeholders are there in a project?
• How do you build a network?
• Which artefacts do a tester needs?
• Which information is relevant for a tester?
• How do you write a test plan?

Analyze with a Quality Mindset

In the analyze activity, the teachers guide the students how to review the artifacts and extract the information necessary to identify the product risks. Based on the product risks, the students prepare test scenarios, assess functional complexity and business criticality of them, and prioritize them in a test schedule.

The test schedule as such is not graded but as we saw in the example of the board game Find the Bug!, a good test prioritization will help you find bugs. We will come back to this in the Execute activity.

The key learning points include:

• Why are test scenarios important?
• How do you assess functional complexity?
• How do you assess business criticality?
• How do you prioritize test?
• How do you prepare a test schedule?

Test the Right Things and Test Things Right

In the design activity, the teachers guide the students what to test in different test stages, which test methods that are most suitable and how to write test cases.

The test cases are graded based on how well written they are and how applicable they are to the test stage chosen. This time, the grades come in the form of ”testing hours” that the students get to use. We will come back to this in the Execute activity.

The key learning points include:

• How do tests differ between test stages?
• How do you choose between test methods?
• Why are test cases important?

Execute as Planned and Replan Execution

The Execute activity is the grand finale of the training where the result of all the effort in the previous activities finally gets paid off — just like in real testing. Using their test schedule and testing hours, the students now allocate time to their test scenarios. The teachers feed the figures into a computerized version of Find the Bug! that return the number of bugs found and the severity of them based on hours, functional complexity and business criticality. Reviewing this bug report, the students replan as needed and proceed with the next test run.

How about the mitigation cards you might wonder? Yes, they are also used now. As in all test projects, the unexpected happens, and as all good testers, the students are expected to be prepared for the unexpected. The teachers reveal unexpected events and the students must play their mitigation cards (and motivate why they mitigate the specific event) to avoid issues.

The key learning points include:

• Why is a test plan important?
• Why is a test prioritization important?
• How do you interpret the test results?
• Which typical events must a tester be prepared for?
• How are those events mitigated?

Close when Everything is Properly Packed

The training is concluded with the students presenting their test findings to the class. The Close activity lets the students practice what to present and how to present it to provide a clear and concise summary of the test. More importantly, it gives the students the chance to stand in the spotlight and be at the center of everybody’s attention — just like real testers after a well performed testing!

The key learning points include:

• What should be included in a test closure memo?
• How do you support your test recommendation?
• Which lessons have you learned?

Conclusion

With that, the circle is completed. We have ”testified” a game by adding a test role, a test goal, test challenges, and test decisions. Using those game elements, we have ”gamified" a test project by providing the students with motivation, context, concrete tasks, social setting, answers, feedback and rewards.

Thanks to this, we have followed in the footsteps of many other games throughout History and taught students how to think like testers and how it feels to be a tester.

Thank you for your attention.