Què cal incloure en un informe d'errors?



Com escriure un bon informe d'errors

Escriure un bon informe de defectes o d’errors serveix per identificar i resoldre els problemes ràpidament. En aquest post, enumerem els elements comuns que normalment s’inclouen en un informe d’errors.

En cap ordre concret:

Identificador de defecte, ID

L'identificador és molt important per poder referir-se al defecte en els informes. Si s’utilitza una eina d’informació de defectes per registrar defectes, l’identificador sol ser un número únic generat pel programa que augmenta per registre de defectes.


Resum

El resum és una descripció general del nivell alt del defecte i del fracàs observat. Aquest breu resum hauria de ser un dels aspectes més destacats del defecte, ja que això és el que primer veuen els desenvolupadors o revisors a l'informe d'errors.

Descripció

La naturalesa del defecte s’ha d’escriure amb claredat. Si un desenvolupador que revisa el defecte no pot entendre i no pot seguir els detalls del mateix, és probable que l’informe es retorni al comprovador per demanar-li més explicacions i més detalls que causen retards en la resolució del problema.


La descripció hauria d’explicar exactament els passos a seguir per reproduir el defecte, juntament amb quins van ser els resultats esperats i quin va ser el resultat del pas de prova. L'informe hauria de dir en quin pas es va observar el fracàs.

Gravetat

La gravetat del defecte mostra la gravetat del defecte en termes de danys a altres sistemes, empreses, medi ambient i la vida de les persones, en funció de la naturalesa del sistema d'aplicació. Normalment, les severitats es classifiquen i es classifiquen en 4 o 5 nivells, segons la definició de l’organització.

  • S1 - Crític: Això vol dir que el defecte és un tap de demostració amb danys potencials elevats i que no té solucions per evitar el defecte. Un exemple pot ser que l'aplicació no s'iniciï en absolut i faci que el sistema operatiu s'apagui. Això requereix atenció immediata, acció i correcció.
  • S2 - Greus: Això vol dir que falten algunes funcionalitats importants de les aplicacions o no funcionen i no hi ha cap solució alternativa. Per exemple, una aplicació de visualització d'imatges no pot llegir alguns formats d'imatge habituals.
  • S3 - Normal: Això vol dir que algunes funcionalitats importants no funcionen, però existeix una solució alternativa per utilitzar-la com a solució temporal.
  • S4 - Cosmètica / Millora: Això significa que la fallada causa molèsties i molèsties. Per exemple, hi ha un missatge emergent cada 15 minuts o sempre haureu de fer clic dues vegades sobre un botó GUI per realitzar l'acció.
  • S5 - Suggeriment: Normalment no es tracta d’un defecte ni d’un suggeriment per millorar una funcionalitat. Això pot ser GUI o preferències de visualització.

Prioritat

Un cop determinada la gravetat, el següent és veure com prioritzar la resolució. La prioritat determina la rapidesa amb què s’ha de corregir el defecte. La prioritat es refereix normalment a la importància empresarial, com ara l’impacte en el projecte i el probable èxit del producte al mercat. Igual que la gravetat, la prioritat també es classifica en 4 o 5 nivells.

  • P1 - Urgent: Vol dir que és extremadament urgent i requereix una resolució immediata
  • P2 - Alt: Requisit de resolució per a la pròxima versió externa
  • P3 - Mitjà: Resolució necessària per al primer desplegament (en lloc de tots els desplegaments)
  • P4 - Baix: Resolució desitjada per al primer desplegament o versions posteriors posteriors

Llegiu més sobre Severitat versus Prioritat


És important tenir en compte que un defecte amb una gravetat elevada també té una alta prioritat, és a dir, un defecte greu requerirà una alta prioritat per resoldre el problema el més ràpidament possible. Mai no hi pot haver un defecte de gravetat elevat ni de baixa prioritat. No obstant això, un defecte pot tenir una gravetat baixa, però té una alta prioritat.

Un exemple pot ser que el nom de l’empresa estigui mal escrit a la pantalla inicial mentre es llança l’aplicació. Això no provoca danys greus al medi ambient ni a la vida de les persones, però pot causar danys potencials a la reputació de l’empresa i perjudicar els beneficis empresarials.

Data i hora

La data i l’hora en què s’ha produït o s’ha notificat el defecte també és essencial. Normalment, això és útil quan voleu cercar defectes identificats per a una versió concreta del programari o des de l'inici de la fase de proves.

Versió i compilació del programari sotmès a prova

Això també és molt important. En la majoria dels casos, hi ha moltes versions de programari; cada versió té moltes correccions i més funcionalitats i millores a les versions anteriors. Per tant, és essencial tenir en compte quina versió del programari va mostrar el fracàs que estem informant. Sempre podem fer referència a aquesta versió del programari per reproduir l’error.


Informat per

Una vegada més, això és important, perquè si és possible que necessitem referir-nos a la persona que va causar el defecte, hem de saber amb qui contactar.

Requisit relacionat

Bàsicament, totes les funcions d’una aplicació de programari es poden rastrejar segons els requisits respectius. Per tant, quan s’observa un fracàs, podem veure quins requisits s’han vist afectats.

Això pot ajudar a reduir els informes de defectes duplicats, ja que si podem identificar el requisit font, si es registra un altre defecte amb el mateix número de requisit, potser no caldrà que el notifiquem de nou, si els defectes són de naturalesa similar.

Documents adjunts / proves

Qualsevol prova de l’error s’ha de capturar i presentar amb l’informe de defectes. Aquesta és una explicació visual de la descripció del defecte i ajuda el revisor i el desenvolupador a entendre millor el defecte.


Conclusió

En aquest article hem après quina informació hauríem d’incloure normalment en un informe d’errors. La creació d’un bon informe d’errors agilita l’anàlisi de la causa arrel i la solució de l’error.