Meny

7-stegs praktisk implementering av manuell testning innan produktionen släpps

7 step practical implementation manual testing before production release

Prova Vårt Instrument För Att Eliminera Problem

I det föregående inlägget i denna serie kring manuell testning försökte jag kasta så mycket ljus som möjligt på grunderna för manuell testning.

Om du saknade det, du kan läsa den här .

Jag hoppas att det lyckades med att ta dig så nära som möjligt till de svar du letade efter.

Skulle du i så fall inte älska att veta mer om det praktiska genomförandet av manuell testning, hur man blir mer bekant med det och hur man faktiskt startar en karriär i det?

Denna artikel kommer att belysa alla dessa aspekter.

Implementering av manuell testning

Låt oss börja.

Vad du kommer att lära dig:

Manuell testcykel

Att förstå Manuell testcykel eller Software Test Life Cycle (STLC), först och främst måste vi förstå Software Development Life Cycle (SDLC), som jag är säker på att du redan har en förståelse för.

Människor hänvisar till dem separat men är inte säkra på om de verkligen kan samexistera. De är så tätt integrerade med varandra. Tja, även dessa cykler har så många versioner av dem skapade och flytande i internetutrymmet, de varierar huvudsakligen beroende på vilken utvecklingsmodell som väljs.

Som de flesta av världen går smidig dessa dagar kommer jag att hålla mina saker förenklade runt Agile.

7 praktiska manuella teststeg innan produktionsutgåvan

Här går jag.

Kom ihåg att jag pratar om både SDLC och STLC.

# 1) Kravsamling

Kravsamlingsfas

Affärsanalytiker (person / team som ansvarar för kravsamling) dokumenterar kraven. De dokumenterar kraven, det är höjdpunkten, du kan bara fokusera på det. Där det är dokumenterat betyder mindre.

Människor använder vad som helst för att dokumentera dessa som passar dem men inte begränsat till traditionella plattformar som MS word doc, moderna plattformar som Jira / Rally och new age-verktyg som Trello.

# 2) Kravsdiskussion / delning

Kravdiskussionsfas

Business Analyst ska sedan dela dokumenterade krav med Development Team, Testing Team och UX-teamet (om det behövs). Detta händer vanligtvis via ett formellt möte där SPOC (Single Point Of Contacts eller ett helt team, det beror på det) från alla tre funktionerna uppfyller och förstår hela kravet.

I en hälsosam arbetskultur diskuteras kraven från alla vinklar och varje medlem av mötet kan ställa frågor och tvivel. När alla frågor har besvarats och nödvändig modifiering av kravet är klar kan denna fas betraktas som Klar. Återigen skiljer det sig från företag till företag vad man kallar just detta möte / steg och dess dokumentation.

Vidare läsning=> Hur man granskar SRS-dokument

När alla frågor har besvarats och nödvändiga ändringar i kravet är gjorda kan denna fas betraktas som Gjort .

Återigen skiljer det sig från företag till företag vad man kallar just detta möte / steg och dess dokumentation.

Till exempel, dokumentationen anropas eller bryts ner som SRS (System Requirement Specification), Requirement Document, Epic, User Story, Story point (möjligen, minsta kravenhet), etc. På samma linjer kallas detta möte där krav delas som Krav Diskussionsmöte, Grooming, Hålslagningsmöte, etc., jag hoppas att du får min poäng?

Att trycka på dessa terminologier så att du alltid kommer ihåg huvudidén oavsett olika namn.

Lägg upp detta möte två steg utlöses samtidigt, i ingen särskild ordning, se nästa två steg.

# 3) Designa

Utvecklingsteamet börjar med sin tekniska design så snart kraven diskuteras och när det inte finns några större pågående poäng. Vad som görs i denna fas skiljer sig igen från företag till företag.

Denna fas kan involvera men inte begränsas till följande uppgifter:

  • Beslut om utvecklingsstrategi
  • Förbereder designdokument
  • Designa flödesscheman
  • Uppskatta ansträngningarna
  • Ta reda på effekterna av detta nya krav på eventuell befintlig funktionalitet
  • Behöver lappa befintlig data etc.

UX-teamet kan också involvera sig i denna fas när det sker en ändring av användargränssnittet eller en ny skärm ska utvecklas. UX-teamet hjälper utvecklingsgruppen och testteamet med UI-prototyp för funktionaliteten / funktionen i diskussionen. Detta kan vara ett Photoshop-dokument, enkel bild, PowerPoint-presentation eller något annat som får utvecklingsgruppen att förstå hur skärmarna ska utvecklas.

Notera: Helst visas dessa skärmar eller åtminstone deras utkastversioner endast i diskussionssessionen Krav för att hjälpa teamet att bygga en bättre förståelse. Det märks till det ursprungliga kravet så att det kan hänvisas till när som helst.

# 4) Testscenario / design av testfall

Testscenario Utformningsfas

Parallellt med designfasen börjar testteamet med att bygga testscenarier och / eller testfall baserat på diskuterade krav. Huruvida testscenarier alltid skrivs först och sedan bryter in i testfall är något som återigen inte är konstant.

Enligt min mening, oavsett om du dokumenterar testscenarierna eller inte, finns de alltid före testfall. Testscenario är din punkt du kan säga, de guidar dig att driva ner saker ytterligare. När testfallets skrivning är över kan den delas med utvecklingsteamet för att ge dem en uppfattning om testomfånget och de kan också se till att den utveckling som har hänt eller händer uppfyller de skriftliga testfallet.

När testfallets skrivning är över kan den delas med utvecklingsteamet för att ge dem en uppfattning om testomfånget och de kan också se till att den utveckling som har hänt eller händer uppfyller de skriftliga testfallet.

Testfall när de är skrivna, granskas helst av en testledare eller kollega från många vinklar som:

  • Kravstäckning
  • Stavningsgrammatik
  • Testfallstandard (ingenting annat än en mall som ett team / företag följer)
  • Bakåtkompatibilitet
  • Plattformskompatibilitet
  • Testdataraferenser
  • Typer av riktade tester etc.

Vidare läsning=> Skriva testfall från SRS-dokument

Helst, efter granskning och nödvändig modifiering, skickas de vidare till utvecklingsteamet.

När jag sa 'när testfallet är slut' menade jag en gång 'alla testfall är skrivna baserat på fullständig kunskap om givna krav och möjliga testscenarier upptäckta fram till den aktuella tiden'. Det är nästan omöjligt att ha 100% testfallstäckning vid första gången.

Det kommer att finnas fel som du hittar i slumpmässiga (men avsedda) åtgärder, i rent slumpmässiga åtgärder (monkey testing) och i några sällsynta scenarier. Det finns chanser att du kommer att sakna några av dessa. Och någon gång kanske du missar även mycket grundläggande, trots allt är du mänsklig. Men här kan åtminstone en bra testfallskontroll och strukturerat sätt att skriva testfall rädda dig.

Oftare fortsätter en testare eller ett testteam att lägga till fler och fler testfall till den befintliga biten när de avslöjar sanningen eller tänker mer på kraven.

Nåväl, nu måste några av er tvivla på mina kunskaper om programvarutestning, eftersom något ord (som har blivit en norm i mjukvarutestning) inte används av mig ännu. Testplan, eller hur?

Låt mig säga något om detta. Jag tror starkt på behovet av det mesta av den information som nämns i testplanen, men att dokumentera dem alla på samma plats och göra den absolut obligatorisk är något jag tycker är diskutabelt.

Hur som helst, det är helt och hållet ett separat ämne att diskutera. Det är svårt att dela informationen 'passar alla' om detta men låt mig försöka.

Antingen du, du med din testledning eller din testledare förbereder testplan eller så dokumenterar du nödvändig information på olika platser.

Vidare läsning=> Hur man skriver testplan dokument

Information som bör frysas absolut i detta skede:

  • Testets omfattning: Krav, bakåtkompatibilitet, plattformar, enheter etc.
  • Person / Team som ska testa
  • Uppskattning av testansträngning
  • Begränsningar: Eventuella antaganden eller begränsningar accepterade i förväg.
  • Människor dokumenterar dessutom tillträdeskriterier, utgångskriterier, risker etc. som jag tror inte egentligen behöver nämnas separat eftersom det snarare borde vara en normal förståelse.
    • Inträdeskriterier (När ska man börja testa): Få startar när det finns testbar del av funktionaliteten tillgänglig för testning. Få väntar på att hela funktionaliteten ska kunna testas. När grundflödet har visat sig fungera startar testningen.
    • Utgångskriterier (När man ska stoppa): När det inte finns någon blockerare kan kritiska och större (utsatta för stötar) defekter vid testning i öppet steg stoppas. Eller i mitten, när det finns alltför många defekter som testas kan stoppas av lämpliga intressenter.
    • Risk : Affärsrisk eller funktionell risk om testning inte sker enligt den dokumenterade planen.

# 5) Utvecklingsfas

Programutvecklingsfas

Utvecklingsteamet efter designfasen börjar med faktisk utveckling och enhetstestning när och när de är färdiga med utvecklingen av testbara kravbitar. De kan vidarebefordra funktionaliteten för testning i bitar när den implementeras eller så kan de skicka hela funktionaliteten samtidigt.

I ett idealiskt scenario sker formell kodgranskning och testning av vita rutor innan den utvecklade funktionaliteten för testning förmedlas. helst bör utvecklingsgruppen också hänvisa till testfall som tillhandahålls av testteamet utöver krav och designdokument.

# 6) Testfas

Som nämnts tidigare skiljer sig början på denna fas från företag till företag, team till team.

Testteamet börjar testa antingen när det kan testas (något som kan testas oberoende) en del av hela kravet utvecklas eller när hela kravet utvecklas.

vid fel återupptas nästa i qtp

Låt mig gå vidare i denna fas och prata om de viktiga uppgifterna:

  • Testare / testteam börjar med testrundan (utforskande testning och utförande av skriftliga testfall) och loggningsfel
  • Utvecklingsteamet löser dem enligt prioritering.
  • Nybyggnad (kod) tas på den miljö där testningen sker
  • Lösta defekter verifieras sedan av Tester / Testing Team och markeras som Fixed
  • Denna cykel fortsätter tills utgångskriterierna har uppnåtts.
  • Observera att vid behov är defekter också markerade som Ogiltigt, Dubblett och kan också kategoriseras som Förbättringar.

En annan sak som skiljer sig från företag till företag är hur många testrundor som ska göras. Liksom i vissa fall sker den första testrundan på små funktionsdelar när de är färdiga, följt av en testrund från slut till slut i en annan miljö när alla krav har utvecklats. Men återigen har jag också hört talas om människor som gör tre ordentliga fullständiga testomgångar och fjärde som sanity / smoke-runda.

Den första agendan bakom att göra flera testrundor är att testa funktionaliteten i olika miljöer och andra för att göra end-to-end-testning när alla berättelsepunkter har utvecklats. Sanitetsrundan råkar vanligtvis få snabbt förtroende när alla berättelser i en release har utvecklats och testats oberoende.

Läs detaljerade steg=> Testutförandefas

# 7) Business Analyst (BA) Review

Affärsanalytiker granskar den frågade funktionen antingen genom att hänvisa till testresultat eller genom att hänvisa till testresultat plus att leka med applikationen för att få en verklig känsla. Detta steg igen utsätts för olika åtgärder mellan företag.

BA kan granska omfattningen av hela utgåvan på en gång eller i bitar. Beroende på samma sak kan det här steget komma före den slutliga sanity-testningen eller efter den slutliga sanity-testrundan av testteamet.

Ovan 7 steg händer för att alla användarberättelser / krav ska uppfyllas i synnerhet Release (Shipment). När alla dessa steg är slutförda för alla krav sägs utgivningen vara redo för leverans.

# 8) Leverans / släpp

Släppet är märkt som redo för leverans efter framgångsrik granskning av Business Analyst.

Rekommenderad läsning=> Testfrigöringsprocess

Typer av manuell testning (läs mänsklig)

Tja, om vi måste prata om övergripande typer av tester i antal så någonstans jag hittade över 100 typer av tester med olika namn . För att vara ärlig är jag inte tillräckligt smart för att förstå skillnaden mellan alla dessa typer (ordlek avsedd).

Det är enkelt och enkelt: Testa applikationens funktionalitet mot det givna kravet med mänskliga ansträngningar och intelligens. Det delas vidare in i några typer baserat på testets omfattning och agenda. Typer som anges i nästa punkt.

Det delas vidare in i några typer baserat på testets omfattning och agenda. Typer som anges i nästa punkt.

Om jag får göra det, låt mig tala några rader av Human Testing (som jag uppmuntrar varje testare att göra över bara manuell funktionstestning). Bli inte förvirrad, enligt min mening är manuell funktionell testning en delmängd av Human Testing. Eftersom det finns så många saker som bara mänskligt sinne kan göra.

Nedan är listan med några av de populära och viktiga testtyperna som kan kategoriseras i humantestning:

  • Manuell funktionstestning : Testa applikationens funktionalitet mot det givna kravet med mänskliga ansträngningar och intelligens. Ytterligare delas in i en hel del typer baserat på omfattning och dagordning för testning, som systemtestning, enhetstestning, rökprovning, sanitetstest, integrationstest, regressionstestning, UI-testning etc.
  • Prestandatester : Detta kategoriseras i icke-funktionell testning, eller hur? Men återigen är det människan som implementerar den, även om utförandet görs av antingen människa eller verktyg. Testaren bör åtminstone göra denna testning när det gäller svarstid (för att se om det är acceptabelt) om han inte ska använda något verktyg för lasttestning och allt.
  • Webbläsare / Testning av plattformskompatibilitet: Applikationen som testas ska se ut och fungera som förväntat (uppenbarligen kan det finnas en liten skillnad beroende på webbläsarmotor) över webbläsare och plattformar (eller enheter om det är en mobilapplikation).
  • Användbarhetstestning : Låt mig först och främst hålla med om att detta är ett stort ämne i sig och som vanligtvis ägs av specialister inom användbarhetstestning. Jag tror fortfarande att vi som testare åtminstone bör rapportera eller markera om vi hittar något som är mindre användbart, eller om vi bör dela vår åsikt.
  • Säkerhetstestning : Återigen mycket enorm testtyp och kräver naturligtvis mycket praktisk kunskap. Testaren bör försöka lära sig och utföra åtminstone grundläggande tester som URL-manipulering, skriptöverföring på plats, SQL-injektion, kapning av sessioner, etc. beroende på tillgänglig kunskap och där det är tillämpligt.
  • Multi-tenancy Testing: Om din applikation är flera hyresgäster, dvs. en enda instans som innehåller data från flera klienter, är denna testning ett måste. Oavsett vad som uttryckligen nämns i kraven bör detta göras. En kunds data som visas till en annan är ett slags utvecklings- och testbrott.

Notera: Ovanstående är mina personliga åsikter. Jag rekommenderar också att du tittar på den omfattande listan över testtyper för din kunskap och följer / använder dem om du finner det nödvändigt. Under årens lopp har jag förstått att oavsett om du använder något eller inte, du tror på något eller inte, så ska du fortfarande ha viss kunskap om begagnade begrepp inom ditt område.

Det är allt för den här delen. Tack för att du läste. Dela dina åsikter / feedback i kommentarer.

I nästa och sista del av detta handledning för manuell testning , Jag kommer att försöka hjälpa er alla med vilken förberedelse du ska göra om du vill komma in i testfältet och vilka möjliga sätt att komma in där.

Rekommenderad läsning

^