Software testen, hoe werkt dat?

Software testen is belangrijker dan ooit. Nu software een steeds grotere rol speelt in bedrijfsprocessen, kan een bug, issue of ander mankement in een nieuw opgeleverd product een grote impact hebben. Denk aan een webwinkel waarbij de orders niet meer uit de printer komen. Of een website waar klanten een foutmelding krijgen bij het inloggen. En zo zijn er nog duizenden andere scenario’s te bedenken!

Het testen van software is dus minstens zo belangrijk als het ontwikkelen ervan. Door het product te onderwerpen aan een grondige testprocedure, krijg je inzicht in de kwaliteit maar ook in de risico’s die de nieuwe software met zich meebrengt. Een goede test is echter meer dan even checken of alles nog werkt: software testen is tegenwoordig een aparte discipline.

Welke softwaretesten?

Er zijn een paar belangrijke hoofdcategorieën als het gaat om het testen van software:

• Functionele testen, waarbij je checkt of de ontwikkelde functionaliteiten doen wat ze zouden moeten doen;
• Niet-functionele testen, waarbij je op niet functionele zaken zoals gebruiksvriendelijkheid checkt of de webapplicatie naar behoren werkt;
• Beveiligingstesten, waarbij je nagaat of de nieuwe software beveiligingsrisico’s met zich meebrengt.

Functionele testen

Het functioneel testen van een webapplicatie houdt in dat je controleert of de nieuwe software voldoet aan de (vooraf) gestelde eisen. Daarbij zijn de volgende vragen belangrijk:

• Welke functies moet de software uitvoeren?
• Met welke data en op welke manier kunnen we deze functies testen?
• Wat is de verwachte uitkomst van de test?
• Welke uitzonderingssituaties kunnen zich voordoen?

Functioneel testen doe je het beste met behulp van testcases: je bedenkt situaties die bij het gebruik van de webapplicatie zouden kunnen voorkomen en voert deze uit. Denk aan het verkeerd of gedeeltelijk invullen van een formulier. Of inloggen met een verkeerd wachtwoord. Vervolgens kijk je wat er gebeurt. Hoe reageert het systeem? Wat gaat er wel goed, wat niet en hoe kun je dit probleem eventueel voorkomen/oplossen?

Er zijn heel veel situaties waarin er iets mis kan gaan. Zomaar een paar steekproeven nemen, is dus niet voldoende. Er zijn dan ook meerdere soorten functionele testen die je op verschillende momenten tijdens het softwareontwikkelproces kunt inzetten. Een paar voorbeelden van functionele testen:

• Unittest. Hierbij schrijft de ontwikkelaar vooraf een geautomatiseerde test waarmee een deel van de code van een webapplicatie wordt getest op het te verwachten resultaat. Komt er een ander resultaat uit dan vooraf door de ontwikkelaar gedefinieerd? Dan gaat er iets fout in de applicatie.
• Smoketest. Een test die aangeeft of de basisfunctionaliteiten werken, de zogenoemde happy flow. Is dat inderdaad het geval, dan kan de software verder ontwikkeld en getest worden. Dit is vaak een snelle eerste test die door iemand anders dan de ontwikkelaar wordt uitgevoerd.
• Regressietest. Met een regressietest check je of de systeemonderdelen waarvoor de software níet is aangepast nog werken nadat er nieuwe functionaliteiten zijn toegevoegd.
• Integratietest. Hiermee controleer je of verschillende onderdelen van de software goed samenwerken.

Automatisch testen webapplicatie: voor- en nadelen

Zelf testen kan behoorlijk tijdrovend zijn. Vooral bij grotere projecten is het praktisch onmogelijk om alle mogelijke situaties handmatig functioneel te testen. Het automatisch testen van webapplicaties kan dan een uitkomst zijn. Je kunt oneindig veel scenario’s automatisch laten testen en zo eventuele fouten in de software opsporen zonder zelf met deze stap bezig te zijn.

Het voordeel van automatisch testen: het neemt veel (en vaak saai, want repeterend) werk uit handen. Automatisch testen is ook zorgvuldiger, want mensen maken nog weleens een invoerfoutje en de computer niet. Dat betekent dat je geen fouten over het hoofd ziet en dat vermindert weer het risico op nawerk. Bovendien kunnen automatische testbatches ook ’s nachts worden gedraaid en dat levert tijdwinst op.

Het nadeel van automatisch testen: je moet wel eerst alle testscenario’s schrijven zodat het programma weet wat er getest moet worden. Dat kost tijd. Automatisch testen is dan ook alleen zinvol als je zeker weet dat het uiteindelijk meer tijd bespaart dan je eraan kwijt bent. Dit is vaak het geval bij terugkerende testscenario’s.

Niet-functionele testen

Het is natuurlijk heel fijn als de software qua technische specificaties goed functioneert. Maar dat wil nog niet zeggen dat de webapplicatie werkt zoals iedereen graag wil. Wat in theorie uitstekend lijkt, kan in de praktijk vies tegenvallen. Daarom is een niet-functionele test een essentiële stap in het testproces.

Ook voor de niet-functionele test kun je meerdere testmethoden gebruiken. Een paar voorbeelden:

• Gebruikerstest. Hoe gebruiksvriendelijk is de webapplicatie nadat de nieuwe software is geïmplementeerd? In een gebruikerstest laat je een groep gebruikers alle functies van de webapplicatie testen, liefst op verschillende browsers en apparaten. Waar lopen de gebruikers tegenaan, kunnen ze alles eenvoudig vinden en hoe kunnen deze fouten/ongemakken worden verholpen?
• A/B-testen. Door middel van een A/B-test kun je bijvoorbeeld achterhalen of de website in een bepaalde weergave (bijvoorbeeld kleurstelling, video, lay-out of CTA-button) tot meer conversie leidt. De ene helft van de gebruikers krijgt versie A te zien, de andere helft versie B. Welke scoort beter?
  
  A/B-testen kan op twee manieren: bij clientside testen maakt de browser van de cliënt een variant van de pagina. Bij serverside testen wordt een willekeurige versie van de testpagina vanuit de server verzonden naar de browser. Statische content kun je testen met de clientside testmethode. Gaat het om dynamische content, zoals database queries, dan is serverside testen de aangewezen methode.

• Stresstest. Wat gebeurt er als de webapplicatie extreem wordt belast, bijvoorbeeld als de website ineens veel vaker wordt bezocht dan normaal of als je een bulk aan data toevoegt? Met een stresstest kun je checken of de webapplicatie overeind blijft.

Beveiligingstesten

Security heeft natuurlijk altijd de hoogste prioriteit. Eén zwakke plek is voldoende voor hackers om toe te slaan. En wat dacht je van al die persoonlijke gegevens van gebruikers; die wil je niet op straat hebben liggen. Het is dus belangrijk om de webapplicatie te testen op eventuele beveiligingslekken.

Er zijn verschillende beveiligingstesten waarmee je security risico’s in de software blootlegt, waaronder:

• Vulnerability assessment, een (geautomatiseerde) test die snel inzicht geeft in de veiligheidsrisico’s op de bekende plekken;
• Handmatige security test, waarbij een tester dieper in het systeem duikt om naar de veiligheid van het systeem te kijken;
• Source code review, hierbij wordt gekeken naar eventuele fouten in de programmacode die de veiligheid in gevaar kunnen brengen;
• Penetration test (pentest), waarbij er van buitenaf wordt geprobeerd om in te breken in de webapplicatie.

Persoonlijk advies over jouw project?

Vertel ons waar we je mee kunnen helpen:

Contact opnemen

Tools voor het (automatisch) testen

Zoveel testen, zoveel testtools. Voor iedere soort test zijn er weer andere handige hulpprogramma’s beschikbaar. Een paar voorbeelden:

• Tools voor het automatisch uitvoeren van visuele tests (via gebruikersinterface), zoals Selenium, MS Web Tester, Cucumber en Sikuli;
• Tools voor het automatisch uitvoeren van code tests, zoals Travis CI, GitHub Actions of Jenkins;
• Tools voor performance en stresstesten, zoals WebLOAD en Apache JMeter;
• Tools voor A/B-testen, zoals Visual Website Optimizer en Google Optimize
• Comparators: automatiseren de vergelijking tussen de daadwerkelijke uitkomst van een test en de  verwachte uitkomst van een test;
• Tools die testen op kwetsbaarheden in de applicatie, bijvoorbeeld of er een risico op SQL injectie is of dat er onderdelen zijn die bekende kwetsbaarheden hebben;
• Stubs, mocks en drivers, onderdelen die in tests worden gebruikt om een deel van de software die nog niet klaar is te vervangen zodat er toch getest kan worden.

Sommige testtools, vaak ook test suites genoemd, zijn gratis, voor andere moet je betalen. Je hele budget uitgeven aan tools is echter niet verstandig. In dat geval kun je beter investeren in een professionele tester die, eventueel met een aantal tools, alles grondig test.

Wanneer webapplicatie testen?

Je zou verwachten dat je software pas kunt testen als het klaar is. Gelukkig is dat niet het geval. Ontwikkelaars kunnen bijvoorbeeld “test driven” ontwikkelen. Hierbij worden er eerst testen uitgedacht en geschreven alvorens er code wordt ontwikkeld.

Onze ervaring is dat het niet handig is om met testen te wachten tot het volledige softwareproject is afgerond. Vaak is er aan het eind van de rit geen tijd (of budget) meer om uitgebreid te testen. Daarnaast is het eenvoudiger en overzichtelijker om te testen terwijl je een specifiek onderdeel aan het ontwikkelen bent, dan achteraf het hele project in één keer te testen. Er worden dan vaak wat steekproeven gedaan waarna het eindproduct wordt opgeleverd, met alle risico’s van dien. Fouten die na de oplevering nog moeten worden hersteld, kosten vaak meer tijd en geld omdat een programmeur in delen van de code moet duiken waar hij weken, zo niet maanden, geleden aan heeft gewerkt. Daar zit dus niemand op te wachten.

Een betere aanpak: de webapplicatie testen tijdens het traject. Vooral als je aan agile softwareontwikkeling doet, is het handig om te gaan testen zodra er een stukje software af is. De eventuele fouten die daarbij aan het licht komen, kun je dan direct in een volgende sprint (een ontwikkelcyclus van bijv. 1 of 2 weken) aanpakken.

Zelf testen of een tester inhuren?

De verleiding is vaak groot om als ontwikkelaar zelf te testen. Er zijn immers tools genoeg die vaak ook nog gratis zijn en een professionele tester inhuren, kost geld. Toch is dit niet altijd de slimste route. Een professionele tester weet alle ins en outs wat betreft het testwerk. Een ander voordeel: een tester kijkt weer met hele andere ogen naar je product. Als developer lees je op een gegeven moment over je eigen fouten heen. Een tester pikt die missers er alsnog uit.

Dat gezegd, veel software bedrijven kiezen ervoor om hun testers na enige tijd toch weer de deur uit te doen. Ze beleggen in dat geval de testverantwoordelijkheid bij de ontwikkelaars, welke inmiddels de nodige kennis hebben overgenomen van hun collega’s. Vaak wordt het werk dan onderling gecontroleerd (peer review).

Wanneer je als bedrijf software laat maken is het verstandig niet alleen zelf, maar ook de gebruikers van jouw software de resultaten te laten testen. Er is immers niemand zo geschikt om de gebruikerstest uit te voeren als de gebruiker zelf! Daarnaast is een software-ontwikkelaar geen expert op het gebied van jouw bedrijf. Het testproces vereist dan ook inspanningen van zowel ontwikkelaars als afnemer.

Web Whales testprocedure

Ook bij Web Whales hebben we natuurlijk te maken met het testen van maatwerksoftware. Dit is een standaard onderdeel van de webapplicatie ontwikkeling. Al onze software testen we via het vierogen-principe: de software en het systeem worden door de ontwikkelaar én door een vakkundige collega getest. Zo krijgen we al veel fouten en risico’s op tijd boven water en kunnen we een werkend product opleveren.

Daarnaast kiezen we bij complexe (delen van) projecten vaak voor test driven development in combinatie met een test suite die onze code tests bij iedere toevoeging aan het project zal uitvoeren.

Wil jij je software test driven gaan ontwikkelen? Dan geven we je graag wat tips. Heb je geen tijd voor het (automatisch) testen van je webapplicatie, dan kunnen we deze klus ook van je overnemen. Bel of mail ons kantoor voor meer informatie.