10 reasons why your bugs are getting rejected
Jeg kommer ikke til å spare henne. Hun har avvist 7 feil, rapporterte jeg, i løpet av de siste tre dagene. Jeg vet at hun bruker personlige nag som et profesjonelt sverd ……
En lagkamerat røk og diskusjonen brant plutselig da et par andre lagkamerater ble med på å dele den samme erfaringen med andre utviklere. Teammøtet snudde et diskusjonspunkt om avvisning av feil. Etter noen diskusjoner bestemte vi oss for å gjøre en enkel øvelse for å redde oss fra ydmykelsen av avvist bug, i fremtiden.
Hver og en av oss begynte å ta ut notater som årsakene til avvisning av feil for de siste 10 feilene, rapportert og avvist. Listen over avvisningsnotatene viste seg å være nyttig for å forstå det fremtidige sporet av feilrapportering og hva som ble gitt den gale antakelsen.
Feilavvisning og grunner bak det
I stedet for å avsløre listen, vil jeg dele utfallets punktpunkter på listen. Her er det -
initialisering av c ++ statisk variabel
# 1) Misforståelse av kravene:
Av en eller annen grunn, hvis du ikke forsto kravet ordentlig, ville du definitivt se opp for det feiltolkte kravet i faktisk implementering, og når du ikke ville finne det, ville det være en feil ifølge deg, som til slutt vil bli avvist.
Eksempel på virkeligheten : Etter å ha testet en oppskrift, fant du ut at den var smakløs da salt ikke ble tilsatt, men du visste ikke at salt skulle tilsettes på serveringstidspunktet, ellers kan det påvirke utseendet på oppskriften.
# 2) Kravsimplementering:
Som en del av en tidligere diskusjon, var du klar over at spesifikke krav skulle implementeres på XYZ-måte. Men under utviklingen fant utvikleren at det ikke var mulig å følge XYZ-banen, og derfor fulgte han ABC-banen, og den ble ikke kommunisert til deg.
Til slutt skal du rapportere en feil når du fant at kravet ikke ble implementert slik det ble diskutert.
Eksempel på virkeligheten : Du ba skredderen om å forberede en skjorte, og da du ble spurt om rettssaken, avviste du den og sa at du ikke fant knapper på den. Når skredderen forklarer at det å ha på seg knapper foran ville ha påvirket skjortens overordnede utseende, og derfor la han den innenfor frontgrensen, ville du definitivt stum.
# 3) Ingen klare krav:
Når det ikke er noen klare krav tilgjengelig, står alle fritt til å påta seg kravet på sin egen måte, og dette fører til en antagelse på et personlig nivå. Når du ser at personlig antagelse ikke er oppfylt, markerer du det som en feil.
Eksempel på virkeligheten : Du må tegne en syklus da læreren kunngjorde at hun hadde forventet at elevene skulle tegne en sykkel. Etter en halvtime, da hun sjekket alles tegning, fant hun ingen som samsvarte med forventningene hennes. Alle tok den vage utsagnet på sin måte, og resultatet ble en trehjulssykkel, babysyklus, for mange sykluser, sykling med rullestolen og så videre.
# 4) Endring i krav:
Et annet eksempel på feilkommunikasjon, mesteparten av tiden. Når testere ikke blir kommunisert om kravendringer, vil flere feil bli rapportert og til slutt avvist.
Eksempel på virkeligheten : Du kommer definitivt til å avvise sandwichen når du finner den brukt honningbrød i stedet for bananbrødet du bestilte. Minst du visste at partneren din endret brødtypen for bestilling mens du var i telefonen, og selvfølgelig fant han / hun ikke det nødvendig å dele det med deg.
# 5) Forstå omfanget:
Mens du tester, begynner du å teste noe som ikke skal betraktes som testbart på et bestemt punkt eller som ikke dekkes under produktkriterier; du kommer til å bli et offer for avvisning av feil.
Eksempel på virkeligheten : Du skal feie et rom, og det er det eneste fokuset. Likevel, hvis du klager på rotet i de andre områdene, vil du definitivt bli ignorert.
# 6) Testmiljø:
Et program / produkt er en kombinasjon av mange maskinvare- og programvarekrav - både store og mindre, og når riktig testmiljø ikke brukes eller noe mangler i testmiljøet, krasjer applikasjon / produkt og en kritisk feil….
Det som skjer videre er - dyp undersøkelse fordi vi utilsiktet ikke passer på å gi mindre detaljer om testmiljøet vi brukte, og som øker utviklerens arbeid. Til slutt blir bug avvist.
Eksempel på virkeligheten : De yummy muffinsene du smakte på en venns hus før et par dager, var kjempebra, og etter å ha fulgt oppskriften var muffinsene ikke engang nærmere den du hadde.
Vel, du skulle ikke bruke foreldet smør, da fersk smør ikke var tilgjengelig, du skulle ikke legge til klype grammel, da du trodde det kunne tilføre smaken, du skulle ikke lage det på pannen som ovnen var ute av drift.
Anbefalt lesing => Hvordan effektivt forberede “Testmiljø”.
# 7) Testdata brukt:
Testdata som ble brukt til testing samsvarte ikke med et krav.
Eksempel på virkeligheten : Selv etter å ha visst at kalkulatoren er nyttig for numerisk behandling hvis du prøver å legge til spesialtegn, og når kalkulatoren reagerer uventet, synes du det var upassende. Egentlig?
Anbefalt lesing => Tips for å designe testdata og Test datahåndteringsteknikker .
# 8) Dupliser feil:
Noen har allerede rapportert den samme feilen, og du passet ikke på å sjekke om den samme før du rapporterte feilen. Igjen avvisning.
Eksempel på virkeligheten: Kundesupportpersonen vil ikke være lykkelig når han mottar flere klagesamtaler for det samme produktet fra hvert familiemedlem. Var ikke en samtale nok, ville han tro.
spørsmål om bedriftsanalytikerforsikringsdomener
# 9) Feil beskrivelse:
Når utvikleren ikke kan forstå hva du prøvde å formidle via feilrapporten, kan du forvente at den blir avvist fordi de også er lastet med andre oppgaver, og når de ikke finner riktig beskrivelse og nødvendige detaljer i feilrapporten, uansett hvordan kritisk feilen er, forventes den å bli merket som Avvist.
Anbefalt lesing => Hvordan skriver jeg en god feilrapport? Tips og triks.
Eksempel på virkeligheten: Du må låse opp bilen, sitte og bør begynne med å bevege nøklene med urviseren ... bilen startet ikke, så du er lei deg. Ble du ikke bedt om å se etter bensin? Åh, en feil i manualen da den antok at du helt sikkert vil forstå at den som standard skal være sjekket.
# 10) Ikke-reproduserbare feil:
Mens du rapporterte en feil, skjønte du aldri viktigheten av reproduserbarheten til feilen. Bare å sørge for om feilen alltid er reproduserbar eller vises tilfeldig, kan spare tid på arbeid og en avvist feil til.
Eksempel på virkeligheten: Hva ville legen sjekke etter når du klager over grov forkjølelse, men han finner ingen symptomer. Jeg nyset hardt , vil ikke gjøre situasjonen bedre.
Konklusjon
Som oftest lar vår menneskelige natur oss tenke negativt når den rapporterte feilen blir avvist. Virkelig, utviklere ser ikke en spesifikk grunn til å avvise feilen hvis den er gyldig.
Så neste gang og fremover må du ikke fokusere på antall feil. Fokuser på kvalitative feil med riktige detaljer, fordi det som betyr noe er til slutt hvordan du hjalp til med å forbedre kvaliteten på produktet og ikke hvor mange feil du rapporterte.
Les også => Hvordan får du løst alle feil uten etiketten 'Ugyldig feil'?
Om forfatteren: Denne nyttige artikkelen er skrevet av STH-teammedlem Bhumika Mehta. Hun er prosjektleder med 7+ års erfaring med programvaretesting.
Glad test! Som vanlig venter du på dine synspunkter på det samme.
Anbefalt lesing
- Hvordan løser jeg alle feilene dine uten 'Ugyldig feil' -merke?
- Hvorfor feilrapportering er en kunst som bør læres av hver tester?
- Kunsten med feilrapportering: Hvordan markedsføre og få fikset feilene dine?
- Hvorfor har programvare feil?
- 7 typer programvarefeil som alle testere burde vite
- 11 måter du vet at du er en tester ..
- Eksempel på feilrapport
- 5 måter å være en fet og selvsikker programvaretester