Meny

Hvordan er testplanlegging forskjellig for manuelle og automatiseringsprosjekter?

how does test planning differ

Prøv Instrumentet Vårt For Å Eliminere Problemer

Vi er alle enige om at automatiseringsprosjekter er forskjellige fra manuell testing. Selv om autonome automatiseringsprosjekter ikke egentlig eksisterer (eller ikke burde eksistere ideelt), blir både manuelle og automatiseringsprosjekter behandlet annerledes når de planlegges.

En blanding som planlagt prosjekt uunngåelig får blir utført; dette påvirker ikke bare det nåværende prosjektet og kaster en skygge for individets evner, men kan også føre til tap av tillit til teamet for klienten / ledelsen - noe som påvirker videre virksomhet. Jeg vil heller si at vi testere er trygge enn beklager.

=> Klikk her for fullstendig testplanopplæringsserie

Testplanlegging

En god Dilbert-tegneserie om planlegging:

prosjektplanlegging dilbert

Før vi går videre, vil jeg fastslå hva denne artikkelen IKKE skal handle om.

#1) Dette er ikke en grundig diskusjon av automatiseringsrammer. Ulike prosjekter bruker forskjellige rammer, avhengig av arten av AUT, arkitektur, kompleksitet, teamets ekspertise osv.

Informasjonen om rammene finner du på linkene nedenfor:

Test automatiseringsrammer del 1 og del 2 .

#to) Dette handler heller ikke om mal, format eller opprettelse av en Testplan dokument . Vi skal ta forutgående dokumentasjonshensyn for et automatiseringsprosjekt, mer i tråd med en gjennomførbarhetsanalyse.

# 3) Dette er heller ikke verktøy spesielt. Hver aktivitet i SDLC tar tid, krefter, infrastruktur - med andre ord - PENGER.

For et manuelt testprosjekt er de kostnadskrevende faktorene:

  • Mennesker
  • Verktøy - Test / Feilbehandling
  • Infrastruktur - miljø
  • Tid
  • Opplæring

For et automatiseringsprosjekt, i tillegg til de ovennevnte postene, trenger det utgifter til:

  • Automatiseringsverktøy
  • Tillegg for integrering av Test Management-verktøy
  • Tillegg for å støtte AUT (som SAP, Oracle, etc)
  • Rammeverk satt opp
  • Verktøysspesifikk trening

Gitt disse omstendighetene, avhenger suksessen til et automatiseringsprosjekt av hvor godt du har skrevet koden, hvor mange gjenbrukbare komponenter du skrev eller i hvor få kodelinjer du oppnådde ønsket resultat?

Ikke.

Det er ett og det eneste spørsmålet som bestemmer suksessen - “Er du i stand til å generere en bedre avkastning (Return on Investment) sammenlignet med den manuelle ruten”? - Hvis ikke umiddelbart, til slutt.

Hvis svaret på dette spørsmålet er 'NEI', har du planlagt Automatiseringsprosjektet feil.

Normalt har en testplan følgende seksjoner. Vi skal diskutere hver enkelt av dem med fokus på automatiseringsspesifikke aspekter å vurdere:

automatiseringstestplan

Automasjonstesting Testplanavsnitt

Seksjon 1:omfang

  • Velg testsaker / scenarier som skal regreseres om og om igjen over flere sykluser.
  • Noen ganger trenger de enkleste testtilfellene mange kompliserte løsninger for å bli automatisert. Hvis disse bare er til engangsbruk, gir det åpenbart ikke mening. Gjenbrukbarhet bør være ditt fokus.
  • Automatiseringstesting utfører ikke / kan ikke utforskende testing.

Seksjon 2: Teststrategi

  • Denne delen er referert til som Framework in the Automation world. Noen rammer er ekstremt utfordrende å lage og er også effektive - men tid, krefter og kompetanse er krevende. Se alltid etter en mellomvei og gjør det beste du kan uten å skade overutnyttelse av ressursene.
  • Bestem deg for koding av beste praksis som skal brukes, navngivningskonvensjoner, steder for testmateriell som skal lagres, formatet på testresultater osv. For å opprettholde ensartethet og øke produktiviteten.

Seksjon 3:Ressurser / roller og ansvar

  • Det første trinnet i denne retningen er å forstå teamets evner og forutse før omfanget av automatisering kommer inn i bildet. Dette vil hjelpe deg med å velge et team som passer både behovet for automatisering og manuell testing. Velg også folk som har riktig holdning - de tror ikke at manuell testing er under deres vekst.
  • Velg et team som er kjent med AUT, Test Management, Defect Management og andre SDLC-aktiviteter
  • Seksjon 1: Omfang

Seksjon 4:Verktøy

Velg automatiseringsverktøy basert på følgende regler:

  • Har selskapet allerede lisenser for et bestemt verktøy, prøv å se om du kan bruke det
  • Se etter verktøy med åpen kildekode (men pålitelig)
  • Kjenner teammedlemmene verktøyet allerede, eller trenger vi å hente inn noen nye? Eller trene de eksisterende?

Seksjon 5: Tidsplaner

  • Inkluder tid for gjennomgang av kode og inspeksjon av automatiseringsskriptene
  • Vedlikehold skriptene i tide. Hvis du lager et stykke kode som du ikke skal bruke de neste 6 månedene eller så, må du sørge for å vedlikeholde det med jevne mellomrom for å redusere sjansene for feil.

Seksjon 6:Miljø

  • Målmiljøet som AUT skal kjøre, og automatiseringsverktøyet du vil bruke, skal være kompatible. Dette er en av faktorene som skal betraktes som forhåndslisensiering av verktøyet.
  • Analyser også om resten av Administrasjonsverktøy på plass og automatiseringsverktøyet du prøver å få inn, kan kobles sammen for ekstra fordel.

Seksjon 7:Leveranser

  • Testskriptene dine er dine leveranser. Imidlertid er ikke alle automatiserings- / programmeringsspråklige. Så planlegg å lage et 'How-to' -dokument som vil hjelpe nåværende brukere og fremtidige teammedlemmer til å kunne forstå dette skriptet selv når du ikke er i nærheten.
  • Ta med kommentarer i skriptet ditt også.

Seksjon 8: Risiko

Hvis du skal foreslå en automatiseringsløsning, må du velge kostnadseffektive verktøy og løsninger for å sikre at Automation-arbeidet ikke belaster prosjektet.

Det er viktig å stille forventningen om at avkastning for et automatiseringsprosjekt ikke kan være positivt umiddelbart, men kan sees tydelig over lange perioder.

Derfor, hvis du foreslår å automatisere et system, velger du det som er

  • Stabil og ikke for mye vedlikehold
  • Har rom for enorme regresjonssuiter
  • Har ikke for mye manuell inngrep eller er ikke avhengig av menneskets intuisjon

Seksjon 9:Testdata

  • Ta hensyn til sikkerhetsaspektene til dataene
  • Ikke skriv noen testdata hardt inn i skriptene. Dette fører bare til for mye vedlikehold av skript og kan forårsake feil under modifikasjonen.
  • Vær veldig spesifikk. For et manuelt teststrinn - ‘skriv inn fornavnet’, kan du si å angi et hvilket som helst navn på 5 tegn. Under testingen kan en tester skrive 'Swati' eller 'Seela' eller noe annet. Men for et verktøy kan det ikke komme med slike antagelser. Oppgi derfor nøyaktige verdier.

Seksjon 10:Rapporter / resultater

  • Resultater for skriptutførelse er også tekniske og kan ikke forstås lett av resten av lagene. Planlegg å skrive detaljerte resultater til notisblokk eller excel-ark som et ekstra tiltak.
  • Det forventes også detaljerte rammedokumenter, gjennomgangsresultater, manglerapporter, utførelsesstatusrapporter.

Vi, som automatiseringsentusiaster, tror kanskje at klienter / ledelse ikke enkelt kjøper automatiseringsforslagene.

beste dvd ripper for Windows 7

Når vårt endelige mål er å maksimere avkastningen gjennom automatisering, er vi imidlertid i perfekt harmoni med ledelsen / klientens mål. Dette vil sikre at vi ikke bare kommer til å automatisere prosjektet vårt, men vil være i stand til å gjøre det, med mye samtykke, samarbeid og spenning.

Planlegging og grundig analyse av alle faktorene som er oppført ovenfor kan være vår allierte gjennom denne reisen. Igjen betyr ROI alt.

Dette innlegget er skrevet av STH-forfatterens teammedlem Swati Seela.

Har du spørsmål eller ting å diskutere? Legg gjerne inn kommentarene nedenfor.

=> Besøk her for komplett testplanopplæringsserie

Anbefalt lesing

^