Livscykel för programvarutestning: Faser, verktyg & bästa praxis

De sex faserna är:

1. Kravanalys
2. Testplanering
3. Utveckling av testfall
4. Konfiguration av testmiljö
5. Testgenomförande
6. Testavslut

Du kan använda dessa sex faser oavsett om du testar en ny funktion, en fullständig release eller en snabbkorrigering. Samma strukturerade metod gäller varje gång.

Varför STLC är viktigt: 5 viktiga fördelar

STLC är viktigt eftersom det hjälper till att upptäcka defekter tidigare, vilket påverkar kostnaden direkt. En vanlig tumregel är att buggar är exponentiellt dyrare att åtgärda i produktionen än under testningen.

En tydlig STLC ger ditt team:

• Tidig upptäckt av defekter: Genom att granska kraven innan ett testfall skrivs upptäcks oklarheter innan de blir dyra buggar.
• Förutsägbar testtäckning: En definierad process ser till att inget faller mellan stolarna mellan sprintar eller överlämningar.
• Standardiserad dokumentation: Varje fas producerar artefakter (t.ex. testplaner, testfall och defektloggar) som skapar ett revisionsspår och stöder efterlevnad.
• Tydligt ansvar: När varje fas har definierade roller och avslutskriterier blir det enklare att mäta framsteg och identifiera flaskhalsar.
• Lägre totalkostnad: Strukturerad testning minskar omarbete, oplanerade snabbkorrigeringar och de operativa följderna av produktionsdefekter.

Jag har upptäckt att team som hoppar över formella STLC-faser inte sparar tid. De lägger i stället den tiden senare på incidenthantering och akuta korrigeringar.

Testlivscykeln för programvara jämfört med livscykeln för programvaruutveckling

SDLC omfattar hela processen för leverans av programvara, från krav via design, utveckling, testning, driftsättning och underhåll. STLC ingår i SDLC och omfattar endast testaktiviteter.

Använd den här tabellen för att jämföra de två:

Dimension	SDLC	STLC
Omfattning	Fullständig programvaruleverans	Endast testaktiviteter
Fokus	Att bygga och leverera programvara	Att verifiera kvalitet och upptäcka defekter
Primärt team	Utvecklare, produktchefer och arkitekter	QA-ingenjörer, testledare och testchefer
Leverabler	Fungerande programvara, arkitekturdokumentation och releasebyggen	Testplaner, testfall, defektrapporter och testsammanfattningsrapporter
Mål	Leverera produkten	Validera att produkten uppfyller kraven

Roller och ansvarsområden i STLC

Varje STLC-fas bygger på att specifika personer utför specifika uppgifter. Här är vem som ansvarar för vad:

• Testansvarig: Fastställer den övergripande teststrategin, hanterar budgetar och tidsplaner samt rapporterar kvalitetsstatus till intressenter. Ansvarar för testplanen.
• Testledare: Samordnar det dagliga testarbetet, fördelar uppgifter till teamet och följer upp framstegen mot kriterierna för avslut.
• QA-ingenjör: Skriver och kör testfall, loggar defekter och utför regressionstester. Stommen i genomförandefasen.
• Automatiseringsingenjör: Utformar och underhåller automatiserade testskript. Ansvarar för automatiseringsramverket och CI/CD-integrationen.
• Verksamhetsanalytiker: Stöder kravanalysen genom att förtydliga acceptanskriterier och lösa oklarheter i användarberättelser.
• Utvecklare: Åtgärdar rapporterade defekter och deltar i enhetstestning. Vid vänsterförskjuten testning involveras utvecklarna tidigare i testutformningen.

I mindre team täcker en person ofta flera roller. En QA-ingenjör kan även ansvara för automatisering, och testledaren kan samtidigt fungera som testansvarig. Det är helt okej; se bara till att varje ansvarsområde uttryckligen tilldelas någon i stället för att tas för givet.

Get Free Access

Get regular tech leadership wisdom for delivering better software and systems.

Create Free Account

Have an account? Log In

De 6 faserna i programvarutestningens livscykel

1. Kravanalys

Kravanalysen är där testningen börjar, innan ett enda testfall har skrivits. Teamet granskar funktionella och icke-funktionella krav för att förstå vad systemet ska göra och identifiera sådant som är oklart eller inte går att testa.

Viktiga aktiviteter i den här fasen:

• Granska krav: Analysera dokument med verksamhetskrav, användarberättelser och acceptanskriterier.
• Identifiera testbara krav: Markera sådant som saknar ett mätbart och verifierbart resultat.
• Fastställ testomfattningen: Besluta vad som ska och inte ska testas i den här cykeln.
• Identifiera risker tidigt: Synliggör krav som är tvetydiga, motsägelsefulla eller tekniskt riskfyllda.
• Dokumentera öppna frågor: Skicka olösta oklarheter till verksamhetsanalytikern eller produktägaren för att lösas.

Den viktigaste leveransen här är en spårbarhetsmatris för krav (RTM). Den kopplar varje krav till de testfall som ska verifiera det.

Inträdeskriterier: Godkända kravdokument finns tillgängliga.
Avslutskriterier: Alla testbara krav har identifierats; RTM har utarbetats; oklarheter har loggats och skickats för lösning.

2. Testplanering

Testplaneringen definierar hur testningen ska genomföras. Testledaren eller den testansvarige tar fram testplanen. Dokumentet fastställer testinsatsens omfattning, angreppssätt, resurser, tidsplan och riskregister.

En bra testplan omfattar:

• Testmål: Vad som ska verifieras och varför.
• Testtyper: Funktionell testning, regressionstestning, prestandatestning, säkerhetstestning och så vidare (beroende på vad som gäller för lanseringen).
• Resursplan: Vem som gör vad och när.
• Tidsplan: Milstolpar, testperioder och datum för överlämning.
• Risk och riskhantering: Vad som kan blockera testningen och beredskapen för varje risk.
• Inträdes- och avslutskriterier: Villkoren som styr varje fas.
• Verktyg: Verktyg för testhantering, automatisering och defektuppföljning som teamet ska använda.

Betrakta testplanen som ett levande dokument. I agila team uppdateras den i varje sprint i stället för att skrivas en gång och sedan glömmas bort.

Inträdeskriterier: Kraven har analyserats; RTM är tillgänglig.
Avslutskriterier: Testplanen har granskats och godkänts av intressenterna.

3. Utveckling av testfall

Utvecklingen av testfall är där QA-ingenjörerna skriver, granskar och fastställer de faktiska testerna. Varje testfall kopplas till ett specifikt krav i RTM. Tillsammans ska de täcka hela den omfattning som överenskommits i testplanen.

Varje testfall bör innehålla:

• Testfalls-ID och namn
• Förutsättningar: Det tillstånd systemet måste befinna sig i före körning.
• Teststeg: Numrerade, tydliga och repeterbara åtgärder.
• Förväntat resultat: Det exakta resultatet eller beteendet som valideras.
• Faktiskt resultat: Fylls i under körningen.
• Godkänd/underkänd-status

Den här fasen producerar också testdata, det vill säga de faktiska indata som teamet använder under körningen. Det är viktigt att få testdata rätt, eftersom dåliga testdata ger missvisande resultat.

Inträdeskriterier: Godkänd testplan; färdigställd RTM.
Utträdeskriterier: Testfall granskade och godkända; testdata förberedda och validerade.

4. Konfiguration av testmiljön

Testmiljön är den infrastruktur som teamet kör tester på. Den omfattar servrar, databaser, operativsystem, webbläsare, nätverkskonfigurationer och alla integrationer som applikationen är beroende av.

Den här fasen har två mål: att göra miljön klar och att verifiera att den är stabil innan körningen börjar.

Vanliga aktiviteter omfattar:

• Tillhandahålla infrastruktur: Konfigurera servrar, containrar eller molnmiljöer som motsvarar produktionen.
• Installera bygget: Distribuera bygget som ska testas till miljön.
• Utföra röktest av miljön: Göra en snabb kontroll för att bekräfta att konfigurationen fungerar innan den fullständiga testkörningen.
• Konfigurera data: Fylla miljön med testdata.

Miljöproblem är en av de vanligaste orsakerna till testförseningar. Jag skulle se röktest av miljön som en obligatorisk kontrollpunkt innan körningen börjar. Om miljön inte är stabil blir testresultaten inte meningsfulla.

Inträdeskriterier: Testfall färdigställda; miljöspecifikationer definierade.
Utträdeskriterier: Miljön stabil; röktest godkänt.

5. Testkörning

Testkörning är den fas där teamet kör testfallen och registrerar resultaten. För varje testfall som misslyckas loggar QA-ingenjören ett fel och tilldelar det till utvecklingsteamet för åtgärd.

Körningscykeln fungerar vanligtvis så här:

1. Kör testfallen mot bygget.
2. Logga godkända/underkända resultat i ditt testhanteringsverktyg.
3. Rapportera fel med steg för att återskapa dem, allvarlighetsgrad och stödjande bevis.
4. Utvecklingsteamet undersöker och åtgärdar felet.
5. QA testar åtgärdade fel på nytt.
6. Kör regressionstester för att bekräfta att åtgärderna inte har skadat befintlig funktionalitet.
7. Upprepa tills utträdeskriterierna är uppfyllda.

Det är lika viktigt att följa felens status som att följa framstegen i testkörningen. En ansamling av olösta fel med hög allvarlighetsgrad visar att lanseringen inte är klar, även om andelen genomförda tester ser hög ut.

Inträdeskriterier: Miljön stabil; testfall godkända; bygget distribuerat.
Utträdeskriterier: Alla planerade testfall genomförda; fel över överenskommen allvarlighetsgrad åtgärdade och omtestade; mätvärdena för utträdeskriterierna uppnådda.

6. Testavslut

Testavslutet slutför testcykeln och producerar de artefakter som teamet behöver för överlämning, efterlevnad och förbättring. Det skyndas ofta igenom eller hoppas över när tidsfristerna är pressade, och det är ett misstag.

Viktiga aktiviteter:

• Utvärdera utträdeskriterierna: Bekräfta att alla utträdesvillkor i testplanen är uppfyllda.
• Skriva testsammanfattningsrapporten: Dokumentera resultat, felmätvärden, uppnådd täckning och kvarstående risker.
• Arkivera testtillgångar: Lagra testfall, testdata och felloggar i ett gemensamt arkiv för framtida referens.
• Genomföra en återblick: Identifiera vad som fungerade, vad som inte fungerade och vad som bör förbättras i nästa cykel.

Testsammanfattningsrapporten är den viktigaste leveransen här. Intressenter använder den för att fatta beslut om lansering eller ingen lansering. Skriv den tydligt och se till att den behandlar öppna risker, inte bara andelen godkända tester.

Inträdeskriterier: Testkörningen slutförd; fel åtgärdade eller uppskjutna med dokumenterad motivering.
Utträdeskriterier: Testsammanfattningsrapporten godkänd; testartefakter arkiverade.

Viktiga verktyg för varje STLC-fas

Här är mina val av de bästa verktygen för programvarutestningens livscykel:

Clicks on the links below may earn a commission, which supports our independent testing and review of software and services. Learn more about how we stay transparent.

1. 1. QA.tech — Bäst för AI-driven testning från början till slut
2. 2. BugHerd — Bäst för visuell buggspårning
3. 3. Kualitee — Bäst för hantering av testfall och buggspårning
4. 4. Testpad — Bäst för checklistebaserad testhantering
5. 5. BugBug — Bäst för webbläsartestning
6. 6. Testiny — Bäst för Jira-användare
7. 7. TestGrid — Bäst för parallell testkörning
8. 8. Appsurify TestBrain — Bäst för riskbaserad testning
9. 9. QA Wolf — Bäst för teamarbete
10. 10. Tricentis Testim — Bäst för skalbar automatisering

Vanliga utmaningar i STLC och hur de kan övervinnas

Här är de vanligaste hindren och hur du hanterar dem:

• Otydliga krav: Oklara acceptanskriterier leder till tester som validerar fel sak. Lös detta under kravanalysen. Vänta inte tills testkörningen med att upptäcka att ett krav inte går att testa.
• Instabil testmiljö: En opålitlig testmiljö slösar tid och minskar förtroendet för resultaten. Investera i miljöer som kod med Docker eller Kubernetes, så att du kan starta konsekventa och reproducerbara miljöer på begäran.
• Opålitliga automatiserade tester: Vissa fel i automatiserade tester beror på opålitliga tester, inte på faktiska defekter. Granska din automatiseringssvit regelbundet och skriv om tester som misslyckas inkonsekvent.
• Snäva tidsramar: När tidspressen ökar skär team ofta ned på testningen, vanligtvis regressionstestning. Tillämpa riskbaserad testning för att prioritera områden med stor påverkan i stället för att skära ned blint.
• Isolerade team: När utvecklare och QA arbetar i separata spår går felprioriteringen långsammare. Skapa gemensamma kanaler, rutiner för felprioritering och överenskomna allvarlighetsdefinitioner innan testkörningen börjar.
• Press på automatiseringens ROI: Automatisering kräver en inledande investering och löpande underhåll. Börja med stabila testfall som körs ofta, till exempel inloggningsflöden, API-kontrakt och kassaflöden, innan du utökar till specialfall.

STLC i agilt och DevOps: tidigarelagd och kontinuerlig testning

De sex STLC-faserna gäller fortfarande i agilt och DevOps, men de komprimeras och upprepas. I stället för en lång cykel per version kör teamet en kortare version i varje sprint.

• Tidigarelagd testning: Det innebär att testningen flyttas till ett tidigare skede i utvecklingen. Testare granskar användarberättelser under sprintplaneringen, testfall finns innan koden skrivs och utvecklare skriver enhetstester parallellt med funktionerna. Ju tidigare du hittar en defekt, desto billigare är den att åtgärda.
• Kontinuerlig testning: Detta integrerar automatiserade tester i CI/CD-pipelinen. Varje incheckning utlöser en testkörning och pipelinen avbryts snabbt när en regression upptäcks. Utvecklarna får omedelbar återkoppling utan att behöva vänta på ett särskilt testfönster.

Följ dessa metoder för att anpassa STLC till agilt och DevOps:

• Integrera QA i sprintceremonierna: Testare bör delta i sprintplaneringen för att granska acceptanskriterier och uppmärksamma testbarhetsproblem innan utvecklingen börjar.
• Automatisera regressionstester parallellt med funktionerna: Bygg inte en regressionssvit efter lanseringen. Bygg den när varje funktion levereras.
• Använd funktionsflaggor: Distribuera koden bakom en flagga och testa sedan i produktion innan du aktiverar den för användarna.
• Behandla miljöer som kod: Använd infrastruktur som kod för att automatiskt tillhandahålla konsekventa miljöer vid varje bygge.

Enligt min erfarenhet är den största förändringen kulturell. Det är att få utvecklare och testare att arbeta som ett team, i stället för i sekventiella steg, som gör agil testning effektiv.

Automatiseringens och AI:s roll i den moderna STLC

Automatisering hör hemma i din STLC, men den ersätter inte teststrategin. Den är en accelerator för rätt typer av tester.

Var du bör automatisera

Automatisera tester som körs ofta, är stabila och tidskrävande att köra manuellt:

• Regressionstestning: Det användningsområde för automatisering som ger högst ROI. Kör hela regressionssviten vid varje bygge.
• API-testning: Snabbare, tillförlitligare och enklare att underhålla jämfört med UI-tester.
• Rökprovning: Automatisera din svit med rökprov så att validering av miljön tar minuter i stället för timmar.
• Last- och prestandatestning: Verktyg som k6 och Apache JMeter kan simulera tusentals samtidiga användare. Detta är omöjligt att återskapa manuellt.

Hur AI förändrar STLC

AI gör märkbara skillnader för hur testning fungerar genom hela livscykeln:

• Generering av testfall: AI-verktyg analyserar krav eller användarberättelser och föreslår testfall som teamet annars kanske hade missat.
• Självläkande tester: AI-drivna ramverk upptäcker när ett UI-element ändras och uppdaterar testväljaren automatiskt, vilket minskar underhållsbehovet.
• Prediktiv defektanalys: Vissa plattformar analyserar historiska defektdata för att förutsäga vilka delar av en kodbas som innebär högst risk i en viss version.
• Visuell testning: AI-drivna verktyg jämför skärmbilder pixel för pixel och markerar layoutändringar utan sköra XPath-väljare.

Jag ser på AI inom testning på samma sätt som jag generellt ser på automatisering: den hanterar repetitivt arbete som bygger på mönstermatchning, så att dina QA-ingenjörer kan fokusera på den testning som kräver mänskligt omdöme.

Bästa praxis för testningens livscykel

Följ dessa metoder för att få ut så mycket som möjligt av din STLC under varje fas:

• Börja testa vid kravfasen: Ju tidigare QA involveras, desto färre oklarheter förs vidare till utvecklingen.
• Håll en aktuell RTM: Håll spårbarhetsmatrisen för kraven uppdaterad så att täckningsluckor syns i realtid.
• Tillämpa riskbaserad testning: Fokusera insatserna på områden med hög risk och stor påverkan först, särskilt när tiden är knapp.
• Granska testfall före körning: Testfall som granskats av kollegor upptäcker luckor och felaktiga antaganden innan de leder till missvisande resultat.
• Integrera tester i CI/CD: Automatiserade tester bör köras vid varje incheckning, inte bara före lansering.
• Genomför retrospektiv efter varje cykel: Använd det du lär dig från varje STLC för att förbättra nästa.

Viktiga mätvärden att följa

Dessa KPI:er ger den tydligaste bilden av testkvaliteten och processens hälsa:

Mätvärde	Vad det mäter	Varför det är viktigt
Defekttäthet	Defekter per kodenhet eller funktion	Visar kodkvalitet och testernas grundlighet
Godkända testfall	% av testfallen som godkänns under en cykel	Följer den övergripande byggkvaliteten
Defektläckage	Defekter som hittas i produktion jämfört med under testning	Mäter hur mycket testningen missade
Testtäckning	% av kraven som täcks av testfall	Säkerställer att inget förblir otestat
Tid för defektlösning	Genomsnittlig tid från registrering till åtgärd	Återspeglar utvecklingsteamets responsförmåga
Testkörningsgrad	% av de planerade testfallen som har körts	Följer om testningen håller tidsplanen

Håll dina testkunskaper aktuella

Om du vill hålla dig uppdaterad om trender inom kvalitetsarbete och verktygen som formar modern utveckling, levererar The CTO Club-nyhetsbrevet veckovisa insikter från CTO:er, utvecklingschefer och tekniska ledare direkt till din inkorg.