3 Vanlige rapporteringsvaner om mangler og hvordan man kan bryde dem

3 worst defect reporting habits

Mangler er alvorlige forretninger, og små fejl kan være dyre.

Du ved hvad du skal gøre, når du finder en defekt. Du rapporterer det; enten i en Defekt Tracker / Fejlhåndteringsværktøj eller i et Excel-ark. De underliggende principper er de samme for begge metoder.

Fejlstyringsværktøjer garanterer ikke bedre rapportering. Det er god praksis, der redder dagen.

For at værdsætte det gode skal vi erkende, hvad der ikke er.

Hvad du lærer:

• 3 Vanlige rapporteringsvaner om mangler og hvordan man kan bryde dem
• # 1) dovenskab
• # 2) Rushing
• # 3) Manglende kreativitet
• Anbefalet læsning

3 Vanlige rapporteringsvaner om mangler og hvordan man kan bryde dem

Her går:

# 1) dovenskab

Ikke tager dig tid til at gøre det bedste, du kan.

Dette er proces til mangelfølgning fulgt i de fleste hold:

(Bemærk- klik på et hvilket som helst billede for at forstørre visningen)

Som du kan se, gennemgår testledningen fejlene, inden de sendes ud af QA-holdene.

Denne anmeldelse inkluderer bekræftelse af:

• Gyldighed - Er det en fejl?
• Fuldstændighed - Titel, trin, data, skærmbillede osv.
• Kopier
• Reproducerbar eller ej ... osv.

Jeg ved førstehånds, at det er umuligt for en kvalitetsledelse at være 100% grundig.

Så holdningen, ”Jeg vil rapportere problemet, som jeg vil. QA-ledningen kan kontrollere igen. Han kan beslutte, om manglen er gyldig / komplet eller ej ”er afslutningen på dit QA-team og din troværdighed.

Vidste du, at nogle klienter har en SLA for antallet af acceptable ugyldige mangler? Når antallet overstiger, begynder de at straffe entreprenørerne for hver rapporteret ugyldig fejl?

Afhjælpe: Udfør din due diligence og vær ansvarlig for din leverance. En defekt kom tilbage for ikke nok information, eller at det ikke er en fejl? Det er ikke altid udviklingsholdets skyld. Det er ikke, at de ikke ønsker at eje problemerne i applikationen. Det kan være et ægte QA-team-rod. Lad det ikke ske.

# 2) Rushing

Lad os gøre dette med eneksempel.

Nedenfor er et skærmbillede af OpenEMR'er Opret patient-skærm. Det er et open source hospital management system.

Denne skærm giver brugeren mulighed for at indtaste patientens fødselsdato gennem en kalenderfunktion. Hvad det ikke gør er at begrænse posten til at vælge fra kalenderen. Hvad jeg mener er, at du kan vælge DOB som sige '31. marts 1983' fra kalenderen. Senere ændre det til '31. feb. 1983'.

Hvorfor 31. februar? At implementere fejl gætte og prøv negative data i marken; hvilket er hele pointen med testning, er det ikke?

Når det er gjort, klikker jeg på 'Opret patient'. Da datoen er ugyldig, forventer jeg, at systemet viser en fejl og ikke opretter patienten. Men det sker ikke. Det skaber patienten som nedenfor.

Bemærk felterne Alder og Fødselsdato i nedenstående skærmbillede:

Når du tester, kan du prøve dette et par gange og beslutte at:

• Det er en fejl.
• Det er reproducerbart.
• Det er ikke en duplikat (kontakt dit team for at bekræfte)
• Du kender den nøjagtige beskrivelse af problemet
• Du kender også de nøjagtige trin, der får det til at ske.

Nu hvor du har råmaterialet, er du klar til at gå.

Du begynder at rapportere det. Tildeling af sværhedsgrad er et obligatorisk trin, og dit team bruger muligvis noget, der ligner følgende tabel til reference:

Da denne defekt ikke går ned over systemet eller blokerer en vital funktionalitet eller forhindrer de andre områder af applikationen i at blive testet, går vi muligvis med 'Lav'.

Ser omkring, ikke?

FORKERT. Fra patientens data er alle vaccinationer og andre påmindelser forsinket. Dette kan eller måske ikke være rigtigt. Også for en patient bestemmer deres alder, om de ser en børnelæge eller en generel læge osv.

Det påvirker dosering af medicin og mange andre behandlingsområder, som vi måske ikke engang kender til.

Så jeg vil gå med 'High'. Jeg er enig i, at det er usandsynligt, at hospitalspersonalet går ind i DOB for en patient forkert. Men lad det være en faktor, der påvirker prioriteten, hvornår problemet skal løses.

Mit job som tester er at sikre, at jeg kommunikerer problemets alvor så godt jeg kan.

Afhjælpe: Skynd dig ikke at rapportere. Vær 100% sikker på, at du forstår virkningen af ​​problemerne fra mange vinkler. Det er den bedste værdi-tilføjelse, som vi testere kan levere. Vi siger ikke bare ”noget fungerer ikke”. Vi siger også, 'Her er hvad der vil ske, hvis dette fortsat ikke fungerer.' Masser af forskel, er det ikke?

# 3) Manglende kreativitet

Testerne har en vidunderlig mulighed for at komme med forslag til forbedring af softwaren.

I din Fejlhåndteringsværktøj også kan du indsende en fejl af typen 'Enhancement Suggestion.' Det er her, du kan blive kreativ.

Afhjælpe: Tænke ud af boksen. Hvis du mener, at en bestemt funktion mangler en 'Wow' -faktor, og du ved, hvordan du bringer den ind i den, skal du bringe ideen frem. I værste fald kan det blive afvist, og det er OK. Den vigtige del er at prøve.

Brug også denne superkraft med forsigtighed. Forsøg ikke at komme med kommentarer som 'Jeg hader banneret, skal du ændre det.'

Her er et godteksempelaf et forbedringsforslag, som jeg stødte på: Udskiftning af 'E-mail til forhandler' med 'Chat med forhandleren' på en bilforhandlerside. Det forudsiges at konvertere mere trafik til salg.

Jeg ville ønske, jeg var så kreativ! Men måske kan vi alle arbejde hen imod det.

Her er en bonus. En tjekliste for at frigøre disse dårlige vaner:

1. Overfører min titel problemet tydeligt og kortfattet?
For eksempel:'Opret patient fungerer ikke' er ikke en god titel. “Oprettelse af patient mislykkes, selvom alle inputfelter indeholder korrekte værdier” er.

2. Hvad er reproducerbarhedsgraden?
Med andre ord, sker det altid? Kender jeg den nøjagtige rækkefølge af trin, der gentager problemet?

3. Er denne problemplatform, browser eller brugerspecifik?

Fire. Er trinene færdige og får dig til dit problem?

5 . Har jeg inkluderet et skærmbillede?

6. Skal jeg kommentere mit skærmbillede for at fremhæve bestemte områder?

7. Er navnet på den vedhæftede billedfil beskrivende?
Brug ikke noget som 'Untitled.jpg.' Giv det et beskrivende navn.

8. Inkluderede jeg testdataene?
For eksempel:For en fejl i et administrationsmodul, der har brug for autorisationsoplysninger, skal du medtage dem. Udviklingsteamet har muligvis ikke adgang til QA-miljøet. Du ønsker ikke en forsinkelse og opfølgning på noget så grundlæggende som det.

9. Kan jeg give andre oplysninger for at forstærke min mangel?
(Eksempel:en henvisning til FRD eller en samtale med klienten osv.)

10. Forstår jeg, hvor alvorligt problemet er fra forskellige perspektiver?

elleve. Kender jeg årsagen til problemet? Hvis ja, har jeg beviser (måske logfiler), og kan jeg medtage det? Bemærk, at du måske ikke altid ved dette eller har brug for at vide dette. Men hvis du gør det, gør det ikke ondt at inkludere det.

12. Er fejlrapporten fri for grammatik, format, stave- og tegnsætningsproblemer?

bedste mobiltelefon spion apps til Android

13. Kender jeg en måde at forbedre produktet på?

Tror du, at dette er tidskrævende? Når det først bliver en vane, vil det ikke længere være.

Rooting for better fejlrapportering rutiner!

Om forfatteren: Denne artikel er skrevet af STH-teammedlem Swati.

Du er velkommen til at sende dine forespørgsler / kommentarer nedenfor.

Anbefalet læsning

• Hvorfor fejlrapportering er en kunst, der bør læres af alle testere?
• Hvad er defekt / bug livscyklus i softwaretest? Vejledning i defekt livscyklus
• Eksempel på fejlrapporter til web- og produktapplikationer
• Hvad er defektbaseret testteknik?
• Process for defekthåndtering: Sådan håndteres en defekt effektivt
• Proces med mangelfrihed og måder at håndtere defekttilslutningsmøde på
• Hvordan man skriver en god fejlrapport? Tips og tricks
• 3 strategier til håndtering af en blokeringsfejl