Veel testers willen graag betrokken zijn vanaf het begin van een ontwikkeltraject. Dit omdat we graag voorbereid willen zijn voor als we echt aan de fase "testuitvoer" gaan beginnen. Dat ligt in een traditionele ontwikkel methodiek (of bij geen ontwikkelmethodiek) namelijk op het kritieke pad. Als men de ontwerpen aan het maken is kan je al bezig met je teststrategie, wat leidt tot een testplan, en vervolgens je testgevallen gaan definiëren.
Er is nog een reden: in het begin van een ontwikkeltraject kan je al veel problemen uit de documentatie halen met relatief weinig inspanning. Een alinea aanpassen in een ontwerp is goedkoper dan later de software aanpassen en hertesten. In vergelijking met een software systeem wat al in productie draait zijn de relatieve kosten die je maakt om een probleem op te lossen al helemaal moeilijk in te schatten en kan dit exponentieel oplopen.
Maar hoe ga je daar als tester mee om? Er zijn een aantal technieken om ontwerp documentatie beter van kwaliteit te maken en er voor te zorgen dat we doelgerichter bezig te zijn met het maken van deze documentatie.
Review sessies
Met review sessies van documentatie kan je al veel problemen in de fase "ontwerp" er uit halen. Het niveau van review sessies loopt van samen in een vergaderruimte gaan zitten en door het document lopen, tot aan een formele review met rolverdeling. Waarbij bij mee gestructureerde reviews meer voorbereiding voor nodig is door alle deelnemers van de review sessie.
Product risico analyses
Voor een moderne testaanpak ga je werken vanuit de risico´s van het nieuwe systeem, waarbij je de hele organisatie betrekt. Op deze manier kan je gericht gaan zoeken naar de grootste problemen in een software systeem, waarbij je de grootste risico´s het eerst afdekt. Als je een product risico analyse vroeg in het traject uitvoert helpt dit ook de ontwerpers en ontwikkelaars om een focus op bepaalde gebieden te leggen, waardoor er al minder problemen ontstaan, juist omdat deze sessies inzicht geven in de risico gebieden.
Droogzwemmen (virtueel testen)
Een nieuwe kreet? De term 'Virtueel testen' heb ik nog niet zo lang geleden bij een presentatie gehoord. Procedures oefenen met alle beheerders van een systeem. Hier kan je ook weer denken aan samenzitten en door de business procedures en eisen lopen en bekijken of iedereen hetzelfde beeld heeft. Je kan kort een paar uur samen gaan zitten, of een sessie van een dag beleggen, waarbij je de rollen ' moderator' en ' tester' apart belegd, de testen voorbereid. En volgens de presentatie die ik gezien heb kan je een publiek van de doorsnede van de organisatie erbij plaatsen.
Evaluaties
Iets wat nog te vaak wordt vergeten of wat vaak afvalt door tijdsdruk en chaos in projecten is het af en toe samenzitten om het traject door te spreken en te bekijken waar je het beter kan doen in een volgende iteratie of fase. Elk project loopt toch weer anders en er kunnen altijd verbeteringen aangebracht worden in de manier van werken.
Belanghebbenden
Bij de toets-soorten, zoals hierboven genoemd heb je altijd de meeste belanghebbenden van het nieuwe IT systeem nodig, de gebruikers, de ontwikkelaars, ontwerpers, architecten, business managers, testers, sales, et cetera. Dit verschilt per systeem, een intern software product behandel je anders dan een IT systeem die over meerdere onderdelen van de organisaties, of over verschillende organisaties gaat.
Testplan
Nu ben je bezig met je testplan, of in ieder geval je teststrategie en je bespreekt je toets strategie met je opdrachtgever:
- Product risico analyse in de analyse fase (levert algemene risico's op)
- Review sessies in de ontwerp fase
- Virtueel testen in de ontwerp fase
- Review sessies in de bouw-fase (dit meer gericht op testdocumentatie)
- Voor elke testfase opnieuw een product risico sessie (ontwikkel-, systeem- en acceptatietesten)
- Evaluatie momenten na testfases over de ontwikkel en test aanpakken
Kosten
- Product risico analyses: 3 keer een risico sessie, 8 personen per keer, 3 uur per sessie (72 uur)
- Review sessies: Zelfde als bij PRA (72 uur)
- Virtueel testen: 1 keer, maar dan met 15 personen, hele dag (120 uur)
- Evaluatie: 3 keer met beperkt aantal mensen, zeg 4 personen, 2 uur per sessie. (24 uur)
Ditt leidt tot de volgende inzet van resources: 72 uur + 72 uur + 120 uur + 24 uur = 288 uurPer sessie voorbereiding en verwerking van 30% (puur voor de inschatting) = 87 uur
In totaal komen we dan op 375 uur, met werkweken van 36 uur, kom je ongeveer op 10 volledige werkdagen die het project moet besteden aan sessies ten behoeve van kwaliteit op de documentatie. En deze investering kan je later een veelvoud van dit aantal dagen opleveren. En dat is geen fabeltje meer, elk van deze technieken hebben zich in de praktijk al bewezen.
Hoe leg ik dit uit aan de projectmanager
Deze blog begon ik eigenlijk met het idee van: Hoe kan ik dit verantwoorden naar mijn opdrachtgever? Dat gaat men nooit doen. De kreet "Poolse landdagen" heb ik al wel vaker gehoord, maar dat is niet van toepassing op dit soort sessies, ze hebben een doel en leiden tot acties en resultaat.
Het aantal dagen wat ik hier heb berekend is natuurlijk een 'nogal vrije' inschatting, maar valt op een ontwikkeltraject van een half jaar wel mee. En als je het objectief bekijkt levert het
zeker wat op. En hoe vaker je dit soort sessies organiseert, hoe effectiever en efficiënter ze worden.
Van de week dacht ik nog: "dat gaat een opdrachtgever nooit accepteren", maar nu zo uitgeschreven heb ik toch weer het beeld voor mij zelf gecreëerd dat het werken op zo'n manier leidt tot betere producten en doel gerichter werken. Tevens leiden alle genoemde onderdelen ook tot een betere samenwerking. Vooral in grotere projecten ontmoeten mensen elkaar pas richting het einde van een project als alles samenkomt, met deze sessies ontstaat eerder een samenwerking en eerder persoonlijk contact.
Dus eigenlijk pleit ik er voor om dit standaard in elk test traject te implementeren, of om er in ieder geval over na te denken en te bespreken met je projectleider. Niet alle projectleiders zullen over te halen zijn, maar de grote voordelen en besparing in de kosten van software ontwikkel trajecten zal toch wel wat projectmanagers over de grens trekken vermoed ik.
