Meny

Praktisk programvarutestning av QA-processflöde (krav att släppas)

practical software testing qa process flow

Prova Vårt Instrument För Att Eliminera Problem

En fullständig översikt över QA-programvarutestningsprocessflöde från helhet till slut:

Obs! Vi publicerar det här användbara inlägget på nytt med uppdaterat innehåll.

Jobbet som professionell programvarutestning är inte lätt. Den är fylld med utmaningar, vilket också är lika krävande. Testare ska vara uppmärksamma och entusiastiska i varje fas av applikationens livscykel.

Även om det finns utmaningar finns det också flera enorma möjligheter att lära sig och utforska de olika aspekterna av testmetoder, processer och naturligtvis programvaran i detalj.

Testingenjörens roll börjar mycket tidigt. Och direkt från konceptualiseringen av projektet är testare involverade i diskussioner med produktägaren, projektledaren och olika intressenter.

Krav att släppa

Denna handledning om ”Software Testing Process flow” ger dig en fullständig översikt över de olika faserna i STLC tillsammans med de utmaningar som är inblandade och de bästa metoderna för att lösa dessa utmaningar på ett lättförståeligt sätt.

Vad du kommer att lära dig:

Krav att släppa - En fullständig översikt

Programvarutestning Livscykel

Direkt från krav till frigivning förklaras varje fas tydligt. Låt oss ta en titt på dem i detalj.

# 1) Krav

Ett projekt kan inte starta utan ett tydligt krav. Detta är den mest avgörande fasen där idéer måste skrivas i ett välförståeligt och formaterat dokument. Om du är en del av projektet där du deltar i kravuppsamlingsfasen, anser dig själv lycklig.

program som använder c ++

Undrar varför? Det beror på att du bevittnar ett projekt som görs från grunden. Även om det är stolt över att vara sedan starten, kommer det också med vissa ansvarsområden och utmaningar.

Utmaningar

Man kan inte föreställa sig alla kraven för att samlas i ett enda sammanträde. Var tålamod nog.

Många diskussioner kommer att hända, varav några helt enkelt är irrelevanta för ditt projekt men även då kan de innehålla viktig information för ditt projekt. Ibland kan diskussionshastigheten överstiga dina förståelsefunktioner eller så skulle du helt enkelt inte uppmärksamma produktägaren.

Bilden nedan belyser de viktiga stegen som är involverade i kravinsamlingen:

Krav Livscykel

Varje information som saknas har en enorm inverkan på projektets övergripande förståelse och testning. För att övervinna detta är här några bästa metoder som bör följas under denna fas.

Bästa praxis

  • Håll ditt sinne öppet och var uppmärksam på varje ord från produktägaren.
  • Lyssna inte bara, rensa ditt tvivel hur liten det verkar vara.
  • Använd alltid anteckningsböcker för snabb anteckningsbok. Du bör använda en bärbar dator, bara om du verkligen kan skriva med en rättvis hastighet.
  • Upprepa meningarna och få dem klargjorda från PO som du tycker är vad du förstod.
  • Rita blockdiagram, länktext etc. för att göra kraven tydligare vid en senare tidsperiod.
  • Om lagen är på olika platser, försök att göra det till en WebEx eller liknande inspelning. Det hjälper alltid när du är osäker efter att diskussionerna är över.

Även om det inte finns någon separat vägg som sådan för varje fas, ändras kraven även mycket sent i utvecklingen. Så tanken är att ta det mesta av kravet och dokumentera detta ordentligt.

När det har dokumenterats med alla nödvändiga punkter, distribuera och diskutera alla intressenter så att alla förslag eller ändringar fångas tidigt och innan de går vidare är alla på samma sida.

# 2) Teststrategi

Testare ska komma ut med en teststrategi som inte bara räcker för att testa programvaran bättre utan också bör ge förtroende för alla intressenter när det gäller produktens kvalitet.

Teststrategi

Utmaningar

Den viktigaste aspekten av denna fas är att skapa en strategi som när man arbetar med den ska leverera en mjukvaruprodukt som är felfri, hållbar och accepterad av slutanvändarna.

Teststrategier är något du inte kommer att ändra varannan dag. I vissa fall måste du också diskutera dina teststrategier med kunderna. Så denna del bör hanteras med stor vikt.

Bästa praxis

  • Här är några av de bästa metoderna, som när de följs kan ge dig stor lättnad och resultera i smidiga tester.
  • Gå igenom kravdokumentet en gång till. Markera importpunkterna med hänsyn till miljön i målprogramvaran.
  • Gör en lista över miljöer där programvaran faktiskt kommer att distribueras.
  • Miljöer kan förstås som en typ av operativsystem eller mobila enheter.
  • Om Windows är operativsystemet listar du alla versioner av fönstret där du ska testa din programvara. Om versionerna dvs. Windows 7, Windows 10 eller Windows Server (er) är fortfarande inte definierade i kravdokumentet, då är det hög tid när dessa ska diskuteras.
  • På en liknande anmärkning, få målwebbläsare med de versioner som diskuterats och dokumenterats om AUT är ett webbaserat system.
  • Gör en lista över alla program från tredje part som applikationen behöver (om det behövs / stöds). Dessa kan inkludera Adobe Acrobat, Microsoft Office, alla tillägg etc.

Här är tanken bakom att hålla alla nödvändiga och nödvändiga plattformar, enheter och programvaror som vår applikation kommer att behöva fungera framför oss så att en heltäckande strategi kan formuleras.

Nedanstående figur hjälper dig att förstå översikten över teststrategi om du arbetar med ett smidigt projekt:

Teststrategi

# 3) Testplanering

När testarna är beväpnade med all information om AUT är planeringsfasen där strategin implementeras.

Precis som en teststrategi är testplanering också en avgörande fas.

Testplan

Utmaningar

Eftersom AUT: s framgång (eller misslyckande) till stor del beror på hur testerna utfördes, blir denna fas en viktig aspekt av hela testets livscykel. Varför? Eftersom en del av testningen definieras i denna fas.

För att klara några utmaningar kan dessa bästa metoder verkligen vara till hjälp.

Bästa praxis

  • Tänk alltid på att inte lämna någon sten orörd när det gäller att testa din ansökan.
  • Det är dags att formulera en teststrategi.
  • Skapa en matris av miljön så att programvaran testas på alla plattformar.
  • Liksom, Windows 10 + Internet Explorer 11+ Windows Office 2010+.
  • Liksom Android 4.2.2+ Chrome-webbläsare.
  • Om din applikation fungerar med flera databaser (om dokumenterad), behåll databaserna (MySQL, Oracle, SQLServer) i testmatrisen på ett sådant sätt att de är för integrerade med vissa tester.
  • Konfigurera testmaskiner i enlighet med detta och namnge dem som SetUp1, SetUp2, etc.
  • SetUp1 har Windows 7+ IE 10+ Office 2007+.
  • SetUp2 kan ha Windows 10+ IE Edge + Office 2013+.
  • SetUp3 kan ha en Android-telefon med din .apk-fil installerad.
  • Grattis! Din testinställning är klar och du har också inkluderat alla möjliga kombinationer av plattformar som din applikation kommer att arbeta med.

# 4) Testning

Hitta buggar

Slutligen är din applikationsbyggnad ute och du är redo att hitta buggar! Nu är det dags att arbeta med testplanering och hitta så många buggar som möjligt. Det kommer att finnas några faser däremellan om du arbetar i en smidig miljö, följ bara dessa scrummetoder.

Nedanstående diagram visar kategoriseringen av olika testtyper:

Typer av testning

Utmaningar

Testning är en besvärlig process som i sig är felbenägen! Man hittar många utmaningar när man testar en applikation. Nedan följer några bästa metoder för att rädda.

Bästa praxis

Muntra upp! Du försöker hitta fel i koden. Du måste vara uppmärksam på programvarans övergripande funktion.

  • Det är alltid tillrådligt att titta på applikationen med ett nytt utseende, utan att gå igenom testfall.
  • Följ navigationsvägen för din programvara (AUT).
  • Bli bekant med AUT.
  • Läs nu testfallet (Alla) för en viss modul (kanske efter eget val).
  • Gå nu till AUT och matcha resultaten med de som nämns i det förväntade avsnittet i testfallet.
  • Tanken bakom detta är att testa alla nämnda funktioner på varje plattform som stöds.
  • Anteckna varje avvikelse hur trivial den än verkar vara.
  • Skriv ned stegen för hur du når någon avvikelse, tar skärmdumpar, fångar felloggar, serverloggar och annan stödjande dokumentation som kan bevisa att det finns fel.
  • Tveka inte att fråga. Även om du har kravdokumentet kommer det att finnas tider när du kommer att vara i tvivel.
  • Kontakta utvecklarna (om de sitter bredvid dig eller om de kan nås) i tvivel innan du når produktägaren. Förstå utvecklarens perspektiv på hur programvaran fungerar. Förstå dem. Om du anser att denna implementering inte stämmer överens med kravet, informera testchefen.

# 5) Före släpp

Innan vi släpper ut någon produkt på marknaden måste produktens kvalitet säkerställas. Programvara utvecklas en gång men de testas faktiskt tills de byts ut eller tas bort.

Utmaningar

Programvaran måste testas noggrant för många av dess parametrar.

Parametrarna kanske inte är begränsade till:

  • Funktionalitet / beteende.
  • Prestanda.
  • Skalbarhet.
  • Kompatibel med nämnda plattformar.

Utmaningen är också att förutsäga framgångsgraden för en applikation som beror på många iterationer av de utförda testerna.

Bästa praxis

  • Se till att alla funktioner på alla plattformar testas.
  • Markera de områden som inte testats eller det som behöver mer testansträngningar.
  • Spara en matris av alla testresultat innan de släpps. Testmatrisen ger en övergripande bild av produktens stabilitet. Det kommer också att hjälpa ledningen att ringa på släppdatum.
  • Ge dina input / förslag till teamet om dina erfarenheter när du testar produkten.
  • Din input som betraktar dig själv som slutanvändare kommer att gynna programvaran i stort.
  • På grund av tidsbesvär eller någon annan sådan situation missar vi antingen några tester eller går inte djupt in i detta. Tveka inte att berätta teststatus för din chef.
  • Presentera applikationens hälsokort för intressenterna. Hälsokort ska ha ett antal av alla loggade, öppna, stängda, intermittenta defekter med deras svårighetsgrad och prioritet.
  • Utarbeta ett släppdokument och dela detta över hela teamet.
  • Arbeta med utgivningsdokumentet.
  • Förbättra de områden som föreslås av ledningen / teamet.

Nedanstående bild visar livscykelkartan för programutgivningen:

Före släpp

# 6) Släpp

Slutligen kommer tiden när vi måste leverera produkten till dess avsedda användare. Vi som team har alla arbetat hårt för att logga ut produkten och låta programvaran hjälpa sina användare.

Utmaningar

Programvarutestingenjörer är främst ansvariga för lanseringen av programvara. Den här aktiviteten kräver ett processorienterat arbetsflöde. Här är några av de bästa metoderna som är involverade i denna fas.

Bästa praxis

  • Kom alltid ihåg att du inte arbetar med utgivningsdokumentet datumet för FAKTISK RELEASE.
  • Planera alltid utgivningsaktiviteten före det faktiska utgivningsdatumet.
  • Standardisera dokumentet enligt företagets policyer.
  • Ditt release-dokument bör försöka skapa positiva förväntningar från programvaran.
  • Nämn alla programvara och hårdvarukrav som är specifika för deras versioner tydligt i dokumentet.
  • Inkludera alla öppna defekter och deras svårighetsgrad.
  • Dölj inte större påverkade områden på grund av öppna defekter. Ge dem en plats i släppdokumentet.
  • Få dokumentet granskat och signerat digitalt (kan variera enligt företagets policy).
  • Var säker och skicka släppdokumentet tillsammans med programvaran.

QA-testprocess på ett riktigt projekt - Metod för vattenfall

Jag fick en intressant fråga från en läsare, Hur utförs tester i ett företag, dvs. i en praktisk miljö?

De som bara går ut ur college och börjar söka jobb har denna nyfikenhet - hur skulle den faktiska arbetsmiljön i ett företag vara?

Här har jag fokuserat på den faktiska arbetsprocessen för Programvarutestning i företagen .

Faktisk testprocess i företag

Närhelst vi får något nytt projekt är det ett inledande projektmöte. I det här mötet diskuterar vi i grunden vem som är klienten? vad är projektets varaktighet och när levereras det? Vem är alla inblandade i projektet, dvs chef, Tech leads, QA leads, utvecklare, testare, etc.?

Från SRS (programvarukravspecifikation) utvecklas projektplanen. Testarnas ansvar är att skapa en programvarutestplan från denna SRS och projektplan. Utvecklare börjar koda från designen. Projektarbetet är indelat i olika moduler och dessa projektmoduler fördelas mellan utvecklarna.

Under tiden är testarens ansvar att skapa ett testscenario och skriva testfall enligt de tilldelade modulerna. Vi försöker täcka nästan alla funktionella testfall från SRS. Uppgifterna kan underhållas manuellt i vissa excel-testfallsmallar eller bug tracking-verktyg.

När utvecklare avslutar de enskilda modulerna tilldelas dessa moduler testarna. Rökprovning utförs på dessa moduler och om de misslyckas med detta test tilldelas modulerna till respektive utvecklare för en fix.

För godkända moduler utförs manuell testning från de skriftliga testfallet. Om något fel hittas som tilldelas modulutvecklaren och loggas in i bug tracking tool . På bug fix fixar en testare buggenverifiering och regressionstestning av alla relaterade moduler. Om bug passerar verifieringen markeras den som verifierad och markerad som stängd. I annat fall upprepas ovannämnda buggcykel. (Jag kommer att täcka buggens livscykel i ett annat inlägg)

Olika tester utförs på enskilda moduler och integrationstester på modulintegration. Dessa tester inkluderar kompatibilitetstest, dvs testapplikationer på olika hårdvaror, OS-versioner, programvaruplattformar, olika webbläsare etc.

Last- och stresstester utförs också enligt SRS. Slutligen utförs systemtestning genom att skapa en virtuell klientmiljö. När alla testfall har utförts, utarbetas en testrapport och beslutet att släppa produkten!

Steg som krävs för att släppa

Nedan följer detaljerna i varje teststeg som utförs i varje programvarukvalitet och testcykel som specificeras av IEEE- och ISO-standarder.

# 1) SRS granskning : Granskning av specifikationerna för programvarukrav.

# 2) Mål är inställda på större utgåvor.

# 3) Måldatum planeras för utgåvorna.

# 4) Detaljerad projektplan är byggt. Detta inkluderar beslutet om designspecifikationer.

# 5) Utveckla testplan bygger på designspecifikationer.

# 6) Testplan: Detta inkluderar mål, den metod som antagits under testningen, funktioner som ska testas och inte testas, riskkriterier, testschema, stöd för flera plattformar och resursallokering för testning.

# 7) Testspecifikationer: Detta dokument innehåller tekniska detaljer (programvarukrav) som krävs före testet.

# 8) Skrivning av testfall

  • Rök ( BVT ) testfall
  • Sanity Test-fall
  • Fall för regressionstest
  • Negativa testfall
  • Utökade testfall

# 9) Utveckling: Moduler utvecklas en efter en.

# 10) Bindande installatörer: Installatörer bygger på den enskilda produkten.

manuella testintervjufrågor för 5 års erfarenhet

#elva) Byggprocedur : En byggnad inkluderar installatörer av tillgängliga produkter - flera plattformar.

# 12) Testning: Smoke Test (BVT): Grundläggande applikationstest för att fatta beslut om ytterligare testning.

  • Test av nya funktioner
  • Cross-webbläsare och plattformstestning
  • Stresstestning och minnesläckagetestning.

# 13) Testöversiktsrapport

# 14) Kodfrysning

  • Inga nya funktioner läggs till just nu.

# 15) Testning: Test av byggnad och regression.

# 16) Beslut att släppa produkten.

# 17) Scenario efter släpp för ytterligare mål.

Detta var en sammanfattning av en faktisk testprocess i en företagsmiljö.

Slutsats

Jobbet som programvarutestare är fullt av utmaningar, men ändå roligt. Detta är för någon som är lika passionerad, motiverad och full av entusiasm. Att hitta fel hos någon är inte alltid ett enkelt jobb! Detta kräver mycket färdigheter och ett tjurfäste för defekterna.

Förutom alla egenskaper bör en testare också vara processorienterad. Liksom alla andra industrier är projekt inom IT alltför bearbetade i faser, där varje fas har några väldefinierade mål. Och varje mål har ett väldefinierat acceptanskriterium. En testingenjör måste bära många massor av programvarukvalitet på sina axlar.

När de arbetar i någon fas av programvara, ska testare följa de bästa metoderna och bör anpassa sig till processen som är involverad i respektive faser. Att följa de bästa metoderna och den välformulerade processen hjälper inte bara till att underlätta testarnas arbete, det hjälper också till att säkerställa kvaliteten på programvaran.

Har du varit en del av någon av ovanstående faser? Dela gärna dina erfarenheter nedan.

Rekommenderad läsning

^