Menu

Live Project Bug Tracking, Test Metrics en Test Sign off - Gratis QA Training Dag 6

live project bug tracking

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Dit is het afsluitende deel van onze “ Software Testing training op een live project ”Serie.

Het gaat over defecten en ook over enkele resterende onderwerpen die de voltooiing van de testuitvoeringsfase van de STLC zullen markeren.

In de vorig artikel , terwijl Test Execution aan de gang was, kwamen we een situatie tegen waarin het verwachte resultaat van de testcase niet werd gehaald. We hebben ook onverwacht gedrag vastgesteld tijdens verkennende tests.

Live Project Bug Tracking, Test Metrics en Test Sign off

Wat gebeurt er als we deze afwijkingen tegenkomen?

We moeten ze uiteraard vastleggen en volgen om er zeker van te zijn dat deze afwijkingen worden afgehandeld en uiteindelijk gerepareerd op de AUT.

# 1) Deze afwijkingen worden defecten / bugs / issues / incidenten / fouten / fouten genoemd.

#twee) Alle volgende gevallen kunnen als defect worden geregistreerd

  • Ontbrekende vereisten
  • Onjuist werkende eisen
  • Extra vereisten
  • Inconsistenties in referentiedocument
  • Milieugerelateerde kwesties
  • Verbeteringssuggesties

# 3) Defectregistratie wordt meestal gedaan in Excel-sheets of via het gebruik van een Defect Management-software / -tool. Probeer de volgende links voor informatie over het omgaan met defecten via tools:

Wat je leert:

Hoe de defecten effectief te registreren

We zullen nu proberen te zien hoe we de defecten die we in het vorige artikel zijn tegengekomen, in een Excel-sheet kunnen loggen. Zoals altijd is het belangrijk om een ​​standaardformaat of sjabloon te kiezen.

verschil in c en c ++

Meestal maken de volgende kolommen deel uit van het defectrapport:

  • Defect ID: Voor unieke identificatie.
  • Defect Beschrijving: Dit is als een titel om het probleem kort te beschrijven.
  • Module / sectie van de AUT: Dit is optioneel, alleen om meer duidelijkheid te geven over het gebied van de AUT waar het probleem zich voordeed.
  • Stappen om te reproduceren: Wat de exacte volgorde is van bewerkingen die op de AUT moeten worden uitgevoerd om de bug opnieuw te creëren, wordt hier vermeld. Als enige invoergegevens specifiek zijn voor het probleem, moet die informatie ook worden ingevoerd.
  • Ernst: Om de intensiteit van het probleem aan te geven en eventueel de impact die dit kan hebben op het functioneren van de AUT. De richtlijnen voor het toewijzen van en welke waarden in dit veld zijn te vinden in het testplan-document. Raadpleeg daarom het Testplan document uit artikel 3 ​
  • Toestand: Zal verder in het artikel worden besproken.
  • Screenshot: Een momentopname van de applicatie om de fout te laten zien wanneer deze is opgetreden.

Dit zijn enkele van de 'must-have'-velden. Dit sjabloon kan worden uitgebreid (bijv. Met de naam van de tester die het probleem heeft gemeld) of gecontracteerd ( Bijvoorbeeld, de modulenaam verwijderd) zoals nodig.

Als u de bovenstaande richtlijnen volgt en de bovenstaande sjabloon gebruikt, kan een voorbeeld van een defectlogboek / -rapport er als volgt uitzien:

Voorbeeld van een defectrapport voor het OrangeHRM Live-project:

OrangeHRM Defect Report

​ Klik hier om live project Defect Report te downloaden

Hieronder ziet u het voorbeeld van een defectrapport dat is gemaakt in de qTest Test Management-tool: (Klik op afbeelding om te vergroten)

Voorbeeld van een defectrapport

Defecten zijn niet goed als we ze registreren en voor onszelf houden. We zullen ze in de juiste volgorde moeten toewijzen om de betrokken teams erop te laten reageren. Het proces - wie moet worden toegewezen of welke volgorde moet worden gevolgd, is ook te vinden in het testplan-document. Het is grotendeels vergelijkbaar met (Klik op afbeelding om te vergroten)

Defect Cyclus:

Defecte levenscyclus 1

Uit het bovenstaande proces kan worden opgemerkt dat bugs door verschillende mensen gaan en dat er verschillende beslissingen worden genomen tijdens het proces om te worden geïdentificeerd en opgelost. Om de exacte status van een bepaalde bug bij te houden en transparant te maken, wordt in het bugrapport een veld 'Status' gebruikt. Het hele proces wordt een 'Bug-levenscyclus' genoemd. Voor meer informatie over alle statussen en hun betekenis verwijzen wij u naar deze Bug Life Cycle-zelfstudie ​

Een paar tips bij het volgen van bugs

  • Als we nieuw zijn in een creatief Team / Project / AUT, is dat altijd het beste bespreek het probleem dat we zijn tegengekomen met een collega om er zeker van te zijn dat ons begrip van wat werkelijk een defect veroorzaakt, juist is of niet.
  • Naar verstrek alle informatie dat is nodig om het probleem te reproduceren. Een defect dat terugkomt bij een testteam met de status 'Te weinig informatie', is niet erg positief voor ons. Bekijk dit bericht - Hoe u alle bugs kunt laten oplossen zonder het label ‘Invalid bug’ ​
  • Controleer of een soortgelijk probleem is opgetreden voordat u een nieuwe maakt. ‘Dubbele’ problemen zijn ook slecht nieuws voor het QA-team.
  • Als er een probleem is, komt dat willekeurig naar voren en we weten niet de exacte stappen / situaties waarin we het probleem opnieuw kunnen creëren - breng het probleem toch naar voren. Met het risico dat het probleem zich voordoet 'Onreproduceerbare / niet genoeg informatie' - we moeten er nog steeds voor zorgen dat we alle mogelijke storingen zo goed mogelijk hebben aangepakt.
  • De huisartspraktijk is dat het QA-team elke dag de defecten in een Excel-sheet maakt en deze aan het eind van de dag consolideert.

De complete levenscyclus van defecten

Voor ons live-project als we de defectlevenscyclus voor defect 1 zouden volgen,

VPN chroom
  • Wanneer ik (de tester) het maak, is de status ​Nieuw​ Wanneer ik het toewijs aan de QA-teamleider, is de status nog steeds 'Nieuw', maar de eigenaar is nu de QA-lead.
  • De QA-lead zal het probleem beoordelen en nadat hij heeft vastgesteld dat het een geldig probleem is, wordt het probleem toegewezen aan de Dev-lead. In deze fase is de status ​Toegewezen​ en de eigenaar is Dev lead.
  • De ontwikkelaar leidt dit probleem vervolgens toe aan een ontwikkelaar die zal werken aan het oplossen van dit probleem. De status is nu ​Lopende werkzaamheden​ (of iets vergelijkbaars met dat effect), de eigenaar is de ontwikkelaar.
  • Voor defect 1 kan de ontwikkelaar de fout niet reproduceren, dus wijst hij deze weer toe aan het QA-team en stelt de status in als ​Kan niet reproduceren​
  • Als alternatief, als de ontwikkelaar eraan kon werken en een probleem kon oplossen, zou de status worden ingesteld op ​opgelost​ en de kwestie zou weer worden toegewezen aan het QA-team.
  • Q Een team zal het dan oppikken, het probleem opnieuw testen en, als het is opgelost, de status instellen op ​Gesloten​ ​Als het probleem nog steeds bestaat, is de status ingesteld op ​Heropenen​ en het proces gaat verder.
  • Afhankelijk van de andere situaties kan de status worden ingesteld als ​Uitgesteld​ , 'Niet genoeg informatie', ​Duplicaat​ ​ ​werken zoals bedoeld​ , etc door de ontwikkelaar.
  • Deze methode om de defecten vast te leggen, te rapporteren en toe te wijzen, ze te beheren, is een van de belangrijkste activiteiten die door de QA-teamleden worden uitgevoerd tijdens de testuitvoeringsfase. Dit wordt dagelijks gedaan totdat een bepaalde testcyclus is voltooid.
  • Zodra cyclus 1 is voltooid, heeft het ontwikkelteam een ​​dag of twee nodig om alle fixes te consolideren en de code opnieuw op te bouwen in de volgende versie die voor de volgende cyclus zal worden gebruikt.
  • Hetzelfde proces gaat ook weer door voor cyclus 2. Aan het einde van de cyclus is er een kans dat er nog enkele problemen zijn die “Open” of niet opgelost zijn in de applicatie.
  • Gaan we in dit stadium nog steeds door met cyclus 3? Zo ja, wanneer stoppen we met testen?

Exit Criteria voor de OrangeHRM Live Project Testing

Dit is waar we gebruik maken van wat we de 'Exit Criteria' zouden noemen. Dit is vooraf gedefinieerd in het Testplan-document. Het is simpelweg in de vorm van de checklist die zal bepalen of we het testen na cyclus 2 afronden of nog een cyclus volgen. Het lijkt erop dat, wanneer het onderstaande wordt ingevuld, rekening wordt gehouden met enkele hypothetische antwoorden op de volgende vragen over het OrangeHRM-project:

Exit-criteria testen

Als we de bovenstaande checklist goed bekijken, worden daar statistieken en afmeldingen vermeld die we niet eerder hebben besproken. Laten we er nu over praten.

Teststatistieken

We hebben vastgesteld dat tijdens de testuitvoeringsfase rapporten worden verzonden naar alle andere projectteamleden om een ​​duidelijk beeld te geven van wat er gebeurt in de QA Execution-fase ​Deze informatie is voor iedereen belangrijk om validatie te krijgen over de algehele kwaliteit van het eindproduct.

Stel je voor dat ik rapporteer dat 10 testcases zijn geslaagd of 100 testcases zijn uitgevoerd - deze cijfers zijn slechts onbewerkte gegevens en geven geen erg goed beeld van hoe de dingen aan de gang zijn.

Metrics spelen een cruciale rol bij het opvullen van deze leemte. Statistieken zijn in eenvoudige bewoordingen, intelligente nummers die het testteam verzamelt en onderhoudt ​ Bijvoorbeeld​ als ik zei dat 90% van de testcases geslaagd zijn, is dat logischer dan te zeggen dat 150 testcases zijn geslaagd. Is het niet?

Er zijn verschillende soorten Metrics die worden verzameld tijdens de testuitvoeringsfase. Welke metrics precies moeten worden verzameld en onderhouden voor welke perioden - deze informatie is te vinden in het testplan-document.

De volgende zijn de meest verzamelde teststatistieken voor de meeste projecten:

  • Geslaagd Percentage van de testgevallen
  • Defecten dichtheid
  • Percentage kritieke defecten
  • Gebreken, ernst wijs getal

Bekijk de Statusrapport bij dit artikel om te zien hoe deze statistieken worden gebruikt.

Test afmelding / voltooiingsrapport

Aangezien we alle belanghebbenden moeten informeren dat het testen is begonnen, is het ook de taak van het QA-team om iedereen te laten weten dat het testen is voltooid en om de resultaten te delen. Er wordt dus meestal een e-mail verzonden van het QA-team (meestal de Team Lead / QA Manager) met een indicatie dat het QA-team het product heeft ondertekend met de testresultaten en de lijst met open / bekende problemen.

Voorbeeldtest Afmelden E-mail:

Naar: Klant, PM, Dev-team, DB-team, BA, QA-team, Environment Team (en iedereen die moet worden opgenomen)
E-mailadres: Hallo team,

QA-team tekent af op de OrangeHRM versie 3.0-software na de succesvolle afronding van de 2 cycli van functionele testen van de website.

De testcases en hun uitvoeringsresultaten worden bij de e-mail gevoegd. (Of vermeld de locatie waar ze aanwezig zijn. Of geef, als u testbeheersoftware gebruikt, details over hetzelfde op.)

De lijst met bekende problemen is ook bij de e-mail gevoegd. (Nogmaals, alle andere verwijzingen die zinvol zijn, kunnen worden toegevoegd.)

Bedankt,
QA teamleider.

Bijlagen: Final Execution Report, Final issue / defect report, Known issues list

Zodra de test-afmeldingsmail van het QA-team is verzonden, zijn we officieel klaar met het STLC-proces. Dit betekent niet noodzakelijk de voltooiing van de 'Test' -fase van de SDLC. We moeten nog de UAT-tests voltooien om dat te laten gebeuren. Vind meer details over UAT-testen hier ​

Nadat de UAT is voltooid, gaat de SDLC over naar de implementatiefase waarin het live gaat en beschikbaar is voor zijn klanten / eindgebruikers om te worden geconsumeerd.

Dat is het!

Dit is onze poging geweest om de meest live-achtige QA Project-ervaring naar onze lezers te brengen. Laat ons uw opmerkingen en vragen over deze gratis online Software Testing QA-trainingsreeks weten.

Aanbevolen literatuur

^