Auteur: Kees Blokland ● kees.blokland@polteq.com
‘Just enough documentation’ en ‘Document stable things’ klinken als goede suggesties, maar hoe vind je de juiste balans? Ik begeleid sinds begin dit jaar een organisatie bij de acceptatietest door meer dan tien afdelingen die in 2015 van eigen systemen en tools voor een bepaald werkproces moeten overstappen naar een ingericht softwarepakket. Het betrokken bedrijfsproces wordt geharmoniseerd, wat voor alle afdelingen ook veranderingen in de werkprocessen inhoudt. Een ervaringsverhaal over hoe je in de praktijk aanloopt tegen de moeilijkheid van het maken van een testplan en testgevallen in een omgeving met veel onzekerheden en vol bewegende doelen.
‘Just enough’ strategie
Zoals het in die organisatie gebruikelijk is, begon ik met het schrijven van een acceptatiestrategie, een soort mastertestplan. Een mooie kapstok voor een projectverkenning, want ik wist nog niet zo veel van het pakket en de business processen. De verkenning liep voorspoedig. Alleen kon ik nog maar weinig onderdelen van de acceptatiestrategie goed beschrijven. De afbakening van de testsoorten, de testorganisatie, de teststrategie en vele andere zaken waren nog te wazig, dus na enkele pogingen liet ik het acceptatiestrategiedocument links liggen. Als alternatief goot ik de ‘stable parts’ van acceptatiestrategie in powerpoint-vorm: in deze fase van de strijd ‘just enough documentation’. De ppt bleek een prima medium om alle betrokkenen in te lichten over de globale testaanpak en hun uit te leggen wat er op dat moment van hen werd verwacht. Met het verlopen van de tijd werd het duidelijker hoe we het testen gingen aanlopen. Het bijhouden van de ppt kostte weinig inspanning.
‘Stable things’ strategie
De volgende stap was het vaststellen wat er precies getest moet gaan worden. Veel requirements moesten nog uitkristalliseren. Geen stabiele basis voor gedetailleerde testgevallen. Toch moesten de key-users wel gaan nadenken over het testen: hoe gaan ze controleren dat de inrichting van het pakket en hun werkproces op elkaar passen? Ook hier hielp het principe ‘document stable things’.
Van de vijf hoofd-werkprocessen hebben er drie veel overeenkomst met bestaande werkwijzen. Testgevallen daarvoor werden gebaseerd op voorbeelden uit de huidige praktijk. Het was nog niet precies bekend hoe de gevallen in het softwarepakket moesten worden verwerkt. Dat kon dus nog niet worden opgenomen in de testgevallen (als het goed is, zou dat helemaal niet nodig zijn, want van de gebruikersvriendelijkheid werd veel verwacht).
Maar goed, we hadden zo nog geen duidelijke checklist voor de transactieflow in de werkprocessen en te testen varianten in nieuwe onderdelen van de werkprocessen. Inmiddels had ik me aangewend om informatieverwerking in mindmaps te doen.
Dat leverde in dit geval vanzelf de oplossing voor het vraagstuk: de mindmap bevatte precies het juiste abstractieniveau voor de kapstok die we zochten. Niet te veel onzekere details, maar vooral zaken waar inmiddels consensus over bestond. De projectmanager was enthousiast en inmiddels hangen de mindmaps aan de muur in de testruimte en fungeren als backbone voor het testen.
Exploratory uitvoering
Dezelfde rol die de ppt speelt bij de acceptatieteststrategie, vervult de mindmap bij de testgevallen. Tijdens het schrijven van dit stuk zitten we in de testfase. De exploratory aanpak die we hebben afgesproken werkt heerlijk. De mindmaps geven de key-users een kapstok voor het testen en bieden tegelijkertijd voldoende vrijheid om te variëren zoals in de praktijk ook gebeurt. De mindmaps worden door het testen nog beter gemaakt en stap voor stap gaat alles over elkaar heen liggen: de mindmaps, de werkprocessen en het systeem. Op het moment dat dit voldoende gelukt is zijn we klaar!
NieuwsMagazine
4 reacties