3 worst defect reporting habits
Defecten zijn een serieuze zaak en kleine fouten kunnen duur zijn.
U weet wat u moet doen als u een defect ontdekt. U meldt het; ofwel in een Defect Tracker / Defect Management tool of in een Excel-sheet. De onderliggende principes zijn voor beide methoden hetzelfde.
Hulpprogramma's voor defectbeheer garanderen geen betere rapportage. Het zijn goede praktijken die de dag redden.
Om het goede te waarderen, moeten we erkennen wat niet is.
Wat je leert:
- 3 Verslaggewoonten van ergste defecten en hoe ze te doorbreken
- # 1) Luiheid
- # 2) Haasten
- # 3) Gebrek aan creativiteit
- Aanbevolen literatuur
3 Verslaggewoonten van ergste defecten en hoe ze te doorbreken
Hier gaat:
# 1) Luiheid
Geen tijd nemen om het beste te doen wat je kunt.
Dit is de defect tracking proces gevolgd in de meeste teams:
Notitie- klik op een afbeelding voor een vergrote weergave)
Zoals u kunt zien, beoordeelt de testleider de defecten voordat u ze uit de QA-teams stuurt.
Deze beoordeling omvat het bevestigen van:
- Geldigheid - Is het een bug?
- Volledigheid - Titel, stappen, gegevens, screenshot etc.
- Duplicaten
- Reproduceerbaar of niet ... enz.
Ik weet uit de eerste hand dat het onmogelijk is dat een QA-lead 100% grondig is.
Dus de houding: “Ik zal het probleem melden zoals ik wil. De QA-lead kan opnieuw controleren. Hij kan beslissen of het defect geldig / compleet is of niet ”, is het einde van uw QA-team en uw geloofwaardigheid.
Wist je dat sommige klanten een SLA hebben voor het aantal acceptabele ongeldige defecten? Zodra het aantal overschrijdt, beginnen ze de aannemers te bestraffen voor elk gemeld ongeldig defect?
Remedie Doe uw due diligence en wees verantwoordelijk voor uw resultaat. Is er een defect teruggekomen bij onvoldoende informatie of is het geen bug? Het is misschien niet altijd de schuld van het ontwikkelteam. Het is niet dat ze de problemen in de applicatie niet willen bezitten. Het kan een echte puinhoop van het QA-team zijn. Laat het niet gebeuren.
# 2) Haasten
Laten we dit doen met eenvoorbeeld
Hieronder ziet u een screenshot van OpenEMR's create-patient scherm. Het is een open source ziekenhuisbeheersysteem.
Op dit scherm kan de gebruiker de geboortedatum van de patiënt invoeren via een kalenderfunctie. Wat het niet doet, is de invoer beperken tot kiezen uit de kalender. Wat ik bedoel is dat je de DOB kunt kiezen zoals '31-Mar-1983' uit de kalender. Verander het later in '31-feb-1983'.
Waarom 31 februari? Implementeren fout bij het raden en probeer negatieve gegevens in het veld; dat is het hele punt van testen, nietwaar?
Als ik klaar ben, klik ik op 'Patiënt aanmaken'. Aangezien de datum ongeldig is, verwacht ik dat het systeem een fout weergeeft en niet de patiënt maakt. Maar dat gebeurt niet. Het creëert de patiënt zoals hieronder.
Let op de velden Leeftijd en Geboortedatum in het onderstaande scherm:
Tijdens het testen kunt u dit een paar keer proberen en besluiten dat:
- Het is een bug.
- Het is reproduceerbaar.
- Het is geen duplicaat (neem contact op met uw team om te bevestigen)
- U kent de exacte omschrijving van het probleem
- U kent ook de exacte stappen die ervoor zorgen dat dit gebeurt.
Nu je de grondstof hebt, ben je klaar om te gaan.
Je begint het te melden. Het toewijzen van de ernst van het defect is een verplichte stap en uw team gebruikt mogelijk iets dat lijkt op het volgende tabel ter referentie:
Ernst | Gevolg |
---|---|
1 (kritiek) | • Deze bug is kritiek genoeg om het systeem te laten crashen, bestanden te beschadigen of mogelijk gegevensverlies te veroorzaken • Het veroorzaakt een abnormale terugkeer naar het besturingssysteem (crash of een systeemfoutbericht verschijnt). • Het zorgt ervoor dat de toepassing vastloopt en dat het systeem opnieuw moet worden opgestart. |
2 (hoog) | • Het veroorzaakt een gebrek aan essentiële programmafunctionaliteit met tijdelijke oplossing. |
3 (gemiddeld) | • Deze bug zal de kwaliteit van het systeem verslechteren. Er is echter een intelligente oplossing om de gewenste functionaliteit te bereiken - bijvoorbeeld via een ander scherm. • Deze bug voorkomt dat andere delen van het product worden getest. Andere gebieden kunnen echter onafhankelijk worden getest. |
4 (laag) | • Er is een onvoldoende of onduidelijk foutbericht, wat een minimale impact heeft op het gebruik van het product. |
5 (cosmetisch) | • Er is een onvoldoende of onduidelijk foutbericht dat geen invloed heeft op het gebruik van het product. |
Aangezien dit defect het systeem niet doet crashen of een vitale functionaliteit blokkeert of niet verhindert dat de andere delen van de applicatie worden getest, kunnen we kiezen voor 'Laag'.
Ziet er ongeveer goed uit?
FOUT. Op basis van de gegevens van de patiënt zijn alle vaccinaties en andere herinneringen te laat. Dit kan wel of niet kloppen. Ook voor een patiënt bepaalt hun leeftijd of ze een kinderarts of een huisarts zien, enz.
Het beïnvloedt de dosering van medicijnen en vele andere behandelingsgebieden die we misschien niet eens kennen.
Dus ik ga met 'High'. Ik ben het ermee eens dat het onwaarschijnlijk is dat het ziekenhuispersoneel de DOB van een patiënt verkeerd invoert. Maar laat dat een factor zijn die van invloed is op de prioriteit van wanneer het probleem moet worden opgelost.
Het is mijn taak als tester ervoor te zorgen dat ik de ernst van het probleem zo goed mogelijk communiceer.
Remedie Wees niet gehaast om te melden. Wees er 100% zeker van dat u de impact van de problemen vanuit verschillende hoeken begrijpt. Het is de beste toegevoegde waarde die wij testers kunnen bieden. We zeggen niet alleen: “Iets werkt niet”. We zeggen ook: 'Dit is wat er zal gebeuren als dit nog steeds niet werkt.' Heel veel verschil, nietwaar?
# 3) Gebrek aan creativiteit
De testers hebben een geweldige kans om suggesties te doen om de software te verbeteren.
In uw Hulpprogramma voor defectbeheer ook kunt u een defect van het type 'Verbeteringssuggestie' indienen. Dit is waar u creatief kunt worden.
Remedie Denk buiten de doos. Als je denkt dat een bepaalde functie een 'Wow' -factor mist en je weet hoe je die erin moet brengen, breng het idee dan naar voren. In het ergste geval kan het worden afgewezen en dat is oké. Het belangrijkste is proberen.
Wees ook voorzichtig met deze superkracht. Probeer geen opmerkingen te maken zoals 'Ik haat de kleur van de banner, verander deze alstublieft.'
Hier is een goedvoorbeeldvan een verbeteringssuggestie die ik tegenkwam: Vervanging van 'E-mail naar dealer' door 'Chat met de dealer' optie op een autodealersite. Er wordt voorspeld dat meer verkeer wordt omgezet in verkopen.
Ik wou dat ik zo creatief was! Maar misschien kunnen we er allemaal naar toe werken.
Hier is een bonus. Een checklist om deze slechte gewoonten te doorbreken:
1. Geeft mijn titel het probleem duidelijk en beknopt weer?
Bijvoorbeeld:'Patiënt maken werkt niet' is geen goede titel. 'Patiënt maken mislukt, zelfs als alle invoervelden de juiste waarden bevatten' is.
twee. Wat is de reproduceerbaarheid?
Met andere woorden, gebeurt het altijd? Weet ik de exacte volgorde van de stappen die het probleem zullen herhalen?
3. Is dit probleemplatform, browser of gebruiker specifiek?
Vier. Zijn de stappen voltooid en helpen we u bij uw probleem?
5 Heb ik een screenshot meegeleverd?
6. Moet ik mijn screenshot annoteren om bepaalde gebieden te markeren?
7. Is de naam van het bijgevoegde afbeeldingsbestand beschrijvend?
Gebruik niet zoiets als 'Untitled.jpg'. Geef het een beschrijvende naam.
8. Heb ik de testgegevens opgenomen?
Bijvoorbeeld:Voor een defect in een Admin-module waarvoor autorisatiegegevens nodig zijn, neemt u deze op. Het ontwikkelteam heeft al dan niet toegang tot de QA-omgeving. U wilt geen vertraging en follow-up van zoiets eenvoudigs.
9. Kan ik andere details geven om mijn defect te versterken?
Voorbeeld:een verwijzing naar de FRD of een gesprek met de klant, enz.)
10. Begrijp ik hoe ernstig het probleem is vanuit verschillende perspectieven?
elf. Ken ik de oorzaak van het probleem? Zo ja, heb ik bewijs (misschien logbestanden) en kan ik dit bijvoegen? Houd er rekening mee dat u dit misschien niet altijd weet of moet weten. Maar als je dat doet, kan het geen kwaad om het op te nemen.
12. Is het defectrapport vrij van grammatica-, formaat-, spelling- en interpunctieproblemen?
programma om video's van websites te downloaden
13. Weet ik een manier om het product te verbeteren?
Denk je dat dit tijdrovend is? Nou, als het eenmaal een gewoonte wordt, zal het dat niet meer zijn.
Wroeten voor beter defectrapportage routines!
Over de auteur: Dit artikel is geschreven door STH-teamlid Swati.
Voel je vrij om je vragen / opmerkingen hieronder te posten.
Aanbevolen literatuur
- Waarom is bugrapportage een kunst die door elke tester moet worden geleerd?
- Wat is de levenscyclus van defecten / bugs bij het testen van software? Zelfstudie over de levenscyclus van een defect
- Voorbeelden van bugrapporten voor web- en productapplicaties
- Wat is een op defecten gebaseerde testtechniek?
- Defectbeheerproces: hoe u een defect effectief kunt beheren
- Defect Triage Process en Manieren om Defect Triage Meeting aan te pakken
- Hoe schrijf je een goed bugrapport? Tips en trucs
- 3 strategieën voor het omgaan met een blocker-defect