Meny

Hur man skriver teststrategidokument (med exempel på teststrategimall)

how write test strategy document

Prova Vårt Instrument För Att Eliminera Problem

Lär dig att skriva teststrategidokument effektivt

En strategiplan för att definiera testmetoden, vad du vill åstadkomma och hur du ska uppnå det.

Detta dokument tar bort all osäkerhet eller vaga kravuttalanden med en tydlig plan för att uppnå testmålen. Teststrategi är ett av de viktigaste dokumenten för QA-teamet.

=> Klicka här för en fullständig handledningsserie för testplan

Hur man skriver teststrategidokument

Vad du kommer att lära dig:

Skriva ett teststrategidokument

Teststrategi

Att skriva en teststrategi effektivt är en färdighet som varje testare ska uppnå i sin karriär. Det initierar din tankeprocess vilket hjälper till att upptäcka många saknade krav. Tänkande och testplaneringsaktiviteter hjälper ett team att definiera testomfånget och testtäckningen.

Det hjälper testchefer att få det tydliga läget för projektet när som helst. Chanserna att missa någon testaktivitet är mycket låga när det finns en korrekt teststrategi på plats.

Testkörning utan någon plan fungerar sällan. Jag känner lag som skriver strategidokument men aldrig hänvisar tillbaka det under testutförandet. Teststrategiplanen måste diskuteras med hela teamet så att teamet överensstämmer med tillvägagångssättet och ansvaret.

I snäva tidsfrister kan du inte bara avstå från någon testaktivitet på grund av tidspress. Åtminstone måste det gå igenom en formell process innan det görs.

Vad är en teststrategi?

Teststrategi betyder 'Hur ska du testa ansökan?' Du måste nämna den exakta processen / strategin som du ska följa när du kommer att få ansökan för testning.

Jag ser att många företag följer teststrategimallen mycket strikt. Även utan någon standardmall kan du hålla detta teststrategidokument enkelt men ändå effektivt.

Teststrategi vs. Testplan

Under åren ser jag mycket förvirring mellan dessa två dokument. Så låt oss börja med grundläggande definitioner. Generellt spelar det ingen roll vad som kommer först. Testplaneringsdokumentet är en kombination av strategi kopplad till en övergripande projektplan. Enligt IEEE Standard 829-2008 är strategiplanen en del av en testplan.

Varje organisation har sina egna standarder och processer för att underhålla dessa dokument. Vissa organisationer inkluderar strategidetaljer i själva testplanen (här är ett bra exempel av detta). Vissa organisationer listar strategi som ett underavsnitt i en testplan men detaljer skiljs åt i olika teststrategidokument.

Projektomfång och testfokus definieras i testplanen. I grund och botten handlar det om testtäckning, funktioner som ska testas, funktioner som inte ska testas, uppskattning, schemaläggning och resurshantering.

Medan teststrategin definierar riktlinjer för testmetod som ska följas för att uppnå testmål och utförande av testtyper som definieras i testplanen. Den behandlar testmål, tillvägagångssätt, testmiljö, automatiseringsstrategi och verktyg och riskanalys med en beredskapsplan.

Att sammanfatta testplanen är en vision om vad du vill uppnå och teststrategin är en handlingsplan utformad för att uppnå denna vision!

Jag hoppas att detta kommer att rensa alla dina tvivel. James Bach har mer diskussion om detta ämne här .

Process för att utveckla ett bra teststrategidokument

Följ inte bara mallarna utan att förstå vad som fungerar bäst för ditt projekt. Varje kund har sina egna krav och du måste hålla fast vid de saker som fungerar perfekt för dig. Kopiera inte någon organisation eller någon standard blint. Se alltid till om det hjälper dig och dina processer.

Nedan följer en exempelstrategimall som beskriver vad som ska täckas i denna plan tillsammans med några exempel för att illustrera vad som är vettigt att täcka under varje komponent.

Teststrategi i STLC:

STLC

(bild källa )

konvertera youtube till mp3 längre än 20 minuter

Vanliga avsnitt av teststrategidokument

Steg 1: Omfattning och översikt

Projektöversikt tillsammans med information om vem som ska använda detta dokument. Inkludera också detaljer som vem som kommer att granska och godkänna detta dokument. Definiera testaktiviteter och faser som ska genomföras med tidslinjer med avseende på övergripande projekttidslinjer som definieras i testplanen.

Steg 2: Testmetod

Definiera testprocessen, testnivån, roller och ansvar för varje teammedlem.

För varje testtyp definieras i testplan ( Till exempel, Enhet , Integration, System, Regression, Installation / avinstallation , Användbarhet, belastning, prestanda och säkerhetstestning) beskriver varför det ska utföras tillsammans med detaljer som när man ska starta, testägare, ansvar, testmetod och detaljer om automatiseringsstrategi och verktyg om tillämpligt.

I testutförandet finns olika aktiviteter som att lägga till nya defekter, defekt triage, defektuppdrag, omprövning, regressionstest och slutligen testavloggning. Du måste definiera de exakta stegen som ska följas för varje aktivitet. Du kan följa samma process som fungerade för dig i dina tidigare testcykler.

En Visio-presentation av alla dessa aktiviteter inklusive ett antal testare och som kommer att arbeta med vilken aktivitet som är till stor hjälp för att snabbt förstå roller och ansvar i teamet.

Till exempel, defekthanteringscykel - nämna processen för att logga den nya defekten. Var ska man logga in, hur man loggar nya defekter, vad ska vara defektstatus, vem ska göra defekt triage, vem tilldela defekter efter triage etc.

Definiera också förändringshanteringsprocessen. Detta inkluderar att definiera inlämnande av ändringsbegäran, mall som ska användas och process för att hantera begäran.

Steg 3: Testa miljön

Testmiljöinstallationen bör beskriva information om ett antal miljöer och nödvändig installation för varje miljö. Till exempel, En testmiljö för det funktionella testteamet och en annan för UAT-teamet.

Definiera antalet användare som stöds i varje miljö, åtkomstroller för varje användare, programvara och maskinvarukrav som operativsystem, minne, ledigt diskutrymme, antal system etc.

Definiera krav på testdata är lika viktigt. Ge tydliga instruktioner om hur skapa testdata (antingen generera data eller använd produktionsdata genom att maskera fält för integritet).

Definiera säkerhetskopiering av testdata och återställningsstrategi. Testmiljödatabasen kan stöta på problem på grund av obehandlade förhållanden i koden. Jag kommer ihåg problemen vi mötte i ett av projekten när det inte fanns någon strategi för säkerhetskopiering av databaser och vi förlorade hela data på grund av kodproblem.

Säkerhetskopierings- och återställningsprocessen ska definiera vem som tar säkerhetskopior när man ska ta en säkerhetskopia, vad som ska ingå i säkerhetskopiering när man ska återställa databasen, vem som kommer att återställa den och datamaskningssteg som ska följas om databasen återställs.

Steg 4: Testverktyg

Definiera testhanterings- och automatiseringsverktyg som krävs för testutförande. För prestanda, belastning och säkerhetstestning beskrivs testmetoden och de verktyg som krävs. Nämn om det är öppen källkod eller kommersiellt verktyg och hur många användare som stöds på det och planera därefter.

Steg 5: Släpp kontrollen

Som nämnts i vår sista UAT-artikel , oplanerad släppcykel kan resultera i olika programvaruversioner i test- och UAT-miljöer. Släpphanteringsplan med korrekt versionshistorik säkerställer testkörning av alla ändringar i den versionen.

Till exempel, Ställ in bygghanteringsprocessen som svarar - var nybyggnad ska göras tillgänglig, var den ska distribueras, när ska den nya byggnaden hämtas, varifrån man kan få produktionsbyggnaden, vem som ger ut, no-go-signalen för produktionsläpp , etc.

Steg 6: Riskanalys

Lista alla risker som du tänker dig. Ge en tydlig plan för att mildra dessa risker och också en beredskapsplan om du ser dessa risker i verkligheten.

Steg 7: Granskning och godkännande

När alla dessa aktiviteter definieras i teststrategiplanen måste den granskas för avloggning av alla enheter som är involverade i projektledning, affärsteam, utvecklingsteam och systemadministrationsteam (eller miljöledning).

Sammanfattning av granskningsändringar bör spåras i början av dokumentet tillsammans med godkännandens namn, datum och kommentar. Det är också ett levande dokument som innebär att detta kontinuerligt bör granskas och uppdateras med förbättringar av testprocessen.

Enkla tips för att skriva teststrategidokument

  1. Inkludera produktbakgrund i teststrategidokumentet. I första stycket i ditt teststrategidokument svarar - Varför intressenter vill utveckla detta projekt? Detta hjälper dig att snabbt förstå och prioritera saker.
  2. Lista alla viktiga funktioner som du ska testa. Om du tror att vissa funktioner inte ingår i den här versionen kan du nämna dessa funktioner under etiketten 'Funktioner som inte ska testas'.
  3. Skriv ner testmetoden för ditt projekt. Det är uppenbart att nämna vilka typer av tester du ska genomföra?
    dvs. funktionstestning, UI-testning, integrationstestning, belastning / stresstestning, säkerhetstestning etc.
  4. Svara på frågor som hur du ska utföra funktionstester? Manuell eller automatiseringstestning? Ska du utföra alla testfall från ditt testhanteringsverktyg?
  5. Vilket felspårningsverktyg ska du använda? Vad blir processen när du hittar ett nytt fel?
  6. Vilka är dina kriterier för testinträde och utgång?
  7. Hur kommer du att spåra dina testförlopp? Vilka mätvärden ska du använda för att spåra testets slutförande?
  8. Uppgiftsfördelning - Definiera roller och ansvar för varje teammedlem.
  9. Vilka dokument kommer du att producera under och efter testfasen?
  10. Vilka risker ser du när du slutför testet?

Slutsats

Teststrategi är inte ett papper. Det återspeglar hela QA-aktiviteter i programvarutestningens livscykel. Se det här dokumentet då och då i testgenomförandeprocessen och följ planen tills programvaran släpps.

När projektet närmar sig släppdatumet är det ganska enkelt att minska testaktiviteterna genom att ignorera det du har definierat i teststrategidokumentet. Men det är tillrådligt att diskutera med ditt team huruvida nedskärning av någon särskild aktivitet hjälper till att släppas utan någon potentiell risk för större problem efter utgivningen.

De flesta av de smidiga lagen minskar med att skriva strategidokument eftersom lagfokus ligger på testkörning snarare än dokumentation. Men att ha en grundläggande teststrategiplan hjälper alltid till att tydligt planera och mildra riskerna i projektet. Agila team kan fånga och dokumentera alla aktiviteter på hög nivå för att slutföra testkörningen i tid utan problem.

Jag är säker på att utveckla en bra teststrategiplan och åta mig att följa den kommer definitivt att förbättra testprocessen och kvaliteten på programvaran. Det vore ett nöje om den här artikeln inspirerar dig att skriva en teststrategiplan för ditt projekt!

Om du gillar det här inlägget kan du överväga att dela det med dina vänner!

=> Besök här för en komplett testplan-handledningsserie

Rekommenderad läsning

^