Bij waterval-projectmanagement worden ontwikkeling en testen in twee verschillende stappen opgesplitst: ontwikkelaars bouwen een functie en 'gooien deze vervolgens over de muur' naar het quality assurance-team (QA) om te testen. Het QA-team schrijft en voert gedetailleerde testplannen uit. Ze registreren ook defecten bij het nauwgezet controleren op regressies in bestaande functies die mogelijk zijn veroorzaakt door nieuw werk.
Veel teams die deze waterval- of andere traditionele testmodellen gebruiken, merken dat naarmate het product groeit, ook de hoeveelheid tests exponentieel groeit, en QA steevast moeite heeft om bij te blijven. Projecteigenaren staan voor een moeilijke keuze: de release uitstellen of beknibbelen op testen. (Je mag één keer raden welke optie in 99% van de gevallen wint.) Ondertussen is de ontwikkeling verdergegaan met iets anders. Niet alleen de technische schulden nemen dus toe, maar het aanpakken van elk defect vereist een dure contextschakelaar tussen twee delen van de codebase. De zaak wordt alsmaar erger.
Tot overmaat van ramp worden QA-teams traditioneel beloond op basis van het aantal bugs dat ze vinden, waardoor ontwikkelaars in de verdediging schieten. Wat als er een betere manier was voor zowel ontwikkelaars als QA om het aantal bugs in de code te verminderen en tegelijkertijd die lastige afwegingen te elimineren die projecteigenaren moeten maken? Zou dat niet zorgen voor betere allround software?
Voer agile en DevOps-tests in.
Overstappen van traditionele naar agile testmethoden
Het doel van agile en DevOps-teams is om duurzaam nieuwe kwaliteitsfuncties te leveren. Traditionele testmethodologieën passen echter niet in een agile of DevOps-framework. Het tempo van ontwikkeling vereist een nieuwe aanpak om de kwaliteit in elke build te waarborgen. Bij Atlassian is de manier waarop we testen agile. Bekijk onze testaanpak met Penny Wyatt, Senior QA Teamlead voor Jira Software.
Net als wanneer creditcardschulden verergeren, begint het bij een beetje last, maar verergert het snel en raakt het team hun kritische agility kwijt. Om escalerende technische schulden tegen te gaan, stimuleren we (nee: verwachten we) bij Atlassian van onze ontwikkelaars om meester te zijn op het gebied van kwaliteit. We zijn van mening dat ontwikkelaars belangrijke vaardigheden inbrengen die helpen de kwaliteit van het product te verhogen:
- Ontwikkelaars zijn goed in het oplossen van problemen met code.
- Ontwikkelaars die hun eigen tests schrijven, hebben vaker de neiging om deze te repareren wanneer ze falen.
- Ontwikkelaars die de functievereisten en hun testimplicaties begrijpen, schrijven over het algemeen betere code.
Wij zijn van mening dat elke userstory in de backlog zowel functiecode als geautomatiseerde testcode vereist. Hoewel sommige teams de functiecode toewijzen aan de ontwikkelaars terwijl het testteam geautomatiseerde tests uitvoert, vinden we het effectiever om één engineer de volledige set te laten leveren.
Behandel bugs in nieuwe functies en regressies in bestaande functies anders. Als er tijdens de ontwikkeling een bug opduikt, neem dan de tijd om de fout te begrijpen, op te lossen en verder te gaan. Als er een regressie optreedt (d.w.z. iets werkte eerder wel maar nu niet meer), dan is de kans groot dat deze weer opduikt. Maak een geautomatiseerde test om je in de toekomst tegen die regressie te beschermen.
Dit model betekent niet dat ontwikkelaars alleen werken. Het is belangrijk om ook QA-engineers in het team te hebben. QA biedt een belangrijk perspectief op de ontwikkeling van een functie. Goede QA-engineers weten waar de bugs zich meestal bevinden en kunnen ontwikkelaars adviseren over waarschijnlijke valkuilen.
Menselijke inmenging door verkennend testen
In onze ontwikkelingsteams werken QA-teamleden samen met ontwikkelaars in verkennende tests, een waardevolle praktijk tijdens de ontwikkeling om ernstigere bugs af te weren. Net bij als codebeoordeling hebben we gezien dat kennis over testen hierdoor werd overgedragen binnen het ontwikkelingsteam. Wanneer ontwikkelaars betere testers worden, wordt de eerste keer betere code geleverd.
Maar is verkennend testen niet handmatig testen? Nee. Althans niet in dezelfde zin als handmatige regressietesten. Verkennend testen is een risicogebaseerde, kritische denkbenadering van testen waarmee de testpersoon zijn kennis van risico's, implementatiedetails en de behoeften van de klant kan gebruiken. Door deze dingen eerder in het testproces te weten, kan de ontwikkelaar of QA-engineer problemen snel en volledig vinden, zonder dat er gescripte testcases, gedetailleerde testplannen of vereisten voor nodig zijn. We vinden het veel effectiever dan traditionele handmatige tests, omdat we inzichten uit verkennende testsessies terug kunnen brengen naar de originele code en geautomatiseerde tests. Verkennend testen leert ons ook over de ervaring van het gebruik van de functie op een manier waarop scripttesten dat niet doet.
Het handhaven van de kwaliteit omvat een mix van verkennend en geautomatiseerd testen. Naarmate er nieuwe functies worden ontwikkeld, zorgt verkennend testen ervoor dat nieuwe code voldoet aan de kwaliteitsnorm in bredere zin dan alleen geautomatiseerde tests. Dit omvat gebruiksgemak, aangenaam visueel ontwerp en algemeen nut van de functie, naast de robuuste bescherming tegen regressies die geautomatiseerd testen biedt.
Verandering kan moeilijk zijn, heel moeilijk
Ik zal eindigen met een persoonlijke anekdote die mijn reis met agile testen mooi samenvat. Ik herinner me dat ik vroeg in mijn carrière een technisch team leidde dat sterk tegen het schrijven van geautomatiseerde tests was, omdat 'dat werk voor QA was'. Na verschillende iteraties van defecte code en het horen van alle redenen waarom geautomatiseerd testen het team zou vertragen, hield ik voet bij stuk: alle nieuwe code moest worden bewezen door geautomatiseerde tests.
Na een enkele iteratie begon de code te verbeteren. En de ontwikkelaar die het hardnekkigst tegen het schrijven van tests was, bleek degene te zijn die in actie kwam toen een test mislukte! In de volgende paar iteraties groeiden de geautomatiseerde tests, werden ze geschaald naar meerdere browsers en maakten ze onze ontwikkelingscultuur beter. Natuurlijk duurde het langer om een functie uit te brengen. Maar bugs en herbewerking daalden aanzienlijk, waardoor we uiteindelijk enorm veel tijd bespaarden.
Verandering is zelden eenvoudig. Maar zoals bij de meeste dingen die de moeite waard zijn: als je je kunt inzetten en nieuwe patronen voor jezelf kunt maken, is de enige vraag die overblijft: 'Waarom hebben we dit niet eerder gedaan?!'
