Meny

Hvordan skrive teststrategidokument (med eksempel på teststrategimal)

how write test strategy document

Prøv Instrumentet Vårt For Å Eliminere Problemer

Lær å skrive teststrategidokument effektivt

En strategiplan for å definere testtilnærmingen, hva du vil oppnå og hvordan du skal oppnå det.

Dette dokumentet fjerner all usikkerhet eller vage kravuttalelser med en tydelig plan for tilnærming for å nå testmålene. Teststrategi er et av de viktigste dokumentene for QA-teamet.

=> Klikk her for fullstendig testplanopplæringsserie

Hvordan skrive teststrategidokument

Hva du vil lære:

Skrive et teststrategidokument

Teststrategi

Å skrive en teststrategi effektivt er en ferdighet hver tester skal oppnå i karrieren. Det initierer din tankeprosess som hjelper til med å oppdage mange manglende krav. Tenke- og testplanleggingsaktiviteter hjelper et team til å definere testomfanget og testdekning.

Det hjelper testledere å få klar oversikt over prosjektet når som helst. Sjansene for å gå glipp av testaktivitet er svært lave når det er en skikkelig teststrategi på plass.

Testutførelse uten plan fungerer sjelden. Jeg kjenner team som skriver strategidokument, men som aldri henviser det tilbake mens testutførelsen utføres. Teststrategiplanen må diskuteres med hele teamet slik at teamet vil være i samsvar med tilnærming og ansvar.

I stramme tidsfrister kan du ikke bare frafalle testaktiviteter på grunn av tidspress. I det minste må den gå gjennom en formell prosess før du gjør det.

Hva er en teststrategi?

Teststrategi betyr 'Hvordan skal du teste applikasjonen?' Du må nevne den nøyaktige prosessen / strategien du skal følge når du får søknaden for testing.

Jeg ser at mange selskaper følger teststrategimalen veldig nøye. Selv uten standardmal kan du holde dette teststrategidokumentet enkelt, men likevel effektivt.

Test strategi mot Testplan

Gjennom årene ser jeg mye forvirring mellom disse to dokumentene. Så la oss starte med grunnleggende definisjoner. Generelt sett spiller det ingen rolle hva som kommer først. Testplanleggingsdokumentet er en kombinasjon av strategi plugget sammen med en samlet prosjektplan. I følge IEEE Standard 829-2008 er strategiplanen et underelement i en testplan.

Hver organisasjon har sine egne standarder og prosesser for å vedlikeholde disse dokumentene. Noen organisasjoner inkluderer strategidetaljer i selve testplanen (her er et godt eksempel av denne). Noen organisasjoner viser strategi som et underavsnitt i en testplan, men detaljer skilles ut i forskjellige teststrategidokumenter.

Prosjektomfang og testfokus er definert i testplanen. I utgangspunktet handler det om testdekning, funksjoner som skal testes, funksjoner som ikke skal testes, estimering, planlegging og ressursadministrasjon.

Mens teststrategien definerer retningslinjer for testtilnærming som skal følges for å oppnå testmålene og utførelsen av testtyper som er definert i testplanen. Den tar for seg testmål, tilnærming, testmiljø, automatiseringsstrategi og verktøy, og risikoanalyse med en beredskapsplan.

Å oppsummere testplanen er en visjon om hva du vil oppnå, og teststrategien er en handlingsplan designet for å oppnå denne visjonen!

Jeg håper dette vil fjerne all tvilen din. James Bach har mer diskusjon om dette emnet her .

Prosess for å utvikle et godt teststrategidokument

Ikke bare følg malene uten å forstå hva som fungerer best for prosjektet ditt. Hver klient har sine egne krav, og du må holde deg til de tingene som fungerer perfekt for deg. Ikke kopier organisasjoner eller standarder blindt. Forsikre deg alltid om det hjelper deg og prosessene dine.

Nedenfor er en eksempelstrategimal som vil skissere hva som skal dekkes i denne planen sammen med noen eksempler for å illustrere hva som er fornuftig å dekke under hver komponent.

Teststrategi i STLC:

STLC

(bilde kilde )

gratis hurtigbokalternativ for småbedrifter

Vanlige seksjoner av teststrategidokument

Trinn 1: Omfang og oversikt

Prosjektoversikt sammen med informasjon om hvem som skal bruke dette dokumentet. Ta også med detaljer som hvem som vil gjennomgå og godkjenne dette dokumentet. Definere testaktiviteter og faser som skal utføres med tidslinjer med hensyn til overordnede prosjekttidslinjer definert i testplanen.

Trinn 2: Test tilnærming

Definer testprosessen, testnivået, roller og ansvar for hvert teammedlem.

For hver testtype definert i testplan ( For eksempel, Enhet , Integrasjon, System, Regresjon, Installasjon / avinstallasjon , Brukervennlighet, belastning, ytelse og sikkerhetstesting) beskriver hvorfor den skal utføres sammen med detaljer som når du skal starte, testeier, ansvar, testtilnærming og detaljer om automatiseringsstrategi og verktøy hvis aktuelt.

I testutførelsen er det forskjellige aktiviteter som å legge til nye feil, defekt triage, defektoppdrag, omprøving, regresjonstesting og til slutt testavlogging. Du må definere de nøyaktige trinnene som skal følges for hver aktivitet. Du kan følge den samme prosessen som fungerte for deg i dine forrige testsykluser.

En Visio-presentasjon av alle disse aktivitetene, inkludert en rekke testere, og som vil jobbe med hvilken aktivitet som er veldig nyttig for raskt å forstå roller og ansvar i teamet.

For eksempel, defekthåndteringssyklus - nevn prosessen for å logge den nye feilen. Hvor skal du logge inn, hvordan logge nye feil, hva som skal være defektstatusen, hvem som skal gjøre defekt-triage, hvem som skal tildele defekter etter triage etc.

Definer også endringsledelsesprosessen. Dette inkluderer å definere innlevering av endringsforespørsel, mal som skal brukes, og prosess for å håndtere forespørselen.

Trinn 3: Test miljø

Oppsett av testmiljø bør skissere informasjon om et antall miljøer og nødvendig oppsett for hvert miljø. For eksempel, Ett testmiljø for det funksjonelle testteamet og et annet for UAT-teamet.

Definer antall brukere som støttes i hvert miljø, tilgangsroller for hver bruker, programvare- og maskinvarekrav som operativsystem, minne, ledig diskplass, antall systemer osv.

Å definere krav til testdata er like viktig. Gi klare instruksjoner om hvordan du gjør det lage testdata (enten generere data eller bruke produksjonsdata ved å maskere felt for personvern).

Definer sikkerhetskopiering av testdata og gjenopprett strategi. Testmiljødatabasen kan komme i problemer på grunn av ubehandlede forhold i koden. Jeg husker problemene vi sto overfor i et av prosjektene da det ikke var definert noen sikkerhetskopistrategi for databaser, og vi mistet hele data på grunn av kodeproblemer.

Sikkerhetskopierings- og gjenopprettingsprosessen skal definere hvem som skal ta sikkerhetskopier når de skal ta en sikkerhetskopi, hva som skal tas med i sikkerhetskopien når databasen skal gjenopprettes, hvem som vil gjenopprette den og datamaskeringstrinn som skal følges hvis databasen gjenopprettes.

Trinn 4: Testverktøy

Definer testadministrasjons- og automatiseringsverktøy som kreves for utføring av test. For ytelse, belastning og sikkerhetstesting beskriver testtilnærmingen og verktøyene som kreves. Nevn om det er åpen kildekode eller kommersielt verktøy, og hvor mange brukere som støttes på det, og planlegg deretter.

Trinn 5: Slipp kontrollen

Som nevnt i vår siste UAT-artikkel , ikke-planlagt utgivelsessyklus kan resultere i forskjellige programvareversjoner i test- og UAT-miljøer. Utgivelsesadministrasjonsplan med riktig versjonshistorikk vil sikre testutførelse av alle modifikasjoner i den utgivelsen.

For eksempel, Angi byggeadministrasjonsprosess som vil svare - hvor nybygg skal gjøres tilgjengelig, hvor den skal distribueres, når skal nybygget hentes, hvorfra produksjonsbygget skal skaffes, hvem som skal gi sjansen, nei-signalet for produksjonsutgivelse , etc.

Trinn 6: Risikoanalyse

Oppgi alle risikoer du ser for deg. Gi en klar plan for å redusere disse risikoene, og også en beredskapsplan i tilfelle hvis du ser disse risikoene i virkeligheten.

Trinn 7: Gjennomgang og godkjenninger

Når alle disse aktivitetene er definert i teststrategiplanen, må den gjennomgås for avmelding av alle enheter som er involvert i prosjektledelse, forretningsteam, utviklingsteam og systemadministrasjonsteam (eller miljøledelse).

Sammendrag av gjennomgangsendringer bør spores i begynnelsen av dokumentet sammen med godkjenningsnavn, dato og kommentar. Det er også et levende dokument som betyr at dette bør gjennomgås kontinuerlig og oppdateres med forbedringene av testprosessen.

Enkle tips for å skrive teststrategidokument

  1. Ta med produktbakgrunn i teststrategidokumentet. I første avsnitt i teststrategidokumentet ditt svar - Hvorfor interessenter vil utvikle dette prosjektet? Dette vil bidra til å forstå og prioritere ting raskt.
  2. Liste opp alle viktige funksjoner du skal teste. Hvis du tror at noen funksjoner ikke er en del av denne utgivelsen, kan du nevne disse funksjonene under 'Funksjoner som ikke skal testes'.
  3. Skriv ned testtilnærmingen for prosjektet ditt. Nevn tydeligvis hvilke typer tester du skal gjennomføre?
    dvs. funksjonstesting, UI-testing, integrasjonstesting, belastning / stresstesting, sikkerhetstesting osv.
  4. Svar på spørsmål som hvordan du skal utføre funksjonstesting? Manuell eller automatiseringstesting? Skal du gjennomføre alle testsaker fra testadministrasjonsverktøyet ditt?
  5. Hvilket verktøy for feilsporing skal du bruke? Hva blir prosessen når du finner en ny feil?
  6. Hva er kriteriene for testoppføring og -utgang?
  7. Hvordan vil du spore testfremdriften din? Hvilke beregninger skal du bruke til å fullføre sporing av test?
  8. Oppgavefordeling - Definer roller og ansvar for hvert teammedlem.
  9. Hvilke dokumenter vil du produsere under og etter testfasen?
  10. Hvilke risikoer ser du når testen er ferdig?

Konklusjon

Teststrategi er ikke et stykke papir. Det er refleksjon av hele QA-aktiviteter i livssyklusen for programvaretesting. Henvis dette dokumentet innimellom i testutførelsesprosessen, og følg planen til programvareutgivelsen.

Når prosjektet nærmer seg utgivelsesdatoen, er det ganske enkelt å kutte på testaktiviteter ved å ignorere det du har definert i teststrategidokumentet. Men det er tilrådelig å diskutere med teamet ditt om å kutte ned på en bestemt aktivitet vil hjelpe til med utgivelse uten potensiell risiko for store problemer etter utgivelsen.

De fleste av de smidige teamene kutter ned på å skrive strategidokumenter, da teamfokus er på testutførelse i stedet for dokumentasjon. Men å ha en grunnleggende teststrategiplan hjelper alltid med å tydelig planlegge og redusere risikoen som er involvert i prosjektet. Agile team kan fange opp og dokumentere alle aktiviteter på høyt nivå for å fullføre testutførelsen i tide uten problemer.

Jeg er sikker på at det å utvikle en god teststrategiplan og forplikte meg til å følge den vil definitivt forbedre testprosessen og kvaliteten på programvaren. Det ville være en glede for meg hvis denne artikkelen inspirerer deg til å skrive en teststrategiplan for prosjektet ditt!

Hvis du liker dette innlegget, kan du vurdere å dele det med vennene dine!

=> Besøk her for komplett testplanopplæringsserie

Anbefalt lesing

^