Snelle quality assurance

Van quality assurance naar quality assistance

Laura Daly Laura Daly
Onderwerpen zoeken

Het is moeilijk traditionele testmethodes aan te passen aan een agile cultuur; teams voelen zich gedwongen kwaliteit in te ruilen voor snellere levering.

Om deze problemen aan te pakken, hebben teams bij Atlassian een andere aanpak voor agile testen ontwikkeld: Quality Assistance. In plaats van een apart testteam verantwoordelijk te houden voor kwaliteit, promoot en ondersteunt een klein team van Quality Assistance-engineers duurzame testmethodes binnen het hele ontwikkelingsteam. Lees meer over deze transformatie en ontdek hoe je:

  • een kwaliteitscultuur creëert
  • verantwoordelijkheid voor testen weer bij de ontwikkelaars legt
  • bugs voorkomt in plaats van te detecteren

Q&A

Lees de Q&A's van deze presentatie om erachter te komen hoe een team van 65 engineers een hoogwaardig product maakt en snel levert met slechts zes QA-engineers.

Q1: Hoe lang doet een ontwikkelaar erover om de manier van denken te veranderen?

A1: Het is lastiger om de cultuur van een heel team te veranderen dan individuen te veranderen. Wij hebben er vijf jaar over gedaan om de mindset van het Jira Software-team over kwaliteitsniveau te veranderen naar de mindset van nu, maar nieuwe ontwikkelaars hebben niet veel tijd nodig om zich de nieuwe mindset eigen te maken. Ze nemen de mindset van hun medeontwikkelaars snel over en leren de testvaardigheden door samen te werken en in workshops. Het lastigste is om alle kennis van risico's en het product op te pikken. Dit kan jaren duren, maar we maken het makkelijker door kennis te delen in QA-kick-offs en QA-demo's.

Q2: Zijn testcases nog steeds nodig en zijn die alleen bedoeld voor regressie-/geautomatiseerd testen?

A2: Gescripte handmatige testcases vormen geen onderdeel van onze strategie. Als een test slechts een 'controle' is, een reeks vooraf bepaalde stappen en een afgebakende stelling, vinden we het efficiënter en minder foutgevoelig om een computer in plaats van een persoon de test uit te laten voeren. Als een test een echte test is, waarbij kritisch denken, vrijheid om te onderzoeken en risicobeoordeling vereist zijn, vinden we het beter om exploratief te testen zodat we die vrijheid en intelligentie kunnen waarborgen.

Q3: Ontwikkelaars zijn doorgaans duurder dan testers. Als we ontwikkelaars als testers gebruiken, gebruiken we ons budget/personeel dan niet inefficiënt?

A3: Absoluut, ontwikkelaars als testers gebruiken om een aparte teststap uit te voeren, is duur en zonde van de tijd voor ontwikkelaars. Als je überhaupt een aparte teststap hebt, zelfs een die wordt uitgevoerd door testers, is dat duur en zonde van de tijd voor ontwikkelaars. Elke keer dat een story of bug van testers terug naar ontwikkelaars wordt gepusht, betekent dat niet slechts testkosten, het zijn ontwikkelingskosten. Door het afwijzingspercentage te verlagen van 100% naar 4% hebben we ontwikkelaars veel tijd bespaard die werd verspild aan het verbeteren van stories en het oplossen van stomme bugs voor de release. We hebben minder tijd besteed aan onderzoeken, rapporteren, sorteren, beoordelen, reproduceren en het fixen van intern gevonden bugs. De code is zo gemaakt dat hij goed getest kan worden, omdat ontwikkelaars weten dat zij tevens de testers zijn. Onze DoTing (Developer-on-Testing)-fase was een tussenstap in het proces om kwaliteit upstream te pushen, zodat we de aparte teststap volledig konden overslaan. Het was een tijdelijke investering die zijn vruchten heeft afgeworpen.

Q4: We hebben ontwikkelaars en QA-testers in verschillende tijdzones. Werkt dit model alleen in dezelfde tijdzone? Hoe werk je met teams op afstand?

A4: We hebben quality assistance op afstand gedaan met teams in Polen en Vietnam waarbij de QA-engineer zich in Australië bevond. Het is minder effectief dan vakkundige QA onsite, omdat het opbouwen van persoonlijke relaties met ontwikkelaars een belangrijk aspect van een goede QA-engineer is. Een externe QA-engineer wordt snel vergeten en het is lastiger om de algehele cultuur van het team te peilen. Toch is het ons gelukt om QA-demo's en -kick-offs op afstand te doen en samenwerkingssessies via videogesprekken te houden. Ontwikkelaar en QA kunnen zo rechtstreeks hun scherm delen.

Q5: Worden de QA-resultaten per story bijgehouden of bouw je een er een soort QA-kennisdatabase van? Hoe ga je om met terugkerende risico's?

A5: QA-resultaten zijn per story, dus zijn het meestal de QA-engineers die patronen herkennen in terugkerende risico's. Dit is de laatste jaren moeilijker geworden, omdat ons Jira Software-QA-team is gegroeid en niet alle QA-engineers over dezelfde kennis beschikken. Eerst losten we dit op door wekelijks meetings te houden om kennis te delen en hadden we wiki-pagina's om veelvoorkomende of onverwachte risico's bij te houden. We kunnen dit inmiddels amper meer opschalen. We werken nu aan een gestructureerdere kennisdatabase met een database van regels die op elke commit worden uitgevoerd. Als bijvoorbeeld de database ziet dat je het gebruikersobject in je Jira Software-code gebruikt, voegt de database een opmerking toe aan de issue: 'Het gebruikersobject kan leeg zijn als de huidige gebruiker anoniem is. Zorg ervoor dat je dit correct invult.' Zo kunnen we de kennis uit de QA'ers krijgen en, in het ideale geval, zijn hun demo's en kick-offs niet eens meer nodig. Dát zou handig zijn!