Ledelse i praksis: Gjennomføring av et testprosjekt

Er du klar?

Gladiatorer, tiden er inne for å gjøre jobben. Formålet med denne artikkelen er å ta deg gjennom hvordan du gjennomfører et testprosjekt. Jeg skal dekke:

• Det klassiske presset på testing
• Rapportering av suksess og feil
• Erosjon i testdekningen
• Hendelseshåndtering
• Håndtering av sluttfasen

Så, er du klar? Det finnes fire kritiske aspekter:

• Personer – er teamet ditt klart?
• Miljøer – har du teknologiene, dataene, enhetene og grensesnittene som trengs for å gjennomføre meningsfulle tester?
• Kunnskap – har du forberedt testene dine med et passende detaljnivå, eller er teamet ditt klart og i stand til å utforske og teste systemet på en dynamisk måte?
• Systemet som testes – er programvaren eller systemet du skal teste, faktisk tilgjengelig?

De tre første aspektene er enten under din kontroll, eller så har du mulighet til å overvåke, styre og koordinere tiltak for å skaffe personer, miljøer og kunnskap. Systemet som testes, er en annen sak. Hvis systemet som testes leveres sent, kan du ikke komme ordentlig i gang med testingen. Dette er det klassiske presset på testing.

Det klassiske presset på testing

Alle som har testet systemer, har opplevd at systemet som skal testes, blir levert sent. På nesten alle nivåer, fra komponenter til komplette systemer, støter utviklere på problemer, og leveransen blir enten forsinket eller ufullstendig. I de fleste tilfeller, der det er satt av en tidsperiode til å gjennomføre testingen, flyttes ikke fristen, og testingen blir presset sammen. Dette tvinger teamene til å velge mellom kvalitet og hastighet. Hvis du vil ha verktøy som tilbyr det beste fra begge verdener, kan du ta en titt på vår liste over de beste plattformene for programvaretesting.

Delvis og trinnvis levering

Selv om det komplette systemet ikke kan leveres til testing, kan noe funksjonalitet – et delvis system – leveres med løfte om at senere utgivelser vil inneholde den resterende funksjonaliteten. Til enhver tid vil statusen for funksjonene i en utgivelse være:

• Fullført som påkrevd: Disse funksjonene kan testes – i det minste isolert.
• Ufullstendig: Funksjonene mangler funksjonalitet og/eller er kjent for å være feil.
• Mangler: Utsatt til levering i en senere utgivelse.

Når det gjelder funksjonene som er tilgjengelige, kan det være mulig å teste dem isolert. De kan imidlertid være avhengige av data som er opprettet av andre funksjoner som ennå ikke er tilgjengelige, noe som kan gjøre det vanskeligere å teste dem.

Funksjoner kan være tilgjengelige, men resultatet av disse funksjonene kan ikke verifiseres av andre funksjoner som ennå ikke er tilgjengelige. Derfor er det nødvendig å undersøke testdatabasen før og etter. Det er nesten sikkert at ende-til-ende-testene dine, som krever testbare kjeder av funksjoner, i stor grad vil være blokkert.

På nesten alle områder blir testing på systemnivå av delvise systemer betydelig hindret.

Å forsvare testingen

Teamet ditt må gjøre fremgang, uansett hvor krevende det er. Hvis systemet ikke er tilgjengelig, eller bare er delvis tilgjengelig for teamet, må du håndtere forventningene og forsvare planen din. 

Testplanen din, enten den gjelder et lite eller et stort omfang, avhenger av at systemet er tilgjengelig – dette er en antakelse – så planen din må endres. Du dokumenterer kanskje ikke formelle inngangskriterier, men budskapet er det samme:

Inngangskriterier er planleggingsforutsetninger – hvis disse kriteriene ikke er oppfylt, er planleggingsforutsetningene dine feil, og planen må justeres.

Enten du venter på at systemet skal leveres, eller du har tilgang til et delvis system, vil du ganske raskt gå tom for nyttige ting å gjøre. Deretter må du ta en vanskelig samtale med produkteieren eller prosjektlederen. Hvis ferdigstillelsesfristen ikke flyttes, vil du bli tvunget til å teste mindre. Noen funksjoner kan bli testet mindre, eller tas helt ut av testomfanget.

Lederen tror kanskje at du kan ta igjen tiden senere, men dette lar seg nesten aldri gjennomføre i praksis.

Testtiden som går tapt på grunn av sene eller delvise leveranser, kan ikke hentes inn igjen ved å «jobbe hardere».

Hvorfor blir testingen forsinket? Det finnes mange mulige årsaker, men de følger vanligvis ett av disse mønstrene:

• Miljøene kan ikke konfigureres i tide. Folk startet sent, var for opptatt eller hadde ikke de nødvendige kvalifikasjonene til å opprette et meningsfullt testmiljø. Det som er tilgjengelig, er delvis, feilkonfigurert eller ufullstendig.
• Leveransen er forsinket fordi arbeidsomfanget ble undervurdert.
• Leveransen er forsinket fordi programvaren har mange feil, er vanskelig å teste og vanskelig å rette.
• Leveransen er forsinket fordi utviklingsteamet mangler ferdighetene, erfaringen eller kompetansen innenfor forretningsområdet eller teknologiene de bruker.
• Leveransen er forsinket fordi utviklingen startet sent.
• Leveransen er forsinket fordi kravene fortsetter å endre seg.

Handlinger fra Gud og andre eksterne faktorer utenfor prosjektteamets kontroll er utelatt fra listen ovenfor. Hvis prosjektlederen insisterer på at fristen for testingen ikke endres, og testomfanget også er fastsatt, står du overfor en betydelig utfordring. I alle tilfellene ovenfor taler årsakene til den sene leveransen for å utføre mer testing, ikke mindre.

Hvis utviklingsarbeidet er undervurdert, er testingen sannsynligvis også det. Hvis programvaren har mange feil, vil testingen ta lengre tid. Hvis utviklerne mangler ferdigheter, vil programvaren sannsynligvis være dårlig og ta lengre tid å teste. Hvis utviklerne startet sent (hvorfor?) og omfanget er uendret, hvorfor skulle testingen reduseres? Hvis kravene endres, er det sannsynlig at planene dine uansett er feil – å følge en dårlig plan gjør uunngåelig livet vanskeligere.

Hvor mange av de vanlige årsakene til forsinkede leveranser tyder på at det er nødvendig med mindre testing? Ingen av dem. Forsvar planen din.

Rapportering av suksess og feil

De fleste testere vet at effektiv testing krever nysgjerrighet, utholdenhet og teft for problemer. Den fremste motivasjonen er å fremprovosere feil og skaffe nok bevis til at feilene kan spores til defekter som deretter kan rettes. 

Selv om det er bra for produktkvaliteten å finne (og rette) defekter, føles det ofte som om du kommer med dårlige nyheter når du kommuniserer defekter til noen. Det kan være en utvikler som har gjort en feil et sted og må rette den, eller du kan rapportere til interessenter at en kritisk funksjonalitet ikke fungerer som den skal, og at systemet blir forsinket.

Ingen liker å komme med dårlige nyheter, og det er naturlig å være motvillig til å gjøre andre opprørte, særlig nære kolleger. Men følelsen av at nyhetene dine er gode eller dårlige, er ikke noe budbringeren bør være opptatt av. 

Defekter er alltid dårlige nyheter for noen, men testrollen er ikke å være dømmende på denne måten. På noen måter er testeren som en journalist som søker etter sannheten. Fortellingen om Elefantens barn av Kipling inneholder linjene:

Jeg har seks ærlige tjenere:
    (De lærte meg alt jeg vet)
De heter Hva og Hvor og Når
    Og Hvordan og Hvorfor og Hvem.

På samme måte som en journalist forteller en nyhetshistorie, forteller du historien om det du oppdaget da du testet et system.

Sannheten – nyheten – kan være god eller dårlig, men ansvaret ditt er ganske enkelt å lete etter både problemer og suksesser så godt du kan. Du forsøker å oppdage hva et system gjør, og hvordan det gjør det. 

Helt på slutten av et prosjekt er målet å sette i produksjon med så få utestående problemer som mulig. Du ønsker at alle testene skal bestå, men veien til suksess hindres av testfeil som må undersøkes og løses. Det taktiske målet ditt er å finne problemer raskt, men det endelige målet er å ikke ha noen problemer å rapportere. 

For å rapportere nøyaktig om testprosjektet ditt lykkes eller mislykkes, bør du vurdere å integrere avanserte teststyringsverktøy som tilbyr omfattende analyser

Du må opptre omtrent som en undersøkende journalist – på jakt etter historien med et kritisk og uavhengig sinn. Som Kipling skrev:

Hvis du kan møte Triumf og Katastrofe og behandle disse to bedragerne helt likt …

Da vil du beholde fatningen og gjøre en god jobb for prosjektet og interessentene.

Erosjon av testdekning

Uansett hvilke mål for testdekning som finnes ved starten av testingen, bidrar flere faktorer til å redusere testdekningen som faktisk oppnås. Erosjon er et passende begrep å bruke, siden det virkelig gjenspeiler den gradvise reduksjonen av omfanget av planlagte tester og den uunngåelige erkjennelsen av at ikke alle de planlagte testene kan gjennomføres innen den tilgjengelige tiden.

Erosjon av testdekningen har flere årsaker før testgjennomføringen:

• For det første identifiserer testplaner risikoene som skal håndteres, og fremgangsmåten som skal brukes for å håndtere dem. Planer forutsetter vanligvis et budsjett for testing – noe som alltid innebærer et kompromiss.
• Dårlige, ustabile eller uferdige systemkrav, utforminger og spesifikasjoner gjør testspesifisering vanskeligere. Testdekningen av systemet svekkes av manglende detaljer i spesifikasjonene.
• At testmiljøene blir tilgjengelige sent eller er utilstrekkelige, gjør enkelte planlagte tester upraktiske eller meningsløse. Integrasjonstesting i større skala kan være umulig å gjennomføre som planlagt fordi ikke alle grensesnitt eller systemer som skal integreres, kan gjøres tilgjengelige.
• Ytelsestesting kan bli svekket fordi miljøene mangler nødvendig skala eller ikke gjenspeiler produksjonsmiljøet.
• Sen levering av programvaren som skal testes betyr at omfanget av testingen må reduseres når tidsfristene ligger fast.

Erosjon av testdekningen under testgjennomføringen har også flere årsaker:

• Hvis kvaliteten på programvaren som skal testes, er dårlig når den går inn i en testfase, kan testkjøringen bli spesielt frustrerende. De mest grunnleggende testene kan feile, og feilene som oppdages, kan være så fundamentale at utviklerne trenger mer tid til å rette dem enn noen hadde forutsett. Hvis testingen avbrytes fordi programvarekvaliteten er for dårlig, vil du bli forsinket. Hvis tidsfristen ikke flyttes, vil enkelte tester tas ut av omfanget.
• Når det oppstår flere feil enn forventet, vil selve syklusen med feilretting og ny testing ta mer tid, og du vil gå tom for tid før alle testene er fullført.
• Når tiden faktisk tar slutt og beslutningen om å lansere tas, vil ikke all testingen være fullført. Enten ble enkelte tester aldri nådd i planen, eller så er det gjenværende feil som hindrer fullføringen av tester som har feilet. Når datoen for produksjonssetting ikke flyttes, er dette den klassiske innstrammingen av testingen som ble nevnt ovenfor.

Å håndtere erosjon av testdekningen er en av utfordringene testerne møter i alle prosjekter. Ting går sjelden problemfritt, og å redusere tiden til testing (og testdekningen) er vanligvis det eneste alternativet for å holde prosjektet på rett spor.

Det er ikke feil å redusere mengden testing; det som er feil, er å redusere testingen vilkårlig. Når du derfor tar valg om hvilke tester som skal fjernes, må konsekvensene for testmålene og risikoene som skal håndteres, vurderes. Du kan måtte ha noen vanskelige samtaler med interessentene.

Når konsekvensen er betydelig, kan det være nødvendig å legge til rette for et møte mellom dem som ber om kuttene (vanligvis prosjektledelsen) og dem hvis interesser kan bli berørt av kuttene (interessentene). Din rolle er å redegjøre for situasjonen med hensyn til gjennomførte tester, den nåværende kjente tilstanden til det testede systemet, testene som feiler og/eller hindrer fremdriften, samt hvor mye testing som gjenstår.

Planene og modellene dine beskriver det opprinnelige testomfanget og er avgjørende for å hjelpe interessenter og ledelse med å forstå manglene og de uavklarte risikoene, og med å ta beslutningen om å fortsette testingen eller stoppe.

Håndtering av hendelser

Når prosjektet går inn i fasene for systemtesting og akseptansetesting, drives det i stor grad av hendelsene som oppstår under testgjennomføringen. Hendelser utløser aktiviteter i resten av prosjektet, og hendelsesstatistikk kan noen ganger gi god innsikt i prosjektets status. Når vi kategoriserer hendelser, må vi tenke fremover på hvordan denne informasjonen senere skal brukes.

En hendelse er en ikke-planlagt begivenhet som oppstår under testing, og som kan ha betydning for en vellykket fullføring av testingen, beslutningen om godkjenning eller behovet for å iverksette andre tiltak.

Vi bruker et nøytralt begrep for disse ikke-planlagte begivenhetene – hendelse. Disse begivenhetene omtales imidlertid ofte med andre begreper, noen mer nøytrale enn andre. 

Tester som feiler, kan omtales som observasjoner, avvik eller problemer – nøytrale begreper som ikke forutsetter en årsak. Men noen ganger brukes problem, feil, defekt eller mangel – noe som forutsetter at systemet er feil. Dette kan imidlertid være en forhastet konklusjon, og disse betegnelsene kan være misvisende.

Vi foreslår at du reserverer begrepene feil, defekt eller mangel for resultatene av diagnostiseringen av feil i konstruksjonen av systemet som testes, og som vanligvis fører til omarbeiding for utviklingsteamet.

Hendelser viser seg på to måter:

1. Systemfeil: systemet oppfører seg ikke som forventet i en test, det vil si at det svikter på en eller annen måte eller ser ut til ikke å oppfylle et krav.
2. Avbrudd i eller undergraving av testing eller tester: en hendelse som påvirker testernes mulighet til å fullføre oppgavene sine, for eksempel tap av eller feil i testmiljøet, data eller grensesnitt, støttende, integrerte systemer eller tjenester, eller annen ekstern påvirkning.

Systemfeil

Disse hendelsene er ofte av størst direkte betydning fordi de undergraver tilliten til systemets kvalitet. 

Avbrudd og undergravde tester

Noen organisasjoner betrakter ikke disse hendelsene som hendelser i det hele tatt – avbrudd er en del av prosjektenes hektiske sluttfase. Undergravde tester, det vil si tester der miljøet eller testoppsettet er feil, kan bli lagt på testteamet (for oppsettet eller i det minste for ikke å ha kontrollert oppsettet før testingen).

I begge tilfeller påvirkes fremdriften i testingen, og hvis du leder prosessen, er du ansvarlig for å forklare forsinkelser. Av denne grunnen bør du enten registrere disse hendelsene som avvik eller be teamet føre en testlogg og registrere driftsavbrudd i miljøet, konfigurasjonsproblemer eller mangel på egnede programvareversjoner å teste. Hvis du ikke gjør det, vil du få problemer med å begrunne forsinkelser i fremdriften, og det kan stille deg og teamet i et dårlig lys.

Registrere avvik eller ikke?

Med fremveksten av smidige metoder og tilnærminger basert på kontinuerlig leveranse har det tradisjonelle synet på avvikshåndtering blitt utfordret. I trinnvise prosjekter behandles avvik som potensielle arbeidspakker for utviklere, som godkjennes i henhold til alvorlighetsgrad og/eller hvor mye det haster. 

Det finnes en formell, ofte byråkratisk prosess som skal følges, der avvik gjennomgås, prioriteres og håndteres av utviklingsteamet (eller et annet team). Avanserte verktøy for avvikshåndtering kan inngå i prosessen.

I mindre, smidige team er forholdet mellom tester og utvikler tett. Hele teamet kan møtes daglig for å diskutere større avvik, men som oftest oppdages, diagnostiseres, rettes og testes feil uformelt, uten behov for å registrere et avvik eller involvere andre i teamet eller eksternt forretnings- eller IT-personell. Mer alvorlige feil kan diskuteres og tas inn i arbeidet med en brukerhistorie, eller samles i egne iterasjoner eller sprinter for feilretting.

Vi diskuterte formålet med og behovet for dokumentasjon i en tidligere artikkel. Denne diskusjonen er også relevant for avvik. Teamet må vurdere om det er behov for et verktøy og en prosess for avvikshåndtering, og om dette er nyttig for teamet og/eller kreves av personer utenfor teamet.

Større team har en tendens til å basere seg på prosesser og verktøy for å håndtere avvik av tre grunner: 

1. For å sikre at avvik ikke blir glemt
2. For å sikre at alvorlige problemer gjennomgås av interessenter og prosjektledelsen 
3. For å samle inn måledata som kan være verdifulle under og etter prosjektet.

Skille mellom hast og alvorlighetsgrad

Uansett hvilken prosess for avvikshåndtering du velger, anbefaler vi at du tildeler både en prioritetskode og en alvorlighetskode til alle avvikene dine.

• Prioritet tildeles fra et testperspektiv og påvirker når et avvik blir løst. Testeren bør avgjøre om et avvik har høy eller lav prioritet (eller hvilken mellomliggende grad som måtte være tillatt). Prioriteten angir hvor mye denne feilen haster for testerne selv, og er basert på hvilken innvirkning testfeilen har på resten av testingen.
• Alvorlighetsgrad tildeles fra brukerens perspektiv og angir hvorvidt (vanligvis) en feil kan aksepteres. Sluttbrukerne eller ledelsen deres bør fastsette alvorlighetsgraden, eller (mer effektivt) overstyre testernes innledende vurdering ved behov. Alvorlighetsgraden gjenspeiler innvirkningen feilen ville hatt på virksomheten dersom den ikke ble rettet før leveransen. Vanligvis gjør en alvorlig feil systemet uakseptabelt. Hvis en feil har lav alvorlighetsgrad, kan den anses som for ubetydelig til at den må rettes før produksjonssetting, men den kan rettes i en senere versjon.

Hvis et avvik stopper testingen og testingen ligger på den kritiske linjen, stopper hele prosjektet.

Et avvik med høy prioritet stopper all testing, og vanligvis også prosjektet.

Det viktige å ha i bakhodet når det gjelder klassifiseringsordninger for avvik, er at ikke alle avvik som haster, er alvorlige, og at ikke alle alvorlige avvik haster.

Håndtering av sluttfasen

Vi kaller de siste fasene i testprosessen vår for «sluttfasen», fordi håndteringen av testaktivitetene i disse siste, muligvis hektiske og stressende dagene krever en annen disiplin enn den tidligere, tilsynelatende mye mer avslappede perioden med testplanlegging.

Husk at formålet med testing er å levere informasjon til interessentene slik at de kan ta en beslutning – om å akseptere, rette, avvise, forlenge prosjektet eller avslutte det fullstendig. 

Hvis dere har en felles forståelse av modellene som skal brukes i testingen, er det mye enklere å forklare hva som «fungerer» (med hensyn til modellen), og også hvor ting ikke fungerer, samt risikoene ved disse feilene. Det er interessentenes oppgave å bruke denne informasjonen til å ta beslutninger – veiledet av deg.

En av fordelene ved å ta i bruk en risikobasert test-tilnærming er at når testingen blir skåret ned sent i et prosjekt, bruker vi restrisikoen som argument for å fortsette testingen, eller til og med legge til mer testing. 

Når ledelsen insisterer på å redusere testingen, bør testerne ganske enkelt presentere risikoene som blir «byttet bort». Dette er mye enklere når en tidlig risikovurdering er gjennomført, brukt til å styre testaktivitetene og fulgt opp gjennom hele prosjektet. Når ledelsen hele tiden er klar over restrisikoene, er det mindre sannsynlig at de vil redusere testingen i utgangspunktet.

Og det var alt, folkens – lykke til med testingen!

Meld deg på nyhetsbrevet fra The QA Lead for å få beskjed når nye deler av serien publiseres. Disse innleggene er utdrag fra Pauls kurs i testledelse, som vi på det varmeste anbefaler for å få en dypere gjennomgang av dette og andre emner. Hvis du gjør det, bruk vår eksklusive kupongkode QALEADOFFER for å få $60 i rabatt på full kurspris!