Menu

Sådan skriver du teststrategidokument (med prøve teststrategiskabelon)

how write test strategy document

Prøv Vores Instrument Til At Fjerne Problemer

Lær at skrive teststrategidokument effektivt

En strategiplan til at definere testmetoden, hvad du vil opnå, og hvordan du skal opnå det.

Dette dokument fjerner al usikkerhed eller vage kravsudsagn med en klar plan for tilgang til at nå testmålene. Teststrategi er et af de vigtigste dokumenter for QA-teamet.

=> Klik her for en komplet testplan-tutorial-serie

Hvordan man skriver teststrategidokument

Hvad du lærer:

Skrivning af et teststrategidokument

Teststrategi

At skrive en teststrategi effektivt er en færdighed, som hver tester skal opnå i deres karriere. Det indleder din tankeproces hvilket hjælper med at opdage mange manglende krav. Tænknings- og testplanlægningsaktiviteter hjælper et team med at definere testomfanget og testdækningen.

Det hjælper testledere med at få den klare tilstand af projektet til enhver tid. Chancerne for at gå glip af en testaktivitet er meget lave, når der er en ordentlig teststrategi på plads.

Testudførelse uden plan fungerer sjældent. Jeg kender hold, der skriver strategidokument, men aldrig henviser det tilbage under testudførelse. Teststrategiplanen skal drøftes med hele teamet, så teamet er i overensstemmelse med tilgang og ansvar.

I stramme tidsfrister kan du ikke bare give afkald på testaktiviteter på grund af tidspres. I det mindste skal det gennemgå en formel proces, før det gøres.

Hvad er en teststrategi?

Teststrategi betyder 'Hvordan skal du teste applikationen?' Du skal nævne den nøjagtige proces / strategi, som du vil følge, når du får applikationen til test.

Jeg ser, at mange virksomheder følger teststrategiskabelonen meget nøje. Selv uden nogen standardskabelon kan du holde dette teststrategidokument simpelt, men stadig effektivt.

Test strategi mod Testplan

I årenes løb ser jeg en masse forvirring mellem disse to dokumenter. Så lad os starte med grundlæggende definitioner. Generelt betyder det ikke noget, hvad der kommer først. Testplanlægningsdokumentet er en kombination af strategi tilsluttet en samlet projektplan. Ifølge IEEE Standard 829-2008 er strategiplanen en underpost i en testplan.

Hver organisation har sine egne standarder og processer til at vedligeholde disse dokumenter. Nogle organisationer inkluderer strategidetaljer i selve testplanen (her er et godt eksempel af dette). Nogle organisationer opregner strategi som et underafsnit i en testplan, men detaljer adskilles i forskellige teststrategidokumenter.

Projektomfang og testfokus er defineret i testplanen. Dybest set handler det om testdækning, funktioner, der skal testes, funktioner, der ikke skal testes, estimering, planlægning og ressourcehåndtering.

Mens teststrategien definerer retningslinjer for testtilgang, der skal følges for at nå testmålene og udførelsen af ​​testtyper defineret i testplanen. Det beskæftiger sig med testmål, tilgang, testmiljø, automatiseringsstrategi og værktøjer og risikoanalyse med en beredskabsplan.

At opsummere testplanen er en vision om, hvad du vil opnå, og teststrategien er en handlingsplan designet til at nå denne vision!

Jeg håber, at dette vil fjerne al din tvivl. James Bach har mere diskussion om dette emne her .

Process til at udvikle et godt teststrategidokument

Følg ikke bare skabelonerne uden at forstå, hvad der fungerer bedst for dit projekt. Hver klient har sine egne krav, og du skal holde dig til de ting, der fungerer perfekt for dig. Kopier ikke nogen organisation eller nogen standard blindt. Sørg altid for, om det hjælper dig og dine processer.

Nedenfor er en eksempelstrategiskabelon, der beskriver, hvad der skal dækkes i denne plan sammen med nogle eksempler for at illustrere, hvad der giver mening at dække under hver komponent.

Teststrategi i STLC:

STLC

(billede kilde )

sql scenariobaserede spørgsmål og svar

Fælles sektioner af teststrategidokument

Trin # 1: Omfang og oversigt

Projektoversigt sammen med oplysninger om, hvem der skal bruge dette dokument. Inkluder også detaljer som hvem der vil gennemgå og godkende dette dokument. Definer testaktiviteter og faser, der skal udføres med tidslinjer med hensyn til overordnede projekttidslinjer defineret i testplanen.

Trin # 2: Test tilgang

Definer testprocessen, testniveauet, roller og ansvar for hvert teammedlem.

For hver testtype defineret i testplan ( For eksempel, Enhed , Integration, System, Regression, Installation / afinstallation , Brugervenlighed, belastning, ydeevne og sikkerhedstest) beskriver, hvorfor det skal udføres sammen med detaljer som hvornår man skal starte, test ejer, ansvar, testtilgang og detaljer om automatiseringsstrategi og værktøj, hvis det er relevant.

I testudførelse er der forskellige aktiviteter som tilføjelse af nye defekter, defekt triage, defektopgaver, re-test, regressionstest og til sidst test sign-off. Du skal definere de nøjagtige trin, der skal følges for hver aktivitet. Du kan følge den samme proces, som fungerede for dig i dine tidligere testcyklusser.

En Visio-præsentation af alle disse aktiviteter inklusive et antal testere, og hvem der vil arbejde på, hvilken aktivitet der er meget nyttigt for hurtigt at forstå roller og ansvar i teamet.

For eksempel, defektstyringscyklus - nævn processen til at logge den nye defekt. Hvor skal man logge ind, hvordan man logger nye mangler, hvad skal defektstatus være, hvem skal udføre defekt triage, hvem tildeles defekter efter triage osv.

Definer også ændringsstyringsprocessen. Dette inkluderer definition af ændring af anmodning om ændring, skabelon, der skal bruges, og proces til håndtering af anmodningen.

Trin # 3: Test miljø

Opsætning af testmiljø skal skitsere information om et antal miljøer og krævet opsætning for hvert miljø. For eksempel, Et testmiljø for det funktionelle testteam og et andet for UAT-teamet.

Definer antallet af brugere, der understøttes i hvert miljø, adgangsroller for hver bruger, software- og hardwarekrav som operativsystem, hukommelse, ledig diskplads, antal systemer osv.

Definition af testdatakrav er lige så vigtigt. Giv klare instruktioner om, hvordan du gør det oprette testdata (generer enten data eller brug produktionsdata ved at maskere felter for privatlivets fred).

Definer sikkerhedskopiering af testdata og gendannelsesstrategi. Testmiljødatabasen kan komme i problemer på grund af uhåndterede forhold i koden. Jeg kan huske de problemer, vi stod over for på et af projekterne, da der ikke var defineret nogen database-backup-strategi, og vi mistede hele data på grund af kodeproblemer.

Sikkerhedskopierings- og gendannelsesprocessen skal definere, hvem der tager sikkerhedskopier, hvornår de skal tage en sikkerhedskopi, hvad der skal medtages i sikkerhedskopien, hvornår databasen skal gendannes, hvem der gendanner den, og de trin til datamaskering, der skal følges, hvis databasen gendannes.

Trin # 4: Testværktøjer

Definer teststyrings- og automatiseringsværktøjer, der kræves til testudførelse. For ydeevne, belastning og sikkerhedstestning beskrives testmetoden og de nødvendige værktøjer. Nævn, om det er open source eller kommercielt værktøj, og hvor mange brugere der understøttes på det, og planlæg derefter.

Trin # 5: Slip kontrol

Som nævnt i vores sidste UAT-artikel , kunne ikke planlagt frigivelsescyklus resultere i forskellige softwareversioner i test- og UAT-miljøer. Udgivelsesstyringsplan med korrekt versionshistorik vil sikre testudførelse af alle ændringer i den udgivelse.

For eksempel, Sæt build-styringsproces, som vil svare - hvor ny build skal gøres tilgængelig, hvor den skal implementeres, hvornår man skal hente den nye build, hvorfra man får produktionsbygningen, hvem giver opgaven, no-go-signalet til produktionsfrigivelse , etc.

Trin # 6: Risikoanalyse

Angiv alle de risici, du forestiller dig. Giv en klar plan for at afbøde disse risici og også en beredskabsplan, hvis du ser disse risici i virkeligheden.

Trin # 7: Gennemgang og godkendelser

Når alle disse aktiviteter er defineret i teststrategiplanen, skal den gennemgås for afmelding af alle enheder, der er involveret i projektledelse, forretningsteam, udviklingsteam og systemadministrationsteam (eller miljøledelse).

Resume af gennemgangsændringer skal spores i begyndelsen af ​​dokumentet sammen med godkendelsesnavn, dato og kommentar. Det er også et levende dokument, hvilket betyder, at dette kontinuerligt skal gennemgås og opdateres med forbedringerne af testprocessen.

Enkle tip til at skrive teststrategidokument

  1. Inkluder produktbaggrund i teststrategidokumentet. I det første afsnit i dit teststrategidokument svarer - Hvorfor interessenter vil udvikle dette projekt? Dette hjælper med at forstå og prioritere ting hurtigt.
  2. Liste over alle vigtige funktioner, du skal teste. Hvis du mener, at nogle funktioner ikke er en del af denne udgivelse, skal du nævne disse funktioner under 'Funktioner, der ikke skal testes'.
  3. Skriv testmetoden til dit projekt ned. Nævn klart hvilke typer test du skal gennemføre?
    dvs. funktionstest, UI-test, integrationstest, belastning / stresstest, sikkerhedstest osv.
  4. Besvar spørgsmål som hvordan du skal udføre funktionel test? Manuel eller automatiseringstest? Skal du udføre alle testsager fra dit testhåndteringsværktøj?
  5. Hvilket fejlsporingsværktøj skal du bruge? Hvad vil processen være, når du finder en ny fejl?
  6. Hvad er dine kriterier for testindgang og udgang?
  7. Hvordan vil du spore dine testfremskridt? Hvilke metrics skal du bruge til at spore testafslutning?
  8. Opgavefordeling - Definer roller og ansvar for hvert teammedlem.
  9. Hvilke dokumenter producerer du under og efter testfasen?
  10. Hvilke risici ser du i testafslutningen?

Konklusion

Teststrategi er ikke et stykke papir. Det afspejler hele QA-aktiviteter i softwaretestens livscyklus. Henvis dette dokument fra tid til anden i testudførelsesprocessen, og følg planen indtil softwareudgivelsen.

Når projektet nærmer sig udgivelsesdatoen, er det ret nemt at skære på testaktiviteter ved at ignorere det, du har defineret i teststrategidokumentet. Men det tilrådes at diskutere med dit team, hvorvidt det at reducere en bestemt aktivitet vil hjælpe med frigivelse eller ej, uden nogen potentiel risiko for større problemer efter frigivelsen.

De fleste af de agile teams skærer ned på at skrive strategidokumenter, da teamfokus er på testudførelse snarere end dokumentation. Men at have en grundlæggende teststrategiplan hjælper altid med at tydeligt planlægge og afbøde de risici, der er involveret i projektet. Agile teams kan registrere og dokumentere alle aktiviteter på højt niveau for at fuldføre testudførelsen til tiden uden problemer.

Jeg er sikker på at udvikle en god teststrategiplan og forpligte mig til at følge den vil helt sikkert forbedre testprocessen og kvaliteten af ​​softwaren. Det ville være en fornøjelse, hvis denne artikel inspirerer dig til at skrive en teststrategiplan til dit projekt!

Hvis du kan lide dette indlæg, så overvej at dele det med dine venner!

=> Besøg her for en komplet testplan-tutorial-serie

Anbefalet læsning

^