Menu

10 grunde til, at dine bugs bliver afvist, og hvad du kan gøre for det som tester!

10 reasons why your bugs are getting rejected

Jeg vil ikke skåne hende. Hun har afvist 7 bugs, rapporterede jeg, inden for de sidste tre dage. Jeg ved, at hun bruger personlige nag som et professionelt sværd ……

En holdkammerat var fumling, og diskussionen brændte pludselig, da et par andre holdkammerater deltog i at dele den samme oplevelse med andre udviklere. Holdmødet drejede et diskussionspunkt om afvisning af fejl. Efter nogle diskussioner besluttede vi alle at gøre en simpel øvelse for at redde os fra den ydmygelse af afvist bug i fremtiden.

Årsager til, at dine fejl bliver afvist

Hver af os begyndte at tage noter ud som årsagerne til afvisning af fejl for de sidste 10 fejl, rapporteret og afvist. Listen over disse afvisningsnotater viste sig nyttig til at forstå det fremtidige spor af fejlrapportering, og hvad der blev taget med den forkerte antagelse.

Bugafvisning og årsager bag det

I stedet for at afsløre listen vil jeg gerne dele resultatet af punktet på listen. Her er det -

# 1) Misforståelse af kravene:

Af en eller anden grund, hvis du ikke forstod kravet ordentligt, ville du helt sikkert holde øje med det fejlagtede krav i den faktiske implementering, og når du ikke ville finde det, ville det være en fejl ifølge dig, som endelig bliver afvist.

Eksempel på det virkelige liv : Efter at have testet en opskrift fandt du, at den var usmagelig, da salt ikke blev tilsat, men du vidste ikke, at der skulle tilsættes salt på serveringstidspunktet, ellers kan det påvirke opskriftens udseende.

# 2) Kravsimplementering:

Som en del af en tidligere diskussion var du opmærksom på, at specifikt krav skulle implementeres på XYZ-måde. Men under udviklingen fandt udvikleren, at det ikke var muligt at følge XYZ-stien, og så fulgte han ABC-stien, og det blev ikke meddelt dig.

I sidste ende skal du rapportere en fejl, når du fandt ud af, at kravet ikke blev implementeret, som det blev diskuteret.

Eksempel på det virkelige liv : Du bad skrædderen om at forberede en skjorte, og da du blev bedt om retssagen, afviste du den og sagde, at du ikke fandt knapper på den. Når skrædderen forklarer, at påsætning af knapper foran ville have påvirket trøjenes overordnede udseende, og derfor satte han den inden i frontgrænsen, ville du bestemt forbavset.

# 3) Ingen klare krav:

Når der ikke er nogen klare krav til rådighed, kan alle frit påtage sig kravet på sin egen måde, og dette fører til en antagelse på et personligt niveau. Når du ser, at personlig antagelse ikke er opfyldt, markerer du det som en fejl.

Eksempel på det virkelige liv : Du skal tegne en cyklus, da læreren meddelte, at hun havde forventet, at de studerende skulle tegne en cykel. Efter en halv time, da hun tjekkede alles tegning, fandt hun ingen, der matchede hendes forventninger. Alle tog den vage udsagn på deres egen måde, og resultatet var en trehjulet cykel, babycyklus, for mange cykler, cykler med kørestolen og så videre.

binært søgetræ c ++ eksempel

# 4) Ændring i krav:

Et andet eksempel på fejlkommunikation, det meste af tiden. Når testere ikke kommunikeres om kravændringer, rapporteres flere fejl og afvises i sidste ende.

Eksempel på det virkelige liv : Du vil bestemt afvise sandwichen, når du finder den brugt honningbrød snarere end det bananbrød, du bestilte. Mindst du vidste, at din partner skiftede brødtype til ordre, mens du var i telefonen, og selvfølgelig fandt han / hun det ikke nødvendigt at dele det med dig.

# 5) Forståelsesområde:

Mens du tester, begynder du at teste noget, der ikke skal betragtes som testbart på et bestemt tidspunkt eller slet ikke er omfattet af produktkriterier; du bliver offer for afvisning af fejl.

Eksempel på det virkelige liv : Du skal feje et rum, og det er det eneste fokus. Stadig, hvis du klager over rodet i de andre områder, vil du bestemt blive ignoreret.

# 6) Testmiljø:

En applikation / et produkt er en kombination af mange hardware- og softwarekrav - større og mindre begge, og når korrekt testmiljø ikke bruges, eller der mangler noget i testmiljøet, går applikations- / produktnedbrud og en kritisk fejl rapporteret….

Hvad der sker næste er - dyb undersøgelse, fordi vi for det meste utilsigtet ikke sørger for at give mindre detaljer om det testmiljø, vi brugte, og det øger udviklerens arbejde. I sidste ende bliver bug afvist.

Eksempel på det virkelige liv : De lækre boller, du smagte en vens hus inden et par dage, var fantastiske, og efter at have fulgt opskriften var boller ikke engang tættere på den, du havde.

Du skulle ikke bruge uaktuelt smør, da der ikke var frisk smør, du skulle ikke tilføje en knivspids grammel, da du troede, det kunne tilføje smagen, du skulle ikke koge det på gryden som ovnen var ude af drift.

Anbefalet læsning => Hvordan man effektivt forbereder 'testmiljø'.

# 7) Anvendte testdata:

Testdata, der blev brugt til test, var uoverensstemmende med et krav.

Eksempel på det virkelige liv : Selv efter at vide, at lommeregneren er nyttig til numerisk behandling, hvis du forsøger at tilføje specialtegn, og når lommeregneren reagerer uventet, synes du det var forkert. Virkelig?

Anbefalet læsning => Tips til design af testdata og Test datastyringsteknikker .

# 8) Duplikatfejl:

Nogen har allerede rapporteret den samme fejl, og du passede ikke på at kontrollere den samme, inden du rapporterede fejlen. Igen afvisning.

Eksempel på det virkelige liv: Kundesupportpersonen vil ikke være glad, når han modtager flere klageopkald for det samme produkt fra hvert familiemedlem. Var ikke et opkald nok, ville han tænke.

# 9) Forkert beskrivelse af fejl:

spørgsmål om manuel testinterview i 4 års erfaring

Når udvikleren ikke kan forstå, hvad du forsøgte at formidle via fejlrapporten, skal du forvente, at den afvises, fordi de også er fyldt med andre opgaver, og når de ikke finder korrekt beskrivelse og krævede detaljer i fejlrapporten, uanset hvordan kritisk fejlen er, forventes den at blive markeret som Afvist.

Anbefalet læsning => Hvordan man skriver en god fejlrapport? Tips og tricks.

Eksempel på det virkelige liv: Du er nødt til at låse bilen op, skal sidde og bør starte med at flytte tasterne med uret ... bilen startede ikke, og så er du ked af det. Blev du ikke instrueret om at kontrollere, om der var benzin? Åh, en fejl i manualen, da den antog, at du helt sikkert vil forstå, at den som standard skal kontrolleres.

# 10) Ikke-reproducerbare bugs:

Mens du rapporterede en fejl, indså du aldrig vigtigheden af ​​bugens reproducerbarhed. Bare det at sørge for, om fejlen altid kan reproduceres eller vises tilfældigt, kan spare timevis af arbejde og endnu en afvist fejl.

Eksempel på det virkelige liv: Hvad ville lægen kontrollere, når du klager over den barske forkølelse, men han finder ingen symptomer. Åh, jeg nysede bare hårdt , vil ikke gøre situationen bedre.

Konklusion

Det meste af tiden giver vores menneskelige natur os mulighed for at tænke negativt, når den rapporterede fejl afvises. Virkelig kan udviklere ikke se en bestemt grund til at afvise fejlen, hvis den er gyldig.

Så næste gang og fremad, skal du ikke fokusere på antallet af fejl. Fokuser på kvalitative bugs med korrekte detaljer, for i sidste ende betyder det vigtige, hvordan du hjalp med at forbedre produktets kvalitet og ikke hvor mange bugs du rapporterede.

Læs også => Hvordan får du alle dine fejl løst uden nogen 'Ugyldig fejl' -mærke?

Om forfatteren: Denne nyttige artikel er skrevet af STH-teammedlem Bhumika Mehta. Hun er en projektleder med 7+ års erfaring med softwaretest.

God test! Som normalt venter på dine synspunkter om det samme.

Anbefalet læsning

^