10 reasons why your bugs are getting rejected
servidor privat de world of warcraft vanilla
No la vaig a estalviar. Va informar que va rebutjar 7 errors durant els darrers tres dies. Sé que fa servir rancors personals com a espasa professional ......
Un company d’equip estava fumant i la discussió es va incendiar de sobte quan un parell d’altres companys d’equip es van unir compartint la mateixa experiència amb altres desenvolupadors. La reunió de l'equip va convertir un punt de discussió sobre el rebuig d'errors. Després d’alguna discussió, tots vam decidir fer un exercici senzill per salvar-nos de la humiliació dels errors rebutjats en el futur.
Cadascun de nosaltres va començar a treure notes com a motius pel rebuig dels darrers 10 errors, denunciats i rebutjats. La llista d’aquestes notes de rebuig va resultar útil per entendre el futur seguiment de la notificació d’errors i quina era la suposició equivocada.
Rebuig d'errors i motius que hi ha al darrere
En lloc de revelar la llista, m'agradaria compartir els resultats de la llista. Aquí està -
# 1) Malentendre els requisits:
Per qualsevol motiu, si no entenguéssiu correctament el requisit, definiríeu definitivament el requisit mal interpretat en la implementació real i, quan no el trobareu, seria un error segons vosaltres, que finalment serà rebutjat.
Exemple de la vida real : Després de provar una recepta, vau comprovar que no tenia sabor, ja que no s'afegia sal, però no sabíeu que se suposava que s'havia d'afegir sal en el moment de servir-la, ja que pot afectar l'aspecte de la recepta.
# 2) Implementació del requisit:
Com a part d’una discussió anterior, era conscient que s’implementaria un requisit específic de manera XYZ. Però, mentre es desenvolupava, el desenvolupador va trobar que no era possible seguir el camí XYZ i, per tant, va seguir el camí ABC i això no us el va comunicar.
En última instància, informareu d’un error quan trobeu que el requisit no s’ha implementat de la manera que es va discutir.
Exemple de la vida real : Heu demanat al sastre que preparés una samarreta i quan se us va demanar el judici, el vau rebutjar dient que no hi trobàveu botons. Quan el sastre explica que posar botons a la part davantera hauria afectat l’aspecte general de la samarreta i, per tant, la posaria dins de la vora frontal, definitivament quedaria bocabadat.
# 3) No hi ha requisits clars:
Quan no hi ha requisits clars disponibles, tothom és lliure d'assumir el requisit a la seva manera i això condueix a una suposició a nivell personal. Quan veieu que aquesta suposició personal no es compleix, la marqueu com un error.
Exemple de la vida real : Cal dibuixar un cicle quan la professora va anunciar que esperava que els estudiants dibuixessin una bicicleta. Al cap de mitja hora, quan va comprovar el dibuix de tots, no va trobar ningú que s’ajustés a les seves expectatives. Tothom va prendre la vaga declaració a la seva manera i el resultat va ser un tricicle, un cicle infantil, massa cicles, un cicle amb la cadira de rodes, etc.
# 4) Canvi de requisit:
Un altre exemple de mala comunicació, la majoria de les vegades. Quan no es comunica als verificadors sobre els canvis de requisits, s’informaran més errors i, finalment, es rebutjaran.
Exemple de la vida real : Definitivament, rebutjaràs l’entrepà quan trobis que utilitzava pa de mel en lloc del pa de plàtan que has demanat. Com a mínim, sabíeu que la vostra parella va canviar el tipus de pa per fer la comanda mentre esteu al telèfon i, per descomptat, no li va semblar necessari compartir-lo amb vosaltres.
# 5) Comprensió de l'abast:
Mentre feu la prova, comenceu a provar alguna cosa que no s’ha de considerar que es pugui comprovar en un punt concret o que no estigui cobert pels criteris del producte; seràs víctima del rebuig d'errors.
Exemple de la vida real : Se suposa que heu d’escombrar una habitació i aquest és l’únic focus. Tot i això, si us queixeu del desordre de les altres àrees, definitivament no us faran cas.
# 6) Entorn de prova:
Una aplicació / producte és una combinació de molts requisits de maquinari i programari, tant majors com menors, i quan no s’utilitza l’entorn de prova adequat o falta alguna cosa a l’entorn de prova, es produeixen fallades de l’aplicació / producte i s’ha informat d’un error crític ...
El que passa a continuació és: investigació profunda, perquè la majoria de les vegades no ens preocupem de proporcionar detalls menors sobre l’entorn de prova que hem utilitzat i això augmenta la feina del desenvolupador. En última instància, l'error es rebutja.
Exemple de la vida real : Aquells deliciosos magdalenes que vas tastar a casa d’un amic abans d’un parell de dies eren increïbles i després de seguir la recepta els magdalenes no eren ni més a prop de la que tenies.
Bé, no se suposa que hauríeu d'utilitzar mantega rasa, ja que no hi havia mantega fresca, no s'havia d'afegir una mica de farina de gram, ja que pensàveu que podia afegir el gust, no se suposava que la cuinés a la paella com el forn. estava fora de funcionament.
quines són les etapes del sdlc
Lectura recomanada => Com preparar efectivament l ''entorn de prova'.
# 7) Dades de prova utilitzades:
Les dades de prova que s’utilitzaven per provar no coincidien amb un requisit.
Exemple de la vida real : Fins i tot després de saber que la calculadora és útil per al processament numèric si intenteu afegir caràcters especials i quan la calculadora respon inesperadament, creieu que no era adequada. De debò?
Lectura recomanada => Consells per dissenyar dades de prova i Tècniques de gestió de dades de proves .
# 8) Error duplicat:
Algú ja ha informat del mateix error i no us heu ocupat de comprovar-ne el mateix abans d’informar-lo. De nou el rebuig.
Exemple de la vida real: La persona d’atenció al client no estarà contenta quan rebi diverses trucades de reclamació del mateix producte de cada membre de la família. Pensaria que no n’hi havia prou amb una trucada.
# 9) Descripció incorrecta de l'error:
Quan el desenvolupador no pugui entendre el que intentàveu transmetre mitjançant l'informe d'errors, espereu que es rebutgi perquè també estan carregats amb altres tasques i quan no troben la descripció adequada i els detalls requerits a l'informe d'errors, per molt que sigui Si l'error és crític, s'espera que es marqui com a rebutjat.
Lectura recomanada => Com s'escriu un bon informe d'errors? Consells i trucs.
Exemple de la vida real: Heu de desbloquejar el cotxe, haureu d’estar assegut i hauríeu de començar movent les tecles en el sentit de les agulles del rellotge ... el cotxe no arrencava i, per tant, us molesteu. No us han donat instruccions de comprovar si hi ha benzina? Oh, un error al manual ja que suposava que segur que entendreu que s’hauria de comprovar per defecte.
aplicació de rellotge de temps lliure per a PC
# 10) Errors no reproduïbles:
Mentre informaves d’un error, mai no t’has adonat de la importància de la reproducibilitat de l’error. Només assegurar-se que l'error es reprodueixi sempre o aparegui a l'atzar pot estalviar hores de treball i un altre d'error rebutjat.
Exemple de la vida real: Què comprovaria el metge quan es queixés del fred fred, però no detecta cap símptoma? Oh, només esternudava fort , no millorarà la situació.
Conclusió
La majoria de les vegades, la nostra naturalesa humana ens permet pensar negativament quan es rebutja l’error informat. Realment, els desenvolupadors no veuen cap motiu específic per rebutjar l'error si és vàlid.
Per tant, la propera vegada, no us centreu en el recompte d’errors. Centreu-vos en els errors qualitatius amb els detalls adequats perquè, en última instància, l’important és com heu ajudat a millorar la qualitat del producte i no quants errors vau informar.
A més, llegiu => Com podeu resoldre tots els vostres errors sense cap etiqueta 'Error no vàlid'?
Sobre l'autor: Aquest útil article està escrit pel membre de l'equip de STH, Bhumika Mehta. És cap de projecte amb més de 7 anys d’experiència en proves de programari.
Bones proves! Com és habitual esperant les vostres opinions sobre el mateix.
Lectura recomanada
- Com podeu resoldre tots els vostres errors sense cap etiqueta 'Error no vàlid'?
- Per què la notificació d'errors és un art que tots els provadors haurien d'aprendre?
- L’art d’informar d’errors: com comercialitzar i solucionar els vostres errors?
- Per què el programari té errors?
- 7 tipus d'errors de programari que tots els provadors haurien de conèixer
- 11 maneres de saber que ets un provador ..
- Exemple d’informe d’errors
- 5 maneres de ser un provador de programari audaç i segur