Developer Diaries: testmethoden

In de vorige Developer Diaries vertelde Roy over het testen van update 1.29 en noemde hij de blackbox test als eerste testmethode voor het testen van een update. Deze keer gaat hij verder in op andere testmethoden die tijdens een testperiode worden toegepast.

Diverse testsoorten

“Zodra uit een blackbox test blijkt dat de algemene functionaliteit van de software voldoet aan de eisen uit het ontwerp, gaan we verder met andere testmethoden”, vertelt Roy. Hieronder zie je welke testmethoden dit zijn:

Het testen van de software leidt tot diverse constateringen van nog niet goed functionerende onderdelen. Deze constateringen noemen we ‘issues’. Per constatering maken we een issue aan waarin wordt toegelicht welke onderdelen niet goed werken. De programmeurs gaan vervolgens aan de slag met het aanpassen van de code om de fouten op te lossen. Dit koppelen ze weer terug aan de productmanagers voor vervolgtesten. Roy geeft aan: “Tijdens het intensief testen van de software kun je van alles tegenkomen. Soms ook issues die niets te maken hebben met aanpassingen die gedaan zijn in een update. Het moeilijkste, maar ook het allerbelangrijkste is dan om de aanpassingen door de ogen van onze klanten te bekijken.”

Voltooiing van de testfase

Roy vervolgt: “Tijdens en na het uitvoeren van de diverse testen, stellen we onszelf de volgende vragen:

• Brengt de update van de software een verbetering voor onze klanten?
• Heb ik door het testen eventuele risico’s voor de klanten weggenomen?

Is het antwoord op beide vragen ‘ja’, dan is de testfase voltooid en is de update klaar om live te gaan.” Zodra de live release van de update heeft plaatsgevonden, ontvangen klanten een supportmail waarin de belangrijkste aanpassingen per module zijn toegelicht. Het ontwikkelteam is dan ondertussen alweer aan de slag met de update cyclus voor versie 1.30.