Defekt livscykel - Som du kanske är medveten om att testutförande är den fas där testaren faktiskt skulle utföra testskripten. Processen för utförande av testskript varierar från företag till företag och kan också vara annorlunda i olika projekt inom samma företag.
Nu finns det några dagar tillgängliga verktyg för testutförande, verktyg som - Quality Center, Microsoft Visual Studio och så vidare. Den faktiska exekveringsprocessen för att utföra varje steg för att jämföra faktiskt och förväntat resultat förblir densamma för den funktionella testaren oavsett vilka verktyg som används.
- Vad händer om faktiskt beteende inte är lika med förväntat beteende?
När en testare finner att det faktiska testresultatet inte är lika med det förväntade resultatet, loggas en defekt.
- Hur loggar jag in en defekt?
Det finns många verktyg tillgängliga nu en dag, några av loggverktygen för defekter är ClearQuest från IBM, HP: s Quality Center, öppna källverktyg som defekts livscykel i JIRA och så vidare.
Det finns några av de obligatoriska fälten som är vanliga i de olika felloggningsverktygen. Dessa fält är -
- Defekt livscykel Beskrivning
- Defekt livscykelöversikt
- Defekt inloggad av
- Defekt Tilldelad till
- Defekt Svårighetsgrad
- Defekter prioritet
- Ytterligare ögonblicksbilder
- Släppnummer / namn
Defekter livscykel
Defekt Livscykeln börjar från att logga in en ny defekt. Varje gång en fel loggas går den i "Nytt" tillstånd.
Tester - Ny defekt
Vem tilldelar en ny defekt?
En testare kan tilldela en defekt till en utvecklare eller en utvecklingsledning. Detta beslut om defektuppdrag varierar från projekt till projekt. På vissa arbetsplatser finns det en livscykelprocess för att tilldela den direkt till en respektive utvecklare och på vissa platser tilldelas defekten först till en dev-ledning och dev-ledningen tilldelar i sin tur den till en utvecklare.
Defect Assignment (New) - Defect Life Cycle Developer
Defect Assignment (Ny) - Dev Leadà Developer
Defektanalys
Utvecklare kommer att analysera defekten för att kontrollera om den är reproducerbar. Här är det viktigaste bidraget från testaren att inkludera alla nödvändiga detaljer i defekten. Defektöversikt, Defekt detaljerad beskrivning är de fält som hjälper intressenterna att förstå felet på en gång. Defektöversikt ska alltid endast ha högnivåinformation om defekten. Samtidigt bör det ha tillräcklig information för att beskriva översikten över defekter på en rad.
Felbeskrivning är platsen där testaren förväntas inkludera all nödvändig information som miljö, scenarie, testdata som används, förväntat resultat, verkligt resultat, referens till filer / data och referens till ögonblicksbild.
Här är en kort översikt över olika delar av Defect Detaljerad beskrivning -
Miljö
Testmiljö där felet hittades. Ofta har projekt flera testmiljöer där testteamet utför tester. Till exempel - AT (Monteringstestmiljö), PT (Produkttestmiljö), UAT (Användaracceptantestmiljö) och så vidare. Syftet med att ha olika miljöer är att det ger flexibilitet inom utvecklings- och testteamet att låta koden distribueras i någon av de tillgängliga miljöerna för att starta testen i tid.
Det finns tillfällen när produkttestet (även kallat systemtest) och UAT-test överlappar varandra, varför ett flertal miljöer är ett måste för att fortsätta testa parallellt.
Det finns fall då utvecklingsgruppen behöver en ytterligare miljö för att felsöka de problem som rapporteras av testteamet. Utvecklingsteamet har också en dedikerad miljö för enhetstestuppgift.
Därför med flera miljöer måste det i defekten nämnas en speciell miljö där problemet hittades.
Scenario
Scenario är uppsättningen steg som utförs av testaren vilket ledde till en defekt. Här förväntas en testare nämna alla steg som utvecklaren kan utföra för att återge felet. Ofta finns det tillfällen då felet rapporteras av testaren, men utvecklaren kan inte replikera detsamma och följaktligen avvisas felet. Detta kan hända på grund av felaktiga steg / saknade steg som nämns i beskrivningen. Tydliga steg hjälper alla att förstå defekten och replikera den utan att ha beroendet att nå ut till en testare för att få input. Ett väl dokumenterat scenario har lättlästa, lätta att förstå och exakta steg som ska följas för att replikera felet.
Testdata
En testare är tänkt att nämna de data som användes under testflödet som ledde till ett problem. Denna information ger utvecklarna en chans att använda liknande data för att reproducera felet och hitta grundorsaken till detsamma.
Det finns vissa scenarier där en testare hittar en defekt med hjälp av specifika data, men samma problem kan inte reproduceras med liknande data. Detta kan hända på grund av datakorruption, vilket innebär att inmatning av data ger en chans att ta reda på grundorsaken till fel. En utvecklare kanske inte gräver till kodnivå om datakorruption är fallet. Den här typen av fel kan konverteras till datadefekt.
Förväntat och faktiskt resultat
Detta är höjdpunkten i det detaljerade beskrivningsfältet där en testare bevisar att felet verkligen är en fel. Att tydligt nämna det förväntade resultatet gör det klart för varje intressent att betrakta felet som en fel. Föreställ dig att en fel är loggad med alla detaljer, men den anger inte det förväntade resultatet av scenariot!
Vanligtvis går en testare in endast det förväntade resultatet kan vara i en rad eller två, men det är mycket viktigt att nämna källan till det förväntade resultatet. Källa här hänvisning till dokumentet där det förväntade resultatet nämns. Detta kan vara ett kravdokument eller en storyboardreferens.
Hänvisning till filer / data
Ibland innebär defekten generering av fil eller input som en fil. I denna typ av scenarier ska testaren tillhandahålla information om filen som användes och som orsakade problemet i applikationen. Dessa filer kan bifogas med hjälp av defekthanteringsverktyget eller referensen för samma kan anges. Dessa referensplatser bör vara tillgängliga för alla intressenter.
Hänvisning till ögonblicksbild
Snapshots spelar en mycket viktig roll när du vill visa dem det exakta felmeddelandet för sidbrytning som visas på skärmen eller när du vill visa skärmnavigeringsdetaljer. Snapshot ger en snabb uppfattning om vilken fel som uppstått, skärm på vilken defekt hittades, data som används på skärmen och så vidare. Varje verktyg för hantering av defekter har tillhandahållande för att bifoga stillbilderna. Ibland kan testare bifoga Excel-kalkylark eller orddokument också.
Dessa var de olika komponenterna i felloggning och bästa praxis för var och en av dem. Kommer tillbaka till defekten livscykel, när defekten har tilldelats en utvecklare, han / hon kommer att analysera det med hjälp av data som finns i defekt objekt. Om enligt analysen är det loggade problemet verkligen en defekt, kommer "utvecklaren" att öppna felet för att arbeta med dess fix.
Rekommenderade kurser
- Webbtjänster i Java Training Bundle
- Träning i spelutveckling i C ++
- Komplett etisk hackningsträning
- Vegas Pro 13-utbildningskurser
Ny - Öppen
En defekt i öppen status visar att den finns i utvecklingsplattan och utvecklarna arbetar med att fixa det. Om analysen finner ut att det loggade problemet inte är något fel kan det hända när det finns förståelsegap i systemets förväntade beteende. Om analysen säger att defekten är ogiltig, kommer utvecklaren att avvisa felet. Terminologi är "Avvisad" eller "Återgå till testning".
Ny - Återgå till testning.
Hur testare bör validera om felet verkligen var en ogiltig defekt?
Detta är scenariot där ett exakt kravdokument hjälper alla i teamet att komma till slutsatsen om den loggade defekten var ogiltig eller giltig. Med hänvisning till kravdokument hjälper testare såväl som utvecklare att komma till samma slutsats och det underlättar verkligen diskussionsprocessen.
Det finns scenarier där korrektheten av design och kravdokument ifrågasätts när man hänvisar dessa dokument i tider med defekta diskussioner, vid sådana tillfällen att gå tillbaka till Business Analyst anses vara det bästa alternativet för att klargöra frågorna.
Som bästa praxis bör krav och designdokument alltid vara uppdaterade för att hänvisa dem utan oklarheter.
I statusen “Öppen” arbetar utvecklingsgruppen med att fixa defekten, när felet har fixats ändras statusen till ”Klar för distribution”.
Öppen - Klar för distribution
Distribution är processen där ändringarna laddas upp på servern så att testteamet kan arbeta med den fasta versionen av koden. Vanligtvis har varje projekt ett separat distributionsteam för denna uppgift.
Så på hög nivå består ett mjukvaruteam huvudsakligen av dessa tre grupper -
- Utveckling
- Defekter livscykeln vid testning
- Distribution (eller ibland kallat Build-team)
När byggandet har distribuerats och felet igen är tillgängligt för omprovning tilldelas det en lämplig testare för omprovningen.
Defekt Tilldelad till - Testledare.
Testledare - individuell testare.
Defekt tilldelad - individuell testare.
På vissa arbetsplatser tilldelas först defekt till testledare och han / hon tilldelar i sin tur det till enskilda testare, men på vissa platser tilldelas defekten direkt testaren som skulle testa den eller den som hade lyft upp defekten.
Status här ändras från Ready for Deployment - Ready SIT Testing.
Nu är defekten i testarens platta. Testteam validerar felet och det finns två möjligheter, antingen skulle fixingen fungera korrekt eller samma problem stöter på igen. Beroende på utfallsdefekt kan gå till följande status -
Klar SIT-testning - stängd
Klar SIT-test - Öppna igen
I båda ovanstående scenarier krävs testare att lägga till kommentarerna om utförda tester. Detta inkluderar att nämna de testade scenarierna och de data som används. Om felet öppnas igen, bör testaren tillhandahålla de exakta stegen som utförts vilket igen ledde till felet.
Återöppningsstatus är samma som "Ny" defektstatus.
När defekten öppnas igen följer den samma cykel igen.
Defekter livscykelutmaningar
- Besluta om svårighetsgraden - detta är ett av de vanliga diskussionsämnena (ofta kämpar) bland testare v / s-utvecklare.
- Defekten är inte reproducerbar på utvecklarens system.
- Fel uppstått på scenariot som inte nämns i krav och designdokument.
- Det finns fel men samma kan inte höjas eftersom scenariot på produktionsmiljön inte är genomförbart.
Hur ska en testare övervinna ovanstående utmaningar?
- Svårighetsgraden är direkt proportionell mot påverkan som felet orsakar applikationen, om testaren inte kan fortsätta på grund av defekten, är det säkert markerat med högsta svårighetsgrad.
- Om det finns en lösning för att fortsätta testa, bör den markeras som medelhög svårighetsgrad. Även förutom att beakta effekterna av ytterligare defekter i livscykeltestning, kan svårighetsgraden också avgöras med hänsyn till situationen där en hel modul misslyckas, i detta fall även om testningen av en annan modul kan utföras men svårighetsgraden för den aktuella modulen är hög så felet bör märkas med högsta svårighetsgrad.
- Om en defekt inte är reproducerbar i utvecklarens system finns det chanser att utvecklings- och testmiljön inte är synkroniserad. En defekt reproducerbar på testsystemet betraktas alltid som en giltig defekt.
- Det finns situationer när en fel loggas med tanke på det övergripande affärsscenariot men det direkta scenariot nämns inte i krav eller designdokument. Det anses alltid vara en bästa praxis att ta hänsyn till de faktiska affärsscenarierna istället för att bara följa teststegen. Kommunikation med affärsanalytiker och andra produktintressenter spelar en viktig roll för att logga sådana fel.
- Det finns scenarier när en testare upptäcker en lucka i affärslogiken under testfasen. Att hitta sådana luckor anses återigen vara ett stort plus för en testare. Designgap hanteras vanligtvis via förbättringar.
- Förbättring - Om ett beteende måste ändras under testfasen i programvarans livscykel skapas en förbättring som kan tas i den aktuella eller nästa utgåvan med tanke på tidslinjerna och bandbredden för utvecklings- och testteamen.
- Det finns några scenarier som en testare kan testa under ad-hoc-tester som faktiskt kan vara ogiltiga scenarier, med tanke på möjligheten att de inträffade i produktionen.
Vem är testarens bästa vän?
Vart ska en testare gå om tvetydighet? Svaret beror på typen av fråga, om en fråga avser krav är det tillrådligt att först diskutera i teamet för att korrekt förståelse av systemet kan vara genom att konsultera äldre medlemmar. Nästa kontaktpunkt ska vara affärsanalytiker.
Om frågan rör testprocessen är det tillrådligt att nå testledare eller testchef.
Om frågan handlar om att förstå applikationens tekniska egenskaper, kan utvecklingsgruppmedlem vara rätt person att gå till.
Eftersom testning är en process som kräver övergripande förståelse för systemet, hjälper kommunikation en testare att få snabbt svar på frågorna, det beror bara på att ställa rätt frågor till rätt personer. Om du skjuter bort från att ställa frågor till rätt tid kan det leda till en brist på läckage till produktionsmiljön.
Hur viktig är en testares roll i företaget idag?
Det finns projekt där testteamet är lika viktigt som utvecklingsgruppen och i vissa scenarier finns det mer beroende av testteamet än av utvecklingsgruppen. Det senare scenariot är sällsynt men det finns på vissa arbetsplatser. Detta har hänt under tiden och kan vara under en viss tidsperiod då utvecklingsgruppen inte är mycket erfaren jämfört med testteamet. Det finns människor som förstår det totala flödet och funktionaliteten bättre än de flesta av de andra teammedlemmarna. En sådan individ kan ingå i test / utvecklingsteam. Detta är en av faktorerna som avgör beroendet hos ett team / individ för det specifika projektet.
Vad är karriärvägen för en testare?
En individ kan ta lite tid att förstå den övergripande testprocessen, domänen och andra uppgifter som han / hon förväntas arbeta med i det dagliga livet. Baserat på denna förståelse är det lämpligt att fatta beslut om att utforska ytterligare områden som en testare kan ta upp. Det finns alltid möjligheter att automatisera olika flöden. Att skapa små verktyg kan också hjälpa teamet på stort sätt. Om en testare är bra på programmering, betraktas det som ett stort plus. Detta öppnar möjligheter för automatiseringsroller. Prestandatestning är också ett av karriärspåren för testare. Affärsanalytiker är ett annat alternativ. God domänkunskap med god kommunikationsförmåga är de förmågor som krävs för att vara affärsanalytiker. Testning öppnar många möjligheter för testarna att arbeta på olika domäner, verktyg, processer och så vidare. Det beror bara på en person att plocka upp och börja gå djupt inuti ett av testkärnområdena. Det finns många certifieringar specifika för olika verktyg för att specialisera sig inom ett testområde. Att ha certifiering från standardleverantören är en fördel för att öka karriären men certifikatet ensamt kan inte hjälpa dig i det långa loppet om inte kombinerat med rätt arbetslivserfarenhet.
Rekommenderade artiklar
Här är några artiklar som hjälper dig att få mer detaljerad information om programvarutestning, så bara gå igenom länken.
- 6 mest fantastiska programtestintervjuer
- Karriärer inom mjukvarutestning
- Hur man får bättre karriärtillväxt i arbete med programvarutester