Testers worden vaak bij een project betrokken wanneer de eerste functionaliteiten worden opgeleverd door de ontwikkelaars, dit is veel te laat. Betrek afgevaardigden van het testteam al bij het vaststellen van de requirements. Dit zal de kwaliteit van het beschrijven van de requirements ten goede komen en het zal tijdens het opstellen van de testgevallen en uitvoeren van de testen tijdwinst opleveren. Daarnaast is het van belang om te zorgen dat de requirements, testgevallen etc. goed zijn vastgelegd. Nog steeds worden requirements, usecases of functioneel ontwerpen (FO’s) in Word en Excel vastgelegd zonder dat er een duidelijk verband tussen de requirements, usecases of FO’s en testgevallen wordt gelegd. Daarnaast wordt er binnen een project vaak wel de project risico’s in kaart gebracht, maar zie je vaak dat de business risico’s of product risico’s (PRA”s) niet in kaart worden gebracht. Als dit niet gebeurt, hoe kun je dan de impact van een bevinding bepalen? Een PRA is ook van belang voor de planning, een functie met een grote business impact zal meer aandacht moeten krijgen, dan een functie met weinig business impact. Er zijn veel tools in omloop om het e.e.a. vast te leggen, maar ik ben nog geen tool tegengekomen waar alle voorgenoemde zaken onder “één dak” zijn vastgelegd. QFactors heeft hier een tool voor ontworpen en gebouwd QFactors Solution Suite (QSS). Ik hoop echt dat er meer aandacht gaat komen voor het belang van testen: betrek het testteam zo vroeg mogelijk in het project, zorg voor goede tools en voor echt een Product Risico Analyse (PRA) uit. Ook het uitvoeren van een regressietest is belangrijk om “doorwerkfouten” te voorkomen of detecteren.
Begint testen bij requirements?
