10 reasons why your bugs are getting rejected
Ik ga haar niet sparen. Ze heeft de afgelopen drie dagen zeven bugs afgewezen, meldde ik. Ik weet dat ze persoonlijke wrok gebruikt als een professioneel zwaard
Een teamgenoot was woedend en de discussie vloog plotseling in brand toen een paar andere teamgenoten samen dezelfde ervaring deelden met andere ontwikkelaars. De teamvergadering veranderde een discussiepunt over het afwijzen van bugs. Na enige discussie hebben we allemaal besloten om een eenvoudige oefening te doen om onszelf te redden van de vernedering van de in de toekomst afgewezen bug.
Ieder van ons begon aantekeningen te maken als de redenen voor het afwijzen van bugs voor de laatste 10 bugs, gerapporteerd en afgewezen. De lijst met die afwijzingsnotities bleek nuttig om het toekomstige spoor van bugrapportage te begrijpen en wat de verkeerde veronderstelling was.
Afwijzing van bugs en redenen erachter
In plaats van de lijst te onthullen, wil ik de uitkomst-opsommingstekens van de lijst delen. Hier is het -
# 1) Misverstand over de vereisten:
Om welke reden dan ook, als je de vereiste niet goed zou begrijpen, zou je zeker letten op de verkeerd geïnterpreteerde vereiste bij de daadwerkelijke implementatie en als je het niet zou vinden, zou het volgens jou een bug zijn, die uiteindelijk zal worden afgewezen.
Real-life voorbeeld : Nadat u een recept had getest, ontdekte u dat het smaakloos was omdat er geen zout aan was toegevoegd, maar u wist niet dat er bij het serveren zout moest worden toegevoegd, anders kan het het uiterlijk van het recept beïnvloeden.
# 2) Implementatie van vereisten:
Als onderdeel van een eerdere discussie wist u dat een specifieke vereiste op XYZ-manier geïmplementeerd zou worden. Maar tijdens de ontwikkeling ontdekte de ontwikkelaar dat het niet mogelijk was om het XYZ-pad te volgen en dus volgde hij het ABC-pad en dat werd niet aan jou gecommuniceerd.
Uiteindelijk ga je een bug rapporteren als je ontdekte dat de vereiste niet was geïmplementeerd op de manier waarop deze werd besproken.
Real-life voorbeeld : U vroeg de kleermaker om een overhemd voor te bereiden en toen u werd gevraagd voor het proces, wees u het af en zei dat u er geen knopen op vond. Als de kleermaker uitlegt dat het omdoen van knopen aan de voorkant van invloed zou zijn geweest op de algehele look van het shirt en hij het daarom in de rand aan de voorkant heeft gestopt, zou je absoluut stomverbaasd zijn.
# 3) Geen duidelijke vereisten:
Als er geen duidelijke eisen voorhanden zijn, staat het een ieder vrij om de eis op zijn / haar eigen manier over te nemen en dit leidt tot een aanname op persoonlijk niveau. Als je ziet dat niet aan die persoonlijke aanname is voldaan, markeer je dat als een bug.
Real-life voorbeeld : Je moet een cyclus tekenen toen de docent aankondigde dat ze had verwacht dat de leerlingen een fiets zouden tekenen. Toen ze na een half uur de tekening van iedereen bekeek, vond ze niemand die aan haar verwachtingen voldeed. Iedereen vatte de vage stelling op zijn eigen manier op en het resultaat was een driewieler, babyfiets, te veel fietsen, fietsen met de rolstoel enzovoort.
# 4) Verandering in vereiste:
Een ander voorbeeld van miscommunicatie, meestal. Wanneer testers niet worden gecommuniceerd over vereiste wijzigingen, zullen meer bugs worden gerapporteerd en uiteindelijk worden afgewezen.
Real-life voorbeeld : Je gaat de sandwich zeker afwijzen als je merkt dat het honingbrood is in plaats van het bananenbrood dat je hebt besteld. Je wist tenminste dat je partner de broodsoort voor bestelling veranderde terwijl je aan de telefoon was en hij / zij vond het natuurlijk niet nodig om het met je te delen.
hoe je een computer programmeert voor beginners
# 5) Scope begrijpen:
Tijdens het testen begint u iets te testen dat op een bepaald punt niet als testbaar mag worden beschouwd of helemaal niet onder de productcriteria valt; u wordt het slachtoffer van afwijzing van bugs.
Real-life voorbeeld : Je zou een kamer moeten vegen en dat is de enige focus. Maar als je klaagt over de rotzooi in de andere gebieden, zul je zeker genegeerd worden.
# 6) Testomgeving:
Een applicatie / product is een combinatie van vele hardware- en softwarevereisten - zowel groot als klein, en wanneer de juiste testomgeving niet wordt gebruikt of er iets ontbreekt in de testomgeving, crasht de applicatie / het product en wordt er een kritieke bug gerapporteerd….
Wat daarna gebeurt, is - diepgaand onderzoek, omdat we meestal onbedoeld niet opletten om kleine details te verstrekken over de testomgeving die we hebben gebruikt en dat vergroot het werk van de ontwikkelaar. Uiteindelijk wordt de bug afgewezen.
Real-life voorbeeld : Die lekkere muffins die je een paar dagen eerder bij een vriend had geproefd, waren geweldig en na het volgen van het recept waren de muffins niet eens dichter bij degene die je had.
Nou, je mocht geen oude boter gebruiken omdat er geen verse boter beschikbaar was, je mocht niet het snufje grammeel toevoegen omdat je dacht dat het de smaak zou toevoegen, het was niet de bedoeling dat je het in de pan kookte zoals in de oven was niet in orde.
Aanbevolen literatuur => Hoe u een 'testomgeving' effectief kunt voorbereiden.
# 7) Gebruikte testgegevens:
Testgegevens die voor het testen werden gebruikt, kwamen niet overeen met een vereiste.
Real-life voorbeeld : Zelfs als u weet dat de rekenmachine handig is voor numerieke verwerking, als u speciale tekens probeert toe te voegen en als de rekenmachine onverwacht reageert, denkt u dat het niet correct was. Werkelijk?
Aanbevolen literatuur => Tips om testgegevens te ontwerpen en Test datamanagementtechnieken
# 8) Dubbele bug:
Iemand heeft dezelfde bug al gerapporteerd en u hebt er niet op gelet deze te controleren voordat u de bug rapporteerde. Opnieuw afwijzing.
Real-life voorbeeld: De klantenservicemedewerker zal niet blij zijn als hij van elk gezinslid meerdere keren een klacht ontvangt voor hetzelfde product. Was niet één telefoontje genoeg, zou hij denken.
# 9) Onjuiste beschrijving van bug:
Als de ontwikkelaar niet kan begrijpen wat u probeerde over te brengen via het bugrapport, verwacht dan dat het wordt afgewezen omdat ze ook vol zitten met andere taken en wanneer ze de juiste beschrijving en vereiste details niet vinden in het bugrapport, ongeacht hoe kritiek is dat de bug naar verwachting wordt gemarkeerd als geweigerd.
Aanbevolen literatuur => Hoe schrijf je een goed bugrapport? Tips en trucs.
Real-life voorbeeld: Je moet de auto ontgrendelen, gaan zitten en beginnen door de sleutels met de klok mee te bewegen…. De auto startte niet en je bent dus van streek. Werd u niet geïnstrueerd om op benzine te controleren? Oh, een fout in de handleiding, omdat er vanuit gegaan werd dat je zeker zult begrijpen dat het standaard gecontroleerd moet worden.
# 10) Niet-reproduceerbare bugs:
Tijdens het rapporteren van een bug heeft u zich nooit het belang van de reproduceerbaarheid van de bug gerealiseerd. Gewoon ervoor zorgen of de bug altijd reproduceerbaar is of willekeurig verschijnt, kan uren werk en nog een afgewezen bug besparen.
Real-life voorbeeld: Waar zou de dokter op letten als je klaagt over de ruwe verkoudheid, maar hij vindt geen symptomen. Oh, ik was gewoon hard aan het niezen , zal de situatie niet verbeteren.
Gevolgtrekking
Meestal stelt onze menselijke aard ons in staat negatief te denken wanneer de gerapporteerde bug wordt afgewezen. Echt, ontwikkelaars zien geen specifieke reden om de bug af te wijzen als deze geldig is.
Concentreer u dus de volgende keer niet op het aantal bugs. Concentreer u op kwalitatieve bugs met de juiste details, want het gaat er uiteindelijk om hoe u heeft geholpen bij het verbeteren van de kwaliteit van het product en niet hoeveel bugs u heeft gerapporteerd.
Lees ook => Hoe kunnen alle bugs worden opgelost zonder het label ‘Ongeldige bug’?
Over de auteur: Dit nuttige artikel is geschreven door STH-teamlid Bhumika Mehta. Ze is een projectleider met meer dan 7 jaar ervaring in het testen van software.
Veel plezier met testen! Zoals gewoonlijk wachtend op uw mening hierover.
Aanbevolen literatuur
- Hoe kunnen alle bugs worden opgelost zonder een 'ongeldige bug'-label?
- Waarom is bugrapportage een kunst die door elke tester moet worden geleerd?
- De kunst van het rapporteren van fouten: hoe u uw bugs op de markt kunt brengen en verhelpen?
- Waarom heeft software bugs?
- 7 soorten softwarefouten die elke tester moet weten
- 11 manieren waarop u weet dat u een tester bent ...
- Voorbeeld bugrapport
- 5 manieren om een gedurfde en zelfverzekerde softwaretester te zijn