defect severity priority testing with examples
En aquest tutorial, aprendreu què és la gravetat i la prioritat dels defectes a les proves, com definir els nivells de prioritat i gravetat dels defectes amb exemples per entendre el concepte amb claredat.
També tractarem detalladament com classificar els defectes en diferents cubs i la seva rellevància en el cicle de vida dels defectes. També cobrirem el paper crucial de la classificació amb un conjunt d’exemples en directe.
Arxivar defectes és molt integral forma part del cicle de vida de les proves de programari . Hi ha diverses pràctiques recomanades definides per a Informes de defectes efectius per Internet o en organitzacions.
Què aprendreu:
- Visió general del seguiment de defectes
Visió general del seguiment de defectes
Un dels aspectes importants del cicle de vida dels defectes a nivell genèric inclou el seguiment dels defectes. Això és important perquè els equips de prova obren diversos defectes en provar un programari que només es multiplica si el sistema concret que es prova és complex. En aquest escenari, gestionar aquests defectes i analitzar-los per provocar el tancament pot ser una tasca descoratjadora.
En línia amb els processos de manteniment de defectes, quan un provador presenta un defecte, a part del mètode / descripció per reproduir el problema vist, també ha de proporcionar alguna informació categòrica que ajudaria a classificar el defecte inexactament. Això, al seu torn, ajudaria a processos eficients de seguiment / manteniment de defectes i també constituiria la base per a un temps de resposta més ràpid dels defectes.
Els dos paràmetres principals que constitueixen la base per a un seguiment i resolució efectius de defectes són:
- Prioritat de defecte en les proves
- Gravetat dels defectes a les proves
Sovint són un concepte confús i s’utilitzen gairebé indistintament no només entre els equips de prova, sinó també els equips de desenvolupament. Hi ha una línia fina entre els dos i és important entendre que de fet hi ha diferències entre tots dos.
Entenem breument les definicions teòriques dels dos paràmetres de la secció següent.
Què és la gravetat i la prioritat dels defectes?
La prioritat segons la definició anglesa s’utilitza en la comparació de dues coses o condicions, en què s’ha de donar una importància més que les altres i s’ha d’abordar / resoldre primer abans de passar a les següents. Per tant, en el context dels defectes, la prioritat d’un defecte indicaria la urgència amb què s’hauria de corregir.
La gravetat segons la definició anglesa s’utilitza per descriure la gravetat d’un fet indesitjable. Per tant, quan es tracta d’errors, la gravetat d’un error indicaria l’efecte que té en el sistema quant al seu impacte.
Qui els defineix?
QA classifica el defecte sota la gravetat adequada en funció de la complexitat i la criticitat dels defectes.
Totes les parts interessades en el negoci, inclosos els gestors de projectes, analistes empresarials i propietaris de productes, defineixen la prioritat dels defectes.
La figura següent mostra el paper de qui posseeix i classifica la criticitat i la gravetat dels defectes.
Com triar aquests nivells?
Com ja hem comentat, el paràmetre de gravetat l’avalua el verificador, mentre que el paràmetre de prioritat l’avalua principalment el gerent de producte o bàsicament l’equip de selecció. Tot i que aquest sigui el cas, la gravetat d’un defecte és definitivament un dels factors que governen i influeixen en la priorització del defecte. Per tant, és important com a provador seleccionar la gravetat adequada per evitar confusions amb els equips de desenvolupament.
Diferència entre gravetat i prioritat
La prioritat s'associa amb la programació i la 'gravetat' s'associa amb els estàndards.
'Prioritat' significa que es concedeix alguna cosa o que mereix una atenció prèvia; precedència establerta per ordre d’importància (o urgència).
La 'gravetat' és l'estat o la qualitat de ser greu; la severitat implica l'adhesió a estàndards rigorosos o principis alts i sovint suggereix duresa; la severitat està marcada per o requereix un estricte compliment d’uns estàndards rigorosos o d’uns principis elevats, Per exemple, un codi de comportament sever.
Les paraules prioritat i gravetat apareixen en el seguiment d’errors.
Hi ha disponibles diverses eines comercials de programari de seguiment / gestió de problemes. Aquestes eines, amb l’entrada detallada d’enginyers de proves de programari, proporcionen a l’equip informació completa perquè els desenvolupadors puguin entendre l’error, fer-se una idea de la seva 'gravetat', reproduir-lo i solucionar-lo.
Les correccions es basen en el projecte 'Prioritats' i 'Severitat' dels errors.
La 'gravetat' d'un problema es defineix d'acord amb l'avaluació del risc del client i es registra a l'eina de seguiment seleccionada.
El programari buggy pot afectar «greument» els horaris, cosa que, al seu torn, pot conduir a una reavaluació i renegociació de les «prioritats».
Què és la prioritat?
La prioritat, com el seu nom indica, consisteix a prioritzar un defecte en funció de les necessitats empresarials i de la gravetat del defecte. La prioritat significa la importància o la urgència de solucionar un defecte.
Mentre obre un defecte, el comprovador generalment assigna la prioritat inicialment mentre veu el producte des de la perspectiva de l'usuari final. En línia amb aquests, hi ha diferents nivells:
A grans trets, la prioritat dels defectes es pot classificar de la següent manera:
Prioritat núm. 1) Immediata / crítica (P1)
S'ha de solucionar immediatament en un termini de 24 hores. Això generalment es produeix en casos en què tota una funcionalitat està bloquejada i no es pot procedir a cap prova. O en alguns altres casos, si hi ha fuites de memòria significatives, el defecte generalment es classifica com a prioritat -1, cosa que significa que el programa / funció no es pot utilitzar en l'estat actual.
Qualsevol defecte que necessiti atenció immediata que afecti el procés de prova es classificarà en la categoria immediata
Tot el Gravetat crítica els defectes pertanyen a aquesta categoria (tret que l'empresa o els grups d'interès no tinguin la prioritat)
Prioritat 2) Alta (P2)
Un cop solucionats els defectes crítics, un defecte que tingui aquesta prioritat és el següent candidat que s'ha de corregir perquè qualsevol activitat de prova coincideixi amb els criteris de 'sortida'. Normalment, quan una característica no es pot fer servir com se suposa que és, a causa d'un defecte del programa, o que s'ha d'escriure un codi nou o, de vegades, fins i tot perquè s'ha de gestionar algun problema mediambiental mitjançant el codi, un defecte pot qualificar-se per a una prioritat 2 .
Aquest és el defecte o problema que s’hauria de resoldre abans de fer la versió. Aquests defectes s’haurien de resoldre un cop resolts els problemes crítics.
Tot el Major severitat els defectes entren en aquesta categoria.
Prioritat 3) Mitjana (P3)
Un defecte amb aquesta prioritat ha de ser discutit per solucionar-lo, ja que també podria tractar problemes de funcionalitat que no són segons les expectatives. De vegades, fins i tot els errors cosmètics com esperar el missatge d'error correcte durant la fallada podrien qualificar-se de defecte de prioritat 3.
Aquest defecte s'hauria de resoldre després de solucionar tots els errors greus.
Un cop fets els errors crítics i els d’alta prioritat, podem optar pels errors de prioritat mitjana.
Tot el Menor severitat els defectes entren en aquesta categoria.
Prioritat 4) Baixa (P4)
Un defecte amb poca prioritat indica que definitivament hi ha un problema, però no s’ha de solucionar perquè coincideixi amb els criteris de “sortida”. Tanmateix, cal solucionar-ho abans que es faci el GA. Normalment, alguns errors d'escriptura o fins i tot errors cosmètics, tal com es va comentar anteriorment, es podrien classificar aquí.
De vegades, també s'obren defectes amb prioritat baixa per suggerir algunes millores en el disseny existent o una sol·licitud per implementar una petita característica per millorar l'experiència de l'usuari.
Aquest defecte es pot resoldre en el futur i no necessita cap atenció immediata i Baixa gravetat els defectes entren en aquesta categoria.
Com ja s'ha comentat, la prioritat determina la rapidesa amb què ha de ser el temps de resposta dels defectes. Si hi ha diversos defectes, la prioritat decideix quin defecte s'ha de corregir i verificar immediatament contra quin defecte es pot corregir una mica més tard.
Què és la gravetat?
La gravetat defineix fins a quin punt un defecte concret pot crear un impacte en l'aplicació o el sistema.
La gravetat és un paràmetre per indicar la implicació del defecte al sistema: fins a quin punt és crític el defecte i quin és l’impacte del defecte sobre la funcionalitat de tot el sistema? La gravetat és un paràmetre establert pel provador mentre obre un defecte i té principalment el control del verificador. De nou, diferents organitzacions tenen eines diferents per utilitzar-les per a defectes, però a nivell genèric es tracta dels nivells de gravetat següents:
Per exemple, Penseu en els escenaris següents
- Si l'usuari intenta fer compres en línia i l'aplicació no es carrega o apareix el missatge del servidor no disponible.
- L'usuari realitza afegir un article al carretó, el nombre de quantitats afegides és incorrecte / s'afegeix un producte incorrecte.
- L’usuari realitza el pagament i, després del pagament, la comanda es manté al carret tal com s’ha confirmat en lloc de reservar.
- El sistema accepta la comanda, però finalment la cancel·la després de mitja hora per problemes.
- El sistema accepta el botó 'Afegeix a la cistella' només en fer doble clic en lloc d'un sol clic.
- El botó Afegeix a la cistella s’escriu com a Afegeix a la cistella.
Quina seria l'experiència de l'usuari si es pogués produir algun dels escenaris anteriors?
En general, els defectes es poden classificar de la següent manera:
# 1) Crítica (S1)
Un defecte que dificulta o bloqueja completament les proves del producte / característica és un defecte crític. Un exemple seria en el cas de les proves d’interfície d’usuari on, després d’haver passat per un assistent, la interfície d’usuari es penja en un panell o no va més enllà per activar la funció. O en alguns altres casos, quan la característica desenvolupada per si mateixa falta a la compilació.
Per qualsevol motiu, si l'aplicació falla o es torna inutilitzable / no pot continuar, el defecte es podria classificar en la gravetat crítica.
Qualsevol fallada catastròfica del sistema podria conduir l'usuari a la inutilització de les aplicacions i es podria classificar en la severitat crítica
Per exemple, Al proveïdor de serveis de correu electrònic com Yahoo o Gmail, després d’escriure el nom d’usuari i la contrasenya correctes, en lloc d’iniciar la sessió, el sistema es bloqueja o llança el missatge d’error, aquest defecte es classifica com a crític ja que aquest defecte fa que tota l’aplicació sigui inutilitzable.
L’escenari del punt 1 comentat anteriorment es podria classificar com a Defecte crític, ja que l’aplicació en línia queda completament inutilitzable.
# 2) Major (S2)
Qualsevol característica important implementada que no compleixi els requisits / casos d'ús i es comporti de manera diferent de l'esperada, es pot classificar en Gravetat major.
Un defecte important es produeix quan la funcionalitat funciona molt lluny de les expectatives o no fa el que hauria de fer. Un exemple podria ser: Digueu que s'ha de desplegar una VLAN al commutador i que utilitzeu una plantilla d'interfície d'usuari que activa aquesta funció. Quan falla aquesta plantilla per configurar la VLAN al commutador, es classifica com un inconvenient greu de la funcionalitat.
Per exemple, Al proveïdor de serveis de correu electrònic com Yahoo o Gmail, quan no es pot afegir més d'un destinatari a la secció CC, aquest defecte es classifica com a defecte major, ja que la funcionalitat principal de l'aplicació no funciona correctament.
El que s'espera el comportament de la secció CC al correu, hauria de permetre a l'usuari afegir diversos usuaris. Per tant, quan la funcionalitat principal de l’aplicació no funciona correctament o quan es comporta de manera diferent a l’esperada, és un defecte important.
Els escenaris dels punts 2 i 3 comentats anteriorment es podrien classificar com a Defecte Major, ja que s’espera que l’ordre passi sense problemes a la següent fase del cicle de vida de l’ordre, però en realitat varia en comportament.
Qualsevol defecte que pugui provocar una persistència incorrecta de les dades, problemes de dades o comportaments incorrectes de l’aplicació es podria classificar en general a la gravetat Major.
# 3) Menor / moderat (S3)
Qualsevol característica implementada que no compleixi els requisits / casos d'ús i es comporti de manera diferent de l'esperada, però l'impacte és insignificant fins a cert punt o no té un impacte important a l'aplicació, es pot classificar en Gravetat menor.
Un defecte moderat es produeix quan el producte o l’aplicació no compleix certs criteris o encara presenta un comportament antinatural, tot i que la funcionalitat en general no es veu afectada. Per exemple, al desplegament de plantilla VLAN anterior, es produiria un defecte moderat o normal quan la plantilla es desplegui correctament al commutador, però no hi ha cap indicació que s'enviï a l'usuari.
Per exemple, Al proveïdor de serveis de correu electrònic, com Yahoo o Gmail, hi ha l'opció anomenada 'Termes i condicions' i, en aquesta opció, hi haurà diversos enllaços sobre els termes i condicions del lloc web. Quan un dels diversos enllaços no funciona bé, s'anomena severitat menor, ja que només afecta les funcions menors de l'aplicació i no té un gran impacte en la usabilitat de l'aplicació.
L'escenari del punt 5 comentat anteriorment es podria classificar com a Defecte menor, ja que no hi ha pèrdua o fallada de dades en l'ordre del flux del sistema, sinó un lleu inconvenient pel que fa a l'experiència de l'usuari.
Aquest tipus de defecte comporta una pèrdua mínima de funcionalitat o experiència de l'usuari.
# 4) Baixa (S4)
Qualsevol defecte cosmètic, com ara errors ortogràfics o problemes d'alineació o carcassa de tipus de lletra, es pot classificar a Baixa gravetat.
Es produeix un error menor de baixa gravetat quan gairebé no afecta la funcionalitat, però encara és un defecte vàlid que s’hauria de corregir. Alguns exemples d'això poden incloure errors ortogràfics en missatges d'error impresos als usuaris o defectes per millorar l'aspecte d'una característica.
Per exemple, En el proveïdor de serveis de correu electrònic com Yahoo o Gmail, hauríeu notat la 'pàgina de llicència', si hi ha errors ortogràfics o desalineació a la pàgina, aquest defecte es classifica com a Baix.
L'escenari del punt 6 comentat anteriorment es podria classificar com a Defecte baix, ja que el botó Afegeix es mostra en una carcassa incorrecta. Aquest tipus de defecte no tindrà cap impacte en el comportament del sistema ni en la presentació de dades, ni en la pèrdua de dades ni en el flux de dades, ni tan sols en l'experiència de l'usuari, sinó que serà molt cosmètic.
Per resumir, la figura següent mostra l’amplia classificació de defectes basada en la gravetat i la prioritat:
Exemples
Com ja s'ha esmentat, atès que diferents organitzacions utilitzen diferents tipus d'eines per al seguiment de defectes i els seus processos relacionats, es converteix en un sistema de seguiment comú entre diversos nivells de gestió i el personal tècnic.
Atès que la gravetat del defecte està més a l'abast de la funcionalitat, l'enginyer de proves estableix la gravetat del defecte. De vegades, els desenvolupadors participen parcialment en la influència de la gravetat dels defectes, però sobretot depèn del comprovador, ja que avalua quant pot afectar una funció concreta en el funcionament general.
D’altra banda, a l’hora d’establir la prioritat dels defectes, tot i que inicialment, l’originador del defecte estableix la prioritat, el director de producte el defineix, ja que té una visió general del producte i la rapidesa amb què s’ha d’abordar un defecte concret. . Un provador no és la persona ideal per establir la prioritat del defecte.
Per sorprenent que sembli, hi ha dos exemples diferents de per què:
Exemple 1) Tingueu en compte que hi ha una situació en què l’usuari troba un error en la denominació del producte mateix o algun problema amb la documentació de la interfície d’usuari. Un provador normalment obriria un defecte petit / cosmètic i pot ser molt senzill de solucionar, però pel que fa a l’aspecte del producte / experiència de l’usuari, pot causar un impacte greu.
Exemple 2) Podrien haver-hi certes condicions en què es produeixi un defecte concret, que pot ser una possibilitat extremadament rara o nul·la d’atacar a l’entorn del client. Tot i que pel que fa a la funcionalitat, un provador pot semblar un defecte d’alta prioritat, tenint en compte la seva raresa d’aparició i el seu elevat cost de reparació, es classificaria com un defecte de baixa prioritat.
Per tant, en efecte, la prioritat de defecte generalment la defineix el gestor de productes en una reunió de 'triatge de defectes'.
Diferents nivells
La prioritat i la gravetat inclouen algunes classificacions que ajuden a determinar com s’ha de tractar el defecte. Hi ha moltes organitzacions diferents diferents eines de registre de defectes , de manera que els nivells poden variar.
Vegem els diferents nivells tant de prioritat com de gravetat.
- Alta prioritat, alta gravetat
- Alta prioritat, baixa gravetat
- Alta gravetat, baixa prioritat
- Baixa gravetat, baixa prioritat
La figura següent mostra la classificació de les categories en un sol fragment.
# 1) Alta gravetat i alta prioritat
Qualsevol error crític / cas empresarial important passa automàticament a aquesta categoria.
Qualsevol defecte a causa del qual les proves no puguin continuar a qualsevol preu o causi una fallada greu del sistema en aquesta categoria. Per exemple, si feu clic a un botó concret, no es carrega la funció en si mateixa. O realitzar una funció concreta fa caure el servidor de manera constant i provoca la pèrdua de dades. Les línies vermelles de la figura anterior indiquen aquest tipus de defectes.
Per exemple,
El sistema es bloqueja després d'efectuar el pagament o quan no podeu afegir els articles al carretó, aquest defecte es marca com a defecte d'alta gravetat i prioritat alta.
Un altre exemple seria la funció de divisa de caixers automàtics en què, després d’introduir el nom d’usuari i la contrasenya correctes, l’equip no distribueix diners sinó que dedueix els transferits del vostre compte.
# 2) Alta prioritat i baixa gravetat
Qualsevol defecte de gravetat lleu que pugui afectar directament l'experiència de l'usuari es promociona automàticament a aquesta categoria.
Els defectes que s'han de corregir però que no afecten l'aplicació pertanyen a aquesta categoria.
Per exemple, s'espera que la funció mostri un error particular a l'usuari respecte al seu codi de retorn. En aquest cas, funcionalment el codi generarà un error, però el missatge haurà de ser més rellevant per al codi de retorn generat. Les línies blaves de la figura indiquen aquest tipus de defectes.
Per exemple,
El logotip de l'empresa a la primera pàgina és incorrecte, es considera que és Prioritat alta i baixa gravetat defecte .
què és una eina de recopilació de dades
Exemple 1) Al lloc web de compres en línia quan s’escriu malament el logotip de FrontPage, per exemple, en lloc de Flipkart, s’escriu com a Flipkart.
Exemple 2) Al logotip del banc, en lloc d’ICICI, s’escriu com ICCCI.
En termes de funcionalitat, no afecta res, de manera que podem marcar-lo com a de baixa gravetat, però té un impacte en l’experiència de l’usuari. Aquest tipus de defecte s’ha de solucionar amb una alta prioritat tot i que tinguin un impacte molt menor en el costat de l’aplicació.
# 3) Alta gravetat i baixa prioritat
Qualsevol defecte que funcionalment no compleixi els requisits o tingui implicacions funcionals en el sistema, però que quedi al marge del seient del darrere per part dels grups d'interès quan es tracta de criticitat empresarial, passa automàticament a aquesta categoria.
Defectes que s'han de corregir però no immediatament. Això pot passar específicament durant les proves ad-hoc. Vol dir que la funcionalitat es veu afectada en gran mesura, però només s’observa quan s’utilitzen certs paràmetres d’entrada poc freqüents.
Per exemple, una funcionalitat concreta només es pot utilitzar en una versió posterior del firmware, de manera que, per comprovar-ho, el comprovador realment modifica la versió del sistema i realitza la prova i observa un greu problema de funcionalitat que és vàlid. En aquest cas, els defectes es classificaran en aquesta categoria amb línies roses, ja que normalment es preveu que els usuaris finals tinguin una versió superior del firmware.
Per exemple,
En un lloc de xarxes socials, si es publica una versió beta d’una nova característica amb pocs usuaris actius que utilitzen aquesta instal·lació a partir d’avui. Qualsevol defecte que es trobi en aquesta característica es pot classificar com a prioritat baixa, ja que la característica ocupa un lloc posterior a causa de la classificació empresarial com a no important.
Tot i que aquesta característica té un defecte funcional, ja que no afecta directament els clients finals, un interessat comercial pot classificar el defecte en prioritat baixa, tot i que té un impacte funcional sever a l’aplicació.
Es tracta d’un error d’alta gravetat, però es pot prioritzar a una prioritat baixa, ja que es pot corregir amb la següent versió com a sol·licitud de canvi. Els grups d'interès empresarials també donen prioritat a aquesta característica com una característica poc utilitzada i no afecten cap altra funció que tingui un impacte directe en l'experiència de l'usuari. Aquest tipus de defecte es pot classificar en el fitxer Alta gravetat però baixa prioritat categoria.
# 4) Baixa gravetat i baixa prioritat
Qualsevol error ortogràfic / lletra de lletra / desalineació al paràgraf del 3rdo 4thpàgina de l'aplicació i no a la pàgina principal / portada / títol.
Aquests defectes es classifiquen en les línies verdes tal com es mostra a la figura i es produeixen quan no hi ha cap impacte funcional, però encara no compleixen els estàndards en un grau petit. Generalment es classifiquen aquí els errors cosmètics o les dimensions d'una cel·la en una taula de la IU.
Per exemple,
Si la política de privadesa del lloc web té un error ortogràfic, aquest defecte es defineix com a Baixa gravetat i baixa prioritat.
Pautes
A continuació es mostren algunes pautes que tots els verificadors han de provar de seguir:
- En primer lloc, entendre bé els conceptes de prioritat i gravetat. Eviteu confondre els uns amb els altres i utilitzar-los indistintament. En línia amb això, seguiu les directrius de gravetat publicades per la vostra organització / equip perquè tothom estigui a la mateixa pàgina.
- Trieu sempre el nivell de gravetat en funció del tipus de problema, ja que afectarà la seva prioritat. Alguns exemples són:
- Per a un problema crític, com ara que tot el sistema cau i no es pot fer res, no s'hauria d'utilitzar aquesta gravetat per solucionar els defectes del programa.
- Per a un problema important, com ara en casos en què la funció no funciona com s'esperava, aquesta gravetat es podria utilitzar per abordar noves funcions o millorar el funcionament actual.
Recordeu que l’elecció del nivell de gravetat adequat, al seu torn, donarà el defecte, és la prioritat deguda.
- Com a provador - entendre com una funcionalitat particular, més aviat aprofundir - entendre com afectaria l'usuari final un cas concret o un cas de prova. Això implica molta col·laboració i interacció amb l'equip de desenvolupament, analistes de negocis, arquitectes, responsable de proves i responsable de desenvolupament. En els vostres debats, també heu de tenir en compte el temps que trigaríeu a corregir el defecte en funció de la seva complexitat i del temps per verificar-lo.
- Finalment , sempre és el propietari del producte qui posseeix el poder de veto de l'alliberament que s'hauria de solucionar el defecte. Tanmateix, atès que les sessions de triatge de defectes contenen membres variats per presentar la seva perspectiva sobre el defecte per cas, en un moment en què els desenvolupadors i els verificadors estan sincronitzats, segurament ajudarà a influir en la decisió.
Conclusió
Tot i que s’obren defectes, és responsabilitat del verificador assignar la gravetat adequada als defectes. La gravetat incorrecta i, per tant, el mapatge de prioritats poden tenir implicacions molt dràstiques en el procés global de STLC i el producte en general. En diverses entrevistes de feina: es fan diverses preguntes sobre prioritat i gravetat per assegurar-vos que, com a provador, teniu aquests conceptes impecablement clars a la ment.
A més, havíem vist exemples en directe de com classificar el defecte en diversos dipòsits de severitat / prioritat. A hores d’ara, m’agradaria que tinguéssiu prou aclariments sobre la classificació de defectes, tant en els dipòsits de gravetat com de prioritat.
Espero que aquest article sigui una guia completa per comprendre els nivells de prioritat i gravetat dels defectes. Feu-nos saber els vostres pensaments / preguntes als comentaris següents.
Lectura recomanada
- Què és la tècnica de proves basades en defectes?
- Què és el cicle de vida de defectes / errors en les proves de programari? Tutorial del cicle de vida de defectes
- Procés de gestió de defectes: com gestionar eficaçment un defecte
- Com reproduir un defecte no reproduïble i fer que el vostre esforç de prova valgui la pena
- 7 Principis de proves de programari: agrupament de defectes i principi de Pareto
- Mètodes i tècniques de prevenció de defectes
- Diferència exacta entre verificació i validació amb exemples
- 3 estratègies per fer front a un defecte de bloqueig