Når det kommer til softwareudvikling, kan alle testaktiviteter opdeles i flere faser. Ligesom softwareudviklingslivscyklussen (SDLC) findes der også en softwaretestlivscyklus (STLC). At følge alle faserne kan være afgørende for at få processen til at fungere korrekt og oversætte til en meget højere effektivitet af de udførte tests og dermed en meget højere kvalitet af det endelige produkt. Læs videre for at finde ud af mere.

6 faser af STLC – indholdsfortegnelse:

  1. Fase 1: Kravanalyse
  2. Fase 2: Testplanlægning
  3. Fase 3: Testcases udvikling
  4. Fase 4: Miljøopsætning
  5. Fase 5: Testudførelse
  6. Fase 6: Testlukning
  7. 6 faser af STLC – opsummering

Fase 1: Kravanalyse

Dette er det første skridt i cyklussen. Testteamet gennemgår omhyggeligt produktkravene. Hvis der er nogen konflikter, udeladelser, unøjagtigheder eller misforståelser, diskuterer testteamet dem med forskellige interessenter i projektet, såsom forretningsanalytikeren eller softwarearkitekten.

Indgangskriterier:

  • Business Requirement Specification (BRS)
  • et softwarearkitekturdokument

Opgaver at udføre:

  • bestemme de tests, der skal udføres
  • fastsætte prioriteter for testudførelse
  • tjekke hvilke tests der skal være manuelle, og hvilke der skal automatiseres

Udgangskriterier:

  • en liste over krav til testning
  • eventuelle tests, der skal automatiseres

Fase 2: Testplanlægning

I denne fase planlægger valideringsteamet alle testaktiviteter ved at skrive en testplan. Dette dokument specificerer:

  • de mål, der skal opnås
  • de processer og metoder, der skal implementeres
  • det miljø og de værktøjer, der skal bruges
  • de elementer, der skal testes eller ikke testes
  • organisationen af teamet og opgavefordelingen
  • intermediate mål for forskellige aktiviteter
  • risici, der kan opstå

Udover at udvikle testplanen udarbejdes der også et omkostningsoverslag i denne fase.

faser af STLC

Fase 3: Testcases udvikling

I denne fase — også kendt som Test Design — er der fire trin at følge:

1. Forbered testscenarier

Testlederen eller testansvarlig forbereder et testscenario, som vil blive brugt til at oprette testcases.

2. Opret testcases

For hvert scenario vil testere skrive testcases, så de kan verificere, at softwarefunktionaliteten opfylder kravene. I tilfælde af testautomatisering er det på dette stadium, at testscripts vil blive skrevet.

3. Forbered testdata

Testteamet skal forberede et sæt data, der skal bruges ved udførelsen af testcases. Dette kan være positive eller negative data for at teste funktionens ydeevne i tilfælde af korrekte eller forkerte data.

4. Forbered RTM

Testteamet forbereder en nøgle Requirement Traceability Matrix (RTM). Dette dokument bruges til at holde styr på, hvilke tests der er nødvendige for at verificere, om kravene vil blive opfyldt eller ej. Før testningen begynder, vil interessenterne udføre kontroller og valideringer af, hvad der blev udviklet under de ovenstående aktiviteter.

Fase 4: Miljøopsætning

Dette er en fase, hvor testteamet ikke er involveret. Et separat team vil håndtere forberedelsen og konfigurationen af miljøet. Testerne vil blive informeret om, hvordan miljøet er blevet opsat, og hvilken softwareversion der er opdateret.

Den eneste aktivitet, der kræves af testteamet, er at forberede smoke tests for at verificere, at den installerede build er egnet til testning. Hvis smoke tests fejler, vil builden blive afvist, og testningen vil blive suspenderet, indtil de angivne problemer er løst.

Indgangskriterier:

  • testplan
  • testdato
  • smoke test

Opgaver at udføre:

  • forberedelse af testmiljø
  • opsætning af testmiljø
  • opsætning af testdata
  • udførelse af smoke tests på kompilering

Udgangskriterier:

  • brugbart testmiljø
  • brugbare testdata
  • positive smoke testresultater

Fase 5: Testudførelse

Dette er simpelthen udførelsen af tests. I denne fase kan testere identificere mulige anomalier og teste de forbedringer, der er udviklet af programmørerne. Opgaverne for testteamet vil være:

  • køre de tidligere udviklede testcases og sammenligne det forventede resultat med det opnåede
  • vedligeholde testscripts
  • identificere, opdage, logge og rapportere eventuelle opdagede fejl
  • reteste fejlrettelser

Indgangskriterier:

  • funktionsdygtigt testmiljø
  • korrekte testdata
  • testplan
  • testcases, der skal udføres

Opgaver at udføre:

  • udføre tests i henhold til testplanen
  • dokumentere testresultater
  • håndtere fejlens livscyklus

Udgangskriterier:

  • udføre alle tests, der involverer MTR
  • opdaterede testcases med resultater
  • fejlrapporter

Fase 6: Testlukning

Softwaren vil blive implementeret. Valideringsteamet mødes for at analysere resultaterne og identificere områder til forbedring i fremtidige projekter. Testlederen forbereder en testlukningsrapport, som vil blive udført dagligt (DSR – daglig statusrapport) eller ugentligt (WSR – ugentlig statusrapport), som aftalt af interessenterne.

Til sidst mødes testteamet for at analysere testcases, fundne fejl, tid brugt, overholdelse af deadlines osv. På denne måde er det muligt at bestemme, hvad der skal forbedres i den næste testcyklus.

Indgangskriterier:

  • testudførelsesrapporter
  • fejlrapporter

Opgaver at udføre:

  • analysere hvad der er blevet testet
  • oprette en testlukningsrapport

Udgangskriterier:

  • lukke processen uden åbne fejl
  • testlukningsrapport

6 faser af STLC – opsummering

Softwareudvikling kunne ikke eksistere uden en testfase. Korrekt forberedelse til denne proces bringer en række fordele, herunder, vigtigst af alt, besparelser af tid og penge til mulige fremtidige revisioner. Vi håber, at denne artikel har hjulpet dig med at lære mere om softwaretestlivscyklussen (STLC).

Du har lige læst om 6 faser af STLC. Tjek vores andre serier om Python og Javascript!

Hvis du kan lide vores indhold, så bliv en del af vores travle bier-fællesskab på Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Robert Whitney

JavaScript-ekspert og instruktør, der coacher IT-afdelinger. Hans hovedmål er at hæve teamproduktiviteten ved at lære andre, hvordan man effektivt samarbejder, mens man koder.

View all posts →