Taula de continguts
Rols amb permisos que poden fer ús de la guia explicativa: Qui pot fer ús de la guia?
| Administrador | Project Leader | Responsable de qualitat | Desenvolupadors | Usuaris | Lectors |
|---|---|---|---|---|---|
| Executar test, Crear , Editar i esborrar tots els tipus de issue | Executar test, Crear , Editar i esborrar tots els tipus de issue | Executar test, Crear , Editar i esborrar tots els tipus de issue | Executar test, Crear , Editar i esborrar tots els tipus de issue | Executar test | Només visibilitat |
Guia de bones pràctiques per a la gestió de defectes en Jira
Objectiu de la Guia
Aquesta guia té com a objectiu proporcionar un conjunt de bones pràctiques per a la gestió de defectes en Jira, amb l’objectiu d’homogeneïtzar la manera de treballar dins dels equips i garantir que els defectes es gestionin de manera eficient i coherent. Per tant, hem de saber el següent:
Tipus de defectes a Jira
Hi ha dos tipus de defectes:
Defect: És qualsevol desviació negativa del funcionament respecte al comportament acceptable, esperat o habitual d’una funcionalitat, aplicació o sistema. Pot ser originat per diferents causes i pot tenir diverses conseqüències, com mal funcionament, pèrdua de qualitat o deficiències de seguretat. Aquest tipus de problema es registra com a un defecte principal.
Sub-Defect: És un problema més específic que forma part d’un defecte principal. Sol ser una causa concreta d’un problema més gran o un detall tècnic que contribueix a l’error general.
Maneres de crear un Defecte en Jira
Es poden crear defectes a Jira de diverses maneres, depenent del context en què es detecta l’error.
Des de la pàgina principal de Jira:
Errors generals detectats fora del procés de test, com problemes reportats per usuaris.
- Utilitza el botó Create situat al menú superior.
- Selecciona el tipus d’issue Defecte o Bug (Segons el tipus de projecte que estiguis treballant, Waterfall o Agile)
- Omple els camps obligatoris com Summary, Description, Affects Version/s i Fix Version/s.
Des d’un Test Execution:
Ideal per a errors trobats durant l’execució de proves. Ja que quan es crea des d’aquí es vincula directament a l’execució del test. D’aquesta manera, es manté una traçabilitat clara entre el test que ha fallat i el defecte associat, permetent un seguiment més efectiu i precís del problema.
- Normalment es crea com a Defect/Sub-Defect per mantenir la relació directa amb el test fallit.
- Disposem de l’opció Add Defects per associar defectes ja existents, útil quan el mateix problema ha estat identificat en altres proves o fases del projecte.
Quan crear un Defect o un Sub-Defect
Defecte
- Si l’error indica un problema general que afecta una funcionalitat completa o un mòdul del sistema.
- Quan no s’ha identificat encara l’origen exacte del problema i pot tenir múltiples causes.
- Si l’impacte és ampli i afecta a diversos aspectes del sistema.
En la majoria del casos, quan es troba un error, aquest és el més utilitzat de forma estandarditzada.
Exemple d’un error creat en una Test Execution:
Sub-Defect
- Si l’error està clarament relacionat amb un defecte principal que ja ha estat identificat.
- Quan és una causa específica d’un problema més gran.
- Si és un detall més tècnic que afecta a un component específic del sistema.
Al seleccionar Sub-Defect Issue Type, tenim disponibles els següents tipus de sub-defectes:
Tipus de Sub-Defect
- Sub Test Execution: Utilitzat per a errors específicament relacionats amb l’execució de proves. S’utilitza quan l’error es detecta durant una validació de test i es vol mantenir una traçabilitat clara entre el test fallit i el defecte que l’ha causat. Això permet identificar ràpidament quines proves han fallat a causa d’un defecte i gestionar-ne la resolució de manera més eficient.
Exemple: Durant la validació del procés d’inscripció escolar, es va executar un test que verifica que, després de completar correctament tots els camps del formulari i fer clic a “Enviar”, es mostri un missatge de confirmació que diu “Confirma la inscripció a l’email”. En aquesta prova, es va detectar que el formulari no confirma correctament l’enviament, ja que no es mostra el missatge esperat o es presenta un error genèric.
Es crea un Sub Test Execution per documentar aquest error específic i fer-ne el seguiment com a part del procés de test. Aleshores, caldria tornar a executar aquesta prova per comprovar si el bug detectat en l’execució principal ha estat resolt. Tot i que es pot fer amb un Sub Test Execution per validar específicament el defecte, això no substitueix la necessitat de repetir els tests principals que contemplen els diferents escenaris per garantir que la correcció no ha introduït nous errors.
Sub-defect creat com: Error en la confirmació del formulari d’inscripció escolar.
- Condició DoD Release: Error vinculat a condicions de finalització (Definition of Done) específiques abans d’un llançament. Aquest tipus de sub-defecte es crea quan es detecta que no es compleixen tots els criteris necessaris per considerar una funcionalitat com a completada, segons les expectatives definides pel projecte.
Exemple: Abans de llançar la funcionalitat del formulari d’inscripció escolar, es detecta que no s’han definit adequadament els missatges que es mostren als usuaris després d’enviar el formulari. Això inclou tant els missatges de confirmació com els missatges d’error, que són essencials per oferir una experiència d’usuari clara i coherent.
Si hi ha un error de xarxa, el missatge hauria de ser específic, com “No es pot connectar amb el servidor. Si us plau, intenta-ho de nou més tard.” En cas d’un error de validació, el missatge ha de ser clar sobre què falta o és incorrecte, com “Alguns camps no són vàlids. Revisa la informació introduïda.”
Sub-defect creat com: DoD - Definir missatge d’error en el formulari d’inscripció escolar.
- Subtasca: Problemes més tècnics o específics que estan directament relacionats amb un defecte principal. S’utilitza per desglossar un problema més gran en components més petits.
Exemple: Un defecte indica que l’aplicació no carrega correctament les dades en el panell d’usuari. Es crea una subtasca per investigar si el problema és causat per una configuració incorrecta del servidor de dades.
Sub-defect creat com: Investigació de l’error en la confirmació del formulari d’inscripció escolar, també podrien ser subtasques més detallades com: Avaluació dels mecanismes de validació de dades, Revisió dels logs del servidor, Comprovació de la integritat de les rutes i endpoint, Depuració de la lògica de confirmació al frontend.
Els defectes principals es consideren resolts només quan tots els subdefectes associats han estat solucionats i verificats per garantir que la funcionalitat està completament restaurada.
Camps importants per a la gestió dels Defects/ Sub-Defects
| Camp | Descripció | Context d’ús |
|---|---|---|
| Assignee | Persona responsable de resoldre el sub-defecte. | Assegura que cada sub-defecte té un responsable clar per al seu seguiment. |
| Fix Version/s | Versió en la qual es preveu que el sub-defecte serà solucionat. En el cas que no se sap en quina versió serà, aquest camp es quedarà sense aplicar fins a conèixer la versió que realitzarà la solució. | Permet planificar la resolució del sub-defecte dins d’una versió específica del producte. |
| Affects Version/s | Versió en la qual es va identificar originalment el sub-defecte. | Ajuda a traçar l’origen del problema i avaluar l’impacte en versions anteriors. |
| Description | Detall del problema, incloent-hi passos per reproduir-lo, impacte i condicions en què es presenta. | Millora la comprensió del problema per part dels desenvolupadors i testers. |
Diferenciació entre “Affects versions” i “Fix versions”
| Campo | Propòsit | Contexto d’Ús |
|---|---|---|
| Affects Version | Indica en quina versió del programari es va identificar originalment el problema o bug. És útil per rastrejar en quina versió va començar un error. | Utilitzat principalment per gestionar errors i problemes (Bugs), així com per entendre l’impacte d’un problema en diferents versions. |
| Fix Version | Defineix en quina versió (release) s’espera que el problema o característica es resolgui o s’inclogui. És essencial per planificar llançaments i gestionar el progrés de les versions del programari. | Principalment utilitzat en històries, tests executions, tasques, errors i èpiques (utilitzats en projectes agile) per planificar què es lliurarà o s’aplicarà en dites versió del producte. |
Exemple pràctic a Test Execution: Un test execution fallit en la versió DW_V1.0 del sistema però que serà solucionat a la versió DW_V1.1, hauria de tenir “Affects versions” configurat com DW_V1.0 i “Fix versions” com DW_V1.1.
Exemple pràctic a Defect: Un defecte descobert en la versió DW_V1.1 del sistema però que serà solucionat a la versió DW_V2.0, hauria de tenir “Affects versions” configurat com DW1.1 i “Fix versions” com DW_2.0.
