Als oud-Logicanen is TestFrame ons met de paplepel ingegoten. Toentertijd was TMAP als vloeken in de kerk. Nu, gezamenlijk ruim veertien jaar verder, zijn wij nog steeds met TestFrame bezig bij de meest uiteenlopende bedrijven. Zowel in Nederland als in Frankrijk en India hebben we dit jaar diverse opdrachten met TestFrame uitgevoerd. Maar waarom zien we toch zo weinig TestFrame om ons heen? Bestaat het nog of is het zo goed als uitgestorven?
TestFrame zag al in 1995 het levenslicht. Ontwikkeld vanuit het vroegere CMG is het een methode voor gestructureerd testen en levert, per project en per testsoort, herbruikbare testproducten op. Daarnaast is TestFrame in de basis een manier om testgevallen op te delen in kleinere 'blokken' (testclusters), waardoor deze aanpak zich ook goed leent voor grotere systemen en teams (er is immers ook een goede werkverdeling op deze manier).
Ook voor niet-automatisering
TestFrame leent zich door het gebruik van actiewoorden uitstekend voor gestructureerd en herhaalbaar testen en wijkt onsinziens niet veel af van de TMAP(Next)-testmethodiek. Sterker nog, ze zijn naast elkaar prima te hanteren en vullen elkaar zelfs aan.
Een actiewoord is een gedefinieerde combinatie van acties op het testobject die beschrijven hoe een testregel uitgevoerd moet worden. Een actiewoord vertegenwoordigt een opdracht voor de testuitvoerder en heeft altijd een relatie met het systeem dat wordt getest (TestFrame, 2008, Chris C. Schotanus en anderen).
De markt kent TestFrame vooral als een oplossing voor testautomatisering. Waar helaas nog wel eens aan voorbij wordt gegaan is het feit dat TestFrame ook prima voor handmatige testuitvoer gebruikt kan worden. De actiewoorden zijn namelijk (indien op het juiste niveau gespecificeerd) voor een testuitvoerder prima leesbaar en uitvoerbaar. Met een TestFrame testscript moeten – idealiter – zelfs gebruikers die onbekend zijn met het systeem in staat zijn de benodigde tests uit te voeren.
Let wel, voor testsoorten dieper in het V-model zullen de actiewoorden een ander niveau kennen (zoals actiewoorden die ‘praten tegen' web services). Dit soort actiewoorden zijn minder bruikbaar voor handmatige testuitvoer. De uitdaging is dus om de juiste mate van actiewoord-beschrijving te vinden binnen ieder testsoort.
TestFrame als kapstok
Het boek van TestFrame is altijd wat minder 'dik' geweest als dat van bijvoorbeeld TMAP. De reden is dat TestFrame meer een 'kapstok' is voor de opbouw van je logische en fysieke testgevallen en niet alle testtechnieken en testmanagement aspecten beschrijft. De uitwerking van technieken naar testgevallen wordt echter gefaciliteerd door TestFrame en vormt daarmee een aanvulling op TMAP. Verder is TMAP meer gericht op testmanagement, een aanvulling die LogicaCMG in 2003 met Risk and Requirement Based testen heeft gerealiseerd.
Maar juist vanwege deze 'kapstok' en open structuur heerst het nadeel dat TestFrame niet zomaar één-op-één geïmplementeerd kan worden vanuit het boek. TestFrame zal ingepast moeten gaan worden in de betreffende organisatie op een dusdanige wijze dat deze past binnen de huidige (!) organisatie (binnen TestFrame wordt dit 'Fitting' genoemd). De open structuur geeft daarmee weinig op een presenteerblaadje. Een testmanager zal dus zelf slimme keuzes moeten maken die niet voorgekauwd zijn. Wellicht heeft dit voor vele organisaties in eerste instantie juist een drempel opgeworpen? Dit terwijl het juist veel pragmatiek brengt in het testwerk.
Organisaties en TestFrame
Bij de diverse organisaties waar wij een testbijdrage hebben geleverd zien we altijd iets van TestFrame teruggevonden. Alleen werd een dergelijke aanpak doorgaans anders genoemd. In plaats van actiewoorden zien we 'keywords' of 'testactions'. Geef het beestje maar een naampje.
Feit blijft dat organisaties meer en meer volwassen worden en kiezen voor meer structuur en vooral herhaalbaarheid. De voordelen behoeven daarmee niet uitgelegd te worden. Het spreekt voor zich dat juist deze aanpak in het geval van TestFrame als een maatpak aansluit.
Conclusie
Onze conclusie is dat TestFrame als propositie/naam door de markt niet erkend is. Dit zal mede de oorzaak zijn van de reactieve manier waarop TestFrame in de markt gezet is en op dit moment nog gepromoot wordt. We zien dan ook weinig aanvragen of projecten waarin expliciet gevraagd wordt naar TestFrame-kennis.
Echter, TestFrame is wel degelijk van deze tijd en springlevend. Doorgaans heeft de test(automatiserings)oplossing echter een heel andere naam gekregen en is deze verweven met andere testmethodieken of organisatie-specifieke zaken rondom testen.
Wij zijn dan ook benieuwd naar de organisaties/projecten waarin expliciet niet gekozen is voor TestFrame maar waar toch gebruik wordt gemaakt van testclusters en actiewoorden, of een vorm van. Dit riekt namelijk naar TestFrame, een methode die zeker niet oudbollig en dood is… maar nog steeds volop leeft onder honderden testers.
Dit artikel kwam tot stand in samenwerking met Chester Jansen, testadviseur bij Identify.
Heren, ik deel de mening geheel. Als oud-Logicaan, maar ook oud-Sogetist is mijn ervaring dat Sogeti beter is in het vermarkten van hun methoden en technieken. Ik vind je conclusie leuk dat beide methoden elkaar zelfs kunnen aanvullen, op mijn huidige opdracht gebruiken we de TestFrame templates in een TMap setting, precies om de door jullie beschreven redenen: TMap is bijzonder compleet in alle facetten van het testen, behalve de wijze waarop je je testgevallen noteert. Daar ligt de grote kracht van TestFrame: de opdeling van testclusters naar testcondities naar testcases met actiewoorden is sterk en maakt dat je testen op diverse abstractieniveaus kunt indelen en bespreekbaar maken (testconditieniveau is bijvoorbeeld bijzonder geschikt voor bespreken met business-stakeholders). Andere voordelen: de management-rapportage, de vastlegging van de uitvoering, de mogelijkheid om testdata dynamisch te maken. Ik denk dat TestFrame als merknaam dus wellicht weinig bestaansrecht heeft, maar dat velen tot in lengte van jaren zullen blijven werken met de toolset