Over software testen: automatisch testen

Het automatische gedeelte van testen kan je op dezelfde vier niveaus doen als manueel testen: op het unit-, module-, integratie- en systeem-niveau. De eerste twee niveaus zijn echter niet bedoeld om als Software Tester te testen, omdat die niveaus typisch te testen zijn zonder dat je de software voor je ziet, dus niet in een browser, applicatie of app. De laatste twee zijn de niveaus die je als Software Tester daadwerkelijk automatische tests voor kan maken.

Bij automatisch testen maak je *iets* dat wordt omgezet in code en dat automatisch een deel van de software test. Dat *iets* is bewust zo vaag, omdat automatisch testen tegenwoordig meestal wordt gedaan door middel van “behavior driven development” waarin je geen echte code schrijft, maar gebruik maakt van keywords die door mensen te lezen zijn. Een test is dan direct door mensen te lezen, en ook door mensen die niets van programmeren weten. Aan de andere kant kan je voor dat *iets* ook echte code gebruiken in een reguliere programmeertaal (Java, C#, Python, enzovoort). In principe maakt het niet uit wat je gebruikt, zolang je er maar een afweging in maakt. Een voorbeeldje met keywords uit behavior driven development:

*** Test case ***
Inloggen
Ga naar inlogpagina
Voer gebruikersnaam in   $gebruikersnaam
Voer wachtwoord in   $wachtwoord
Klik op inlogknop
Verifieer dat inloggen is gelukt

Het idee hiervan is door iedereen te begrijpen: je opent een pagina, voert de gegevens in (en wat die gegevens precies zijn, kan je zelf bepalen), klikt op de inlog-knop en dan zou je ingelogd moeten zijn, dus dat verifieer je. Als dat verifiëren gelukt is, en er ondertussen niets is misgegaan, dan is de test case geslaagd! Achter deze keywords zitten uiteraard nog meerdere lagen, die vaak minder goed te begrijpen zijn door niet-IT’ers. Bijvoorbeeld: “Verifieer dat inloggen is gelukt” zegt wel wat het doet, maar niet precies hoe. Misschien kijkt hij wel naar of er staat “U bent ingelogd als …”, of dat de inlog-knop er niet meer is, of dat je op een ander scherm zit dat je alleen als ingelogde gebruiker te zien krijgt, of nog iets anders, of allemaal! Dat is maar net hoe uitgebreid je de test case maakt, en hoe de software zou moeten reageren. Want zo’n verifieer stap is precies het gedeelte dat je écht test: daar test je of wat je zou verwachten overeenkomt met wat er gebeurt.

Ook voor automatisch testen geldt hetzelfde principe als voor manueel testen: je kan niet alles testen, dus je wil testtechnieken gebruiken. Helaas zijn er bij automatisch testen nog wat meer belemmeringen: het kost veel tijd om één complete test case te draaien. Daarom zal je minder kunnen testen dan je manueel kunt doen. Maar doordat ze automatisch zijn, kan je ze wel elke dag een keer draaien. En dat gaat helemaal automatisch. En zo krijg je elke dag een overzicht van welke test case gelukt is, en welke niet. Door alle belemmeringen van automatisch testen wil een falende test case niet per direct zeggen dat er iets mis is. Het kan ook een incident zijn, bijvoorbeeld veroorzaak door een eerdere (terecht) falende test case. Maar als een test case meerdere keren achter elkaar niet goed draait, dan kan je er bijna vanuit gaan dat er echt iets mis is. Ofwel met de test case (die veranderd moet worden), ofwel met de functionaliteit van de software (die kapot is).

Het lastige aan automatisch testen is dat het veel onderhoud vergt. Er verandert nou eenmaal vaak veel aan de software. En als jij een verifieer stap hebt gedefinieerd die niet meer van toepassing is, gaat de test case fout, maar werkt de software nog wel. De test case kan ook fout gaan als een ding (knop, invoerveld, tekst) van plek verandert, want de achterliggende keywords gebruiken allerlei “selectors” om te bepalen op welke plek iets moet gebeuren. Een selector is precies wat de naam zegt: het selecteert iets (een knop, een stukje tekst, een deel van de pagina, enzovoort). En die selectors kunnen vrij snel veranderen. Als je twee knoppen hebt, en jouw selector is “de eerste knop op de pagina”, en de twee knoppen verwisselen van plek, dan gaat het mis.

Aan de andere kant heb je er ook enorm baat bij als je eenmaal genoeg automatische test cases hebt draaien. Als je elke dag weet dat de functionaliteit (met grote zekerheid) het nog doet, dan hoef je ook bestaande functionaliteit minder vaak manueel te testen. En eenmaal zo’n test geschreven, dan kan hij elke dag automatisch draaien.

In de praktijk zal je altijd een combinatie van manueel én automatisch testen nodig hebben. Je kan nou eenmaal niet alles afdekken met automatisch testen, omdat het daarvoor té tijdrovend is. Bovendien is er ook een kwestie van vertrouwen nodig: hoe weet je zo zeker dat die automatisch test cases echt alles zien wat jij als mens ook ziet? Dat is nooit zo, dan zou je teveel moeten verifiëren (staat elk knopje nog wel precies goed, zijn alle kleuren goed, …). Maar het grootste gedeelte, het gedeelte wat het meest belangrijk is, daar is automatisch testen heel geschikt voor. En zeker als je daar intern (in de code) veel veranderingen aan doet die extern (in de webapplicatie of app) niets veranderen. De automatisch test cases zouden het dan nog allemaal prima moeten doen. Elke dag weer.

Dit bericht is geplaatst in de categorie Beta met de tag . Bookmark de permalink.

1 Reactie op Over software testen: automatisch testen

  1. John zegt:

    Tip voor Test Automation: gebruik de Gherkin language! Daarmee beschrijf je heel mooi de uitgangssituatie, welke actie gedaan wordt en wat er dan gebeurt.

Geef een reactie

Jouw e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd met *