Overzicht krijgen met Rapid Software Testing

Beter voorbereid beginnen aan de testwerkzaamheden, is ook wat aan bod komt bij Rapid Software Testing (RST). RST is een context-driven testmethodologie waarbij testen wordt gezien als een uitdagend en intellectueel proces. Met RST kun je sneller testen met betere resultaten en met zo min mogelijk verspilling van tijd. Het is belangrijk dat je kunt uitleggen waarom je doet wat je doet, en welke afwegingen je hebt gemaakt. Noteer dit bijvoorbeeld in een document en maak ook aantekeningen tijdens de testwerkzaamheden. Zonder dat deze administratie je werk gaat worden. Want dat is bij RST juist niet de bedoeling.

Technieken voor een goede voorbereiding

Er zijn een aantal technieken die helpen bij het in kaart brengen van hetgeen je wilt gaan testen. Bepaal vooraf hoeveel tijd je besteed aan deze technieken. Dus hoe lang mag de voorbereidingen duren? Onderstaand bespreek ik twee van deze technieken die tevens terugkomen in RST.

1. Het toepassen van SFDIPOT

Deze techniek is ontwikkeld door James Bach en betreft het maken van een mindmap met behulp van heuristieken (wetenschap, de leer of de kunst van het vinden). Met als doel het schrijven van een gestructureerde, bondige teststrategie die als uitgangspunt dient voor de testen. Onderstaande heuristieken helpen om alle belangrijke aspecten voor het testen mee te nemen en vormen de afkorting SFDIPOT.

S staat voor structuur

F voor functie

D voor data

I voor interfaces

P voor platform

O voor operatie

T voor tijd

Meer informatie en voorbeelden over de heuristieken van bovenstaand voorbeeld kun je hier vinden.

2. Het verzamelen van orakels

Orakels helpen je bij het maken van de juiste keuzes. Orakels kun je eigenlijk zien als heuristieken. Voorbeelden hiervan zijn:

• Een referentie document met nuttige informatie
• Een bekend voorbeeld van goede output
• Een bekend voorbeeld van verkeerde output
• Een persoon waarvan de mening belangrijk is
• Een gevoel van verwarring of irritatie

Op basis van de verzamelde orakels bepaal je jouw teststrategie. De volgende voorbeeldvragen kunnen je hierbij op weg helpen: Waar zit de meeste businesswaarde? Waar zitten de risico’s? Wat moet absoluut functioneren bij livegang? Wie heb je nodig bij je testen? Wat heb je nodig om je testen goed te kunnen doen? Welke systemen zijn betrokken? Zijn deze aanwezig op de omgeving die beschikbaar is gesteld voor je om te testen? Is er überhaupt wel een omgeving beschikbaar? Wanneer je het antwoord op deze vragen weet, kun je de kostbare tijd ook daadwerkelijk besteden aan testen. Bovendien zorgt het ervoor dat je gefocust aan het werk kunt gaan.

De techniek van kritische vragen stellen

De hierboven genoemde technieken zijn zeer bruikbaar, maar je kunt zelf ook manieren bedenken waarop je de voorbereiding doet. Wat voor mij goed werkt, is naast de ontwerper of developer gaan zitten en in gesprek gaan over het te testen object. Wat is er veranderd aan de software? Hoe was de oude situatie? Waar moet ik extra goed op letten? Wat is belangrijk voor de klant? Wat heeft prioriteit en waar moet ik me dus als eerste op richten? Waar liggen de belangrijkste risico’s? enz. Een goede tester stelt veel (kritische) vragen. Met behulp van de antwoorden op deze vragen kun je een soort van handleiding voor jezelf maken waarin staat wat er moet gebeuren en wanneer je wat doet. Een teststrategie dus.

Focus en defocus

De voorbereiding is afgerond; je hebt in kaart gebracht wat er precies moet gebeuren. Na het maken van een teststrategie is het tijd om daadwerkelijk te gaan testen. Om goed te kunnen testen is het belangrijk om focus te hebben, zodat je effectief met het te testen object of objecten aan de slag kunt. Uit ervaring weet ik dat het belangrijk is om periodes van focus, meestal niet langer dan een uur, af te wisselen met periodes van defocus. Als je in focus bent, ben je in principe logisch aan het nadenken. Bij defocus neem je een stap terug en orden je de informatie die je tot nu toe hebt vergaard opnieuw, zodat je tot nieuwe inzichten komt. Ook hier is de strategie die je eerder hebt bepaald erg nuttig: je stelt jezelf, door het verkregen overzicht en inzicht, in de gelegenheid om te kunnen defocussen.

Ga dus niet in een rechte lijn op je doel af tijdens het testen, maar neem de tijd om nieuwe scenario’s en situaties te bedenken. Zo verklein je de kans dat je bugs en errors mist en heb je een beter inzicht in de kwaliteit van het object of het product.

Just do it!

Hoe je structuur aanbrengt aan het begin van het testtraject, is aan jou. Je kunt bijvoorbeeld de twee technieken uit deze blog gebruiken. Het belangrijkste is dát je het doet. Het geeft je met name overzicht en inzicht in het te testen object en het stelt je in staat om te kunnen focussen en defocussen. Een goede voorbereiding is het halve (test)werk!