Constructing Test Cases That Don’t Suck (and How to Avoid Common Mistakes)

Software testen is een cruciaal onderdeel van de software ontwikkelingscyclus. Zonder testcases mist u functionaliteitsproblemen of grote bruikbaarheidsfouten die uw eindgebruikers frustreren. Maar niet alle testcases zijn gelijk. Het schrijven van kwalitatieve, effectieve test cases is net zo belangrijk als het testen van uw applicaties. Sterker nog, slechte testcases kunnen resulteren in een testproces dat weinig effectiever is dan helemaal niet testen.

Dus, wat hebben slecht geschreven testcases met elkaar gemeen? Hoe kunnen software test professionals kwalitatief goede testcases schrijven en daarbij veelgemaakte fouten vermijden? Om daar achter te komen, hebben we op internet gezocht naar het beste advies voor het schrijven van effectieve testcases en hebben we een panel van ontwikkelprofessionals en softwaretesters benaderd en hen gevraagd hun mening te geven over deze vraag:

“Wat hebben slecht opgestelde testcases gemeen (en hoe kunnen ontwikkelaars deze fouten vermijden)?”

Met ons panel van Software Testing Experts:

Ontdek wat onze professionals te zeggen hadden door hun antwoorden hieronder te lezen.

Avaneesh Dubey

@qsometests

Avaneesh Dubey is de CEO van Qsome Tech. Zijn carrière is bezaaid met een sterke set van innovaties in verschillende aspecten van het bedrijfsleven: Mensen, Processen, en Technologie. Nu bouwt hij aan Qsome Tech als een baanbrekende innovator op het gebied van Software Kwaliteit.

“Er zijn een paar dingen die veel slecht opgebouwde testcases gemeen hebben…”

1.

Testgevallen moeten rekening houden met een verscheidenheid aan omstandigheden die de software geacht wordt te verwerken. De testcase moet in staat zijn de softwaremodule uitgebreid te testen met vrijwel alle mogelijke combinaties van hoofdcondities. Om alle combinaties van condities uitvoerig te kunnen testen, moet de auteur een manier vinden om deze condities zodanig te presenteren dat het voor anderen gemakkelijk is om ze na te kijken.

2. Bestrijken een klein deel van de functionaliteit – ze moeten een groter deel van het systeem testen.

Testgevallen richten zich vaak op een specifieke functie. Vaak wordt deze functie bepaald door het interne technische ontwerp van de software. In plaats daarvan moeten de testgevallen de gebruikspatronen en -stromen weerspiegelen. Elke test case zou moeten proberen om zoveel mogelijk van de flow te dekken als redelijkerwijs mogelijk is – over de technische grenzen van de onderliggende applicatie heen.

3. Testen volgens een specifieke gebruikersrol.

We hebben vaak gezien dat test cases zijn geschreven voor een specifieke gebruikersrol. Dit beperkt hen in hun reikwijdte en compromitteert daarom hun effectiviteit aanzienlijk. Testgevallen die het meest effectief zijn, weerspiegelen de gebruikspatronen. Een bedrijfsapplicatie, bijvoorbeeld, zou moeten worden getest met testgevallen die zijn ontworpen om het gehele bedrijfsproces te testen – waarbij alle gebruikersrollen en alle systemen die betrokken kunnen zijn bij het bedrijfsproces aan bod komen.

4. Geschreven om aan te tonen dat de meest voorkomende use-cases goed worden afgedekt in de applicatie.

Dit is, naar mijn mening, een van de meest voorkomende problemen en is een gevolg van wat ik noem een ‘luie’ benadering van testontwerp. De testontwerper herhaalt simpelweg het requirements document in testgevallen. In plaats daarvan zou de testontwerper op zoek moeten gaan naar de ‘corner-cases’ of ‘boundary conditions’. De meeste ontwikkelaars zijn gemakkelijk in staat om code te schrijven voor de meest voorkomende use-cases. De problemen komen bovendrijven op het moment dat er een omstandigheid is van de meest voorkomende use-case. Een goed ontworpen test case zal deze gemakkelijk opvangen.

5. Elke testcase kan volkomen nutteloos worden als hij niet systematisch wordt gecatalogiseerd en beschikbaar wordt gehouden voor gebruik.

Stel je een bibliotheek voor met boeken die niet gecatalogiseerd zijn en niet systematisch op de planken worden bewaard. Het zou onmogelijk zijn om de boeken te gebruiken als je ze niet gemakkelijk kunt vinden wanneer je ze nodig hebt.

Vaak worden honderden testgevallen met veel moeite geschreven en dan in een gedeelde mappenstructuur gedumpt. Hoewel dit kan werken als je heel weinig testgevallen hebt, stort dit in op het moment dat het aantal testgevallen toeneemt. Daarom hebben we een systematische tagging en catalogisering van testgevallen nodig. Vervolgens moet een test management systeem in staat zijn om testgevallen ‘eruit te trekken’ wanneer ze moeten worden uitgevoerd. Het maken en onderhouden van meerdere versies van testgevallen is cruciaal.

Wes Higbee

@g0t4

Wes Higbee is de president van Full City Tech Company.

“Testcode die geforceerd is, is meestal waardeloos…”

Er is misschien een regel dat er 100% codedekking moet zijn, of dat je geen code mag toevoegen zonder dat er minstens één test is uitgevoerd. Dus schrijven mensen net genoeg testcode om aan die regel te voldoen. Het is veredeld papierwerk, TPS-rapporten (Office Space).

Mensen leren door na te bootsen wat ze waarnemen. Dus als je testen eist zonder mensen te helpen de waarde van testen te begrijpen, dan zullen ze het als een ceremonie zien en proberen bestaande testen te kopiëren en er hun eigen use case in te stoppen.

Testen is geen doel op zich. Testen, wanneer nuttig, geeft vertrouwen, kan tijd besparen, en kan toekomstige veranderingen veiligstellen. Dus als mensen die deze voordelen hebben ervaren ze kunnen overbrengen op collega’s, dan zullen andere mensen die voordelen zoeken en dat leidt vaak tot productief testen.

Mensen die de voordelen van testen hebben ervaren moeten proberen die voordelen op te hemelen, niet het testen zelf. Als je bijvoorbeeld in een echt softwaresysteem ingewikkelde code gebruikt die in het verleden vol bugs zat, er een paar eenvoudige tests omheen zet en je hebt die bugs niet meer – dan zal het vertrouwen toenemen, mensen zullen niet meer zo bang zijn, en dat zullen ze onthouden en bij hun volgende onzekere gevoel de tests ter tafel brengen.

Je hoeft testen niet verplicht te stellen als mensen de voordelen ervan aan den lijve hebben ondervonden.

Bernard Perlas

@MyCorporation

Bernard Perlas is Quality Assurance Manager bij MyCorporation en heeft zijn opleiding genoten aan de DeVry University. Hij voert tests uit voor bestaande producten en updates van producten en interne systemen. Hij werkt aan het ontwerpen van UI-automatiseringstests en grey-box tests van sites om er zeker van te zijn dat de informatie correct is.

“Slecht opgebouwde testcases hebben vage teststappen gemeen…”

Om deze fouten te voorkomen, moet je specifiek zijn over datgene wat je aan het testen bent en duidelijk zijn over je stappen op de weg. Hoe specifieker je bent, hoe beter je in staat zult zijn om problemen te repliceren en verbeterpunten te identificeren en daarnaar te handelen.

Benjamin Waldher

@wildebeest_dev

Benjamin Waldher is de Lead Dev Ops Engineer bij Wildebeest.

“Slechte testcases zijn vaak erg afhankelijk van…”

De interne werking van de code die wordt getest, wat kan betekenen dat als interne details van een functie worden veranderd, de testcase zal breken – zelfs als de functie al goed werkt. Als je het gevoel hebt dat je deze fout maakt, kan het zijn dat de functies die je test te lang zijn, of dat je meer aan scheiding van zaken moet doen.

Matt MacPherson

@itsMattMac

Matt MacPherson is de oprichter van Edabit.

“Er zijn een paar dingen die slecht opgebouwde testgevallen gemeen hebben…”

1. Het testen van irrelevante zaken

Testen zonder een echt doel is zinloos. Ik ben een grote fan van het single responsibility principe. Elke unit test moet één ding testen en dat is het.

2. Meteen testen

Ik zal hier waarschijnlijk veel kritiek op krijgen, maar ik doe nooit unit tests voordat mijn ontwerpbeslissingen vaststaan. De reden hiervoor is dat ik weet dat ik grote veranderingen zal maken en dat die veranderingen waarschijnlijk veel van mijn tests zullen breken. Dit betekent dat ik in de praktijk ofwel minder tests zal schrijven ofwel geen grote veranderingen in het ontwerp zal aanbrengen. Beide zijn slecht, en wachten op duidelijkheid over het ontwerp lost het dilemma op.

3. Integratietesten vs. unit testen

Ik zie veel ontwikkelaars die integratietesten doen terwijl ze eigenlijk unit willen testen (en vice versa). Wanneer je de applicatie als geheel test op bugs, dan wordt dat gezien als een integratietest. De unit-test richt zich op het gedrag van één specifieke code-eenheid, terwijl de integratietest zich richt op het gedrag van de applicatie als geheel.

Manu Singh

@ClrMobile

Manu Singh is een Mobile Architect bij Clearbridge Mobile met ervaring in Android Design, Ontwikkeling en Testen. Bij Clearbridge beheert Manu projectresources voor een team van ontwikkelaars dat apps van wereldklasse bouwt voor zakelijke klanten.

“Er zijn verschillende gemeenschappelijke kenmerken van slecht opgebouwde testcases…”

Ten eerste kunnen de testcases te eenvoudig zijn, wat betekent dat ze alleen de hoofdfunctie testen zonder te veel extreme gevallen te testen. Om dit te voorkomen, moet een ontwikkelaar zoveel mogelijk hoekgevallen afdekken. Als een interface wordt ontwikkeld en een invoer vereist die niet triviaal is, dan is het testen op slechte of lege invoer belangrijk.

Ten tweede, slecht opgebouwde testgevallen geven niet weer hoe een gebruiker de functionaliteit zal waarnemen en gebruiken. Het maken van testgevallen hiervoor is lastiger, omdat je je moet verplaatsen in de denkwijze van een andere gebruiker. Overweeg om uw gebruikers te segmenteren en hun use cases te identificeren. Identificeer vervolgens de snelste paden om een gebruikersreis te voltooien, aangezien een gebruiker zal proberen het aantal stappen dat hij moet invoeren om een bepaalde reis te voltooien, te beperken. Het is belangrijk om verschillende use cases te kwalificeren, met ontwerpers en project managers om dit soort test cases verder te identificeren.

En tenslotte, een slecht geconstrueerde test case test niet tegen aspecten van een app die ervoor kunnen zorgen dat deze parallel of na elkaar wordt opgestart. Vaak testen de testcases alleen op een specifieke functie van een app zonder de vertakkingen te zien van meerdere functies die worden ingeschakeld en waarmee wordt samengewerkt. Het overwegen van cross-functionele testgevallen is belangrijk, vooral als er prestatiebeperkingen zijn. Twee schijnbaar gescheiden functies kunnen dezelfde bronnen gebruiken en zo deadlocks veroorzaken.

Rick Rampton

@QASource

Rick Rampton is Head of Client Success bij QASource en houdt toezicht op marketing, verkoop en klantenbeheer. Hij heeft een belangrijke rol gespeeld bij de opbouw van QASource, met een bewezen track record voor het opbouwen, managen en behouden van goed presterende offshore engineeringteams. Het hoofdkantoor is gevestigd in Pleasanton, Californië, QASource is een van ’s werelds toonaangevende software QA aanbieders.

“Er zijn meerdere herkenningspunten waaraan we een slecht geconstrueerde testcase kunnen herkennen…”

1. Vaak wordt in een samenvatting van de slechte testcases niet duidelijk wat het doel van de testcase is, of wat er bereikt moet worden.
2. De randvoorwaarden voor het uitvoeren van de testcase zijn niet duidelijk gedefinieerd of ontbreken, waardoor verwarring kan ontstaan bij de ontwikkelaar/tester over welke testgegevens of voorwaarden nodig zijn voor het uitvoeren van de testcase.
3. Als er stappen ontbreken in de testcases, dan laat dat hiaten achter voor de ontwikkelaar/tester, waardoor zij aannames maken bij het uitvoeren van de testcases. Dit kan leiden tot onnauwkeurige uitvoering van de testgevallen en het missen van belangrijke scenario’s.
4. Aanwezigheid van de juiste omgeving voor het uitvoeren van de testgevallen is een andere indicator van slecht opgebouwde testgevallen.
5. Als het verwachte resultaat niet duidelijk in de testcase is beschreven, dan zal de tester niet zeker zijn van de resultaten die hij met die testcase moet verifiëren.

Rachel Honoway

@rachelhonoway

Rachel is een ervaren executive die gespecialiseerd is in Internet Startups en Growth Mode Companies. Haar carrière bestaat uit het hands-on werken met ondernemers om SaaS-producten en aanverwante diensten te bouwen en te laten groeien.

“De volgorde van gebeurtenissen wordt vaak te eenvoudig voorgesteld, wat leidt tot een slecht geconstrueerde testcase…”

Ontwikkelaars hebben de neiging uit te gaan van een rechtlijnig, logisch pad van begin tot eind. In werkelijkheid zullen eindgebruikers echter een exponentieel aantal paden bewandelen, waarvan vele onlogisch zijn. Als ontwikkelaars niet de tijd nemen om alle variabelen te overwegen die van invloed kunnen zijn op de gebruiker op het moment dat ze worden geconfronteerd met de functie, dan laten ze veel ruimte voor vals-positieve tests.

In het algemeen zouden ontwikkelaars verschillende gebruikers moeten observeren tijdens hun interactie met het platform, en vervolgens wat tijd moeten besteden aan het vragen aan interne customer advocates (customer support, product managers, sales agents) om de gebruiker beter te begrijpen. Verkoopmedewerkers kunnen helpen definiëren wie de gebruiker is en de behoefte beschrijven waarin de applicatie voorziet. Klantenservice-medewerkers kunnen gemeenschappelijke knelpunten voor de gebruikers identificeren, zoals verloren wachtwoorden of veelvoorkomende aandachttrekkers zoals on-page advertenties. Productmanagers kunnen inzicht geven in de manier waarop de gebruiker met de applicatie omgaat en hoe die interactie past binnen de grotere workflow of dagelijkse routine van de gebruiker, waarbij ze afleidingen buiten de applicatie zelf kunnen beschrijven (het beheren van meerdere schermen tegelijk, mobiele gebruikers die meldingen ontvangen terwijl ze rijden, enzovoort).

Inzicht in wat de eindgebruiker van het logische, rechte pad afleidt, helpt ontwikkelaars bij het testen op deze variabelen en zorgt voor een succesvolle ervaring ondanks afleidingen, onlogische paden en verlies van focus.

Anthony Breen

@BreenAnthony77

Anthony Breen is medeoprichter en CEO van de app Feasty Eats. Feasty Eats is een geïntegreerd SaaS platform dat restaurants helpt om traffic te genereren tijdens hun low-volume tijden.

“When considering test cases…”

Het is belangrijk voor ontwikkelaars om terug te gaan naar enkele van de meest eenvoudige, maar toch meest belangrijke, aspecten van het onderzoeksproces. Net als bij een wetenschappelijk experiment zijn er twee factoren die bij elke ontwikkelaar op de voorgrond moeten staan om een effectieve en zinvolle test mogelijk te maken: duidelijkheid en controle. Meer in het bijzonder moeten duidelijk omschreven hypothesen en zorgvuldige aandacht voor de belangrijkste prestatie-indicatoren worden gecommuniceerd voor het begin van de test. Dit schept een sterk kader voor verder onderzoek.

Daarnaast is het essentieel dat alle variabelen niet alleen worden geïdentificeerd, maar ook zorgvuldig worden gecontroleerd. Vooringenomenheid moet worden geëlimineerd uit de testpopulaties en mogelijke verstorende variabelen moeten worden geïdentificeerd, zodat de ontwikkelaars inzichtelijke, nauwkeurige gegevens kunnen verkrijgen. Een goed gedefinieerd en duidelijk geformuleerd doel, in combinatie met een nauwkeurig gecontroleerde testomgeving, zal niet alleen waardevolle resultaten opleveren, maar nog belangrijker nieuwe vragen en hypotheses oproepen die leiden tot uitgebreider onderzoek.

Devlin Fenton

@devfen

Devlin Fenton is de CEO van Go99. Devlin leidt een klein, gespecialiseerd team van ingenieurs en programmeurs die zich toeleggen op het oplossen van problemen door de industrie, voor de industrie. Dit team heeft onlangs een digitaal vrachtmatching platform opgezet om de $700B trucking industrie van Noord-Amerika te ontwrichten. Devlin gelooft dat je een team van experts moet samenstellen en hen hun gang moet laten gaan.

“De ergste testgevallen zijn die welke niet bestaan…”

Verreweg het grootste probleem is dat er niet genoeg zijn en dat het systeem niet op een betrouwbare, geautomatiseerde manier opnieuw kan worden getest. Ze hebben geen aandacht voor prioriteit. Als ontwikkelaars eenmaal aan de slag gaan met het schrijven van testcases, ontwikkelen ze vaak veel van de makkelijke, die triviale, statische en weinig risicovolle code testen. Men zou zich moeten richten op complexe en risicovolle code en daarvoor is de use case soms ook complexer en moeilijker te ontwikkelen.

De overtuiging is dat als het geen unit test is, het ook niet gedaan moet worden. Integratietesten, datatesten, performancetesten, stresstesten, enzovoort moeten allemaal deel uitmaken van de testsuite.

Het gebrek aan focus in termen van het doel is een ander probleem. Bijvoorbeeld, is dit een unit test, integratie test, performance test, of een ander type? Het mengen van deze prioriteiten maakt de use cases brozer en moeilijker te repareren. Ze moeten focus hebben en dienovereenkomstig worden geannoteerd, zodat de testsuite doelgericht kan worden uitgevoerd.

Daarnaast missen sommige testgevallen grondigheid door slechts een happy path te bestrijken en niet genoeg van de alternate en exception flows. In feite volgt de use case de make-it-work-standaard van de ontwikkelaar, in plaats van de make-it-fail-standaard van het testen.

Een ander probleem zijn testgevallen die niet worden onderhouden, waardoor ze zouden falen als ze zouden worden uitgevoerd, of ze worden helemaal uitgecommentarieerd. In de haast, zullen ontwikkelaars vaak de code veranderen en het repareren van de testgevallen omzeilen.

Slecht geconstrueerde testgevallen kunnen ook onduidelijk zijn over wat er wordt getest, inclusief het object, de methode, of het scenario. Testgevallen moeten een conventie volgen (naamgeving, commentaar, etc.) die het makkelijk maakt om de scope van de test te identificeren.

Goede testgevallen vermijden een web van afhankelijkheden. Afhankelijkheden tussen testgevallen moeten worden vermeden; anders kan een enkele mislukking vele tests laten mislukken, waardoor het moeilijker wordt om de oorzaak te achterhalen. Als er een gemeenschappelijke logica is voor het opstellen van randvoorwaarden, of het evalueren van resultaten, moet die logica worden geabstraheerd en gedeeld in plaats van het stapelen van testgevallen.

Rohit Keserwani

@EquifaxInsights

Rohit Keserwani is BI-consultant en Sr. Business Analyst bij Equifax.

“Ik heb de volgende kenmerken waargenomen die vaak in slechte testcases voorkomen…”

1. Impactanalyse niet gedocumenteerd. Wanneer een testanalist de impact niet documenteert, gaat hij ervan uit dat hij de impact niet kent. Het resultaat? POOF…!

2. De testvoorwaarde is of niet gedefinieerd of losjes verwoord.

3. De achtergrond van de gebruiker over het hoofd zien en dingen aannemen. Als je niet begrijpt wat het kennisniveau is van degene die gaat testen, ga dan nergens van uit. Documenteer alles tot in het kleinste detail. Zo niet, dan zou het kunnen gebeuren dat u een bepaalde kennis aanneemt die niet aanwezig is, waardoor de gebruiker anders zou kunnen testen dan verwacht.

4. De criteria voor slagen en tolerantie zijn niet duidelijk gedefinieerd. Als om wat voor reden dan ook de doorslagcriteria niet zijn geformuleerd, wordt het aan de testpersoon overgelaten om te beslissen of een bepaalde test geslaagd of mislukt is. Als je geen duidelijk gedefinieerd slaagscenario hebt, heeft de tester geen benchmark om mee te vergelijken. Dat zorgt voor onduidelijkheid en zet uiteindelijk de hele testinspanning op het spel.

Pete Van Horn

@PraxentSoftware

Pete Van Horn is een Business Technology Analyst bij Praxent.

“Ik heb veel ervaring met slecht opgebouwde testcases, en ik maak me er waarschijnlijk ook af en toe schuldig aan dat ik ze schrijf…”

Vaak is een testcase niet goed uitvoerbaar. Als ik een ontwikkelaar ben, moet ik genoeg informatie hebben en zo gepositioneerd zijn dat ik mijn testcase kan uitvoeren om een uitkomst te bepalen. Ik denk dat één ding over testgevallen is dat ze niet noodzakelijk moeten resulteren in het beoogde resultaat, maar ze moeten altijd uitvoerbaar zijn van einde tot einde. Zelfs als je een negatief resultaat krijgt, is dat beter dan vastlopen. Een slecht geconstrueerde test case stelt degene die de test uitvoert niet in staat om hem volledig uit te voeren.

In termen van fouten van ontwikkelaars, misschien denk ik er te veel over na, maar meestal schrijven ontwikkelaars de test case niet. Ze schrijven misschien unit tests, maar een test case wordt meestal geschreven door een business analist of een solution architect. Zij zijn verantwoordelijk voor het maken van wat het verwachte resultaat zou moeten zijn. Ik zou zeggen dat het hebben van goed geschreven testgevallen echt zijn oorsprong vindt in het hebben van echt goed geschreven requirements. Het hebben van goede vereisten stelt je in staat om een goede test case te maken. En een goede testcase kan van begin tot eind worden uitgevoerd, zonder onderbreking.

Hans Buwalda

@logigear

Bij Stackify begrijpen we hoe cruciaal het testen van software is in de ontwikkelingslevenscyclus, dus het is een onderwerp dat we regelmatig bespreken. Wist je dat je APM kunt integreren in je teststrategie? Lees hier hoe.

Voor meer deskundig advies over het schrijven van kwaliteitstestcases (en waarom het net de wetenschappelijke methode is), bekijk je deze post, of bezoek je dit artikel voor een lijst met 101 deskundige tips en adviezen voor het testen van software om het meeste uit je testproces te halen. Voor een meer diepgaande kijk op de soorten prestatietesten en softwaretesten, stappen voor prestatietesten en best practices, bezoek je deze gids.