Testa strategi

Jämför med testplan

En teststrategi är en översikt som beskriver testmetoden för mjukvaruutvecklingscykeln . Syftet med en teststrategi är att ge ett rationellt avdrag från organisatoriska mål på hög nivå till faktiska testaktiviteter för att uppfylla dessa mål ur ett kvalitetssäkringsperspektiv. Skapandet och dokumentationen av en teststrategi bör göras på ett systematiskt sätt för att säkerställa att alla mål är helt täckta och förstådda av alla intressenter. Den bör också ofta granskas, utmanas och uppdateras allteftersom organisationen och produkten utvecklas över tiden. Vidare bör en teststrategi även syfta till att samordna olika intressenter för kvalitetssäkring när det gäller terminologi, test- och integrationsnivåer, roller och ansvar, spårbarhet, planering av resurser m.m.

Teststrategier beskriver hur intressenternas produktrisker minskas på testnivå, vilka typer av tester som ska utföras och vilka in- och utträdeskriterier som gäller. De skapas baserat på utvecklingsdesigndokument. Systemdesigndokument används i första hand och ibland kan konceptuella designdokument hänvisas till. Designdokument beskriver funktionaliteten hos programvaran som ska aktiveras i den kommande releasen . För varje steg i utvecklingsdesignen bör en motsvarande teststrategi skapas för att testa de nya funktionsuppsättningarna.

Testnivåer

Teststrategin beskriver testnivån som ska utföras. Det finns i första hand tre nivåer av testning: enhetstestning , integrationstestning och systemtestning . I de flesta programvaruutvecklingsorganisationer ansvarar utvecklarna för enhetstestning. Enskilda testare eller testteam ansvarar för integration och systemtestning.

Roller och ansvar

Testledarens, individuella testares och projektledarens roller och ansvar ska tydligt definieras på projektnivå i detta avsnitt. Detta kanske inte har associerade namn, men rollen måste vara mycket tydligt definierad.

Teststrategier bör granskas av utvecklarna. De bör också granskas av leads för alla testnivåer för att säkerställa att täckningen är komplett, men inte överlappande. Både testchefen och utvecklingsansvariga bör godkänna teststrategin innan testning kan påbörjas.

Miljökrav

Miljökrav är en viktig del av teststrategin. Den beskriver vilka operativsystem som används för att testa. Den informerar också tydligt om nödvändiga OS- patchnivåer och säkerhetsuppdateringar som krävs. Till exempel kan en viss testplan kräva att Windows 8.1 är installerat som en förutsättning för testning.

Testverktyg

Det finns två metoder som används för att utföra testfall: manuell och automatiserad . Beroende på testets karaktär är det vanligtvis så att en kombination av manuell och automatiserad testning är den bästa testmetoden.

Risker och begränsningar

Alla risker som kommer att påverka testprocessen måste listas tillsammans med begränsningen. Genom att dokumentera en risk kan den förutses i god tid i förväg. Proaktiva åtgärder kan vidtas för att förhindra att det inträffar eller för att mildra dess skada. Exempel på risker är beroende av slutförandet av kodning gjord av underleverantörer, eller förmågan hos testverktyg.

Testschema

En testplan bör göra en uppskattning av hur lång tid det kommer att ta att slutföra testfasen. Det finns många krav för att slutföra testfaser. Först måste testare utföra alla testfall minst en gång. Dessutom, om en defekt hittades måste utvecklarna åtgärda problemet. Testarna bör sedan omtesta det misslyckade testfallet tills det fungerar korrekt. Sist men inte minst måste testaren utföra regressionstestning mot slutet av cykeln för att se till att utvecklarna inte av misstag bröt delar av programvaran medan de fixade en annan del. Detta kan inträffa i testfall som tidigare fungerade korrekt.

Testschemat bör också dokumentera antalet testare som är tillgängliga för testning. Om möjligt, tilldela testfall till varje testare.

Det är ofta svårt att göra en korrekt uppskattning av testschemat eftersom testfasen innebär många osäkerheter. Planerare bör ta hänsyn till den extra tid som behövs för att hantera eventuella problem. Ett sätt att göra denna uppskattning är att titta på den tid som krävs av de tidigare versionerna av programvaran. Om programvaran är ny är det ett bra sätt att börja multiplicera det initiala testschemat med två.

Regressionstestmetod

När ett särskilt problem identifieras, felsöks programmen och korrigeringen tillämpas på programmet. För att säkerställa att korrigeringen fungerar kommer programmet att testas igen för det kriteriet. Regressionstest kommer att minska sannolikheten för att en fix skapar några andra problem i det programmet eller i något annat gränssnitt. Så en uppsättning relaterade testfall kan behöva upprepas igen för att testa om något annat påverkas av en viss fix. Hur detta kommer att gå till ska utvecklas i detta avsnitt.

Tänk på olika testnivåer när du väljer regressionstestfall. Enhets-, integrations- och systemtestfall är bra kandidater. Välj ärenden som har ett direkt samband med korrigeringen och inkluderar även få affärskritiska fall som visar att grundläggande affärsscenarier fortfarande fungerar. Kom också ihåg att icke-funktionella tester (säkerhet, prestanda, användbarhet) spelar en viktig roll för att bevisa verksamhetens fortsättning.

I vissa företag, när det finns en fix i en enhet, kommer alla enhetstestfall för den enheten att upprepas.

Testgrupper

Från listan över krav kan vi identifiera relaterade områden, vars funktionalitet är liknande. Dessa områden är testgrupperna. Till exempel, i ett järnvägsreservationssystem är allt som har med biljettbokning att göra en funktionell grupp; allt som har med rapportgenerering att göra är en funktionell grupp. På samma sätt måste vi identifiera testgrupperna utifrån funktionalitetsaspekten.

Testprioriteringar

Bland testfallen måste vi göra prioriteringar. När man testar programvaruprojekt kommer vissa testfall att behandlas som de viktigaste, och om de misslyckas kan produkten inte släppas. Vissa andra testfall kan vara av mindre funktionell betydelse, eller till och med kosmetiska och om de misslyckas kan vi släppa produkten utan att kompromissa med funktionaliteten. Dessa prioriteringsnivåer måste tydligt anges. Dessa kan också mappas till testgrupperna.

Teststatusinsamlingar och rapportering

När testfall genomförs måste testledaren och projektledaren veta exakt var projektet står när det gäller testaktiviteter. För att veta var projektet står måste input från de enskilda testarna komma till testledaren. Detta kommer att inkludera vilka testfall som körs, hur lång tid det tog, hur många testfall som godkänts, hur många som misslyckades och hur många som inte är körbara. Hur ofta projektet samlar in status ska också tydligt anges. Vissa projekt kommer att ha praxis att samla in status på daglig basis eller veckovis.

Testet registrerar underhåll

När testfallen utförs är det viktigt att hålla reda på utföringsdetaljerna som när det utförs, vem som gjorde det, hur lång tid det tog, vad är resultatet etc. Dessa data måste vara tillgängliga för testledaren och projektledare, tillsammans med alla teammedlemmar, på en central plats. Detta kan lagras i en specifik katalog på en central server och dokumentet måste tydligt tala om platserna och katalogerna. Namnkonventionen för dokumenten och filerna ska också nämnas.

Krav spårbarhetsmatris

Helst måste programvaran helt uppfylla kraven. Från design måste varje krav tas upp i varje enskilt dokument i mjukvaruprocessen. Dokumenten inkluderar HLD , LLD , källkoder, enhetstestfall, integrationstestfall och systemtestfall. I en kravspårbarhetsmatris kommer raderna att ha kraven. Kolumnerna representerar varje dokument. Korsande celler markeras när ett dokument adresserar ett visst krav med information relaterad till krav-ID i dokumentet. Idealiskt, om varje krav adresseras i varje enskilt dokument, alla individuella celler har giltiga avsnitts-ID eller namn ifyllda, då vet vi att varje krav är adresserat. Om några celler är tomma, betyder det att ett krav inte har åtgärdats korrekt.

Testsammanfattning

Den högsta ledningen kan vilja ha testsammanfattning på vecko- eller månadsbasis. Om projektet är mycket kritiskt kan de behöva det även dagligen. Detta avsnitt måste ta upp vilken typ av testsammanfattningsrapporter som kommer att tas fram för den högsta ledningen tillsammans med frekvensen.

Teststrategin måste ge en tydlig vision om vad testteamet kommer att göra för hela projektet under hela varaktigheten. Detta dokument kan presenteras för kunden vid behov. Den som utarbetar detta dokument måste vara funktionellt stark inom produktdomänen, med mycket god erfarenhet, eftersom det är detta dokument som ska driva hela teamet för testaktiviteterna. Teststrategi måste tydligt förklaras för testteammedlemmarna redan i början av projektet.

Se även

Ammann, Paul och Offutt, Jeff. Introduktion till mjukvarutestning. New York: Cambridge University Press, 2008
Bach, James (1999). "Teststrategi" (PDF) . Hämtad 31 oktober 2011 .
Dasso, Aristides. Verifiering, validering och testning inom mjukvaruteknik. Hershey, PA: Idea Group Pub., 2007