Meny

Hur skiljer sig testplaneringen för manuella och automatiseringsprojekt?

how does test planning differ

Prova Vårt Instrument För Att Eliminera Problem

Vi är alla överens om att automatiseringsprojekt är annorlunda än manuella testprojekt. Även om autonoma automatiseringsprojekt inte existerar (eller inte borde existera helst), hanteras både manuella och automatiseringsprojekt olika när de planeras.

En mix som planeras av projektet kommer oundvikligen att genomföras; detta påverkar inte bara det aktuella projektet och kastar en skugga på individens förmåga, utan kan också leda till förlust av förtroende för teamet för klienten / ledningen - vilket påverkar ytterligare affärer. Jag skulle hellre säga att vi testare är säkra än ledsna.

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

Testplanering

En bra Dilbert-serie om planering:

projektplanering dilbert

Innan vi går vidare vill jag fastställa vad den här artikeln INTE kommer att handla om.

# 1) Detta är inte en fördjupad diskussion om automatiseringsramar. Olika projekt använder olika ramar beroende på vilken typ av AUT, arkitektur, komplexitet, teamets expertis etc.

Informationen om ramarna finns på länkarna nedan:

Testautomatiseringsramar del 1 och del 2 .

#två) Det handlar inte heller om mall, format eller skapande av en Testplan dokument . Vi kommer att ta itu med övervägandena för dokumentationen för ett automatiseringsprojekt, mer i linje med en genomförbarhetsanalys.

# 3) Detta är inte heller specifikt verktyg. Varje aktivitet i SDLC tar tid, ansträngning, infrastruktur - med andra ord- PENGAR.

För ett manuellt testprojekt är de kostnadskrävande faktorerna:

  • människor
  • Verktyg - Test / Defekthantering
  • Infrastruktur - miljö
  • Tid
  • Träning

För ett automatiseringsprojekt behöver det utöver ovanstående poster utgifter för:

  • Automationsverktyg
  • Tillägg för integration av testhanteringsverktyg
  • Tillägg för att stödja AUT (som SAP, Oracle, etc)
  • Ställa in ram
  • Verktygsspecifik utbildning

Med tanke på dessa omständigheter, beror framgången för ett automatiseringsprojekt på hur bra du har skrivit koden, hur många återanvändningsbara komponenter du skrev eller i hur få kodrader du uppnått önskat resultat?

Låt bli.

Det finns en enda fråga som avgör framgången - ”Kan du generera en bättre ROI (Return on Investment) jämfört med den manuella rutten”? - Om inte omedelbart, så småningom.

Om svaret på denna fråga är ”NEJ” har du planerat Automation-projektet felaktigt.

Normalt har en testplan följande avsnitt. Vi kommer att diskutera var och en av dem med fokus på automatiseringsspecifika aspekter att beakta:

plan för automatiseringstest

Automation Testing Test Plan Sections

Sektion 1:Omfattning

  • Välj testfall / scenarier som ska regresseras om och om igen över flera cykler.
  • Ibland behöver de enklaste testfallet massor av komplicerade lösningar för att automatiseras. Om dessa bara är för engångsbruk är det uppenbarligen inte meningsfullt. Återanvändbarhet bör vara ditt fokus.
  • Automation Testing utför inte / kan inte utforska testning.

Sektion 2: Teststrategi

  • Detta avsnitt kallas Framework in the Automation-världen. Vissa ramar är extremt utmanande att skapa och är också effektiva - men tid, ansträngning och kompetens är krävande. Leta alltid efter en mellanväg och gör det bästa du kan utan att äventyra resursutnyttjandet.
  • Beslut om kodning av bästa metoder som ska användas, namngivningskonventioner, platser för testtillgångar som ska lagras, formatet för testresultat etc. för att upprätthålla enhetlighet och öka produktiviteten.

Avsnitt 3:Resurser / roller och ansvar

  • Det första steget i den här riktningen är att förstå teamets förmåga och förutse innan Automation kommer in i bilden. Detta hjälper dig att välja ett team som passar både automatiserings- och manuella testbehov. Välj också personer som har rätt attityd - de tror inte att manuell testning är under deras storlek.
  • Välj ett team som är väl insatt i AUT, Test Management, Defect Management och andra SDLC-aktiviteter
  • Avsnitt 1: Omfattning

Avsnitt # 4:Verktyg

Välj automatiseringsverktyg baserat på följande regler:

  • Har företaget redan licenser för ett visst verktyg, försök se om du kan använda det
  • Leta efter verktyg med öppen källkod (men tillförlitlig)
  • Känner lagmedlemmarna verktyget redan eller behöver vi ta med någon ny? Eller träna de befintliga?

Avsnitt 5: Scheman

  • Inkludera tid för kodgenomgångar och inspektion av Automation-skript
  • Underhåll skripten i rätt tid. Om du skapar en kod som du inte ska använda de närmaste sex månaderna, se till att regelbundet underhålla den för att minska risken för misslyckande.

Avsnitt 6:Miljö

  • Målmiljön som din AUT ska köras och det automatiseringsverktyg som du vill använda ska vara kompatibla. Detta är en av de faktorer som ska betraktas som förlicenser för verktyget.
  • Analysera också om resten av Hanteringsverktyg på plats och automatiseringsverktyget du försöker ta med är sammankopplingsbara för ytterligare fördelar.

Avsnitt 7:Leveranser

  • Dina testskript är dina leveranser. Men inte alla är automatiserade / programmeringsspråk kunniga. Så planera att skapa ett 'How-to' -dokument som hjälper nuvarande användare och framtida teammedlemmar att kunna förstå detta manus även när du inte är i närheten.
  • Inkludera kommentarer i ditt manus också.

Avsnitt 8: Risker

Om du ska föreslå en automatiseringslösning, var noga med att välja kostnadseffektiva verktyg och lösningar för att se till att Automation-strävan inte belastar projektet.

Det är viktigt att ställa förväntningen på att ROI för ett automatiseringsprojekt inte kan vara positivt omedelbart utan kan ses tydligt under långa perioder.

Därför, om du föreslår att ett system automatiseras, välj det som är

  • Stabilt och inte för mycket underhåll
  • Har utrymme för stora regressionssviter
  • Har inte för mycket manuellt ingripande eller beror inte på människans intuition

Avsnitt 9:Testdata

  • Ta hänsyn till säkerhetsaspekterna av data
  • Hårdkod inte testdata i skripten. Detta leder bara till för mycket skriptunderhåll och kan orsaka fel under modifieringen.
  • Var väldigt specifik. För ett manuellt teststeg - ”ange förnamn” kan du säga ange valfritt 5 teckennamn. Under testningen kan en testare skriva 'Swati' eller 'Seela' eller något annat. Men för ett verktyg kan det inte göra sådana antaganden. Ange därför exakta värden.

Avsnitt # 10:Rapporter / resultat

  • Skriptkörningsresultat är också tekniska och kanske inte lätt kan förstås av resten av lagen. Planera att skriva detaljerade resultat till anteckningsblock eller excel-ark som en ytterligare åtgärd.
  • Detaljerade ramdokument, granskningsresultat, felrapporter, exekveringsstatusrapporter förväntas också.

Vi som automationsentusiaster kanske tror att kunder / ledning inte enkelt köper automatiseringsförslagen.

c ++ -sorteringsalgoritm

Men när vårt slutmål är att maximera avkastningen genom automatisering, är vi i perfekt harmoni med ledningens / kundens mål också. Detta kommer att säkerställa att vi inte bara kommer att automatisera vårt projekt utan kommer att kunna göra det med mycket samtycke, samarbete och spänning.

Planering och noggrann analys av alla faktorer som anges ovan kan vara vår allierade genom denna resa. Återigen betyder ROI allt.

Det här inlägget är skrivet av STH-författarens teammedlem Swati Seela.

Har du frågor eller saker att diskutera? Skicka gärna in kommentarerna nedan.

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

Rekommenderad läsning

^