Software testen is een leuk en uitdagend vak. Er zijn echter verschillende aspecten aan testen die je als tester irritant en niet-productief kunt ervaren. Wij hebben een top 3 gemaakt van de ons meest frustrerende dingen in software testen. Daarbij geven we ook aan op welke manier wij er mee omgaan.

1. Ontbreken van requirements en acceptatiecriteria

Of je nu volgens Agile, Scrum, Waterfall of …. werkt er is gewoon geen excuus voor het niet hebben van requirements en acceptatiecriteria. Toch gebeurt het met regelmaat dat een user story uit niet meer bestaat dan een regel tekst. De beschrijving in één regel bestaat vaak ook nog uit vijf of minder woorden die een willekeurige ontwerpgedachte beschrijven die hopelijk gerelateerd is aan de gewenste functionaliteit. Is het dan raar dat de software gebreken vertoond? Het is frustrerend en het is niet te doen om op basis van zo weinig informatie nuttige testen voor te bereiden en uit te voeren.

Hoe kun je dit aanpakken?

Het biedt ons testers natuurlijk ook kansen om meer uit je werk te halen door de requirements op te gaan halen bij de andere teamleden. Je kunt eerst met de ontwikkelaar bespreken wat hij heeft ontwikkeld op basis van de beschikbare informatie. Vervolgens maak je een globale beschrijving en bespreek je deze met de product owner. Op basis van deze bespreking en de eventuele aanvullende informatie die je hebt gekregen maak je vervolgens de testgevallen.

Het komt regelmatig voor dat er tegenstellingen zijn tussen dat wat de product owner wil en dat wat de ontwikkelaar heeft begrepen. In dat geval is het verstandig een meeting met beide personen te organiseren en daarin de functionaliteit te bespreken.

De uitkomst van zo’n bespreking is vaak dat de ontwikkelaar aanpassing moet doorvoeren en dat het team als geheel een globale schets heeft van hoe de functie moet werken. Daarnaast zijn er al problemen gevonden voordat er ook maar een test is uitgevoerd.

2. Testen is kreukelzone van project of sprint

Als tester vraag je jezelf wel eens af waarom je een begroting moet afgeven, terwijl we weten dat er vaak niet genoeg tijd zal zijn voor het testen. Natuurlijk geven we een zo nauwkeurig mogelijke begroting af omdat dat nu een maal bij ons werk hoort. Soms is het maken van een begroting echter een nutteloze activiteit, omdat testen als kreukelzone wordt gebruikt wanneer de ontwikkelaars meer tijd nodig hebben. De beschikbare testtijd is dan de tijd die nog over is nadat de ontwikkelaars klaar zijn en de oplevering van een release of einde sprint.

Uiteraard doen we als testers onze best om zoveel mogelijk van een applicatie te testen, inclusief regressietesten. We kunnen echter geen volledige systeemtest uitvoeren als nog niet alle functionaliteiten beschikbaar zijn. Wanneer 2 of 3 user stories nog in ontwikkeling zijn dan is een regressietest bijna nutteloos. Het is geen volledige tijdverspilling, maar volledig is het zeker niet.

Het pas aan het einde van een testtraject uitvoeren van systeem-, regressie- en integratietesten maakt de kans groter dat er fouten niet zullen worden ontdekt. Helaas is deze trend toegenomen door het toepassen van Agile/Scrum, ongeacht hoe goed het proces is ingericht. Het is een feit dat moeilijke en ingewikkelde wijzigingen over het algemeen meer tijd kosten, maar dat er waarschijnlijk minder tijd is voor het testen.

Hoe kun je dit aanpakken?

De volgende dingen kun je doen om de risico’s te verkleinen:

• Na het testen van een stukje nieuwe functionaliteit, kun je direct de integratie- en regressietesten uitvoeren.
• Automatiseer de regressietesten en laat deze testset iedere nacht draaien. Daarmee kun je iedere morgen zien of de wijzigingen van de vorige dag regressie hebben veroorzaakt.

3. Ongeorganiseerd testproces

Het ontwikkelproces is bij organisaties niet altijd goed georganiseerd. En dat geldt dan ook voor het testproces. Tools kunnen het proces ondersteunen, alleen ze bepalen niet hoe het proces zou moet werken binnen de organisatie. Het gaat er hierbij niet om dat iedereen exact hetzelfde doet, in dezelfde volgorde, op hetzelfde moment, maar dat er een standaard is. Een standaard helpt bij het communiceren naar andere teams en naar het management.

Het dient ook als een referentie voor nieuwe testers, of wanneer er vragen naar boven komen over het test-proces.

Hoe kun je dit aanpakken?

Een stap die je kunt nemen is een eenvoudig stapsgewijs proces- of procedure document op te stellen. Dit kun je doen in een formaat dat het beste past bij de organisatie en kan een word document, excel sheet, mind map of testplan zijn.

Start met het opschrijven van de processen die je voor het testen gebruikt. Hou het in eerste instantie globaal. Gebruik deze beschrijving en deel ze met anderen die geïnteresseerd zijn. Zorg ervoor dat de beschrijving up to date blijft als er nieuwe processen bijkomen. Als een ander teamlid met een productievere methode komt, probeer het dan uit en voeg het toe aan het document.

Wat zijn jouw frustraties? Vertel het ons via een commentaar onder het blog.