Leiderschap in testen: testplanning
Opmerking van de redactie: Welkom bij de serie Leiderschap in testen van softwaretestexpert en consultant Paul Gerrard. De serie is bedoeld om testers met enkele jaren ervaring—vooral degenen in agileteams—te helpen uitblinken in hun rollen als testleider en manager.
In het vorige artikel gingen we dieper in op documentatie en enkele best practices. Deze keer passen we veel van de kennis uit eerdere artikelen toe en gebruiken we die om een testproject te plannen.
Schrijf je in voor de nieuwsbrief van The QA Lead om een melding te ontvangen wanneer nieuwe delen van de serie verschijnen. Deze berichten zijn fragmenten uit Pauls cursus Leiderschap in testen, die we ten zeerste aanbevelen voor een diepere duik in dit en andere onderwerpen. Als je dat doet, gebruik dan onze exclusieve kortingscode QALEADOFFER voor $60 korting op de volledige cursusprijs!
Wat is een plan eigenlijk?
Een projectplan combineert de projecttaken, geschatte doorlooptijden, afhankelijkheden en op te leveren resultaten tot een gepland model van de werkelijkheid.
Als je het plan beschouwt als een voorspelling van de toekomst, zou je zeer terughoudend zijn om erop te vertrouwen, maar dat is wat we meestal doen.
Misschien ben je projectmanagers tegengekomen die hun plan behandelen als hun persoonlijke werkelijkheid—hun eigen waanwereld. Maar we moeten niet zo hard zijn voor projectmanagers—zij worden vaak gemotiveerd om een plan te maken en het koste wat kost uit te voeren.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Het plan is niet de werkelijkheid; het is een model van de werkelijkheid dat voortdurend moet veranderen.
In dit artikel behandel ik elke fase van testplanning, waaronder:
- Op te leveren resultaten
- Hoe
- Middelen
- Je ondersteuningsnetwerk
- Schattingen
- Afhankelijkheden, risico's en aannames
- Communicatie, toezeggingen en voortgangsrapportage
Maar laten we eerst een duidelijk beeld krijgen van het nut van een plan.
Waarom plannen?
Het doel van plannen is meestal om een overeengekomen aanpak, reeks toezeggingen, afhankelijkheden, kosten en planning op te stellen voor de uitvoering van een project. Het plan vormt een overeenkomst tussen projectbelanghebbenden, leveranciers en deelnemers waarin doorgaans het volgende wordt vastgelegd:
- Welke middelen wanneer nodig zijn
- Wanneer taken moeten beginnen en eindigen en wie ze zal uitvoeren
- Welke vaardigheden nodig zijn om taken te voltooien
- Welke hulpmiddelen en technologieën het plan ondersteunen
- Welke resultaten moeten worden opgeleverd en wanneer
- De kosten van de benodigde inspanningen en middelen
- Het proces om het project/proces door de verschillende fasen heen te begeleiden
- De risico's die de oplevering bedreigen.
Sommige van deze aspecten zijn mogelijk in een strategie vastgelegd of al aanwezig. Het kan bijvoorbeeld bekend zijn welke leveranciers betrokken zijn en wat zij voor het project zullen doen. De te gebruiken hulpmiddelen en technologie zijn mogelijk al bekend en geïmplementeerd. De mensen, testomgevingen en gegevens zijn wellicht al beschikbaar. Er kan ook een strategie zijn die het te gebruiken proces, de aanpak of de technieken definieert.
Maar terwijl de strategie de principes of de theorie uiteenzet, beschrijft het plan de praktische aspecten of logistiek van de manier waarop het project in werkelijkheid zal worden uitgevoerd.
Een strategie zet uiteen hoe een project in principe zal worden uitgevoerd; het plan definieert en bevestigt hoe het project in de praktijk zal worden uitgevoerd.
Voor veel projectmanagers wordt het plan bijgehouden in software zoals Microsoft Project, maar een levensvatbaar plan hangt ervan af of alle projectdeelnemers weten wat ze doen en hoe ze dat moeten doen. Om dit te bereiken, moeten het plan en de kennis over hoe zaken worden uitgevoerd door alle betrokkenen worden gecommuniceerd en onderschreven.
Plannen is een reis, geen taak
Om de voormalige Amerikaanse president Dwight D. Eisenhower te citeren: “planning is alles. Het plan is niets.” Dit sentiment is zo belangrijk dat het in bijna elke werkcontext binnen systeemprojecten herhaald moet worden. Maar wat betekent het om te zeggen dat het plan niets is? Wat is het nut van plannen als het resultaat een waardeloos plan is?
Het plan waarmee je uiteindelijk eindigt, is nooit waardeloos, maar het sentiment van Eisenhower heeft betrekking op het plannen zelf en de waarde daarvan in vergelijking met het plan. Laten we snel afzonderlijk vergelijken hoe planning werkt in langere, gestructureerde projecten en in agile/continue projecten.
Gestructureerde versus agile planning
In een langlopend project moeten je bedrijf, leveranciers en interne IT-medewerkers weten welke inzet van hen wordt verwacht, zodat ze de beschikbaarheid van mensen en fysieke middelen kunnen plannen.
Het kost kostbare tijd om de benodigde informatie te verzamelen om een plan op te stellen. Met alle afhankelijkheden van middelen en mensen, en van de inzet en prestaties van leveranciers en interne medewerkers, kan er veel misgaan. Sommige dingen zullen misgaan. Daarom is het plan, als voorspelling van de toekomst, bijzonder moeilijk op te stellen.
De dag nadat een plan is gepubliceerd, en elke daaropvolgende dag, komt er nieuwe informatie aan het licht en is enige aanpassing nodig. Vereisten worden geschrapt; leveranciers leveren te laat; omgevingen, testgegevens of hulpmiddelen zijn niet op tijd gereed. De lijst gaat maar door. Plannen is nooit een eenmalige taak, het is een voortdurende — bijna dagelijkse —activiteit.
Ongeplande gebeurtenissen worden vaak als ruis beschouwd en krijgen niet veel aandacht. Maar later groeien sommige van deze kleine problemen uit tot grote problemen. Een van de uitdagingen van watervalprojecten is dat deze voortdurende aanpassing belastend kan zijn, omdat wijzigingen worden gezien als onnodig gepruts. Projecten gaan vaak gewoon door, in de hoop dat alles ‘op de avond zelf’ wel goed komt. Maar dat is zelden het geval en er is al vaak gezegd:
Hoe loopt een project een jaar vertraging op? Eén dag tegelijk.
De agile aanpak is gedeeltelijk een reactie op de frustratie van vaste of inflexibele plannen. Wendbaarheid is het bewezen alternatief voor de inertie van omslachtige, gefaseerde aanpakken. Maar betekent dit dat agile projecten niet plannen? Nee.
Zelfs in agile is enige planning vooraf nodig om het werk te structureren, middelen te mobiliseren en — ten minste op hoofdlijnen — het releaseproces voor de komende maanden in te plannen. Maar iteratie na iteratie, en vaak dag na dag, wordt het algemene plan voortdurend aangepast om rekening te houden met gebeurtenissen en nieuwe informatie die aan het licht komt.
Planning is een voortdurend leertraject, geen taak met een opleverbaar resultaat.
Testplanning
Tot nu toe hebben we projectplanning in het algemeen bekeken en aangegeven dat het in grote mate een voortdurende activiteit is. Nu richten we ons specifiek op het plannen van testen in projecten.
Testplanning lijkt sterk op projectplanning – het is eigenlijk gewoon een plan op kleinere schaal. Natuurlijk moet het testplan ook worden geïntegreerd met het grotere projectplan, omdat het afhankelijk is van andere projectactiviteiten en opleveringen (en andere taken afhankelijk zijn van testen). Testplannen worden vaak verstoord omdat niet aan deze afhankelijkheden wordt voldaan.
Testplannen zijn in grote lijnen relatief eenvoudig. Er kunnen verschillende activiteiten zijn die afhankelijk zijn van het bovenliggende project. Dit zijn de activiteiten die vaak als taken in het grotere projectplan verschijnen. Maar deze activiteiten zijn verdeeld over een team, met mogelijk een grote inventaris van testitems waarvoor tests moeten worden gepland en uitgevoerd.
Dit detailniveau is niet zo relevant voor de planning van de projectmanager en wordt doorgaans lokaal binnen het testteam gedefinieerd en beheerd.
Laten we enkele kernelementen van je testplan bekijken.
Opleveringen
Wat zijn de opleveringen van testen?
Wat een vraag! Dat zijn toch zeker de testspecificaties, de tests, de resultaten en rapporten? De opleveringen zijn in wezen opgenomen in documentatie, dus het enige waar we ons zorgen over hoeven te maken, is het papierwerk afronden en enkele vakjes aanvinken.
Maar deze aanpak, hoewel gebruikelijk, is er gedeeltelijk verantwoordelijk voor dat testen (en testers) de reputatie hebben gekregen van dure, starre bureaucraten die weinig waarde toevoegen. Wie leest al die omvangrijke documenten immers?
Stel dat er in een agile project geen intentie is om testdocumentatie op te stellen. Dat is zeer waarschijnlijk, dus wat levert testen in die situaties daadwerkelijk op? Welke waarde heeft testen überhaupt? Het is een beetje laat om deze vragen te stellen, nietwaar?
Wanneer een component, subsysteem of het volledige systeem wordt getest, is de output bewijs van hoe het systeem zich in een bepaalde situatie of context gedraagt. Bewijs van systeemgedrag wordt verzameld en gebundeld om aan belanghebbenden (ontwikkelaars, gebruikers, managers enzovoort) te worden gepresenteerd, zodat zij een beslissing kunnen nemen: bugs oplossen, een component integreren, functionaliteit accepteren of afwijzen, of een subsysteem of het systeem als geheel uitbrengen of implementeren.
De oplevering van testen is bewijs van systeemgedrag dat door belanghebbenden wordt gebruikt om een beslissing te nemen.
Nu is het in sommige projecten essentieel om testdocumentatie te verstrekken waarin wordt vastgelegd hoe een test is afgebakend, ontworpen, geïmplementeerd en uitgevoerd. Maar het bewijs van systeemgedrag is uiteindelijk het waardevolste eindproduct voor belanghebbenden.
De waarde van testen is het vertrouwensniveau dat belanghebbenden hebben bij het nemen van beslissingen op basis van testbewijs.
Dit bewijs kan systematisch worden verzameld, in tabellen worden vastgelegd en geanalyseerd in geavanceerde oplossingen voor testbeheer, en aan belanghebbenden worden gepresenteerd in elegante grafische formaten. Of de handgeschreven aantekeningen kunnen door een tester worden gebruikt om tijdens een stand-upvergadering mondeling het testverhaal aan een producteigenaar te presenteren.
Ongeacht hoe het wordt verzameld en gepresenteerd, de laatste taak van testen is het overdragen van het bewijs.
Hoe
Ongeacht de omvang of methodologie van het project, is testen afhankelijk van een bepaalde reeks activiteiten. We bekijken een generiek proces door de ogen van de tester (of het team) en kijken vervolgens naar enkele variaties die voorkomen.
Er zijn zogenaamde ‘testactiviteiten’ en er zijn ‘testondersteunende’ of ‘logistieke’ activiteiten. Om er zeker van te zijn dat je alle activiteiten in het plan opneemt, kunnen de onderstaande tabellen nuttige controlelijsten zijn.
Een activiteit in de bovenstaande tabel die je misschien minder goed herkent, is de feedbackactiviteit. Je hebt waarschijnlijk al eens met gebrekkige requirements moeten werken.
Tijdens de activiteit voor feedback, beoordeling en het ter discussie stellen van requirements ontdekken testers, nadat ze een requirement hebben doordacht en gemodelleerd, problemen en kunnen ze voorbeelden gebruiken om aan te tonen waar requirements ontbreken, dubbelzinnig of tegenstrijdig zijn.
Als je requirements als gebrekkig beschouwt, is het zeker de moeite waard om ruimte te maken voor deze activiteit.
Testlogistiek
Testlogistiek ondersteunt de bovenstaande testactiviteiten. Hoewel de lijst met testactiviteiten die ik heb gegeven redelijk uitgebreid is, varieert de testlogistiek per project en organisatie. De onderstaande lijst is daarom niet volledig. Neem in je project de tijd om elke activiteit of afhankelijkheid te overdenken die nodig is om het testen uit te voeren.
Middelen (menselijk, fysiek)
We gebruiken vaak het woord middelen om te verwijzen naar mensen in onze projecten, en voor sommigen voelt dat ongemakkelijk. Mensen zijn geen dingen, maar natuurlijk menselijke wezens. In kleinere projecten is het misschien mogelijk om namen te gebruiken, maar in grotere organisaties, wanneer projectteams betrokken zijn en mogelijk nog niet zijn samengesteld, is een aantal middelen simpelweg een verkorte manier om een aantal mensen aan te duiden.
Belangrijker is dat het niet noodzakelijkerwijs het aantal mensen is dat telt – het zijn hun capaciteiten die er echt toe doen. Mensen werken natuurlijk op verschillende manieren en meestal ook met verschillende snelheden, dus daar moet je in je planning rekening mee houden.
Naast mensen heb je in verschillende fasen verschillende fysieke middelen nodig om het testen voort te zetten. Deze variëren van alledaags tot zeer specifiek, en het ontbreken van een van deze middelen kan de testopdracht in gevaar brengen.
Misschien heb je al het geluk toegang te hebben tot een volledig uitgeruste, beheerde, speciale testomgeving. Zo niet, dan moet je mogelijk alles specificeren – van fysieke ruimte en meubilair tot post-its en gummen – om je werkomgeving te definiëren.
In de onderstaande tabel staan enkele typische vereiste middelen. Jouw lijst zal ongetwijfeld aanzienlijk verschillen.
Wanneer je alle middelen hebt geïdentificeerd die nodig zijn om je plan uit te voeren, ga dan na of je extra activiteiten in je plan moet opnemen om deze te verwerven.
Je ondersteuningsnetwerk
Als de mensen en vaardigheden die je nodig hebt om het testen uit te voeren onder jouw controle stonden, zouden projecten veel eenvoudiger kunnen zijn! Maar weinig teams beschikken over alle benodigde vaardigheden of over de autorisatie en toegang tot de noodzakelijke fysieke middelen. Veel projecten worden bemand en uitgevoerd volgens de stijl van matrixmanagement. Belangrijke teamleden rapporteren daadwerkelijk aan managers van andere gespecialiseerde afdelingen en je krijgt slechts beperkte inzet van hen.
Mogelijk moet u een vast aantal uren per dag of tijdstippen opgeven waarop u toegang wilt tot de hierboven genoemde specialistische vaardigheden. Soms wordt u gevraagd welk serviceniveau aanvaardbaar is, bijvoorbeeld: ‘verzoeken met hoge prioriteit worden binnen dertig minuten beantwoord, enzovoort.’
Schattingen
Schattingen maken in softwareprojecten is een lastige bezigheid. Er is veel geschreven over hoe moeilijk of zelfs onmogelijk schatten is. Toch zijn schattingen in alle projecten nodig, en hoe groter het project, hoe meer we ervan afhankelijk zijn.
We hebben schattingen nodig om een planning te maken, maar het probleem is dat schatten geen nauwkeurigheid oplevert. Het beste wat we ooit kunnen doen, is een inspanning of verstreken tijd berekenen met een bepaald niveau van zekerheid of waarschijnlijkheid.
Sommige mensen beschouwen schatten als een duistere kunst en er is zelfs een #NoEstimates-beweging met een aanzienlijke aanhang. Er bestaat veel discussie over de vraag of schattingen ooit nauwkeurig genoeg kunnen zijn of zelfs wel een goede praktijk zijn in softwareprojecten.
Schatten zal nooit een exacte wetenschap zijn. Maar op basis van mijn ervaringen zijn er enkele principes die ik met vertrouwen kan delen:
- Vereisten zijn feilbaar en onnauwkeurig.
- Mensen zijn min of meer bekwaam, gewetensvol en hardwerkend.
- Hoe kleiner het werkitem, hoe gemakkelijker het te schatten is; splits grote taken waar mogelijk op in kleinere eenheden en tel de schattingen daarvan op tot de grotere taak.
- Schatten is gebaseerd op ervaring. Als u die niet hebt, zoek dan uit waar de ervaring van anderen relevant is en kan worden aangepast.
- Uw werkitem is uniek, dus zoek naar werkpatronen in andere bekende situaties waarin u ervaring hebt.
- Vraag anderen om een schatting te maken en vergelijk deze. Het bespreken van verschillen brengt verschillen in verwachtingen, vertrouwen en grondigheid aan het licht.
- Schat de best mogelijke situatie en vervolgens de slechtst mogelijke situatie. Een goede schatting ligt daar ergens tussenin.
Schat vandaag en begin met werken; morgen en elke daaropvolgende dag zal uw schatting van de resterende werkzaamheden, dankzij de opgedane kennis, verbeteren.
Afhankelijkheden, risico's en aannames
In een eerder artikel bespraken we risico's en de rol van testen in risicobeheer. Productrisico's hebben betrekking op de vraag of het product voldoet aan de behoeften van gebruikers met betrekking tot functionele of technische vereisten. Hier ligt de focus op de risico's voor het daadwerkelijke opleveringsplan.
In projecten kan er van alles misgaan. Tijdens uw planningsactiviteiten moet u duidelijk maken met welke faalrisico's u rekening hebt gehouden en welke maatregelen u daarvoor hebt getroffen. Dit bestaat uit drie aspecten: afhankelijkheden, risico's en reacties.
Afhankelijkheden
Afhankelijkheden omvatten een lijst van de benodigde menselijke en fysieke middelen en voorafgaande activiteiten die moeten zijn voltooid voordat uw geplande activiteiten succesvol kunnen zijn en resultaten kunnen opleveren.
Er zijn altijd afhankelijkheden voor elke testactiviteit, of het nu gaat om een grootschalige test op systeemniveau of een verkennende testsessie van een functie. Afhankelijkheden omvatten drie hoofdaspecten.
Risico's
Het risico is de waarschijnlijkheid dat uw plan tijdens de uitvoering mislukt. Risico's hebben betrekking op zaken zoals:
- Uw schattingen: waardoor kunnen uw schattingen onjuist zijn? Een systeem dat complexer, gebrekkig, onvolledig of voortdurend aan verandering onderhevig is, kan uw schattingen allemaal beïnvloeden.
- Mensen die niet beschikbaar zijn, over onvoldoende ervaring of vaardigheden beschikken of zich niet volledig inzetten voor uw fase van het project. Dit kunnen teamleden zijn of mensen in uw ondersteuningsnetwerk.
- Infrastructuur, zoals testomgevingen, hulpmiddelen (of training in het gebruik daarvan) of kantoorruimte, die niet beschikbaar, onjuist voorbereid of defect is.
- Voorafgaande activiteiten die niet op tijd worden voltooid (of worden opgegeven, gedeeltelijke of gebrekkige producten opleveren of helemaal niets opleveren).
Reacties
Voor elk van deze risico's moet u de waarschijnlijkheid en de impact beoordelen en, wanneer dat van belang is, een passende reactie of verwacht gevolg bepalen. Deze reacties hebben doorgaans een van de volgende vormen:
- Aanname: het risico wordt laag genoeg geacht om het te negeren of als onbeduidend te beschouwen. Het staat echter wel op de radar en wordt als aanname vastgelegd (van beschikbaarheid, volledigheid enzovoort).
- Aanpassen: het risico is aanzienlijk, maar er kan actie worden ondernomen om de impact ervan op het plan te beperken. Als het systeem dat wordt getest bijvoorbeeld gedeeltelijk is opgeleverd en functies ontbreken, kan het plan worden aangepast om alleen de beschikbare functies te testen.
- Gevolg: sommige risico's kunnen niet worden opgevangen. Als het systeem te laat wordt opgeleverd, kan het testen pas beginnen nadat het is opgeleverd.
Communicatie, betrokkenheid en voortgangsrapportage
Tot slot komen we bij een cruciaal maar vaak over het hoofd gezien aspect van planning. Je kunt een projectplan opstellen waarin alle taken, deelnemers, middelen, verantwoordelijkheden, afhankelijkheden, planningen, inspanningen en kosten zijn opgenomen. Of het kan gaan om een mondelinge afspraak tussen de leden van een agile team.
Hoe dan ook moet het plan effectief met iedereen worden gecommuniceerd, zodat iedereen weet wat er nodig is en wanneer.
Een overeengekomen plan is een contract tussen deelnemers. Als een teammanager een plan goedkeurt, vormt dat impliciet of expliciet een toezegging om het deel van het contract waarvoor het team verantwoordelijk is, na te komen.
Het plan is een contract tussen deelnemers.
Bij minder formele projecten is er mogelijk helemaal geen schriftelijk plan of schriftelijke toezegging. In deze omstandigheden is het plan een doorlopend gesprek tussen de leden van het team. Het team komt dagelijks bijeen en de actieve taken in het plan worden in realtime besproken. Waar werken mensen aan? Verloopt de voortgang volgens de verwachtingen? Welke problemen ervaren mensen? Welke problemen belemmeren de voortgang?
Bij alle projecten heeft voortgangsrapportage twee doelen. Uiteraard is het nodig om te communiceren waar iedereen staat wat betreft de huidige projectactiviteiten. Maar het voortgangsrapport is ook een periodieke, doorlopende controle om vast te stellen of de voortgang kan worden gehandhaafd en om te verifiëren of er op de toezeggingen van de deelnemers kan worden vertrouwd.
Bedankt voor het lezen, en kom de volgende keer bij ons terug voor… je raadt het al: uitvoering!
Schrijf je in voor de nieuwsbrief van The QA Lead om een melding te ontvangen wanneer nieuwe delen van de reeks verschijnen. Deze berichten zijn fragmenten uit Pauls Leadership In Test-cursus, die we van harte aanbevelen voor een diepgaandere behandeling van dit en andere onderwerpen. Als je dat doet, gebruik dan onze exclusieve kortingscode QALEADOFFER voor $60 korting op de volledige cursusprijs!
