Leiderschap in testen: een testproject uitvoeren

De klassieke druk op testen

Iedereen die systemen heeft getest, heeft meegemaakt dat het te testen systeem te laat wordt opgeleverd. Op vrijwel elk niveau, van componenten tot volledige systemen, komen ontwikkelaars problemen tegen en wordt de oplevering vertraagd of onvolledig uitgevoerd. In de meeste situaties, waarin een periode is toegewezen om het testen uit te voeren, verschuift de deadline niet en komt het testen onder druk te staan. Hierdoor moeten teams kiezen tussen kwaliteit en snelheid. Bekijk voor tools die het beste van beide werelden bieden onze lijst met de beste softwaretestplatforms.

Get Free Access

Get regular tech leadership wisdom for delivering better software and systems.

Sign up with:

LinkedInGoogleMicrosoft

Or sign up with email:

Name*

First name Last name

Seniority*

Select an optionExecutive / C-suiteVPDirectorManagerIndividual ContributorOther

Business email*

Create Password*

This field is hidden when viewing the form

LinkedIn profile

This field is hidden when viewing the form

Company's AI adoption maturity

Select an optionExploring opportunitiesRunning pilotsScaling adoptionEmbedded in the business model

This field is hidden when viewing the form

Free Account Module

Bottom BarLanding PageFooterInlinePop UpSidebarSSO

Gedeeltelijke en incrementele oplevering

Hoewel het volledige systeem niet voor het testen kan worden opgeleverd, kan bepaalde functionaliteit – een gedeeltelijk systeem – worden geleverd met de belofte dat latere releases de resterende functionaliteit zullen bevatten. Op elk moment is de status van de functies in een release als volgt:

• Voltooid zoals vereist: deze functies zijn testbaar – op zijn minst afzonderlijk.
• Onvolledig: functies missen functionaliteit en/of staan erom bekend fouten te bevatten.
• Ontbrekend: uitgesteld tot levering in een latere release.

Wat betreft de beschikbare functies kan het mogelijk zijn om ze afzonderlijk te testen. Ze kunnen echter afhankelijk zijn van gegevens die door andere, nog niet beschikbare functies worden aangemaakt, waardoor het testen ervan moeilijker kan worden.

Functies kunnen beschikbaar zijn, maar de uitvoer van die functies kan niet worden geverifieerd door andere functies die nog niet beschikbaar zijn. Daarom is onderzoek van de testdatabase vóór en na de test vereist. Het is vrijwel zeker dat je end-to-endtests waarvoor testbare reeksen functies nodig zijn, grotendeels geblokkeerd zullen worden.

In vrijwel alle opzichten wordt testen op systeemniveau van gedeeltelijke systemen ernstig belemmerd.

Testen verdedigen

Je team moet hoe dan ook vooruitgang boeken. Als het systeem niet beschikbaar is, of slechts gedeeltelijk beschikbaar is voor het team, zul je de verwachtingen moeten managen en je plan moeten verdedigen. 

Je testplan, in het klein of in het groot, is afhankelijk van de beschikbaarheid van het systeem – dit is een aanname – dus je plan moet veranderen. Misschien leg je geen formele toegangscriteria vast, maar de boodschap blijft hetzelfde:

Toelatingscriteria zijn planningsaannames – als niet aan deze criteria wordt voldaan, zijn je planningsaannames onjuist en moet het plan worden aangepast.

Of je nu wacht tot het systeem wordt opgeleverd of toegang hebt tot een gedeeltelijk systeem, je zult vrij snel door je nuttige werkzaamheden heen zijn. Vervolgens krijg je een lastig gesprek met je product owner of projectmanager. Als de deadline voor de voltooiing niet verschuift, zul je gedwongen zijn minder te testen. Sommige functies worden mogelijk minder uitgebreid getest of volledig buiten de testscope geplaatst.

De manager denkt misschien dat je de tijd later kunt inhalen, maar in de praktijk is dat bijna nooit haalbaar.

De verloren testtijd als gevolg van late of gedeeltelijke opleveringen kan niet worden teruggewonnen door ‘harder te werken’.

Waarom loopt het testen vertraging op? Er zijn veel mogelijke oorzaken, maar meestal volgen ze een van deze patronen:

• Omgevingen kunnen niet op tijd worden geconfigureerd. Mensen zijn te laat begonnen, hadden het te druk of waren niet gekwalificeerd om een zinvolle testomgeving te creëren. Wat beschikbaar is, is gedeeltelijk, verkeerd geconfigureerd of onvolledig.
• De oplevering loopt vertraging op omdat de omvang van het werk is onderschat.
• De oplevering loopt vertraging op omdat de software fouten bevat en moeilijk te testen en te repareren is.
• De oplevering loopt vertraging op omdat het ontwikkelteam niet beschikt over de vaardigheden, ervaring of competentie op het gebied van het bedrijfsdomein of de technologieën die het gebruikt.
• De oplevering loopt vertraging op omdat de ontwikkeling te laat is begonnen.
• De oplevering loopt vertraging op omdat de requirements voortdurend veranderen.

Overmacht en andere externe factoren buiten de controle van het projectteam zijn niet opgenomen in bovenstaande lijst. Als de projectmanager erop staat dat de deadline voor het testen niet verandert en de scope van het testen eveneens vastligt, sta je voor een aanzienlijke uitdaging. In elk van de bovenstaande gevallen pleiten de oorzaken van de late oplevering ervoor om meer te testen, niet minder.

Als het ontwikkelwerk is onderschat, geldt dat waarschijnlijk ook voor het testen. Als de software fouten bevat, zal het testen langer duren. Als ontwikkelaars niet over de juiste vaardigheden beschikken, zal de software waarschijnlijk van slechte kwaliteit zijn en langer nodig hebben om te testen. Als ontwikkelaars te laat zijn begonnen (waarom?) en de scope ongewijzigd is, waarom zou het testen dan worden verminderd? Als requirements veranderen, is de kans groot dat je plannen sowieso onjuist zijn – werken volgens een slecht plan maakt het leven onvermijdelijk moeilijker.

Hoeveel van de veelvoorkomende oorzaken van vertraagde oplevering wijzen erop dat er minder getest moet worden? Geen enkele. Verdedig je plan.

Succes en mislukking rapporteren

De meeste testers weten dat effectief testen nieuwsgierigheid, volharding en een neus voor problemen vereist. De belangrijkste motivatie is het uitlokken van fouten en het verzamelen van voldoende bewijs om fouten te herleiden tot defecten die vervolgens kunnen worden opgelost. 

Hoewel het vinden (en oplossen) van defecten goed is voor de kwaliteit van het product, voelt het communiceren van defecten vaak alsof je iemand slecht nieuws brengt. Dat kan een ontwikkelaar zijn die ergens een fout heeft gemaakt en deze moet oplossen, of je rapporteert aan belanghebbenden dat bepaalde kritieke functionaliteit niet correct werkt en dat het systeem vertraging zal oplopen.

Niemand brengt graag slecht nieuws en het is natuurlijk om terughoudend te zijn met het van streek maken van andere mensen, vooral directe collega's. Maar of je nieuws goed of slecht is, is geen gevoel waar de boodschapper zich druk over zou moeten maken. 

Defecten zijn altijd slecht nieuws voor iemand, maar de rol van testen is niet om op deze manier te oordelen. In sommige opzichten lijkt de tester op een journalist die de waarheid probeert te achterhalen. Het verhaal van Het olifantenkind van Kipling bevat de volgende regels:

Ik houd zes eerlijke dienaren:
    (Zij leerden mij alles wat ik weet)
Hun namen zijn Wat en Waar en Wanneer
    En Hoe en Waarom en Wie.

Net zoals een journalist een nieuwsverhaal vertelt, vertel jij het verhaal van wat je hebt ontdekt terwijl je een systeem testte.

De waarheid – het nieuws – kan goed of slecht zijn, maar het is simpelweg jouw verantwoordelijkheid om zowel de problemen als de successen zo goed mogelijk te achterhalen. Je probeert te ontdekken wat een systeem doet en hoe het dat doet. 

Aan het einde van een project is het doel om met zo weinig mogelijk openstaande problemen naar productie te gaan. Je wilt dat al je tests slagen, maar de weg naar succes wordt bemoeilijkt door mislukte tests die moeten worden onderzocht en opgelost. Je tactische doel is om problemen snel te vinden, maar je uiteindelijke doel is om geen problemen te hebben om te rapporteren. 

Om het succes of de mislukking van je testproject nauwkeurig te rapporteren, kun je overwegen geavanceerde testmanagementtools te integreren die uitgebreide analyses bieden

Je moet je gedragen als een onderzoeksjournalist – op zoek naar het verhaal met een kritische en onafhankelijke blik. Zoals Kipling schreef:

Als je Triomf en Tegenspoed kunt ontmoeten en die twee bedriegers precies hetzelfde kunt behandelen …

Dan houd je het hoofd koel en lever je goed werk voor je project en belanghebbenden.

Erosie van testdekking

Welke doelstelling(en) voor dekking er ook aan het begin van het testen bestaan, verschillende factoren werken samen om de daadwerkelijk behaalde dekking te verminderen. Erosie is een passende term, omdat deze de geleidelijke vermindering van de omvang van de geplande tests en het onvermijdelijke besef dat niet alle geplande tests binnen de beschikbare tijd kunnen worden uitgevoerd, goed weerspiegelt.

Erosie van de testdekking heeft vóór de testuitvoering verschillende oorzaken:

• Ten eerste identificeren testplannen de risico’s die moeten worden aangepakt en de aanpak die daarvoor moet worden gebruikt. Plannen gaan meestal uit van een budget voor het testen – wat altijd een compromis is.
• Gebrekkige, instabiele of onvoltooide systeemvereisten, ontwerpen en specificaties maken het opstellen van testspecificaties moeilijker. De dekking van het systeem wordt beperkt door een gebrek aan details in de specificaties.
• De late beschikbaarheid of ontoereikendheid van testomgevingen maakt bepaalde geplande tests onpraktisch of niet zinvol. Integratietests op grotere schaal kunnen mogelijk niet volgens plan worden uitgevoerd, omdat niet alle interfaces of gekoppelde systemen beschikbaar kunnen worden gesteld.
• Prestatietests kunnen worden beperkt doordat omgevingen niet de juiste schaal hebben of niet overeenkomen met de productieomgeving.
• Een late oplevering van de te testen software betekent dat, wanneer deadlines vast blijven staan, de hoeveelheid testen binnen de scope moet worden verminderd.

Erosie van de testdekking tijdens de testuitvoering heeft ook verschillende oorzaken:

• Als de kwaliteit van de te testen software bij de start van een testfase slecht is, kan het uitvoeren van tests bijzonder frustrerend zijn. De meest basale tests kunnen mislukken en de gevonden fouten kunnen zo fundamenteel zijn dat de ontwikkelaars meer tijd nodig hebben om ze te herstellen dan iemand had verwacht. Als het testen wordt opgeschort omdat de softwarekwaliteit te slecht is, loop je achter op schema. Als de deadline niet verschuift, zullen sommige tests buiten de scope worden geplaatst.
• Wanneer er meer fouten optreden dan verwacht, neemt de herstel- en hertestcyclus zelf meer tijd in beslag en zal de tijd opraken om al je tests te voltooien.
• Wanneer de tijd daadwerkelijk op is en de beslissing wordt genomen om uit te brengen, zal niet al het testen zijn voltooid. Sommige tests zijn in het plan nooit bereikt, of sommige resterende fouten blokkeren de voltooiing van mislukte tests. Wanneer de livegangdatum niet verschuift, is dit de eerder genoemde klassieke druk op het testen.

Omgaan met erosie van testdekking is een van de uitdagingen waarmee testers in alle projecten te maken krijgen. Dingen verlopen zelden soepel en het verkorten van de testtijd (en de dekking) is meestal de enige optie om het project op schema te houden.

Het is niet verkeerd om de hoeveelheid testen te verminderen; het is alleen verkeerd om de tests willekeurig te verminderen. Bij het maken van keuzes over welke tests moeten vervallen, moet daarom worden beoordeeld wat de impact is op je testdoelstellingen en de risico’s die moeten worden aangepakt. Mogelijk moet je enkele lastige gesprekken met belanghebbenden voeren.

Wanneer de impact aanzienlijk is, moet je mogelijk een bijeenkomst begeleiden van degenen die om de verminderingen vragen (doorgaans het projectmanagement) en degenen wier belangen door de verminderingen kunnen worden geraakt (de belanghebbenden). Jouw rol is om de situatie uiteen te zetten met betrekking tot de voltooide tests, de huidige bekende toestand van het geteste systeem, de tests die mislukken en/of de voortgang blokkeren, en de hoeveelheid testen die nog moet worden uitgevoerd.

Je plannen en modellen beschrijven de oorspronkelijke omvang van het testen en zijn essentieel om belanghebbenden en het management te helpen de hiaten en resterende risico’s te begrijpen en de beslissing te nemen om door te gaan met testen of te stoppen.

Incidentbeheer

Zodra het project de fasen Systeemtesten en Acceptatietesten ingaat, wordt het grotendeels gestuurd door de incidenten die tijdens de testuitvoering optreden. Incidenten brengen activiteiten in het resterende deel van het project op gang en incidentstatistieken kunnen soms goed inzicht geven in de status van het project. Bij het categoriseren van incidenten moeten we vooruitdenken over hoe die informatie later zal worden gebruikt.

Een incident is een ongeplande gebeurtenis die tijdens het testen plaatsvindt en die van invloed kan zijn op het succesvol voltooien van het testen, de acceptatiebeslissing of de noodzaak om een andere actie te ondernemen.

We gebruiken een neutrale term voor deze ongeplande gebeurtenissen: incident. Deze gebeurtenissen worden echter vaak met andere termen aangeduid; sommige daarvan zijn neutraler dan andere. 

Tests die mislukken kunnen observaties, anomalieën of problemen worden genoemd – neutrale termen die geen oorzaak veronderstellen. Maar soms worden problemen, bugs, defecten of fouten gebruikt – wat veronderstelt dat het systeem gebrekkig is. Dat kan echter een voorbarige conclusie zijn en deze labels kunnen misleidend zijn.

We raden je aan de termen bug, defect of fout te reserveren voor de uitkomsten van de diagnose van fouten bij het bouwen van het te testen systeem, die doorgaans herstelwerk voor het ontwikkelingsteam veroorzaken.

Incidenten manifesteren zich op twee manieren:

1. Falen van het systeem: het systeem gedraagt zich niet zoals verwacht tijdens een test, dat wil zeggen dat het op een bepaalde manier faalt of niet aan een bepaalde eis lijkt te voldoen.
2. Onderbreking van of ondermijning van het testen of tests: een gebeurtenis die het vermogen van testers om hun taken te voltooien beïnvloedt, zoals het verlies of falen van de testomgeving, gegevens, interfaces, ondersteunende, geïntegreerde systemen of diensten, of een andere externe invloed.

Falen van het systeem

Deze incidenten zijn vaak de meest directe zorg, omdat ze het vertrouwen in de kwaliteit van het systeem ondermijnen. 

Onderbrekingen en ondermijnde tests

Sommige organisaties beschouwen deze gebeurtenissen helemaal niet als incidenten – onderbrekingen maken deel uit van het vallen en opstaan van projecten die hun afronding naderen. Ondermijnde tests, waarbij de omgeving of testopstelling onjuist is, kunnen aan het testteam worden verweten (vanwege de inrichting of op zijn minst het niet controleren van de inrichting vóór het testen).

In beide gevallen wordt de voortgang van het testen beïnvloed en, als je het proces beheert, ben je verantwoordelijk voor het verklaren van vertragingen. Om deze reden moet je deze gebeurtenissen als incidenten vastleggen of het team vragen een testlogboek bij te houden en uitval van de omgeving, configuratieproblemen of het ontbreken van geschikte softwareversies om te testen te registreren. Als je dat niet doet, zul je moeite hebben om vertragingen in de voortgang te rechtvaardigen en kan dat een slechte indruk geven van jou en het team.

Incidenten registreren of niet?

Met de opkomst van agile en continue opleveringsmethoden is de traditionele visie op incidentbeheer ter discussie komen te staan. In gefaseerde projecten worden incidenten beschouwd als mogelijke werkpakketten voor ontwikkelaars, die worden goedgekeurd op basis van ernst en/of urgentie. 

Er is een formeel, vaak bureaucratisch proces dat moet worden gevolgd, waarbij incidenten door het ontwikkelteam (of een ander team) worden beoordeeld, geprioriteerd en afgehandeld. Hierbij kunnen geavanceerde hulpmiddelen voor incidentbeheer worden gebruikt.

In kleinere, agile teams is de relatie tussen tester en ontwikkelaar nauw. Het team als geheel kan dagelijks bijeenkomen om grotere incidenten te bespreken, maar meestal worden softwarefouten informeel gedetecteerd, gediagnosticeerd, opgelost en opnieuw getest, zonder dat het nodig is een incident te registreren of anderen binnen het team of externe medewerkers uit de bedrijfs- of IT-organisatie erbij te betrekken. Ernstigere softwarefouten kunnen worden besproken en opgenomen in het werk voor een gebruikersverhaal, of worden gebundeld in speciale iteraties of sprints voor het oplossen van softwarefouten.

We hebben in een eerder artikel het doel en de noodzaak van documentatie besproken. Die bespreking is ook van toepassing op incidenten. Het team moet overwegen of een incidenthulpmiddel en -proces nodig zijn en of dit nuttig is voor het team en/of vereist wordt door mensen buiten het team.

Grotere teams vertrouwen doorgaans op processen en hulpmiddelen om incidenten om drie redenen te beheren: 

1. Om ervoor te zorgen dat incidenten niet worden vergeten
2. Om ervoor te zorgen dat ernstige problemen door belanghebbenden en projectmanagement worden beoordeeld 
3. Om statistieken vast te leggen die tijdens en na het project waardevol kunnen zijn.

More Articles

• Testdesign: een essentiële QA-vaardigheid
• Kwetsbaarheidsscanning versus penetratietesten
• 5 belangrijkste fasen van het proces voor kwetsbaarhedenbeheer

Urgentie en ernst van elkaar scheiden

Ongeacht welk incidentbeheerproces je invoert, raden we aan om aan al je incidenten zowel een prioriteitscode als een ernstcode toe te wijzen.

• De prioriteit wordt vanuit een testperspectief toegewezen en bepaalt wanneer een incident wordt opgelost. De tester moet bepalen of een incident een hoge of lage prioriteit heeft (of welke tussenliggende gradaties dan ook zijn toegestaan). De prioriteit geeft aan hoe urgent deze fout voor de testers zelf is en is gebaseerd op de impact die het mislukken van de test heeft op de rest van het testen.
• De ernst wordt vanuit het perspectief van een gebruiker toegewezen en geeft aan of (meestal) een defect aanvaardbaar is. De eindgebruikers of hun management moeten de ernst toewijzen, of (efficiënter) indien nodig het aanvankelijke oordeel van de testers aanpassen. De ernst weerspiegelt de impact van dat defect op de bedrijfsvoering als het vóór de oplevering niet zou worden opgelost. Een ernstig defect maakt het systeem doorgaans onaanvaardbaar. Als een defect weinig ernstig is, kan het als te onbeduidend worden beschouwd om vóór de ingebruikname te worden opgelost, maar kan het in een latere versie worden verholpen.

Als een incident het testen stopt en het testen op het kritieke pad ligt, stopt het hele project.

Een incident met hoge prioriteit stopt alle tests en meestal ook het project.

Het belangrijke punt om in gedachten te houden bij classificatieschema's voor incidenten is dat niet elk urgent incident ernstig is en dat niet elk ernstig incident urgent is.

De eindfase beheren

We noemen de laatste fasen in ons testproces de ‘eindfase’, omdat het beheer van de testactiviteiten tijdens deze laatste, mogelijk hectische en stressvolle dagen een andere discipline vereist dan de eerdere, ogenschijnlijk veel meer ontspannen periode van testplanning.

Onthoud dat het doel van testen is om informatie aan belanghebbenden te leveren, zodat zij een beslissing kunnen nemen – accepteren, oplossen, afwijzen, het project verlengen of het volledig stopzetten. 

Als je een gedeeld begrip hebt van de modellen die voor het testen worden gebruikt, is het veel eenvoudiger om uit te leggen wat ‘werkt’ (met betrekking tot het model), en ook waar dingen niet werken en wat de risico’s van deze tekortkomingen zijn. Het is aan de belanghebbenden om deze informatie te gebruiken bij het nemen van hun beslissingen – onder jouw begeleiding.

Een van de voordelen van het toepassen van een risicogestuurde testaanpak is dat we, wanneer het testen laat in een project onder druk komt te staan, het resterende risico gebruiken om te beargumenteren dat we moeten doorgaan met testen of zelfs meer tests moeten toevoegen. 

Wanneer het management erop staat het testen in te perken, moeten testers eenvoudigweg de risico’s presenteren die worden ‘uitgeruild’. Dit is veel eenvoudiger wanneer er vroegtijdig een risicoanalyse is uitgevoerd, die is gebruikt om de testactiviteiten te sturen en gedurende het hele project is gemonitord. Wanneer het management voortdurend op de hoogte is van de resterende risico’s, is de kans kleiner dat het testen überhaupt wordt ingeperkt.

En dat was alles, mensen; veel succes met jullie tests!

Schrijf je in voor de nieuwsbrief van The QA Lead om op de hoogte te worden gebracht wanneer nieuwe delen van de serie online komen. Deze berichten zijn fragmenten uit Pauls Leadership In Test-cursus, die we ten zeerste 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!