Meny

Live Project Bug Tracking, Test Metrics, and Test Sign Off - Gratis QA-träningsdag 6

live project bug tracking

Prova Vårt Instrument För Att Eliminera Problem

Detta är den avslutande delen av vår ” Programvarutestning i ett liveprojekt ' serier.

Det kommer att handla om brister och även några återstående ämnen som markerar slutförandet av testutförandefasen av STLC.

I föregående artikel , medan testutförandet pågick, stötte vi på en situation där det förväntade resultatet av testfallet inte uppnåddes. Vi identifierade också något oväntat beteende under Exploratory Testing.

Live Project Bug Tracking, Test Metrics och Test Sign Off

Vad händer när vi stöter på dessa avvikelser?

Vi måste självklart spela in dem och spåra dem för att se till att dessa avvikelser hanteras och så småningom fixas på AUT.

# 1) Dessa avvikelser kallas Defekter / buggar / problem / incidenter / fel / fel.

#två) Alla följande fall kan loggas som defekter

  • Saknade krav
  • Felaktigt fungerande krav
  • Extra krav
  • Inkonsekvenser i referensdokumentet
  • Miljörelaterade frågor
  • Förbättringsförslag

# 3) Defektinspelning görs oftast i Excel-ark eller med hjälp av ett program / verktyg för Defect Management. För information om hur man hanterar defekter via verktyg, försök använda följande länkar:

Vad du kommer att lära dig:

Hur man loggar in bristerna effektivt

Vi kommer nu att försöka se hur vi loggar de defekter som vi stött på i föregående artikel i ett Excel-ark. Som alltid är det viktigt att välja ett standardformat eller en mall.

vad är den bästa gratis YouTube-nedladdaren?

Följande kolumner är vanligtvis en del av Defektrapporten:

  • Fel-ID: För unik identifiering.
  • Felbeskrivning: Det här är som en titel för att kort beskriva frågan.
  • Modul / avsnitt av AUT: Detta är valfritt, bara för att ge mer tydlighet för att ange området för AUT där problemet uppstod.
  • Steg för att reproducera: Vilken exakt sekvens av operationer som ska utföras på AUT för att återskapa felet ska listas här. Dessutom, om någon indata är specifik för problemet, ska informationen också matas in.
  • Allvarlighetsgrad: För att ange intensiteten i problemet och så småningom den inverkan detta kan ha på AUT: s funktion. Riktlinjerna för hur man tilldelar och vilka värden som ska tilldelas i detta fält finns i testplandokumentet. Så hänvisa till Testplan dokument från artikel 3 .
  • Status: Kommer att diskuteras vidare i artikeln.
  • Skärmdump: En ögonblicksbild av applikationen som visar felet när det hände.

Det här är några av de 'måste-ha' -fälten. Den här mallen kan utvidgas (t.ex. för att inkludera namnet på testaren som rapporterade problemet) eller kontrakt ( Till exempel, modulnamnet har tagits bort) efter behov.

I enlighet med ovanstående riktlinjer och med hjälp av mallen ovan kan ett exempel på en defektlogg / -rapport se ut så här:

Exempel på felrapport för OrangeHRM Live-projekt:

OrangeHRM-felrapport

=> Klicka här för att ladda ner live-projekt Defektrapport

Nedan följer ett exempel på Defektrapport som skapats i qTest Test Management Tool: (Klicka på bilden för att förstora)

Exempel på felrapport

Fel är inte bra när vi loggar dem och håller dem för oss själva. Vi måste tilldela dem i rätt ordning för att berörda team ska agera på dem. Processen - vem som ska tilldelas eller vilken ordning som ska följas finns också i testplandokumentet. Det liknar mest (Klicka på bilden för att förstora)

Defektcykel:

Defekt livscykel 1

Från ovanstående process kan det noteras att buggar går igenom olika människor och olika beslut i processen för att identifieras för att fixas. För att spåra och skapa transparens om exakt vilket tillstånd en viss bugg befinner sig i används ett ”Status” -fält i buggrapporten. Hela processen kallas ”Bug life cycle”. Mer information om alla statuser och deras betydelse finns i detta Bug Life Cycle tutorial .

Några pekare medan bugspårning

  • När vi är nya i ett kreativt team / projekt / AUT är det alltid bäst att diskutera frågan vi stött på med en kamrat för att se till att vår förståelse för vad som verkligen orsakar en defekt är korrekt eller inte.
  • Till ge all information det är nödvändigt för att återge problemet. En defekt som kommer tillbaka till ett testteam med status som ”Inte tillräckligt med information” återspeglar inte särskilt positivt på oss. Kolla in det här inlägget - Hur du löser alla buggar utan någon ”Ogiltig bug” -etikett .
  • Kontrollera om ett liknande problem togs upp innan du skapade ett nytt. 'Duplicera' frågor är också dåliga nyheter för QA-teamet.
  • Om det finns ett problem kommer det slumpmässigt och vi vet inte exakta steg / situationer där vi kan återskapa problemet - ta upp problemet på samma sätt. Med risk för att frågan sätts till “IrReproducerbar / inte tillräckligt med information” - Vi måste fortfarande se till att vi hanterar alla möjliga störningar i bästa möjliga utsträckning.
  • Allmän praxis är att QA-teamet skapar varandras defekter i ett excel-ark under en dag och konsoliderar det i slutet av dagen.

Hela defektens livscykel

För vårt live-projekt om vi skulle följa defektens livscykel för defekt 1,

standardgatewayen är inte tillgänglig windows 10 wifi
  • När jag (testaren) skapar den är dess status 'Ny”. När jag tilldelar den till QA-teamledningen är statusen fortfarande 'Ny' men ägaren är nu QA-lead.
  • QA-lead kommer att granska problemet och när det fastställs att det är ett giltigt problem, tilldelas problemet Dev-lead. I denna fas är status 'Tilldelad' och ägaren är Dev lead.
  • Dev-lead tilldelar sedan problemet till en utvecklare som kommer att arbeta med att åtgärda problemet. Statusen blir nu 'Pågående arbete' (eller något liknande den effekten), är ägaren utvecklaren.
  • För defekt 1 kan inte utvecklaren reproducera felet, så han tilldelar det tillbaka till QA-teamet och ställer in status som 'Kan inte reproducera”.
  • Alternativt, om utvecklaren kunde arbeta med det och åtgärda ett problem, skulle statusen ställas in 'löst' och frågan skulle tilldelas tillbaka till QA-teamet.
  • QA-teamet hämtar sedan upp det, testar problemet igen och om det är löst kommer det att ställa in status till 'Stängd' . Om problemet fortfarande finns, är status inställd på 'Öppna igen' och processen fortsätter.
  • Beroende på andra situationer kan status ställas in som 'Uppskjuten' , 'Inte tillräckligt med information', 'Duplicera' , 'fungerar som avsett' , etc av utvecklaren.
  • Denna metod för att registrera defekterna, rapportera och tilldela dem, hantera dem är en av de viktigaste aktiviteterna som utförs av QA-teammedlemmarna under testutförandefasen. Detta görs dagligen tills en viss testcykel är klar.
  • När cykel 1 är klar tar dev-teamet en dag eller två för att konsolidera alla korrigeringar och bygga om koden till nästa version som kommer att användas för nästa cykel.
  • Samma process fortsätter också igen för cykel 2. I slutet av cykeln finns det en chans att det fortfarande kan finnas några problem 'öppna' eller ofixade i applikationen.
  • I det här skedet - fortsätter vi fortfarande med cykel 3? Om ja, när slutar vi testa?

Utgångskriterier för OrangeHRM Live Project Testing

Det är här vi använder det vi skulle kalla ”Exit Criteria”. Detta är fördefinierat i testplandokumentet. Det är helt enkelt i form av checklistan som kommer att avgöra om vi avslutar testet efter cykel 2 eller går en cykel till. Det ser ut som nedan när det fylls i med beaktande av några hypotetiska svar på följande frågor angående OrangeHRM-projektet:

Testa utgångskriterier

När vi tittar noggrant på ovanstående checklista finns det mätvärden och avloggade som vi inte har diskuterat tidigare. Låt oss prata om dem nu.

Testa mätvärden

Vi har konstaterat att under testutförandefasen skickas rapporter ut till alla andra projektgruppmedlemmar för att ge en tydlig uppfattning om vad som händer i QA-genomförandefasen . Denna information är viktig för alla för att få validering av den slutliga produktens övergripande kvalitet.

Tänk dig att jag rapporterar att 10 testfall har godkänts eller 100 testfall har utförts - dessa siffror är bara rådata och ger inte ett särskilt bra perspektiv på hur saker och ting går.

Mätvärden spelar en viktig roll för att fylla detta gap. Mätvärden är i enkla ord, intelligenta nummer som testteamet samlar in och underhåller . Till exempel, om jag sa att 90% av testfallet var godkänt, är det mer meningsfullt än att säga att 150 testfall är godkända. Är det inte?

Det finns olika typer av mätvärden som samlats in under testutförandefasen. Vilka mätvärden exakt ska samlas in och underhållas under vilka tidsperioder - denna information finns i testplanen.

Följande är de mest samlade testmätvärdena för de flesta projekt:

  • Godkännandeprocent av testfallet
  • Defektdensitet
  • Procent av kritiska fel
  • Fel, allvarlighetsnummer

Kolla in Statusrapport bifogad den här artikeln för att se hur dessa mätvärden används.

Testavlogg / slutföringsrapport

Eftersom vi måste meddela alla intressenter att testningen har börjat är det också QA-teamets skyldighet att låta alla veta att testningen har slutförts och dela resultaten. Så vanligtvis skickas ett e-postmeddelande från QA-teamet (vanligtvis Team Lead / QA Manager) som ger en indikation på att QA-teamet har undertecknat den produkt som bifogar testresultaten och listan över öppna / kända problem.

Exempel på testavloggnings-e-post:

Till: Client, PM, Dev team, DB team, BA, QA team, Environment Team (och alla andra som behöver ingå)
E-post: Hej team,

QA-teamet loggar in på OrangeHRM version 3.0-programvaran efter att de två cyklerna med funktionell testning av webbplatsen lyckats.

Testärenden och deras genomföranderesultat bifogas e-postmeddelandet. (Eller nämn platsen där de finns. Eller om du använder testhanteringsprogramvara, ge information om densamma.)

Listan över kända problem bifogas också till e-postmeddelandet. (Återigen kan alla andra referenser som är meningsfulla läggas till.)

Tack,
QA-teamledare.

Bilagor: Slutlig utföranderapport, slutlig utgåva / felrapport, lista över kända problem

När testavslutnings-e-postmeddelandet har skickats från QA-teamet är vi officiellt klara med STLC-processen. Detta markerar inte nödvändigtvis slutförandet av 'Test' -fasen i SDLC. Vi har fortfarande UAT-testningen att slutföra för att det ska hända. Hitta mer information om UAT-testning här .

Efter att UAT är klar flyttar SDLC till distributionsfas där den går live och är tillgänglig för sina kunder / slutanvändare som ska konsumeras.

Det är allt!

Detta har varit vårt försök att få de mest levande som QA Project-upplevelserna till våra läsare. Låt oss veta dina kommentarer och frågor om den här kostnadsfria utbildningsserien QA för programvarutestning online.

Rekommenderad läsning

^