Ledelse i test: Gennemførelse af et testprojekt

Er du klar?

Gladiatorer, tiden er inde til at udføre arbejdet. Formålet med denne artikel er at guide dig gennem, hvordan man udfører et testprojekt. Jeg kommer ind på:

• Det klassiske pres på test
• Rapportering af succes og fejl
• Forringelse af dækningsgraden
• Håndtering af hændelser
• Håndtering af slutspillet

Så, er du klar? Der er fire kritiske aspekter:

• Personer – er dit team klar?
• Miljøer – har du de teknologier, data, enheder og grænseflader, der skal til for at gennemføre meningsfulde test?
• Viden – har du forberedt dine test med et passende detaljeringsniveau, eller er dit team klar til og i stand til at udforske og teste systemet på en dynamisk måde?
• Systemet under test – er den software eller det system, du skal teste, faktisk tilgængeligt?

De første tre aspekter er enten under din kontrol, eller også har du mulighed for at overvåge, styre og koordinere handlinger, der sikrer personer, miljøer og viden. Systemet under test er en anden sag. Hvis systemet under test leveres for sent, kan du ikke komme meningsfuldt i gang med testen. Dette er det klassiske pres på test.

Det klassiske pres på test

Alle, der har testet systemer, har oplevet, at systemet, der skal testes, bliver leveret for sent. På næsten alle niveauer, fra komponenter til hele systemer, støder udviklere på problemer, og leveringen bliver enten forsinket eller ufuldstændig. I de fleste tilfælde, hvor der er afsat en periode til at gennemføre testen, flyttes deadline ikke, og testen bliver presset sammen. Det tvinger teams til at vælge mellem kvalitet og hastighed. Hvis du vil se værktøjer, der tilbyder det bedste fra begge verdener, kan du kigge på vores liste over de bedste softwaretestplatforme.

Delvis og trinvis levering

Selvom det komplette system ikke kan leveres til test, kan noget funktionalitet – et delvist system – leveres med løfte om, at senere udgivelser vil indeholde den resterende funktionalitet. På et hvilket som helst tidspunkt vil status for funktionerne i en udgivelse være:

• Færdige som krævet: Disse funktioner kan testes – i det mindste isoleret.
• Ufuldstændige: Funktionerne mangler funktionalitet og/eller er kendt for at være fejlbehæftede.
• Manglende: Udskudt til levering i en senere udgivelse.

Hvad angår de funktioner, der er tilgængelige, kan det være muligt at teste dem isoleret. De kan dog afhænge af data, der er oprettet af andre funktioner, som endnu ikke er tilgængelige, hvilket kan gøre det vanskeligere at teste dem.

Funktioner kan være tilgængelige, men outputtet fra disse funktioner kan ikke verificeres af andre funktioner, der endnu ikke er tilgængelige, så det er nødvendigt at undersøge testdatabasen før og efter. Det er næsten sikkert, at dine ende-til-ende-test, som kræver testbare sekvenser af funktioner, for det meste vil være blokerede.

På næsten alle områder bliver test på systemniveau af delvise systemer alvorligt hæmmet.

Forsvar testen

Dit team skal dog gøre fremskridt, uanset hvor besværligt det er. Hvis systemet ikke er tilgængeligt eller kun er delvist tilgængeligt for teamet, bliver du nødt til at håndtere forventningerne og forsvare din plan. 

Din testplan, uanset om den er lille eller omfattende, afhænger af, at systemet er tilgængeligt – dette er en antagelse – så din plan må ændres. Du dokumenterer måske ikke formelle indgangskriterier, men budskabet er det samme:

Indgangskriterier er planlægningsforudsætninger – hvis disse kriterier ikke er opfyldt, er dine planlægningsforudsætninger forkerte, og planen skal justeres.

Uanset om du venter på, at systemet bliver leveret, eller du har adgang til et delvist system, løber du hurtigt tør for nyttige ting at lave. Derefter får du en vanskelig samtale med din produktejer eller projektleder. Hvis færdiggørelsesfristen ikke flyttes, bliver du tvunget til at teste mindre. Nogle funktioner bliver måske testet mindre, eller helt taget ud af testomfanget.

Lederen tror måske, at du kan indhente tiden senere, men det er næsten aldrig muligt i praksis.

Den testtid, der går tabt på grund af sene eller delvise leverancer, kan ikke indhentes ved at ‘arbejde hårdere’.

Hvorfor bliver testningen forsinket? Der er mange mulige årsager, men de følger typisk et af disse mønstre:

• Miljøerne kan ikke konfigureres i tide. Folk kom sent i gang, havde for travlt eller var ikke kvalificerede til at skabe et meningsfuldt testmiljø. Det, der er tilgængeligt, er delvist, forkert konfigureret eller ufuldstændigt.
• Leveringen er forsinket, fordi arbejdets omfang blev undervurderet.
• Leveringen er forsinket, fordi softwaren er fejlbehæftet, vanskelig at teste og rette.
• Leveringen er forsinket, fordi udviklingsteamet mangler færdigheder, erfaring eller kompetence inden for forretningsområdet eller de teknologier, de anvender.
• Leveringen er forsinket, fordi udviklingen begyndte sent.
• Leveringen er forsinket, fordi kravene bliver ved med at ændre sig.

Udeladt fra listen ovenfor er force majeure og andre eksterne faktorer uden for projektteamets kontrol. Hvis projektlederen insisterer på, at fristen for testning ikke ændres, og testningens omfang også er fastlagt, står du over for en betydelig udfordring. I alle ovenstående tilfælde taler årsagerne til den sene levering for at udføre mere testning, ikke mindre.

Hvis udviklingsarbejdet er undervurderet, er testningen det sandsynligvis også. Hvis softwaren er fejlbehæftet, vil testningen tage længere tid. Hvis udviklerne mangler færdigheder, vil softwaren sandsynligvis være af dårlig kvalitet og tage længere tid at teste. Hvis udviklerne begyndte sent (hvorfor?) og omfanget er uændret, hvorfor skulle testningen så reduceres? Hvis kravene ændrer sig, er dine planer sandsynligvis alligevel forkerte – at arbejde efter en dårlig plan gør uundgåeligt livet sværere.

Hvor mange af de almindelige årsager til forsinket levering antyder, at der er behov for mindre testning? Ingen af dem. Forsvar din plan.

Rapportering af succes og fiasko

De fleste testere ved, at effektiv testning kræver nysgerrighed, vedholdenhed og sans for problemer. Den primære motivation er at fremprovokere fejl og skabe tilstrækkelig dokumentation til, at fejlene kan spores til defekter, som derefter kan rettes. 

Selvom det er godt for produktets kvalitet at finde (og rette) defekter, føles det ofte som om, man giver nogen dårlige nyheder, når man kommunikerer om defekter. Det kan være en udvikler, der har begået en fejl et eller andet sted og skal rette den, eller du kan rapportere til interessenter, at en kritisk funktionalitet ikke fungerer korrekt, og at systemet bliver forsinket.

Ingen bryder sig om at give dårlige nyheder, og det er naturligt at være tilbageholdende med at gøre andre kede af det, især nære kolleger. Men følelsen af, om dine nyheder er gode eller dårlige, er ikke noget, budbringeren bør bekymre sig om. 

Defekter er altid dårlige nyheder for nogen, men testningens rolle er ikke at være fordømmende på denne måde. På nogle måder er testeren som en journalist, der søger sandheden. Kipling-fortællingen Elefantungen indeholder linjerne:

Jeg har seks ærlige tjenere:
    (De lærte mig alt, hvad jeg ved)
De hedder Hvad og Hvor og Hvornår
    Og Hvordan og Hvorfor og Hvem.

På samme måde som en journalist fortæller en nyhedshistorie, fortæller du historien om det, du opdagede, mens du testede et system.

Sandheden – nyheden – kan være god eller dårlig, men dit ansvar er ganske enkelt at opsøge både problemer og succeser så godt, du kan. Du forsøger at opdage, hvad et system gør, og hvordan det gør det. 

Helt til sidst i et projekt er målet at levere til produktion med så få uafklarede problemer som muligt. Du ønsker, at alle dine test skal bestå, men vejen til succes vanskeliggøres af testfejl, der skal undersøges og løses. Dit taktiske mål er hurtigt at finde problemer, men dit ultimative mål er ikke at have nogen problemer at rapportere. 

For nøjagtigt at rapportere succes eller fiasko i dit testprojekt bør du overveje at integrere avancerede teststyringsværktøjer, der tilbyder omfattende analyser

Du skal opføre dig meget som en undersøgende journalist – på udkig efter historien med et kritisk og uafhængigt sind. Som Kipling skrev:

Hvis du kan mødes med Triumf og Katastrofe og behandle disse to bedragere helt ens …

Så vil du kunne bevare overblikket og udføre et godt stykke arbejde for dit projekt og dine interessenter.

Dækningserosion

Uanset hvilke dækningsmål der findes ved teststart, medvirker flere faktorer til at reducere den faktisk opnåede dækning. Erosion er et passende begreb at bruge, da det reelt afspejler den gradvise reduktion af omfanget af de planlagte tests og den uundgåelige erkendelse af, at ikke alle planlagte tests kan udføres inden for den tilgængelige tid.

Dækningserosion har flere årsager, før testudførelsen begynder:

• For det første identificerer testplaner de risici, der skal håndteres, og den tilgang, der skal bruges til at håndtere dem. Planer antager normalt et budget til test – hvilket altid er et kompromis.
• Dårlige, ustabile eller ufærdige systemkrav, designs og specifikationer gør testspecifikation vanskeligere. Dækningen af systemet forringes af manglende detaljer i specifikationerne.
• Sen tilgængelighed eller utilstrækkelighed af testmiljøer gør visse planlagte tests upraktiske eller meningsløse. Integrationstest i større skala kan være umulig at udføre som planlagt, fordi ikke alle grænseflader eller systemer, der skal integreres, kan gøres tilgængelige.
• Ydeevnetest kan blive kompromitteret, fordi miljøerne mangler skala eller ikke afspejler produktionsmiljøet.
• Sen levering af den software, der skal testes, betyder, at omfanget af testene må reduceres, når tidsfristerne ligger fast.

Dækningserosion under testudførelsen har også flere årsager:

• Hvis kvaliteten af den software, der skal testes, er dårlig ved starten af en testfase, kan testkørslen være særligt frustrerende. De mest grundlæggende tests kan mislykkes, og de fundne fejl kan være så fundamentale, at udviklerne har brug for mere tid til at rette dem, end nogen havde forventet. Hvis testen suspenderes, fordi softwarekvaliteten er for dårlig, kommer du bagud. Hvis tidsfristen ikke flyttes, vil nogle tests blive taget ud af omfanget.
• Hvis der opstår flere fejl end forventet, vil selve rettelses- og gentestcyklussen tage mere tid, og du løber tør for tid til at færdiggøre alle dine tests.
• Når tiden løber ud, og beslutningen om at frigive systemet træffes, vil ikke al din test være færdig. Enten blev nogle tests aldrig nået i planen, eller også er der resterende fejl, som blokerer for færdiggørelsen af de tests, der mislykkedes. Når idriftsættelsesdatoen ikke flyttes, er dette den klassiske indsnævring af testarbejdet, der blev nævnt ovenfor.

Håndtering af dækningserosion er en af de udfordringer, testere står over for i alle projekter. Tingene forløber sjældent problemfrit, og en reduktion af tiden til test (og dækning) er normalt den eneste mulighed for at holde projektet på sporet.

Det er ikke forkert at reducere mængden af test; det er kun forkert at reducere testen vilkårligt. Når der derfor træffes beslutninger om, hvilke tests der skal fjernes, skal indvirkningen på dine testmål og de risici, der skal håndteres, gennemgås. Du kan få nogle vanskelige samtaler med interessenter, som du skal igennem.

Når indvirkningen er betydelig, kan det være nødvendigt at facilitere et møde mellem dem, der beder om nedskæringerne (typisk projektledelsen), og dem, hvis interesser kan blive påvirket af nedskæringerne (interessenterne). Din rolle er at redegøre for situationen med hensyn til de gennemførte tests, den aktuelt kendte tilstand for det testede system, de tests, der mislykkes og/eller blokerer fremdriften, samt mængden af test, der mangler at blive udført.

Dine planer og modeller beskriver det oprindelige testomfang og er afgørende for at hjælpe interessenter og ledelse med at forstå hullerne og de resterende risici samt træffe beslutningen om at fortsætte testen eller stoppe.

Håndtering af hændelser

Når projektet går ind i faserne med systemtest og accepttest, styres det i høj grad af de hændelser, der opstår under testudførelsen. Hændelser udløser aktiviteter i resten af projektet, og hændelsesstatistikker kan nogle gange give et godt indblik i projektets status. Når vi kategoriserer hændelser, skal vi tænke fremad på, hvordan oplysningerne senere vil blive brugt.

En hændelse er en uplanlagt begivenhed, der opstår under test, og som kan have betydning for en vellykket afslutning af testen, acceptbeslutningen eller behovet for at træffe en anden foranstaltning.

Vi bruger et neutralt begreb for disse uplanlagte begivenheder – hændelse. Disse begivenheder omtales dog ofte med andre begreber, hvor nogle er mere neutrale end andre. 

Tests, der mislykkes, kan omtales som observationer, anomalier eller problemer – neutrale begreber, der ikke forudsætter en årsag. Men nogle gange bruges problemer, fejl, defekter eller mangler – hvilket forudsætter, at systemet er fejlbehæftet. Dette kan dog være en forhastet konklusion, og disse betegnelser kan være vildledende.

Vi foreslår, at du reserverer betegnelserne fejl, defekt eller mangel til resultaterne af diagnosticeringen af fejl i konstruktionen af det system, der testes, og som normalt medfører omarbejde for udviklingsteamet.

Hændelser viser sig på to måder:

1. Systemfejl: Systemet opfører sig ikke som forventet i en test, dvs. det fejler på en eller anden måde eller ser ud til ikke at opfylde et krav.
2. Afbrydelse af eller underminering af testning eller test: En hændelse, der påvirker testernes mulighed for at udføre deres opgaver, såsom tab af eller fejl i testmiljøet eller data, grænseflader, understøttende eller integrerede systemer eller tjenester, eller en anden ekstern påvirkning.

Systemfejl

Disse hændelser er ofte de mest direkte bekymrende, fordi de undergraver tilliden til systemets kvalitet. 

Afbrydelser og underminerede test

Nogle organisationer betragter slet ikke disse hændelser som hændelser – afbrydelser er en del af projekternes hektiske afslutningsfase. Underminerede test, hvor miljøet eller testopsætningen er forkert, kan blive lagt testteamet til last (for opsætningen eller i det mindste for ikke at kontrollere opsætningen før testning).

I begge tilfælde påvirkes fremdriften i testningen, og hvis du leder processen, er du ansvarlig for at forklare forsinkelser. Derfor bør du enten registrere disse hændelser som hændelser eller bede teamet føre en testlog og registrere udfald i miljøet, konfigurationsproblemer eller mangel på passende softwareversioner til test. Hvis du ikke gør det, får du svært ved at begrunde forsinkelser i fremdriften, og det kan få dig og teamet til at fremstå dårligt.

Skal hændelser registreres eller ej?

Med fremkomsten af agile tilgange og kontinuerlig levering er det traditionelle syn på hændelseshåndtering blevet udfordret. I faseopdelte projekter behandles hændelser som potentielle arbejdspakker for udviklere, der godkendes i henhold til alvor og/eller hastende karakter. 

Der er en formel, ofte bureaukratisk proces, der skal følges, hvor hændelser gennemgås, prioriteres og håndteres af udviklingsteamet (eller et andet team). Der kan indgå avancerede værktøjer til hændelseshåndtering.

I mindre, agile teams er forholdet mellem tester og udvikler tæt. Teamet som helhed mødes måske dagligt for at drøfte større hændelser, men oftere end ikke opdages, diagnosticeres, rettes og gentestes fejl uformelt uden behov for at registrere en hændelse eller involvere andre i teamet eller eksternt forretnings- eller it-personale. Mere alvorlige fejl kan blive drøftet og indarbejdet i arbejdet med en brugerhistorie eller samlet i dedikerede iterationer eller sprint til fejlrettelser.

Vi drøftede formålet med og behovet for dokumentation i en tidligere artikel. Denne drøftelse er også relevant for hændelser. Teamet skal overveje, om der er behov for et hændelsesværktøj og en proces, og om det er nyttigt for teamet og/eller kræves af personer uden for teamet.

Større teams har en tendens til at være afhængige af processer og værktøjer til håndtering af hændelser af tre grunde: 

1. For at sikre, at hændelser ikke bliver glemt
2. For at sikre, at alvorlige problemer gennemgås af interessenter og projektledelsen 
3. For at indsamle målinger, der kan være værdifulde under og efter projektet.

Adskillelse af hastende karakter fra alvor

Uanset hvilken proces for hændelseshåndtering du vælger, anbefaler vi, at du tildeler både en prioritetskode og en alvorlighedskode til alle dine hændelser.

• Prioritet tildeles ud fra et testperspektiv, og den påvirker hvornår en hændelse bliver løst. Testeren bør afgøre, om en hændelse har høj eller lav prioritet (eller en af de mellemgrader, der måtte være tilladt). Prioriteten angiver, hvor hastende denne fejl er for testerne selv, og er baseret på den indvirkning, testfejlen har på resten af testningen.
• Alvor tildeles ud fra en brugers synspunkt og angiver, om en (normalt) defekt kan accepteres eller ej. Slutbrugerne eller deres ledelse bør tildele alvoren eller (mere effektivt) tilsidesætte testernes oprindelige vurdering efter behov. Alvoren afspejler den indvirkning, denne defekt ville have på forretningen, hvis den ikke blev rettet før leveringen. En alvorlig defekt gør typisk systemet uacceptabelt. Hvis en defekt har lav alvor, kan den vurderes som for ubetydelig til at skulle rettes før produktionssætning, men den kan rettes i en senere udgivelse.

Hvis en hændelse stopper testningen, og testningen ligger på den kritiske vej, stopper hele projektet.

En hændelse med høj prioritet stopper al testning og normalt også projektet.

Det vigtige at huske ved klassifikationsordninger for hændelser er, at ikke alle hastende hændelser er alvorlige, og at ikke alle alvorlige hændelser haster.

Håndtering af slutfasen

Vi kalder de afsluttende faser i vores testproces for ’slutfasen’, fordi håndteringen af testaktiviteterne i disse sidste, muligvis hektiske og stressende dage kræver en anden disciplin end den tidligere, tilsyneladende langt mere afslappede periode med testplanlægning.

Husk, at formålet med testning er at levere information til interessenter, så de kan træffe en beslutning – at acceptere, rette, afvise, forlænge projektet eller helt opgive det. 

Hvis I har en fælles forståelse af de modeller, der skal bruges til test, er det meget lettere at forklare, hvad der ‘fungerer’ (i forhold til modellen), og også hvor tingene ikke fungerer, samt hvilke risici disse fejl indebærer. Det er interessenterne, der skal bruge disse oplysninger til at træffe deres beslutninger – vejledt af dig.

En af fordelene ved at anvende en risikobaseret test-tilgang er, at når testningen bliver begrænset sent i et projekt, bruger vi den resterende risiko som argument for at fortsætte med at teste eller endda tilføje mere testning. 

Når ledelsen insisterer på at begrænse testningen, bør testere blot fremlægge de risici, der bliver ‘handlet væk’. Dette er meget lettere, når der er blevet gennemført en tidlig risikovurdering, som er blevet brugt til at styre testaktiviteterne og fulgt gennem hele projektet. Når ledelsen løbende er opmærksom på de resterende risici, er det mindre sandsynligt, at de overhovedet vil begrænse testningen.

Og det var det hele, held og lykke med jeres testning!

Tilmeld dig The QA Lead-nyhedsbrevet for at få besked, når nye dele af serien bliver udgivet. Disse indlæg er uddrag fra Pauls kursus i ledelse inden for test, som vi varmt anbefaler, hvis du vil dykke dybere ned i dette og andre emner. Hvis du gør det, skal du bruge vores eksklusive kuponkode QALEADOFFER for at få $60 i rabat på den fulde kursuspris!