In meer dan 10 jaar Polteq kom je in aanraking met flink wat ontwikkel- en testmethodieken. In mijn gereedschapskist zitten inmiddels JBF, TMap(Next), ISTQB, CAT, CDT/RST, Testframe, TestGrip, Waterval, V-model en Agile. Daarnaast bevat mijn gereedschapskist inzichten over handmatig versus automatisch testen en kennis over het meten en laten groeien van (test)volwassenheid. Samen vormt dit een breed scala aan visies op testen die soms overeenkomstige onderdelen hebben maar soms ook lijnrecht tegenover elkaar lijken te staan.
Al een tijdje liep ik met de gedachte om al deze zaken in één, overkoepelende, visie op testen samen te brengen zodat ik, afhankelijk van de context, kan kiezen welke gereedschappen ik gebruik. Daarbij stelde ik als randvoorwaarde dat ik de visie eenvoudig kan uitleggen, ook aan niet-testingewijden. Bij Bosch kreeg ik, twee jaar geleden, de vraag om een integrale teststrategie op te zetten voor een agile omgeving. Een mooie kans om te proberen de overkoepelende visie uit te werken en in de praktijk te testen. In een paar iteraties heeft dit geleid tot de Goal-Focus-Approach (GFA) aanpak voor testen. Graag wil ik deze aanpak delen zodat je er je voordeel mee kunt doen.
Het uitgangspunt voor de aanpak is dat alle activiteiten die je als tester uitvoert, doet met een bepaald doel in gedachten. Als testen geen specifieke doelen heeft dan kun je het beter niet doen, het is namelijk niet gratis! Het meest belangrijke doel van testen is informatie verzamelen over het product en de werking ervan voor de business. De vraag is nu, naar welke informatie ben je op zoek?
Hier hielp Context Driven Testing mij met het inzicht dat ieder mens “weet wat hij weet” en “niet weet wat hij niet weet”. Deze wetenschap is om te zetten in de volgende doelen voor testen: informatie verschaffen over gedrag van het product dat gewenst (bekend) is en informatie verschaffen over onbekend gedrag van het product waarvan beoordeeld moet worden of het gewenst of ongewenst is. Gewenst gedrag vind je in requirements (user story’s), in acceptatiecriteria en in de van belang zijnde kwaliteitscriteria (ook requirements!). Daarnaast ondermijnen product-, proces- en gebruiksrisico’s gewenst gedrag dus door ze als risicotestdoel te benoemen kun je ze mitigeren. Hier zie je de risicogebaseerde aanpak van BDTM/TMap in GFA terug. Requirements (inclusief kwaliteitscriteria), product-, proces- en gebruiksrisico’s zijn allemaal belangrijke zaken waarover je de belanghebbenden wilt informeren.
Je kunt geen expliciete testdoelen benoemen voor productgedrag waarvan “je niet weet dat je het niet weet”, je kent het namelijk niet! Wel kun je het product systematisch op verschillende manieren onderzoeken (exploren) om onbekend gedrag te ontdekken. Deze onderzoeksopdrachten op het product zijn specifieke nieuwe testdoelen. Met requirements (in brede zin), risico’s (in brede zin) en exploren heb je drie pilaren die samen een gedegen set testdoelen vormen. Afhankelijk van de context zijn er in het ene project/sprint meer uit de ene pilaar en in een ander project/sprint meer uit een andere. Het komt erop neer dat je er altijd voor zorgt dat je in je testaanpak testdoelen uit alle drie pilaren hebt. De exacte invulling en verdeling is daarbij context afhankelijk.
Al snel heb je op deze manier meer testdoelen dan je gezien tijd, resources en/of geld kunt waarmaken. Je zal dus moeten kiezen wat meer, minder en misschien wel niet belangrijk is. Bij een testdoel hoort dus een specifieke testfocus. Je moet je testinspanning focussen op de testdoelen die echt belangrijk zijn. Het is dus zaak de benoemde testdoelen te prioriteren (H, M, L). Prioriteren van requirements gaat op business belang. Prioriteren van exploren gaat op business belang of risico (afhankelijk van de aard van de onderzoeksopdracht) en risico’s worden volgens impact x faalkans geprioriteerd.
Met het concreet maken van de testdoelen en de testfocus per testdoel breng je duidelijk in kaart wat je wilt gaan doen. De enige nog openstaande vraag is, hoe, met welke aanpak ga je zorgen dat elk testdoel met de gewenste focus wordt getest? Hiertoe beschrijf je de test-approach per testdoel. Onder test-approach vallen heel veel dingen:
Zoals inmiddels duidelijk naar voren komt, krijgen alle, voor ons bekende, testtermen een plek in de GFA-aanpak zonder elkaar uit te sluiten, ze vullen elkaar in GFA juist aan tot een gedegen maatwerkaanpak voor testen in elke situatie. Onder GFA past de totale testgereedschapskist zoals ik die aan het begin van dit artikel beschreef. Dit is de grote kracht van de GFA-aanpak!
Rest mij nog het onderdeel testvolwassenheid binnen GFA te plaatsen. Het idee is dat je elk van de drie componenten van GFA kunt invullen op een manier die past bij de actuele volwassenheid van de organisatie. In een onvolwassen organisatie begin je met het benoemen van een paar belangrijke testdoelen die de opdrachtgevers aanspreken. De focussessie doe je zelf en je legt het resultaat voor aan je opdrachtgever zodat hij er wat van kan vinden. Vervolgens beschrijf je een test-approach op hoofdlijnen die past in de overige aanpak van het project zonder al te veel specifieke testdetails te benoemen. Naarmate je meer volwassen wordt, worden de testdoelen specifieker, doe je een meer gedegen focussessie met alle stakeholders en benoem je meer detailaspecten van de test-approach (bv. benodigde hooks, stubs en mocks voor geautomatiseerd testen). Ongeacht de testvolwassenheid blijft de GFA-aanpak overeind, je gaat alleen op een meer volwassen manier met G, F en A om!
Wim ten Tusscher
