Het heeft even geduurd, maar hier is dan de tweede blog over testen. Dagelijks wordt er in de hele wereld getest op allerlei gebieden, maar we beperken ons in dit geval tot het testen van templates in combinatie met de Word add-in Orange Pepper style. Dat valt in de categorie software testen en in eerste instantie kijken we naar de testen die je als gebruiker uit zult voeren. Mogelijk heb je zoiets al eens gedaan voor deze add-in of een ander programma en dan zul je al snel gemerkt hebben dat er heel veel is wat getest kan worden. Je moet keuzes maken, want je wilt er natuurlijk niet te veel tijd aan besteden. Dat resulteert soms in maar wat “op goed geluk wat zaken uitproberen”. En dat is altijd zonde van je tijd: de kans dat je wat vindt is klein en achteraf weet je vaak niet eens meer precies wat je wel en niet getest hebt of wat er ook al weer uit kwam.
Dus: documenteer je testen. Al heb je alleen maar tijd om wat “steekproeven” uit te voeren, leg het vast, desnoods op een blocnote. Moet er later toch meer of opnieuw getest worden, dan weet je in ieder geval wat je de vorige keer gedaan hebt.
Maar veel beter is natuurlijk vooraf te bedenken wat je gaat testen en daarvoor maak je dan zogenaamde test cases. Of je nu als enkeling een simpele template gaat testen of met een compleet team een uitgebreide versie van Orange Pepper style, het vooraf bedenken van goede test cases is de beste investering om je tijd voor testen zo effectief en efficiënt mogelijk te besteden.
In het geval van uitgebreide testen door meerdere personen moet je het hele proces ook goed plannen en organiseren. Hier kom ik later nog op terug, maar of het testtraject groot of klein is, test cases zijn nodig, dus daar beginnen we mee.
Testen is dus in de basis niets anders dan het bedenken van test cases, het uitvoeren daarvan en het vastleggen van de resultaten. Je hebt daarbij te maken met wat men noemt een Device under test (afgekort DUT, in dit geval Orange Pepper style) die je een stimulus toedient (je klikt bijvoorbeeld op de knop “Nieuw document”) waardoor de DUT een response geeft (bijvoorbeeld het zichtbaar maken van het scherm om alle documentgegevens in te vullen). Wat je dan doet is kijken of de response datgene is wat je ook verwacht en als dat zo is, is de test gelukt en anders is de test mislukt.
Bij het maken van de test cases zet je al deze zaken op een rijtje, samen met nog wat andere gegevens. De totale lijst van alle gegevens van een test case ziet er dan als volgt uit:
1. ID: een of andere code (een nummer of wat je maar wilt) om deze test case uniek te identificeren. Dat is handig bij het maken van een test log (zie verderop) en bij het bespreken van resultaten.
2. Korte omschrijving bijvoorbeeld “Nieuw document maken”.
3. Startvoorwaarden waaraan voldaan moet zijn om de test uit te kunnen voeren (bijvoorbeeld: “Word is gestart en de Orange Pepper style ribbons zijn zichtbaar”).
4. Actie (de stimulus, bijvoorbeeld “Klik op de button Nieuw document”) .
5. Verwachte response (bijvoorbeeld het zichtbaar worden van het invulscherm voor de documentgegevens.
6. Showstopper Ja of nee. Dit geeft aan of het nog wel zin heeft om door te gaan als deze test mislukt. Krijg je bijvoorbeeld geen invulscherm te zien, dan kun je ook niet testen of bij het invullen van de gegevens de juiste controles worden uitgevoerd, want je kunt die gegevens niet invoeren.
7. Afsluiting: de acties die je uitvoert na afloop, bijvoorbeeld het opslaan van een gemaakt document als je dat in volgende testen nodig hebt of om op te ruimen zodat je aan de volgende test kunt beginnen.
Wat je misschien mist, is de werkelijke response, maar die leg je vast in je test log. Dit is de feitelijke vastlegging van de resultaten en die kun je gewoon toevoegen aan de omschrijving, maar wij raden aan dat apart te doen. Het wordt dan een minder dik document en bovendien moet je testen soms nog een keer uitvoeren waardoor je de beschrijving van de test cases elke keer gaat kopiëren.
Wat je vermeldt in je test log:
1. Test case ID het ID zoals in de beschrijving (is natuurlijk niet nodig als je beschrijving en log combineert).
2. Datum waarop de test is uitgevoerd.
3. Naam van de tester.
4. Systeem waarop de test is uitgevoerd (PC naam, login, naam enz)
5. Response. Als dat niet de verwachte is, is het vaak nuttig om deze te beschrijven of een screenprint toe te voegen, omdat dat waardevolle informatie is bij het zoeken naar de oorzaak van het mislukken.
6. Resultaat gelukt (als de response overeenkomt met de verwachte response) of mislukt. En dit zijn de enige mogelijkheden.
7. Opmerkingen. Alles wat je opgevallen is. Vooral als je wat meer ervaring met het systeem en testen hebt, zijn je observaties vaak erg nuttig voor degene die aan de hand van de testresultaten eventuele fouten moet oplossen.
Als je het bovenstaande bekijkt, zie je dat het heel wat is om te bedenken en bij te houden, zeker als er veel test cases nodig zijn (omdat er veel functies getest moeten worden). Juist daarom is het zaak om de test cases zo goed mogelijk te kiezen, dus geen overbodige te hebben. Bovendien is daarom ook de organisatie van het testproces ook zo belangrijk. Hier kom ik dan ook nog op terug.