by René Ceelen,
on september 24, 2020
Testgevallen zijn erg belangrijk bij het bepalen van software kwaliteit. Het zijn de eerste stappen in een testcyclus en als testgevallen niet voldoende kwaliteit hebben, heb je daar het gehele project “last” van. Het schrijven van goede testgevallen is een vaardigheid die in de praktijk wordt vormgegeven (door het gewoon te doen!). Maar het is wel handig om een paar handvatten te hebben die je helpen. Met dit artikel wil ik jullie handreikingen geven om het makkelijker, leuker en beter te maken. De tips die worden gegeven hebben met name betrekking op de testgevallen bij het acceptatietesten van ERP-systemen.
Wat zijn testgevallen?
Omdat er binnen de testwereld nogal wat definities zijn is het van belang om onze definitie te benoemen. In onze filosofie is een testgeval (gebaseerd op IEEE610):
“Een verzameling van testinstructies, welke in specifieke omstandigheden worden uitgevoerd, verwachte resultaten opleveren van een vooraf bepaald doel.”
Weten hoe je goede testgevallen schrijft is uiterst handig voor iedereen die wil gaan testen. Of je nu een functionele test of een gebruikersacceptatietest gaat uitvoeren of een webapplicatie gaat testen, een module van een ERP-systeem of een mobiele applicatie, in alle situaties bepalen de testgevallen in welke mate de resultaten een oordeel kunnen geven over het vooraf gestelde doel.
Waarom is het schrijven van testgevallen dan zo moeilijk?
Zoals in de definitie al omschreven zijn testgevallen een verzameling van testinstructies die een doel moeten bewerkstelligen. Het uitvoeren van testgevallen helpt ons dus informatie te ontdekken om dat bepaalde doel te realiseren.
Het eerste probleem waar we nu al tegenaan lopen is de diversiteit aan mogelijke doelen. En omdat er verschillende soorten testen en doelen zijn heb je dus ook navenant verschillende soorten testgevallen.
Een tweede probleem heeft betrekking op de inhoud van de daadwerkelijke testinstructies of -stappen. Het niveau van het uitschrijven van deze instructies is weer afhankelijk van de type tester die deze informatie moet interpreteren en een oordeel moet geven. Een professionele tester zal andere instructies nodig hebben dan een eindgebruiker die betrokken wordt bij het acceptatietesten van een ERP-systeem.
Het laatste probleem heeft betrekking op de definitie van “goed”. Het bepalen van “goed” is nogal discutabel. Geen enkel testgeval zal “goed" zijn voor alle situaties. Het is van belang om dit in de context van het project vast te stellen en hier consensus over te krijgen.
Tip 1: Bepaal je doel en wat je wil rapporteren
Denk na over wat je wilt rapporteren, zodat je het afgeleide doel kunt vaststellen. Op basis daarvan heb je de contouren van de testgevallen in beeld. Er zijn verschillende doelen, waarbij we telkens onszelf de vraag moeten stellen wat we proberen te leren of te bereiken als we de test gaan uitvoeren. Hier zijn enkele voorbeelden:
- Het vinden van gebreken. Dit is het klassieke doel van het testen. Een test wordt uitgevoerd om de gebreken bloot te leggen.
- Maximaliseer het aantal bugs. Het onderscheid tussen “maximalisatie van bugs” en “het vinden van gebreken" is dat het totale aantal bugs belangrijker is dan de dekking.
- Blokkeer voortijdige product releases. Het doel van deze test is om voortijdig dusdanig veel ernstige gebreken (showstoppers) te vinden dat niemand het product in productie neemt.
- Ondersteun managers met hun go/no-go beslissingen. Managers maken beslissingen op basis van de risico’s. Risico indicaties als testdekking, impact van gevonden gebreken, e.d. geven hen een betere achtergrond om daarop hun beslissingen te funderen.
- Beoordeel conformiteit volgens specificatie. De gestelde specificatie worden gecontroleerd op hun werking. Alle zaken die niet gekoppeld zijn aan de specificaties worden buiten beschouwing gelaten.
- Beoordeel de kwaliteit. Dit is een lastige doelstelling, want kwaliteit is multi-dimensionaal. De aard van kwaliteit is afhankelijk van de aard van het product. Om de kwaliteit te beoordelen moeten duidelijke kwaliteitscriteria worden opgesteld die zo zijn opgesteld dat ze ook daadwerkelijk meetbaar gemaakt kunnen worden.
De testresultaten als afgeleide van de testgevallen geven direct relevante informatie over het doel.
Tip 2: Reserveer voldoende ontwerptijd
Reserveer voldoende tijd om je testgevallen te ontwerpen, zodat deze aansluiten bij je doelstellingen. Slechte testgevallen blijven je in het gehele testtraject achtervolgen. Het vergelijken van testresultaten, het rapporteren over meerdere testrondes, e.d. worden in essentie bepaald door de kwaliteit van je testgevallen.
Mocht je nu echt te weinig tijd hebben voor het ontwerpen, maar wil je toch beginnen met testen, zorg dan dat je de belangrijkste risicogebieden in ieder geval hebt omschreven. Indien 10 testers ieder 5 testgevallen met 1 teststap moeten beoordelen ontstaan er 50 testresultaten. Deze 50 testresultaten geven in ieder geval al meer informatie over de kwaliteit dan helemaal niks doen. Waarschijnlijk niet uitputtend, maar wel een eerste aanzet. Van daaruit kan de detaillering voor bepaalde onderdelen dan worden bepaald.
Onze voorkeur is dat je vooraf goed nadenkt over hoe de test vormgegeven moet worden en dat de resultaten van de test ook daadwerkelijk antwoord geven op de gestelde doelstelling. Maar de praktijk is soms weerbarstiger.
Tip 3: Naam testgeval
De benaming van een testgeval is belangrijk. Bij een beetje ERP test heb je al snel meer dan 500 testgevallen. Je zult begrijpen dat een logische benaming de terugvindbaarheid bevorderd. In de literatuur wordt vaak verwezen naar een zo compleet mogelijke naam, waarbij het te testen requirement, module, object, e.d. allemaal in de naam worden verwerkt. Je kunt je voorstellen dat 500 testgevallen voorzien van zo'n complete titel een behoorlijke onoverzichtelijke administratie oplevert. Met een simpel Excel lijstje raak je dan ook al gauw het overzicht kwijt. Testmanagement tools bieden hiervoor een structuur, waarmee je testgevallen kan relateren aan herbruikbare objecten, zonder dat deze de naam "vervuilen".
Binnen TestMonitor bijvoorbeeld is daar een andere oplossing voor bedacht. Daarin kun je labels definiëren die je vervolgens kunt koppelen aan de testgevallen. Binnen TestMonitor zijn de testgevallen dus aan een of meerdere bedrijfsproces-, risico-, requirement- of applicatie labels gekoppeld. Hierdoor kunnen testgevallen vanuit verschillende perspectieven gegroepeerd en teruggevonden worden.
De benaming van een testgeval binnen TestMonitor volstaat met een duidelijke omschrijving van het doel van het testgeval. Simpel gezegd omschrijf je een activiteit met een impliciete verwachting.
Voorbeeld benaming testgeval:
“Opzeggen huurcontract - zelfstandige woning”
”Aanmaken klant”“Voorlopige ontvangstboeking”
etc.
Voorbeeld van testgeval “voorlopige ontvangstboeking” welke gekoppeld is aan enkele labels:
- bedrijfsproces ‘Ontvangst goederen’
- requirement "Een voorlopige ontvangstboeking moet binnen 30 dagen na de order zijn aangemaakt"
- risico ‘Operationeel risico’
- applicatie ‘ERP’
Belangrijk is om per testgeval het verwachte resultaat te omschrijven. De tester weet dan in welke richting het “antwoord” moet liggen en heeft dan direct een expliciet toetsingskader.
Tip 4: Omschrijving teststappen
Zoals in de definitie al omschreven zijn testgevallen een verzameling van testinstructies die ons helpen informatie te ontdekken om een bepaalde doel te realiseren.
Een testgeval moet een duidelijk begin en einde hebben om vast te stellen of het testgeval geslaagd of niet-geslaagd is. Daarnaast bestaat een testgeval uit één of meerdere testinstructies of -stappen, waarbij ook meerdere paden mogelijk zijn om het gewenste resultaat te bereiken. Het alleen testen van het succespad is vaak onvoldoende. Voor bepaalde situaties kunnen juist verschillende niet-succespaden het verschil maken.
Het is belangrijk om de teststappen zo duidelijk mogelijk te omschrijven zodat eindgebruikers voor een gebruikersacceptatietest precies weten wat ze moeten doen. Natuurlijk zijn hier ook pré-condities bij te verzinnen, zoals functieniveau tester, opgedane kennis van het nieuwe systeem, opgedane kennis van de mogelijk aangepaste bedrijfsprocessen, e.d. maar in essentie zal iedereen alle teststappen moeten begrijpen.
Stel dat we bijvoorbeeld het testgeval “opzeggen huurcontract - zelfstandige woning” verder uitschrijven voor een simpel succespad:
- Selecteer een eenheid en start de huuropzegging. Controleer of er voorwaarden zijn waaronder de huuropzegging wel/niet worden geaccepteerd en leg dit eventueel vast.
- Plan een afspraak voor de eindinspectie
- Vul de gegevens in het scherm Opzegging huurcontract. Controleer de huurdergegevens in de Huurcontractopzeggingskaart.
- Registreer de huuropzegging en stuur de bevestigingsbrief. Controleer of de bevestigingsbrief in het digitale archief terecht is gekomen.
- Controleer in het contractoverzicht van de eenheid dat het huidige contract is beëindigd, dat het beëindigd contract is gekoppeld aan de huuropzegging en dat er een leegstandscontract is aangemaakt.
- Controleer het nieuwe (leegstands)contract op basis van het huurprijsbeleid en de element sjablonen.
Wat valt je op?
- Elke teststap begint met een werkwoord
- Gevolgd door een onderwerp
- Afsluitend met detaillering en eventueel controle vragen. Je zou ervoor kunnen kiezen om deze controle vragen in aparte teststappen te zetten, maar de praktijk leert dat de controlevraag een verfijning is van de actie en dan logischerwijs bij de teststap wordt opgeschreven.
In het bovenstaande voorbeeld wordt de aanname gedaan dat een specialist van een bepaald vakgebied de teststap gaat beoordelen. En omdat het een specialist is, worden geen input-condities meegegeven of expliciete verwachting geschetst, omdat de specialist zijn eigen cases zo uit zijn mouw schut en ook de verwachting glashelder in beeld heeft.
Mocht je nu geen specialist hebben, kun je de teststappen uitbreiden met input-condities en expliciete verwachtingen.
Bijvoorbeeld teststap 1 bij testgeval “huuropzegging - zelfstandige woning” met meer detaillering.
- Selecteer de eenheid “Krommenakker 677” en start de huuropzegging. De voorwaarden zorgen ervoor dat deze eenheid niet kan worden opgezegd, voordat de achterstanden zijn betaald.
- etc.
Tip 5: Niet meer dan 10 testinstructies in 1 testgeval
Wij komen nogal eens testtrajecten tegen waar >50 teststappen worden ontworpen bij één testgeval. Dit is teveel om een paar redenen:
- Alle teststappen moeten afzonderlijk worden doorlopen (of expliciet worden overgeslagen) voordat het testgeval een oordeel krijgt.
- Het eindoordeel van een testgeval wordt bepaald door de “slechtste” score. Het kan dus best zo zijn dat 49 teststappen “goed” werden beoordeeld en één “fout” wat resulteert in een “fout” testgeval. De weging van de teststappen moet hierbij ongeveer gelijk zijn. Daar bedoel ik mee dat elke teststap nagenoeg gelijk moet zijn in het effect van de beoordeling. Als je 10 teststappen moet doorlopen, waarvan er 2 dusdanige kleine teststappen zijn dat ze niet in verhouding staan tot de andere 8 teststappen, moet je deze herformuleren. Hetzelfde geldt andersom met een te zware teststap.
- De tester bij teveel teststappen binnen een testgeval snel de weg kwijt raakt. We hebben hier geen wetenschappelijke studie van gemaakt, maar de praktijk leert dat een testgeval niet meer dan 10 teststappen moet omvatten. Er zijn vele uitzonderingen te bedenken (conversiecontroles, e.d.), maar voor een gebruikersacceptatietest werkt dit in de praktijk het beste.
- Het is moeilijk voor ontwikkelaars om een geconstateerde fout te reproduceren. Met veel teststappen zal de ontwikkelaar voor het naspelen van de situatie veel tijd kwijt zijn. …
- Hertesten van grote testgevallen kost te veel tijd. Wanneer een fout wordt geregistreerd door een tester, zal het betreffende testgeval opnieuw getest moeten worden. Een hertest vereist dat iedere stap opnieuw wordt beoordeeld, je wilt regressiefouten natuurlijk voorkomen. Door te veel teststappen op te nemen test je waarschijnlijk te veel, waardoor testtrajecten langer duren en uiteindelijk je testers te zwaar belasten.
Tip 6: Review door een niet-ontwerper/ leverancier
In de praktijk zien we regelmatig testscripts die opgesteld zijn door de programmeurs van de softwareleverancier. Bij het reviewen van deze testscripts door de uiteindelijke testers blijken er meer vragen dan antwoorden te zijn. Andersom werkt dit hetzelfde dat indien de testscripts door de eigen medewerkers zijn opgesteld het een echte meerwaarde geeft om deze te laten reviewen door de softwareleverancier. Zij bekijken het opgeleverde met andere ogen en komen altijd met zinvolle toevoegingen of aanpassingen.
Met een beetje brainstormen met de specialisten van de softwareleverancier en de klantorganisatie heb je snel de essentie van hetgeen getest moet worden in beeld. Neem daarna de tijd om de testgevallen, niet-succes scenario’s te overwegen en je zult zien dat je testmodel snel uitgebreider en gedetailleerder wordt. Daarnaast krijg je meer informatie over de kwaliteit die je voor mogelijk had gehouden.
Tip 7: TestMonitor
Maak daarnaast gebruik van een professioneel testplatform en maak kwaliteit echt inzichtelijk. Vraag vandaag nog een gratis proefversie van TestMonitor aan en zie en ervaar het verschil voor jezelf.
Start testing with TestMonitor
Not a TestMonitor user just yet? Good and easy testing is key priority to quality assurance managers, testmanagers, IT-managers, test managers and the release manager. TestMonitor makes testing easy and fun for test users as well.
So let's get you started. You might want to check out our video or download the product leaflet. But of course, with a free trial you can really experience the ease of use of TestMonitor yourself.
