live project bug tracking
Dette er den afsluttende del af vores ” Software Testing træning på et live projekt ”-Serien.
Det vil dreje sig om fejl og også et par resterende emner, der markerer afslutningen af testudførelsesfasen af STLC.
I forrige artikel , mens testudførelsen foregik, stødte vi på en situation, hvor det forventede resultat af testsagen ikke blev opfyldt. Vi identificerede også en uventet adfærd under Exploratory Testing.
Hvad sker der, når vi støder på disse afvigelser?
Vi er naturligvis nødt til at registrere dem og spore dem for at sikre, at disse afvigelser bliver håndteret og til sidst rettet på AUT.
# 1) Disse afvigelser kaldes defekter / fejl / problemer / hændelser / fejl / fejl.
#to) Alle følgende tilfælde kan logges som mangler
- Manglende krav
- Forkert fungerende krav
- Ekstra krav
- Uoverensstemmelser i referencedokumentet
- Miljørelaterede spørgsmål
- Forslag til forbedring
# 3) Defektoptagelse udføres for det meste i excel-ark eller ved brug af et Defect Management-software / -værktøj. For at få oplysninger om, hvordan man håndterer fejl via værktøjer, kan du prøve at bruge følgende links:
- HP ALM
- Atlassian JIRA
- Se også dette indlæg for en liste over mest populære Bug Tracking-værktøjer på markedet.
Hvad du lærer:
- Sådan logges fejlene effektivt
- Et par pointer, mens fejlsporing
- Den komplette defekt livscyklus
- Udgangskriterier for OrangeHRM Live Project Testing
- Test målinger
- Test Sign Off / Færdiggørelsesrapport
- Anbefalet læsning
Sådan logges fejlene effektivt
Vi vil nu forsøge at se, hvordan vi logger de mangler, vi stødte på i den foregående artikel, i et excel-ark. Som altid er det vigtigt at vælge et standardformat eller en skabelon.
værktøjer, du har brug for til webudvikling
Følgende kolonner er typisk en del af fejlrapporten:
- Fejl-id: Til unik identifikation.
- Fejlbeskrivelse: Dette er som en titel, der kort beskriver problemet.
- Modul / sektion af AUT: Dette er valgfrit, bare for at tilføje mere klarhed til at angive det område af AUT, hvor problemet blev stødt.
- Trin til reproduktion: Hvad er den nøjagtige rækkefølge af operationer, der skal udføres på AUT for at genskabe fejlen, skal vises her. Også, hvis inputdata er specifikke for problemet, skal oplysningerne også indtastes.
- Alvorlighed: For at indikere intensiteten af problemet og til sidst den indvirkning dette kan have på AUT's funktion. Retningslinjerne for hvordan man tildeler og hvilke værdier der skal tildeles i dette felt findes i testplandokumentet. Så henvises til Testplan dokument fra artikel 3 .
- Status: Vil blive diskuteret yderligere i artiklen.
- Skærmbillede: Et øjebliksbillede af applikationen for at vise fejlen, da den skete.
Dette er nogle af de 'must-have' felter. Denne skabelon kan udvides (f.eks. For at inkludere navnet på testeren, der rapporterede problemet) eller indgået kontrakt ( For eksempel, modulnavnet fjernet) efter behov.
Ved at følge ovenstående retningslinjer og bruge skabelonen ovenfor kan en prøvefejllog / rapport se sådan ud:
Eksempel på fejlrapport til OrangeHRM Live-projekt:
=> Klik her for at downloade live-projektfejlrapport
Nedenfor er eksemplet på fejlrapport oprettet i qTest Test Management-værktøjet: (Klik på billedet for at forstørre det)
Mangler er ikke gode, når vi logger dem og holder dem for os selv. Vi bliver nødt til at tildele dem i den rigtige rækkefølge for at få de berørte hold til at reagere på dem. Processen - hvem der skal tildeles, eller hvilken ordre der skal følges, kan også findes i testplandokumentet. Det ligner for det meste (Klik på billedet for at forstørre det)
Fejlcyklus:
Fra ovenstående proces kan det bemærkes, at fejl går gennem forskellige mennesker og forskellige beslutninger i processen med at blive identificeret til at blive rettet. For at spore og etablere gennemsigtighed med hensyn til nøjagtigt, i hvilken tilstand en bestemt fejl er, bruges et 'Status' -felt i fejlrapporten. Hele processen betegnes som en ”bug livscyklus”. For mere information om alle statuser og deres betydning henvises til dette Bug Life Cycle tutorial .
Et par pointer, mens fejlsporing
- Når vi er nye i et kreativt team / projekt / AUT, er det altid bedst at diskutere det problem, vi stødte på med en peer for at sikre, at vores forståelse af, hvad der virkelig skaber en defekt, er korrekt eller ej.
- Til give alle oplysninger det er nødvendigt for at gengive problemet. En defekt, der vender tilbage til et testteam med status som 'Ikke nok information', afspejler os ikke meget positivt. Tjek dette indlæg - Sådan får du løst alle dine fejl uden nogen 'Ugyldig fejl' -mærke .
- Kontroller, om et lignende problem blev rejst, inden du oprettede et nyt. Problemer med 'duplikat' er også dårlige nyheder for QA-teamet.
- Hvis der er et problem, kommer det tilfældigt op, og vi ved ikke de nøjagtige trin / situationer, hvor vi kan genskabe problemet - rejse problemet alligevel. Med risiko for, at problemet sættes til “IrReproducerbar / ikke nok information” - vi er stadig nødt til at sikre os, at vi har håndteret alle mulige fejl i den bedst mulige udstrækning.
- Den almindelige praksis er, at QA-teamet opretter hver enkelt mangel i et excel-ark i løbet af en dag og konsoliderer det i slutningen af dagen.
Den komplette defekt livscyklus
For vores live-projekt, hvis vi skulle følge defektens livscyklus for defekt 1,
standard gateway er ikke tilgængelig windows 10 wifi
- Når jeg (testeren) opretter den, er dens status 'Ny”. Når jeg tildeler det til QA-teamledelsen, er status stadig 'Ny', men ejeren er nu QA-leder.
- QA-leadet gennemgår problemet, og når det fastslås, at det er et gyldigt problem, tildeles problemet Dev-leadet. I denne fase er status 'Tildelt' og ejeren er Dev lead.
- Dev-leadet tildeler derefter dette problem til en udvikler, der vil arbejde på at løse dette problem. Status vil nu være 'Arbejde der er i gang' (eller noget der ligner den effekt), ejeren er udvikleren.
- For defekt 1 er udvikleren ikke i stand til at reproducere fejlen, så han tildeler den tilbage til QA-teamet og indstiller status som 'Ikke i stand til at reproducere”.
- Alternativt, hvis udvikleren kunne arbejde på det og løse et problem, ville status blive indstillet til 'løst' og spørgsmålet ville blive tildelt tilbage til QA-teamet.
- QA-team vil derefter afhente det, prøve problemet igen, og hvis det er løst, vil det indstille status til 'Lukket' . Hvis problemet stadig eksisterer, er status indstillet til 'Åbn igen' og processen fortsætter.
- Afhængigt af de andre situationer kan status indstilles som 'Udskudt' , 'Ikke nok information', 'Duplikere' , 'fungerer efter hensigten' osv. af udvikleren.
- Denne metode til registrering af mangler, rapportering og tildeling af dem, styring af dem er en af de største aktiviteter, der udføres af QA-teammedlemmerne under testudførelsesfasen. Dette gøres dagligt, indtil en bestemt testcyklus er afsluttet.
- Når cyklus 1 er færdig, tager dev-teamet en dag eller to for at konsolidere alle rettelserne og genopbygge koden til den næste version, der skal bruges til den næste cyklus.
- Den samme proces fortsætter igen også i cyklus 2. I slutningen af cyklussen er der en chance for, at der stadig er nogle problemer 'Åbn' eller ikke-fastgjort i applikationen.
- På dette stadium - fortsætter vi stadig med cyklus 3? Hvis ja, hvornår stopper vi testningen?
Udgangskriterier for OrangeHRM Live Project Testing
Det er her, vi anvender det, vi kalder ”Exit Criteria”. Dette er foruddefineret i testplandokumentet. Det er simpelthen i form af tjeklisten, der bestemmer, om vi afslutter testen efter cyklus 2 eller går i endnu en cyklus. Det ser ud til, at nedenstående når de udfyldes under hensyntagen til nogle hypotetiske svar på følgende spørgsmål vedrørende OrangeHRM-projektet:
Når vi ser nøje på ovenstående tjekliste, er der metrics og afmeldt der nævnt der, som vi ikke har diskuteret tidligere. Lad os tale om dem nu.
Test målinger
Vi har fastslået, at der i testudførelsesfasen sendes rapporter til alle de andre projektmedlemmer for at give en klar idé om hvad der sker i QA-udførelsesfasen . Disse oplysninger er vigtige for alle for at få validering af den samlede kvalitet af det færdige produkt.
Forestil dig, at jeg rapporterer, at 10 testsager, der er bestået, eller 100 testsager blev udført - disse tal er kun rådata og giver ikke et meget godt perspektiv på, hvordan tingene foregår.
Metrics spiller en vigtig rolle i udfyldningen af dette hul. Metrics er i enkle ord, intelligente tal, som testteamet indsamler og vedligeholder . For eksempel, hvis jeg sagde, at 90% af de testsager, der var bestået, giver det mere mening end at sige, at 150 testsager var bestået. Er det ikke?
Der er forskellige slags målinger indsamlet i løbet af testudførelsesfasen. Hvilke målinger nøjagtigt der skal indsamles og vedligeholdes i hvilke tidsrum - denne information kan findes i testplandokumentet.
Følgende er de mest indsamlede testmålinger for de fleste projekter:
- Bestå procentdel af testsagerne
- Defekter tæthed
- Procent af kritiske fejl
- Mangler, alvorlighedsvis antal
Tjek den Statusrapport vedhæftet denne artikel for at se, hvordan disse målinger bruges.
Test Sign Off / Færdiggørelsesrapport
Da vi er nødt til at underrette alle interessenter om, at testen er begyndt, er det også QA-holdets pligt at lade alle vide, at testen er afsluttet og dele resultaterne. Så der sendes typisk en e-mail fra QA-teamet (normalt Team Lead / QA Manager), der giver en indikation af, at QA-teamet har underskrevet det produkt, der vedhæfter testresultaterne og listen over åbne / kendte problemer.
Prøve Test Log af E-mail:
Til: Klient, PM, Dev-team, DB-team, BA, QA-team, Miljøteam (og alle andre, der skal medtages)
E-mail: Hej team,
QA-teamet tilmelder sig OrangeHRM version 3.0-softwaren efter den vellykkede afslutning af de 2 cyklusser med funktionstest af hjemmesiden.
Testsagerne og deres eksekveringsresultater er knyttet til e-mailen. (Eller nævn det sted, hvor de er til stede. Eller hvis du bruger testadministrationssoftware, skal du angive oplysninger om det samme.)
Listen over kendte problemer er også knyttet til e-mailen. (Igen kan der tilføjes andre referencer, der giver mening.)
Tak,
QA-teamleder.
Vedhæftede filer: Endelig udførelsesrapport, endelig udgave / fejlrapport, liste over kendte problemer
Når testafmeldings-e-mailen går ud af QA-teamet, er vi officielt færdige med STLC-processen. Dette markerer ikke nødvendigvis afslutningen af 'Test' -fasen af SDLC. Vi har stadig UAT-testen til at afslutte for at det skal ske. Finde flere detaljer om UAT-test her .
Når UAT er færdig, flytter SDLC til implementeringsfase, hvor den går live og er tilgængelig for sine kunder / slutbrugere, der skal forbruges.
Det er det!
Dette har været vores bestræbelse på at få mest mulig ud af QA Project-oplevelsen til vores læsere. Fortæl os dine kommentarer og spørgsmål om denne gratis online software test QA træningsserie.
Anbefalet læsning
- Software Testing Training: End to End Training på et live projekt - Gratis online kvalitetsuddannelse del 1
- Skrivning af testsager fra SRS-dokument (DOWNLOAD Live Project-prøveeksempler)
- Ofte stillede spørgsmål om QA-træningskursus til softwaretest
- 11 bedste online træningssoftware til problemfri træning i 2021
- Arbejde med nøgleordsvisning - QTP-træningsvejledning 2
- Hvad er defekt / bug livscyklus i softwaretest? Vejledning i defekt livscyklus
- JIRA Bug Tracking Tool Tutorial: Sådan bruges JIRA som billetværktøj
- Sådan gennemgår du SRS-dokument og opretter testscenarier - Software Testing Training på et live projekt - dag 2