Vaak krijgen wij als testers van onze projectmanager de vraag: hoe lang duurt het om de applicatie te testen? We kunnen dan antwoorden dat we een week nodig hebben om alle gemaakte testscripts een keer uit te voeren. Maar dat is niet het antwoord dat we geven. Waarom? Omdat een projectmanager niet wil horen wanneer de test klaar is, hij wil horen wanneer de software klaar is.
Stel, na twee testrondes, geheel volgens plan, is de conclusie dat de software niet voldoet. Wij hebben dan misschien optimaal gepresteerd, een projectmanager wordt niet enthousiast van het nieuws dat de software nog zo brak is als het IJsselmeer. Hun opdracht is dan nog niet af, en daarmee de onze ook niet. Projectmanagers zijn dus geïnteresseerd in het moment waarop de software klaar is voor productie, en het vervelende is: dat vragen ze aan ons!
Het lijkt alsof de algemene perceptie is dat testers binnen de afgesproken testplanning kwaliteit moeten bereiken, in plaats van aantonen. Iedere tester heeft weleens meegemaakt dat een stakeholder zich openlijk afvraagt waarom dat testen zo lang duurt. En iedere tester heeft weleens ervaren dat de doorlooptijd van de testplanning ter discussie gesteld wordt.
Tuurlijk, het tijdig bereiken van kwaliteit is mede afhankelijk van het zo vroeg mogelijk vinden van de belangrijkste fouten, het helder beschrijven en reproduceerbaar maken van bevindingen, en het onderhouden van goede relaties met ontwerpers en ontwikkelaars. Maar uiteindelijk moeten fouten snel en efficiënt worden opgelost door de ontwikkelaars! Testers kunnen dit onmogelijk garanderen. Vaak is dus het bereike en, niet het aantonen van kwaliteit oorzaak van uitloop in het testtraject.
Een paar veel voorkomende voorbeelden:
– In de eerste testronde worden meer en zwaardere bevindingen gevonden dan ontwikkelaars in de eerstvolgende oplevering kunnen oplossen. Pas in latere testrondes worden meer bevindingen opgelost dan er gevonden worden en loopt het aantal openstaande bevindingen terug;
– Niet alle geplande functionaliteit kan in de eerste testronde onderzocht worden. Een bevinding kan achterliggende functionaliteit blokkeren, die daardoor pas in een volgende release getest kan worden. Als die bevinding eenmaal is opgelost blijken ook in de achterliggende functionaliteit nog bevindingen te bestaan;
– Gemiddeld 20 provent van alle bevindingen (eigen ervaring) wordt niet correct opgelost. Dat betekent dat als in de tweede oplevering honderd bevindingen zijn opgelost, er gemiddeld twintig bevindingen heropend worden. Dat staat nog los van eventuele nieuwe bevindingen die gedaan worden.
Het bereiken van kwaliteit is dus een delicaat samenspel van ontwerper, ontwikkelaar en tester. En de testplanning is dat idealiter ook. Moeten testers dan stoppen met het afgeven van testplanningen? Nee, zeker niet! Testers verzamelen beroepshalve namelijk zowel expliciet en impliciet veel informatie over processen. Dat betekent dat testers beter (of minder slecht) dan anderen in staat zijn om een redelijke inschatting te geven hoe lang het duurt alvorens een bepaald kwaliteitsniveau bereikt is.
Wel kunnen we als testers beter communiceren over de waarde van een testplanning:
– vertel de projectmanager dat de doorlooptijd van het testtraject enerzijds wordt bepaald door de mate waarin testers bevindingen kunnen aantonen, en anderzijds door de snelheid waarmee ontwerpers en ontwikkelaars bevindingen kunnen oplossen;
– communiceer tijdig wanneer de planning dreigt uit te lopen en maak inzichtelijk wat de oorzaken zijn;
– als een projectmanager het testtraject inkort, wijs erop dat het risico toeneemt dat de kwaliteit aan het einde van het geplande traject tegenvalt;
– vraag de projectmanager te organiseren dat ook ontwikkelaars hun oploscapaciteit moeten verhogen om de nieuwe deadline te halen, iets wat bij het inkorten van testplanningen vaak wordt vergeten.
Ik neem in het planningshoofdstuk van mijn testplannen standaard de volgende zin op:
“Deze planning geeft aan hoe lang het duurt om de software conform de in dit document beschreven scope en werkwijze te testen, waarbij de kwaliteit van de software wordt vergeleken met de afgesproken acceptatiecriteria. Het bereiken van kwaliteit is een projectproduct, geen testproduct: testen draagt daar enkel aan bij door kwaliteit te onderzoeken en erover te rapporteren. Hoewel x testrondes zijn ingepland, kunnen minder, of meer rondes nodig zijn om het gewenste kwaliteitsniveau te bereiken.”
Ik heb nog geen projectmanager meegemaakt die na het lezen van deze zin niet de behoefte voelt om erover te discussiëren. En dat is perfect! Tenslotte is bewustwording de eerste stap van verbetering.
Een verhaal met veel herkenning erin.
Twee aanvullingen:
– overweeg eens je projectmanagers een cursus ISTQB foundation (of vergelijkbaar) te laten doen, zodat ze wat meer kennis (en daarmee hopelijk ook begrip) krijgen op het gebied van testen. Dit kan veel discussie voorkomen
– rapporteer niet in vorm van tijd, maar in vorm van vooruitgang op basis van het aantal testcases wat nog gedaan moet worden. Zoals terecht opgemerkt wordt kun je niet zeggen dat je na X uur testen een uitspraak kunt doen over de kwaliteit. Wel kun je zeggen: als ik deze Y testcases uitgevoerd heb, kan ik een uitspraak doen over de kwaliteit van het product. Voor die Y testcases heb ik Z uren nodig.
Hiermee maak je de testvoortgang leidend, en niet de geplande tijd.
Goed artikel. Ben zo vrij geweest om je zin op te nemen in leerproject testen op de wikiversiteit:
http://beta.wikiversity.org/wiki/Testen
Los van de ‘formele’ opstelling zoals je die schets in je stuk, is het in mijn ervaring het volgende behulpzaam om de beschreven situatie met de project manager te voorkomen:
– Ga zelf de dialoog met de project manager aan ruim voordat de oplevering plaats moet vinden. Overigens je bent al een in geweldige positie als een project manager je vraagt hoe lang het gaat duren. In mijn ervaring wordt een test manager pas laat of helemaal niet betrokken bij de (initiële) planning van een project.
– Zorg ervoor dat de tester een integraal onderdeel is van het ontwikkel-proces. Positioneer het dus niet als een losse activiteit. Uiteindelijk is het ontwikkelaar die verantwoordelijk is voor het voldoen aan de eisen van zijn product. De tester is een belangrijk hulpmiddel daarbij.
– Daarnaast is een goed onderscheidt tussen de type testen ook van belang. Met name bij acceptatie testen kan het nogal eens spaak lopen doordat de acceptatie-testers onvoldoende betrokken zijn geweest en/of geïnstrueerd zijn. Het gaat uiteindelijk om de perceptie van de klant. Het managen hiervan is een belangrijk samenspel tussen de project manager, change manager (indien aanwezig) en de test manager.
@PaVaKe: helemaal eens dat een stuk opleiding aan project managers een belangrijke bijdrage levert in het onderlinge begrip.
Enkele aandachtspunten:
– @ PaVaKe zijn de projectmanagers wel bereid om een cursus te volgen om het testen beter te begrijpen
– in hoeveel gevallen komt het voor dat er goede communicatie is tussen testers, ontwerpers en ontwikkelaars
Mijn ervaring:
1. projectmanagers zijn niet geinteresseerd in kwaliteit – want slecht meetbaar.
2. projectmanagers kijken naar planning als iets lineairs, terwijl het ontwikkel/test traject circulair is.
Long way to go…
@PaVaKe: helemaal met je eens wat betreft opleidingen. Ik zie trouwens ook een toename van projectmanagers in de TMap Next Foundation trainingen, maar gemeengoed is het nog zeker niet.
@Tim: leuk, dank!
@Christof: dank voor je reactie.
Algemeen geldt dat het managen van verwachtingen misschien wel je belangrijkste taak als testmanager is. Mijn ervaring is dat ik in de meeste gevallen gelukkig wel betrokken word bij het opstellen van planningen, maar als dat niet gebeurt is het zaak om aan te geven wat het maximale resultaat binnen de opgelegde tijdlijnen zijn. Als men niet kan krijgen wat men verwacht is het in ieder geval zaak dat men kan verwachten wat men krijgt.
Wat betreft je tweede punt, goede aanvulling, dat is inderdaad een uitstekende uitgangspunt. Daarom werk ik graag volgens Agile-achtige methodieken, waarin die integraliteit basis van de aanpak is. Helaas heb je ook dit als testmanager niet altijd voor het uitkiezen, maar je kunt het zeker proberen te beinvloeden. En op punt drie kunnen we elkaar de hand schudden, die ervaringen met gebruikers en acceptatietesten heb ik ook. Naast het managen van de perceptie is het stellen van duidelijke randvoorwaarden aan (kennis, mandaat en inzet van) de gebruikersorganisatie trouwens deel van het succes, waarbij de handhaving ervan (net zoals alles in ons vak) de delicate balans bewandelt tussen rigiditeit en pragmatiek.
De projectmanager die je in je artikel beschrijft lijkt me iemand te zijn die niet veel ervaring met projectmanagement/projectleiding heeft! Of is er sprake van iets anders waar jij geen weet van heb en je denkt dat dit door projectmanager en zijn aanpak veroorzaakt is!
Ik lees hier een artikel met veel hij, wij, zij, hun, ons …… spijtig dat het zo gekeken wordt naar een teamwerk!
Het ontwikkelen van een software is een teamwerk met veel interactie tussen verschillende eenheden binnen het team. Testers, ontwikkelaars en projectmanager vormen een driehoek die SAMEN het product moeten opleveren. Bij het opstellen van planning, test en kwaliteitsactiviteiten en nog meer zaken zullen de betrokken medewerker(s) door projectmanager geraadpleegd worden om tot juiste raming voor verschillende activiteiten, volgorde, doorlooptijden etc te komen. Het is niet waar dat de projectmanagers geen interesse hebben in de activiteiten van een tester/ontwikkelaar of iemand anders in het projectteam, zoals je het aangeeft.
Als projectleider zal ik zeer waarde hechten aan de fouten die tijdens bouwfase gevonden en opgelost zijn voordat het product in de productie opgenomen word. En ik kan me moeilijk voorstellen dat het opleveren van een product dat degelijk getest en betrouwbaar is geen doel van een projectmanager is. Als zijn planning dit niet toelaat dan zou hij eerder met zijn opdrachtgever dit probleem bespreekbaar moeten maken (onnodige tip! Want elke projectmanager weet dit al). De achtergrond van het project, politiek en nog veel andere zaken waar de teamleden geen weet van hebben zijn soms de oorzaak van strakke planning en minder aandacht aan kwaliteit en werkzaamheden van teamleden. In dit geval vind ik het niet terecht als gezegd wordt dat de projectmanagers alleen naar oplevering kijken en niet naar mensenwerk, want deze situatie (gebrek aan tijd) is door andere mensen en op ander niveau gecreëerd en niet projectmanager.
Tijd is een belangrijk aspect die effect heeft op kwaliteit en kosten. Als een tester in de beginfase van het project aangeeft dat de planning, volgorde van activiteiten of de beschikbare tijd niet juist geschat zijn dan zal de projectmanager gek zijn om hem/haar niet te vragen om samen een kopje koffie te gaan drinken. Maar neemt een tester ook zijn verantwoordelijkheid om dit te doen?
@Christof: mooie reactie met waardevolle informatie, dank!
@Reza, dank voor je reactie. Goed om ook weerwoord te krijgen.
Ik alleen denk dat onze boodschap niet wezenlijk verschillend is, ik krijg alleen het idee dat je gestruikeld bent over iets dat ik in mijn eerste alinea noem waardoor je de rest van mijn stuk gelezen hebt als een aanklacht tegen de projectmanager. Maar dat is allerminst wat ik beoog te bereiken.
Wanneer ik aangeef dat de projectmanager ‘niet geinteresseerd is in…’ dan wil ik daarmee niet een hele beroepsgroep een gebrek aan kennis en empathie verwijten, maar geef ik aan dat testers moeten beseffen dat voor de projectmanager het aantonen van kwaliteit slechts een halte is op de lijn naar het eindstation ‘kwaliteit bereikt’. Ik constateer dat als projectmanagers (als pars-pro-toto voor de rest van het projectteam) aan het einde van de geplande testruns de verwachting hebben dat de applicatie kwalitatief goed genoeg is om live te gaan dat we als testers een slag gemist hebben.
Overigens verschillen mijn ervaringen wel van de jouwe, ik heb diverse (ervaren) projectmanagers meegemaakt die weinig kennis van testen hebben, maar ook diverse (ook relatief onervaren) die wel een behoorlijke basiskennis van testen hebben. Dat bedoel ik niet als een veroordeling, dat is een constatering waarin ik vind dat testers een taak hebben om uitleg te geven. Door meer uitleg te geven en beter te rapporteren over voortgang kun je op alle mogelijke momenten in het project een open dialoog voeren over het bereiken van een zo maximaal mogelijk resultaat in zo min mogelijk tijd.
Interessant artikel, Peter.
N.a.v. de reacties op je verhaal een opmerking over het kweken van testbewustzijn:
Waarom gaan mensen die iets over testen willen weten naar een examentraining (ISTQB of TMap)? Het ‘gevaar’ is dat ze het examen halen en dan als gecertificeerd tester door het leven gaan, terwijl ze nog nooit getest hebben en dat misschien ook wel nooit gaan doen. Een dergelijke training bereidt voor op een examen en niet meer dan dat. Er zijn toegespitste trainingen / workshops die deelnemers (testers en niet-testers) kennis en begrip bijbrengen. En daar zijn projecten veel meer bij gebaat.
Gerard,
Absoluut eens. Er is in testland zelf al veel discussie over certificering, omdat het schijnveiligheden geeft. Je hoeft geen praktiserend tester te zijn (laat staan een goede) om een certificaat te kunnen halen. Ik ben het met je eens dat zeker voor aanpalende disciplines deze examentrainingen geen goed medium zijn.Op zich is de diepgang nog wel voldoende, maar de nadruk ligt op het halen van het examen, en niet op het duurzaam bijbrengen van de stof, laat staan op het geven van praktijkvoorbeelden (die zoals bekend nog wel eens willen afwijken van de theorie ;-)).
Overigens ben ik niet bekend met goede test-awareness trainingen waarmee bijvoorbeeld andere projectmedewerkers inzicht kunnen krijgen in de basis van testen. Ik ben heel benieuwd of je concrete trainingen kent, dat hoor ik graag van je!