Reactief en proactief testen: het zijn geen officiƫle testtermen. Toch merk ik dat ze voor mij steeds meer een belangrijk onderwerp worden. Wanneer test je op basis van incidenten, wanneer op basis van strategie? En waarom is beide nodig?
Bij reactief testen test je op basis van "wat moet er nu getest worden". Hierbij moet je denken aan gebouwde story's, gemelde bugs. Maar ook op basis van klachten en zorgen van klanten, managers, helpdesk, collega's. Je reageert met je testen op wat er in je omgeving gebeurt.
Bij proactief testen test je op basis van een strategie. Dit kan een testtechniek zijn, een risicoanalyse, een analyse van de fouten gevonden in de afgelopen maand. Het grote verschil: hoewel de opgeleverde story's en bugs en ook de klachten en zorgen meetellen, zijn ze niet doorslaggevend. Je kan besluiten om een bug niet te testen of een klacht te negeren.
Ik weet: de scheiding is niet zo strikt. Je kan reactief een story testen, maar deze story vervolgens proactief testen met behulp van een gekozen testtechniek. Of je kan op basis van een proactieve risicoanalyse besluiten om alle bugs reactief te testen. Het belangrijkste is: je hebt als tester een andere rol. Bij reactief doe je wat er van je gevraagd wordt: testen wat getest moet worden. Bij proactief doe je wat er van je verwacht wordt: de kwaliteit bewaken.
Je kan niet altijd de hele omgeving negeren als tester. Opgeleverd werk moet getest worden. Bugs moeten gecontroleerd worden. En klanten of managers hebben eisen en verwachtingen. Als de prioriteit hoog genoeg is, kan je niet als tester zeggen: kan best, maar ik test het niet, want het komt niet overeen met mijn strategie.
Maar je kan ook niet altijd zeggen: ik test gewoon alleen wat er van me gevraagd wordt. Waarom? Dat heeft te maken met een vaak vergeten balans. Iedereen kent de balans van tijd v.s. kwaliteit. Als je minder tijd krijgt, gaat over het algemeen de kwaliteit achteruit. Maar zo is er ook een balans tussen kwaliteit v.s. kwaliteit. Je hebt als tester maar x uur in de week. Als je deze aan programma A besteed, kan deze niet naar programma B. Als je deze aan performance testen besteed, kan deze niet naar functioneel testen. En als je minder tijd kan besteden aan programma B of functioneel testen, is de kans groot dat de kwaliteit van deze applicatie of dit onderdeel gaat afnemen.
Om dit te voorkomen heb je een soort basisdekking nodig. Een soort gegarandeerde minimale tijd of dekking, die een test of een programma of een ander los te testen onderdeel nodig heeft. Dit kan letterlijk tijd zijn. Maar ook een groep eisen, die minimaal getest moeten zijn. Een automatische test, die minimaal uitgevoerd moet zijn. Wat er nodig is, zal je als tester moeten bepalen. En, en dit is het moeilijkste, dit zal onder alle omstandigheden moeten plaatsvinden. Ook als het druk is, ook als het je niet uitkomt, ook als hierdoor een deadline in gevaar komt. Je kan altijd proactief besluiten om meer te testen, maar deze minimale dekking moet plaatsvinden. Zo zorg je ervoor dat de balans nooit teveel doorslaat van A naar B.
Waarom is dit nodig? Vooral in drukke tijden ontstaat de neiging om "per dag" te leven. En als een team onder druk wordt gezet, ontstaat de neiging om "per managerswens" te leven. Je test wat wordt aangeleverd en wat je omgeving van je vraagt. En wat niet wordt gevraagd of wordt aangeleverd, test je niet. Totdat wordt opgemerkt dat in deze opleveringen wel erg veel fouten zitten. Dan opeens wordt het werk geconcentreerd op dit probleem. En ontstaat er precies zo'n zelfde situatie op andere plaatsen. Plaatsen waar jij nu niet test. Zo spring je, als je niet oppast, van de ene critical situation naar de andere critical situation. En zou het dan niet veel beter zijn om een volgende critical situation te voorkomen?
Ja, reactief testen is nodig. Wat opgeleverd is, moet getest worden. En in elke organisaties zijn er nu eenmaal prioriteiten, waar je als tester rekening mee moet houden. Maar je moet wel je testersvaardigheden blijven inzetten. Zorg ervoor dat je alles zo blijft testen, dat je een zekere kwaliteit kan blijven garanderen. Dat de kwaliteit van een oplevering niet alleen afhankelijk is van de externe omstandigheden, maar ook van jou kennis en ervaring als tester. Blijf altijd proactief testen. Het zal niet altijd makkelijk zijn, maar uiteindelijk zal het zowel jou als je organisatie meer rust geven.
Deze blog is geschreven vanuit een onbekender perspectief: agile testen in organisaties met heel weinig testers, regelmatig zelfs maar 1. Organisaties waar veel testonderwerpen nog geheel nieuw zijn. En het vaak bijbehorende effect: op de vraag "Kan ik....." kan de tester regelmatig "Nee" als antwoord krijgen. Met aan de tester de taak dit niet als belemmering, maar als uitdaging te zien.
zondag 5 april 2020
Reactief en proactief testen: wat is het en waarom is het beide nodig?
Labels:
Hoe test je?,
Kwaliteit,
Management,
Team,
Teststrategie,
Testuitvoering,
Testvoorbereiding
Abonneren op:
Reacties posten (Atom)
Wat een herkenbare situatie! Hierbij denk ik nog regelmatig tevreden terug aan een project waar we samen nauw bij betrokken waren. Hierin hebben we mijns inziens de juiste balans weten te vinden in hetgeen je hierboven beschrijft waardoor we verantwoord elke dag nieuwe updates konden uitrollen/installeren. Jij als enige tester met beperkte set aan middelen die ik als projectmanager ter beschikking kon stellen maar 'samen' in goed overleg het maximale resultaat behaald. Key Succes Factoren: (jouw) beheersing van het tekstvak en businesskennis, zelfkennis en wederzijds vertrouwen.
BeantwoordenVerwijderen