defect management process
Introducció al procés de gestió de defectes:
El procés i les proves més enfocats permetran que hi hagi menys programari erroni al mercat.
Prevenció de defectes és molt més eficaç i eficaç per reduir el nombre de defectes i també és molt rendible per solucionar els defectes trobats durant la primera etapa del procés de programari. La majoria de les organitzacions condueixen Descobriment de defectes , Eliminació de defectes i llavors Millora del procés que es coneix col·lectivament com a Procés de gestió de defectes .
Unix ordena preguntes i respostes d'entrevistes per a persones experimentades
Què aprendreu:
- Objectius del procés de gestió de defectes (DMP)
- Cicle de vida de la gestió de defectes
- Procés de gestió de defectes
- Conclusió
- Lectura recomanada
Objectius del procés de gestió de defectes (DMP)
A continuació es detallen els diversos objectius d’aquest procés:
- Prevenir el defecte
- Detecció precoç
- Minimitzeu l’impacte
- Resolució del Defecte
- Millora del procés
Abans d’explorar el procés de gestió de defectes, primer entenem-ho què és en realitat un defecte o un error?
Cicle de vida de la gestió de defectes
Quan un sistema proporciona un resultat diferent del requisit real del negoci, és a dir, quan hi ha una desviació del requisit real o original del negoci, podem dir que hi ha un defecte en el sistema / programari.
Quan l'equip de proves executa els casos de prova, es troba amb una situació en què el resultat real de la prova és diferent del resultat esperat. Aquesta variació es denomina a Defecte .
Bàsicament, un defecte de programari és una condició que no compleix els requisits de programari. El defecte és un error o un error que produeix un comportament inesperat o incorrecte al sistema.
Per gestionar els projectes de manera adequada, heu de saber com fer front al desenvolupament i la publicació, però juntament amb això també heu de saber com gestionar els defectes.
Imagineu-vos què passarà si l’equip de proves informa verbalment dels defectes i l’equip de desenvolupament també actualitza verbalment l’estat del defecte? El procés serà més complicat, ja que aquests defectes inclouen tots els defectes, com ara realment solucionats i que funcionen com s’esperava, solucionats però encara no funcionen, rebutjats, ajornats i el procés continua.
En el cas anterior, a mesura que augmenta el nombre de defectes i la comunicació es fa verbalment, la situació aviat serà molt pitjor. Per controlar i manejar el defecte eficaçment, necessiteu un cicle de vida adequat dels defectes.
El cicle de vida dels defectes garanteix que el procés sigui uniforme i estandarditzat. Un defecte aconsegueix diferents estats en el cicle de vida. Després de trobar un defecte, passa per diverses etapes durant la seva vida i es coneix comunament com Cicle de vida de defectes .
En general, el cicle de vida dels defectes comença a partir de l’etapa en què l’equip de proves troba o aixeca el defecte i acaba quan es tanca un defecte, ja que s’assegura que un equip de desenvolupament no el reprodueixi o el rebutgi. El nombre d'estats pels quals passa un defecte varia d'un projecte a un altre.
Per llegir més:
Nota: El cicle inferior difereix lleugerament d’organització en organització.
El següent cicle de vida dels defectes cobreix tots els estats possibles:
- Sempre que l’equip de proves troba un defecte a l’aplicació, el planteja amb l’estat de “ NOU '.
- Quan un client de control de qualitat revisa un nou defecte i si el defecte és vàlid, l'estat del defecte seria ' Obert ”I està llest per ser assignat a l’equip de desenvolupament.
- Quan un client de control de qualitat assigna el defecte al desenvolupador corresponent, l'estat del defecte es marcaria com ' Assignat ”. Un desenvolupador hauria de començar a analitzar i solucionar el defecte en aquesta etapa.
- Quan el desenvolupador creu que el defecte no és autèntic o vàlid, el desenvolupador rebutja el defecte. L'estat del defecte es marca com a ' Rebutjada ”I assignat de nou a l’equip de proves.
- Si el defecte registrat es repeteix dues vegades o tots dos defectes reportats tenen resultats i passos similars per reproduir-se, es canvia un estat de defecte a ' Duplicat '.
- Si hi ha alguns problemes o obstacles a la versió actual per solucionar un defecte concret, el defecte es prendria a les properes versions en lloc de la versió actual i es marcarà com a ' Diferit 'O' Ajornat '.
- Quan un desenvolupador no pot reproduir el defecte seguint els passos esmentats a 'Passos per reproduir' per l'equip de proves, el desenvolupador pot marcar el defecte com a ' No es pot reproduir ” . En aquesta etapa, l’equip de proves hauria de proporcionar passos detallats de reproducció a un desenvolupador.
- Si el desenvolupador no té clars els passos per reproduir proporcionats per un control de qualitat per reproduir el defecte, pot marcar-lo com a ' Necessiteu més informació ”. En aquest cas, l’equip de proves ha de proporcionar els detalls necessaris a l’equip de desenvolupament.
- Si un defecte ja és conegut i actualment present a l'entorn de producció, el defecte es marca com a ' Defecte conegut '.
- Quan un desenvolupador fa els canvis necessaris, el defecte es marca com a ' Fixat '.
- Ara el desenvolupador passa el defecte a l'equip de proves per verificar-lo, de manera que el desenvolupador canvia l'estat com a ' A punt per tornar a provar '.
- Si el defecte no té més problemes i es verifica correctament, el provador el marca com a ' Tancat '.
- Mentre es torna a provar el defecte si el comprovador ha trobat que, el defecte encara es pot reproduir o parcialment solucionat, el defecte es marcarà com a ' Reobert ”. Ara el desenvolupador ha de tornar a examinar aquest defecte.
Un cicle de vida de defectes ben planificat i controlat proporciona el nombre total de defectes trobats en una versió o en totes les versions. Aquest procés estandarditzat proporciona una imatge clara de com s’ha escrit el codi, de com s’ha realitzat correctament la prova, de com s’ha alliberat el defecte o el programari, etc. Això reduirà el nombre de defectes en la producció en trobar-ne els defectes. fase en si.
Procés de gestió de defectes
A continuació s’explica detalladament el procés de gestió de defectes.
# 1) Prevenció de defectes:
Prevenció de defectes és el millor mètode per eliminar els defectes en la fase inicial de les proves en lloc de trobar els defectes en la fase posterior i després solucionar-los. Aquest mètode també és rendible, ja que el cost necessari per solucionar els defectes trobats en les primeres etapes de les proves és molt baix.
Tot i això, no és possible eliminar tots els defectes, però almenys podeu minimitzar l'impacte del defecte i el cost per solucionar-los.
Els passos principals relacionats amb la prevenció de defectes són els següents:
inserció codi d'ordenació c ++
- Identificar el risc crític : Identifiqueu els riscos crítics del sistema que afectaran més si es produeixen durant les proves o en la fase posterior.
- Estimació de l'impacte esperat : Per a cada risc crític, calculeu quant seria l’impacte financer si el risc realment es trobés.
- Minimitzar l'impacte esperat : Un cop hàgiu identificat tots els riscos crítics, assumiu els principals riscos que poden ser perjudicials per al sistema si es troba i intenteu minimitzar o eliminar el risc. Per als riscos que no es poden eliminar, redueix la probabilitat d’ocurrència i el seu impacte financer.
# 2) Línia de base lliurable:
Quan un lliurable (sistema, producte o document) arriba a la fita predefinida, es pot dir que un lliurament és una línia de base. En aquest procés, el producte o el lliurament es mou d'una etapa a una altra i, a mesura que el lliurament es mou d'una etapa a una altra, els defectes existents en el sistema també es traslladen a la següent fita o etapa.
Per exemple, tingueu en compte un escenari de codificació, prova unitària i, a continuació, prova del sistema. Si un desenvolupador realitza proves de codificació i unitat, l'equip de proves realitza les proves del sistema. Aquí la codificació i les proves unitàries són una fita i les proves de sistemes són una altra fita.
Així doncs, durant les proves unitàries, si el desenvolupador troba alguns problemes, no es coneix com a defecte, ja que s’identifiquen abans de la data límit de la data límit. Un cop finalitzades les proves de codificació i unitat, el desenvolupador lliura el codi per a la prova del sistema i, a continuació, podeu dir que el codi és 'Baselined' i a punt per a la propera fita, aquí, en aquest cas, és la 'prova del sistema'.
Ara, si s’identifiquen els problemes durant les proves, s’anomena defecte, ja que s’identifica després de completar la fita anterior, és a dir, la codificació i la prova unitària.
Bàsicament, els lliuraments es basen quan s’acaben els canvis en els lliurables i s’identifiquen i esmenen tots els possibles defectes. A continuació, el mateix lliurable passa al següent grup que hi treballarà.
# 3) Descobriment de defectes:
És gairebé impossible eliminar tots els defectes del sistema i convertir-lo en un sistema lliure de defectes. Però podeu identificar els defectes abans d’hora abans que resultin més costosos per al projecte. Podem dir que el defecte descobert significa que es posa formalment en coneixement de l’equip de desenvolupament i, després d’analitzar-ho, l’equip de desenvolupament de defectes també l’ha acceptat com a defecte.
Els passos relacionats amb el descobriment de defectes són els següents:
- Troba un defecte : Identifiqueu els defectes abans que esdevinguin un problema important per al sistema.
- Notificar un defecte : Tan bon punt l’equip de proves detecta un defecte, la seva responsabilitat és fer conscient a l’equip de desenvolupament que hi ha un problema identificat que cal analitzar i solucionar.
- Reconeix el defecte : Un cop l'equip de proves assigni el defecte a l'equip de desenvolupament, és responsabilitat de l'equip de desenvolupament reconèixer el defecte i continuar solucionant-lo si es tracta d'un defecte vàlid.
# 4) Resolució de defectes:
En el procés anterior, l'equip de proves ha identificat el defecte i ha informat a l'equip de desenvolupament. Ara aquí, l'equip de desenvolupament ha de procedir a la resolució del defecte.
Els passos per a la resolució de defectes són els següents:
- Prioritzeu el risc : L’equip de desenvolupament analitza el defecte i prioritza la solució del defecte. Si un defecte té més impacte en el sistema, doncs, la fixació del defecte serà prioritària.
- Solucioneu el defecte : Basat en la prioritat, l’equip de desenvolupament corregeix el defecte, primer es resolen els defectes de prioritat més alta i al final s’arreglen els defectes de prioritat inferior.
- Informeu de la resolució : És responsabilitat de l’equip de desenvolupament assegurar-se que l’equip de proves tingui coneixement de quan es solucionen els defectes i de com s’ha solucionat el defecte, és a dir, canviant un dels fitxers de configuració o fent alguns canvis de codi. Això serà útil perquè l'equip de proves entengui la causa del defecte.
# 5) Millora del procés:
Tot i que en el procés de resolució de defectes els defectes es prioritzen i es solucionen, des de la perspectiva del procés, no vol dir que els defectes de menor prioritat no siguin importants i que no afectin molt al sistema. Des del punt de vista de la millora del procés, tots els defectes identificats són els mateixos que un defecte crític.
Fins i tot aquests defectes menors donen l’oportunitat d’aprendre a millorar el procés i evitar que es produeixin defectes que puguin afectar el fracàs del sistema en el futur. La identificació d’un defecte que tingui un impacte menor en el sistema pot no ser un gran problema, però la incidència d’aquest defecte en el propi sistema és una gran cosa.
Per millorar el procés, tothom al projecte ha de mirar enrere i comprovar d’on es va originar el defecte. Basat en això, podeu fer canvis en el procés de validació, el document de base, el procés de revisió que pot detectar els defectes inicials del procés que siguin menys costosos.
Conclusió
El procés de gestió de defectes s'ha de seguir durant el procés general de desenvolupament de programari i no només per a proves específiques o activitats de desenvolupament.
Si es troba un defecte en la fase de proves, es pot plantejar la pregunta que si el defecte es detecta en aquesta fase, què passa amb els altres defectes que hi ha al sistema i que poden provocar un error del sistema si es produeix i encara no es descobreix.
Per tant, tots els processos, com ara el procés de revisió, les proves estàtiques, la inspecció, etc., s’han de reforçar i tots els participants del projecte haurien de ser seriosos sobre el procés i contribuir sempre que sigui necessari. L'alta direcció de l'organització també ha d'entendre i donar suport al procés de gestió de defectes.
Els enfocaments de proves, el procés de revisió, etc., s’han de triar segons l’objectiu del projecte o el procés organitzatiu.
Espero que aquest article informatiu sobre el procés de gestió de defectes us sigui d’immensa ajuda.
Lectura recomanada
- Què és la tècnica de proves basades en defectes?
- Procés de triatge de defectes i maneres de gestionar la reunió de triatge de defectes
- Què és el cicle de vida de defectes / errors en les proves de programari? Tutorial del cicle de vida de defectes
- Tutorial Bugzilla: Tutorial pràctic de l'eina de gestió de defectes
- Mètodes i tècniques de prevenció de defectes
- Tutorial de l'eina de gestió de defectes de l'IBM Rational Team
- Com reproduir un defecte no reproduïble i fer que el vostre esforç de prova valgui la pena
- Les proves de programari es basen en idees (i com generar-les)