10 reasons why your bugs are getting rejected
Jag tänker inte skona henne. Hon har avvisat sju buggar, rapporterade jag, under de senaste tre dagarna. Jag vet att hon använder personliga nag som ett professionellt svärd ……
En lagkamrat fumrade och diskussionen blev plötsligt eld när ett par andra lagkamrater deltog i samma erfarenhet med andra utvecklare. Teammötet vände en diskussionspunkt om avvisande av fel. Efter en del diskussioner bestämde vi oss alla för att göra en enkel övning för att rädda oss från den förödmjukelse av avvisad bugg i framtiden.
Var och en av oss började ta ut anteckningar som orsaker till avvisande av buggar för de senaste 10 buggarna, rapporterade och avvisade. Listan över dessa avvisningsanteckningar visade sig vara användbar för att förstå det framtida spåret av felrapportering och vad som gjordes fel antagande.
Felavslag och skäl bakom det
I stället för att avslöja listan skulle jag vilja dela listans resultatpunkter. Här är det -
# 1) Missförståelse av kraven:
Av någon anledning, om du inte förstod kravet ordentligt, skulle du definitivt se upp för det misstolkade kravet i verklig implementering och när du inte skulle hitta det skulle det vara ett fel enligt dig, som äntligen kommer att avvisas.
Verkligt exempel : Efter att ha testat ett recept fann du att det var smaklöst eftersom salt inte tillsattes men du visste inte att salt skulle tillsättas vid serveringen, annars kan det påverka receptets utseende.
initialisering av c ++ statisk variabel
# 2) Kravsimplementering:
Som en del av en tidigare diskussion var du medveten om att specifika krav skulle implementeras på XYZ-sätt. Men under utvecklingen fann utvecklaren att det inte var möjligt att följa XYZ-vägen och så han följde ABC-vägen och det meddelades inte till dig.
I slutändan kommer du att rapportera ett fel när du upptäckte att kravet inte implementerades på det sätt som det diskuterades.
Verkligt exempel : Du bad skräddaren att förbereda en skjorta och när du blev ombedd till rättegången avvisade du den och sa att du inte hittade knappar på den. När skräddaren förklarar att sätta på knappar på framsidan skulle ha påverkat skjortans övergripande utseende och därmed satte han den inuti den främre gränsen, skulle du definitivt bli dummad.
# 3) Inga tydliga krav:
När det inte finns några tydliga krav tillgängliga är alla fria att anta kravet på sitt eget sätt och detta leder till ett antagande på personlig nivå. När du ser att personligt antagande inte uppfylls markerar du det som ett fel.
Verkligt exempel : Du måste rita en cykel när läraren meddelade att hon hade förväntat sig att eleverna skulle rita en cykel. Efter en halvtimme, när hon kollade allas teckning, hittade hon ingen som matchade hennes förväntningar. Alla tog det vaga uttalandet på sitt sätt och resultatet blev en trehjuling, barncykel, för många cykler, cyklade med rullstolen och så vidare.
# 4) Ändring av krav:
Ett annat exempel på felkommunikation, oftast. När testare inte kommuniceras om kravändringar kommer fler buggar att rapporteras och slutligen avvisas.
Verkligt exempel : Du kommer definitivt att avvisa smörgåsen när du tycker att den använde honungsbröd snarare än bananbrödet du beställde. Minst du visste att din partner ändrade brödtypen för beställning medan du var i telefon och självklart tyckte han / hon inte att det var nödvändigt att dela det med dig.
# 5) Förstå omfattning:
Under testningen börjar du testa något som inte bör betraktas som testbart vid en viss punkt eller som inte alls omfattas av produktkriterier; du kommer att bli ett offer för avvisande av fel.
Verkligt exempel : Du ska sopa ett rum och det är det enda fokuset. Ändå, om du klagar på röran i de andra områdena kommer du definitivt att ignoreras.
# 6) Testmiljö:
En applikation / produkt är en kombination av många hårdvaru- och programvarukrav - både större och mindre, och när rätt testmiljö inte används eller något saknas i testmiljön, kraschar applikation / produkt och ett kritiskt fel ...
Vad som händer härnäst är - djup utredning eftersom vi oavsiktligt inte tar hand om att ge mindre detaljer om den testmiljö vi använde och som ökar utvecklarens arbete. I slutändan avvisas fel.
Verkligt exempel : De smaskiga muffinsna du smakade på en väns hus innan ett par dagar var fantastiska och efter att ha följt receptet var muffinsna inte ens närmare den du hade.
Du borde inte använda gammalt smör eftersom färskt smör inte var tillgängligt, du skulle inte lägga till nypa grammjöl eftersom du trodde att det skulle kunna ge smak, du skulle inte laga det på pannan som ugnen var i ordning.
Rekommenderad läsning => Hur man effektivt förbereder 'Testmiljö'.
# 7) Testdata som används:
Testdata som användes för testning stämde inte överens med ett krav.
Verkligt exempel : Även efter att ha vetat att räknaren är användbar för numerisk bearbetning om du försöker lägga till specialtecken och när räknaren svarar oväntat, tycker du att den var felaktig. Verkligen?
Rekommenderad läsning => Tips för att designa testdata och Testa datahanteringstekniker .
# 8) Duplicate Bug:
Någon har redan rapporterat samma fel och du har inte varit noga med att leta efter samma innan du rapporterar fel. Återigen avslag.
Verkligt exempel: Kundsupportpersonen kommer inte att bli glad när han får flera klagomål för samma produkt från varje familjemedlem. Var inte ett samtal tillräckligt, skulle han tro.
sql intervju frågor och svar för nybörjare pdf
# 9) Felaktig beskrivning av fel:
När utvecklaren inte kan förstå vad du försökte förmedla via felrapporten, förvänta dig att den avvisas eftersom de också är laddade med andra uppgifter och när de inte hittar korrekt beskrivning och nödvändiga detaljer i felrapporten, oavsett hur kritiskt att felet är, förväntas det markeras som Avvisat.
Rekommenderad läsning => Hur skriver jag en bra felrapport? Tips och tricks.
Verkligt exempel: Du måste låsa upp bilen, ska sitta och börja med att flytta nycklarna medurs ... bilen startade inte och så du är upprörd. Har du inte fått i uppdrag att kontrollera bensin? Åh, ett misstag i manualen eftersom det antog att du säkert kommer att förstå att det ska vara standard kontrollerat.
# 10) Icke-reproducerbara buggar:
När du rapporterade ett fel insåg du aldrig vikten av reproducerbarheten. Att bara se till att felet alltid är reproducerbart eller visas slumpmässigt kan spara arbetstimmar och ytterligare en avvisad bugg.
Verkligt exempel: Vad skulle läkaren kontrollera efter när du klagar på den hårda förkylningen men han inte hittar några symtom. Jag nysade bara hårt , kommer inte att göra situationen bättre.
Slutsats
För det mesta låter vår mänskliga natur oss tänka negativt när det rapporterade felet avvisas. Egentligen ser utvecklare inte någon specifik anledning att avvisa felet om det är giltigt.
Så nästa gång och framåt bör du inte fokusera på felräkningen. Fokusera på kvalitativa buggar med korrekta detaljer, för i slutändan är det viktigt hur du hjälpte till att förbättra produktens kvalitet och inte hur många buggar du rapporterade.
Läs också => Hur kan du lösa alla fel utan någon ”Ogiltig bugg” -etikett?
Om författaren: Denna användbara artikel är skriven av STH-teammedlem Bhumika Mehta. Hon är projektledare med 7+ års erfarenhet av programvarutestning.
Lycklig testning! Som vanligt väntar du på dina åsikter om samma sak.
Rekommenderad läsning
- Hur löser du alla buggar utan någon 'Ogiltig bug' -etikett?
- Varför är felrapportering en konst som ska läras av varje testare?
- The Art of Bug Reporting: Hur marknadsför jag och fixar dina buggar?
- Varför har programvara fel?
- 7 typer av programvarufel som varje testare borde veta
- 11 sätt du vet att du är en testare ..
- Exempel på felrapport
- 5 sätt att vara en fet och säker programvarutestare