Oprettelse af en kvalitetsstrategi

Genudgivet med tilladelse fra Kristins fremragende blog, thinkingtester.

I mit seneste indlæg introducerede jeg begrebet kvalitetsmodenhedsmodellen: en række adfærdsmønstre, der er knyttet til kvalitetsattributter, og som hjælper teams med at opnå forskellige kvalitetsattributter i deres software.

En af de ting, det er vigtigt at bemærke, er, at indførelsen af en kvalitetsmodenhedsmodel kræver, at hele teamet bidrager til kvaliteten.

Kvalitet er ikke noget, der skal kastes “over muren” til testere; det er snarere et mål, som både udviklere og testere deler.

Men hvordan får man hele teamet til at tage ejerskab over kvaliteten?

En måde er gennem udarbejdelsen af en kvalitetsstrategi. Dette er et dokument, som hele teamet bliver enige om i fællesskab. Betragt det som en kontrakt, der beskriver, hvordan kvalitetssoftware vil blive udviklet, testet og udgivet af teamet. 

Her vil jeg gennemgå nogle spørgsmål, som I måske ønsker at besvare i teamets kvalitetsstrategi.

Oprettelse og forfining af brugerhistorier

Spørgsmål: Hvordan beslutter teamet, hvilke brugerhistorier der skal arbejdes på? 

Det kan være en beslutning, som hele teamet træffer, eller som kun produktejeren træffer. Eller prioriteringen kan foretages af en person uden for teamet.

Spørgsmål: Hvem forfiner brugerhistorierne, så de bliver klar til udvikling? 

Det kan være hele teamet eller en del af teamet. Ideelt set bør mindst produktejeren, en udvikler og en tester deltage.

Udviklingsproces

Spørgsmål: Hvordan beslutter teamet, hvem der arbejder på hvilken brugerhistorie?

Det kan være, at udviklerne frit kan vælge en hvilken som helst brugerhistorie fra tavlen, eller at udviklerne hver især har brugerhistorier inden for specifikke funktionsområder, som de kan vælge imellem. 

På nogle teams arbejder softwaretestere også på simple udviklingsopgaver, såsom at ændre ord eller farver på en webside eller tilføje automatiserings-id'er for at gøre automatisering lettere.

Spørgsmål: Hvordan ser “Færdig” ud for brugerhistorien? Måles det ved, om alle acceptkriterierne i brugerhistorien er opfyldt? Skal udvikleren tilføje enhedstests, før brugerhistorien kan betragtes som færdig? Hvordan ved man, at en funktion er klar til test? 

På mange teams forventes det, at udvikleren udfører nogle indledende tests for at bekræfte, at det, vedkommende har kodet, er klar til yderligere test.

Overdragelse af funktioner

Spørgsmål: Hvordan overdrages en brugerhistorie til test?

På nogle teams gøres dette blot ved at flytte brugerhistorien til kolonnen “Test” på tavlen. På andre teams kræves en mere formel overdragelsesceremoni, hvor udvikleren demonstrerer den fungerende brugerhistorie og kommer med forslag til yderligere test.

Spørgsmål: Hvem udruller koden til testmiljøet? 

Det virker måske som en ubetydelig ting, men det kan faktisk være årsag til mange misforståelser og meget spildt tid. Hvis udvikleren tror, at det er testerens opgave at udrulle koden til testmiljøet, og testeren antager, at udvikleren har gjort det, kan testeren begynde at teste uden at opdage, at den nye kode mangler, før vedkommende har brugt betydelig tid på at arbejde med applikationen.

Spørgsmål: Hvem skal udføre testen? 

På nogle teams kan udviklerne tage simple testopgaver op for at bidrage til at forbedre produktets udviklingshastighed, mens de mere komplekse brugerhistorier overlades til testeksperterne.

Udarbejdelse af testplan

Spørgsmål: Hvem skal udarbejde testplanerne? Hvordan skal de udarbejdes? Hvor skal testplanerne opbevares? 

Nogle teams foretrækker måske at udføre ad hoc-undersøgende test med minimal dokumentation. Andre teams har måske avancerede systemer til håndtering af testsager, som dokumenterer alle produktets tests. Og der findes mange andre muligheder derimellem. 

Uanset hvad I vælger, bør det være det rigtige for jeres team og det rigtige for jeres produkt.

Spørgsmål: Hvem skal skrive testautomatiseringen?

På nogle teams skriver udviklerne enhedstests, mens testerne skriver API- og UI-tests. På andre teams skriver udviklerne enheds- og API-tests, mens testerne opretter UI-testene. Endnu bedre er det, hvis både udviklerne og testerne deler ansvaret for at oprette og vedligeholde API- og UI-testene. 

På den måde kan udviklerne bidrage med deres ekspertise inden for kodehåndtering, mens testerne bidrager med deres ekspertise i at vide, hvad der bør testes.

Spørgsmål: Hvem skal udføre andre typer test, såsom sikkerheds-, ydelses-, tilgængeligheds- og brugeroplevelsestest? 

Nogle større virksomheder har måske dedikerede sikkerheds- og ydelsesingeniører, som tager sig af denne test. Små startupvirksomheder har måske kun ét udviklingsteam, der skal være ansvarligt for det hele.

Testværktøjer

Spørgsmål: Hvilke værktøjer vil blive brugt til manuel og automatiseret test? 

Det er meget vigtigt at vælge testværktøjer, når hele teamet skal tage ansvar for test. Udviklere vil højst sandsynligt foretrække at bruge værktøjer, der anvender det samme sprog, som de bruger til udvikling, fordi det minimerer behovet for at skifte kontekst.

Testvedligeholdelse

Spørgsmål: Hvem er ansvarlig for at vedligeholde testene? 

Det er utroligt, hvor hurtigt testautomatisering kan blive forældet. En ændring af ét ord på en side kan betyde, at en test fejler. Ideelt set bør et team have en politik om, at “hvis du ødelægger det, reparerer du det”, hvor testene repareres af den person, der tjekkede den kode ind, som fik dem til at fejle.

Hvis det ikke er muligt, skal du i det mindste sørge for, at alle i teamet forstår, hvordan testene fungerer, og hvordan de repareres i en situation, hvor der hurtigt er brug for en løsning.

Fejl og teknisk gæld

Spørgsmål: Hvordan håndteres fejl, når de opdages under test? Bliver de diskuteret af udvikleren og testeren, prioriteret af hele teamet eller registreret i en backlog, så de kan ses på senere?

Det er ofte en god idé at rette fejl, så snart de opdages, fordi udvikleren allerede arbejder i den del af koden.

Spørgsmål: Hvordan vil teamet håndtere teknisk gæld?

Har teamet en aftale om at påtage sig en bestemt mængde teknisk gæld pr. sprint? Nogle teams har en politik om, at når en udvikler ikke har flere historier at arbejde på, vælger vedkommende elementer vedrørende teknisk gæld fra backloggen.

Udgivelser

Spørgsmål: Hvilken form for test vil I udføre før en udgivelse? Vil der være en plan for regressionstest, som hele teamet kan gennemføre sammen? Hvad med eksplorativ test?

Et højtydende team, jeg kender, mødes til eksplorativ test lige før en udgivelse. Ved hjælp af denne strategi har de opdaget vanskelige fejl og rettet dem, før de blev udgivet til produktion.

Spørgsmål: Hvordan vil softwaren blive udgivet?

I nogle virksomheder er der en udgivelsesansvarlig, som tager sig af at gennemføre udgivelsen. I andre virksomheder skiftes teammedlemmerne til at udgive softwaren. En meget nyttig teknik er kontinuerlig implementering, hvor softwaren automatisk implementeres, og test automatisk køres for at kontrollere implementeringen i hvert miljø, så alle sparer tid og kræfter.

Relateret læsning: SÅDAN KØRER DU API-SMOKETEST I DIN PIPELINE TIL KONTINUERLIG IMPLEMENTERING

Vedligeholdelse

Spørgsmål: Hvordan vil I måle, om udgivelsen er en succes? 

Når softwaren er blevet udgivet, er det let for udviklingsteams at glemme den; men det er på dette tidspunkt, brugerne begynder at arbejde med den. Hvilke former for målepunkter kan du bruge til at måle, hvor godt dit produkt fungerer? Du kan holde styr på fejl, som kunder rapporterer, eller se efter uventede fejl i logfilerne.

Spørgsmål: Hvordan vil I overvåge applikationens tilstand?

Det vil være en god idé at opsætte alarmer, så du kan få besked om problemer med din applikation, før dine brugere gør det. 

Spørgsmål: Hvilke former for adfærd bør I holde øje med?

Kvalitetsstrategier kan være lige så forskellige som snefnug. Forestil dig forskellene mellem en lille startupvirksomhed med ti personer, der udvikler en mobil chatapp, og en virksomhed med tyve tusind medarbejdere, der designer software til flyvemaskiner. Disse to virksomheder får brug for meget forskellige strategier! 

Du kan designe en kvalitetsstrategi, der fungerer godt for dit team, ved at diskutere disse spørgsmål sammen og udarbejde en strategi, som I alle kan blive enige om.

Hvis du har brug for værktøjer og teknologi til at understøtte dine processer, kan du se denne liste over DE 10 BEDSTE VÆRKTØJER TIL TESTDATAHÅNDTERING.