Laat je niet beperken door de testbasis
Naam Rob van Steenbergen
Functie Test consultant
Bedrijf Chickenwings Test Consultancy
Vaak gaan testers er vanuit dat alles beschreven kan worden in documentatie, een volledige beschrijving in functionele specificaties. Dit wordt dan gezien als de testbasis. Je vergelijkt de testbasis met de software en de verschillen hiertussen zijn bugs. Als alles vergeleken is weet je wat de kwaliteit van een product is.
Of niet? Vanuit jarenlange ervaring en gesprekken met andere IT’ers weet ik dat geschreven documentatie (als het er überhaupt is), nooit volledig, eenduidig, tot in de detail beschreven en al verouderd is op het moment van schrijven. Er zijn testers die zich gemotiveerd voelen om de organisatie waar ze in werken te helpen met het schrijven van goede functionele documentatie door technieken te gebruiken zoals UML, Flow diagrammen, Gherkin, et cetera.
Op dat moment stap je uit de rol van tester en ben je bezig als ontwerper. Of wellicht ‘documentalist’. Ik ben zeker voor verantwoordelijkheden nemen of breder kijken dan je eigen perspectief, het helpen in je organisatie om ‘dingen beter te maken’. Op het moment dat je bezig bent met het verbeteren van de specificaties, ben je in ieder geval niet aan het testen.
Het hebben van documenten is niet een voorwaarde om te testen. Testen is in mijn ogen niet “het vergelijken van het testobject met de testbasis”, maar het doen van onderzoek en het vinden van informatie over de kwaliteit. En dit kan op meer manieren dan alleen maar het vergelijken met (verouderde en statische) documentatie.
- Ga snel aan de slag met de software, loop door de functionaliteiten heen. Kan je zelf uitleggen waarvoor elke functionaliteit is? Ondersteunt elke functionaliteit het doel waarvoor de software is gemaakt?
- ‘Voelt’ de software goed aan? We hebben allemaal ervaring met software, je kan de software doorlopen en gebruiken. Soms duurt het openen van een scherm net iets te lang, soms raak je in de war omdat een functionaliteit niet duidelijk is. Schrijf deze punten op, mogelijk zijn hier risico’s om nader te onderzoeken.
- Over risico’s gesproken: heb je al eens rond gevraagd waar men de belangrijkste risico’s ziet in deze software? Wat zijn de belangrijkste nachtmerrie-krantenkoppen die uit kunnen komen als de software vandaag in productie komt?
- Vergelijk een versie van de software met eerdere versies.
- Zoek vergelijkbare functionaliteiten in andere software en gebruik deze als referentie.
- Doe een rondje ‘marketing’ afdeling binnen je organisatie. Bekijk of de website iets beschrijft over het product en wat men belooft. Doet de software dit echt?
- Laat het product bekijken door échte gebruikers. Zij hebben zeker ideeën hoe het product voor hen zou moeten werken.
- Start met bughunt sessies in je organisatie
- Werk met de software zoals de standaarden van een platform werken. Een mobile app wordt anders gebruikt dan PC-software. Op Windows werk je anders dan op een Apple Mac.
Zelfs al heb je goede doordachte en uitgewerkte functionele specificaties, je komt zeker tegen verassingen aan als je vanuit meerdere perspectieven de software bekijkt. Laat je niet beperken door de paradigma van de testbasis.