Menú

Seguiment d'errors del projecte en viu, mètriques de prova i tancament de prova: dia 6 de formació gratuïta sobre control de qualitat

live project bug tracking

Proveu El Nostre Instrument Per Eliminar Problemes

Aquesta és la part final del nostre ' Formació en proves de programari en un projecte en viu ”Sèrie.

Es tractarà de defectes i també d’alguns temes restants que marcaran la finalització de la fase d’execució de la prova del STLC.

A la article anterior , mentre s'estava executant la prova, ens vam trobar amb una situació en què no es va complir el resultat esperat del cas de prova. A més, vam identificar algun comportament inesperat durant les proves exploratòries.

Seguiment d

Què passa quan ens trobem amb aquestes desviacions?

Evidentment, hem de gravar-los i fer-ne un seguiment per assegurar-nos que aquestes desviacions es gestionen i, finalment, es corregiran a l’automòbil.

# 1) Aquestes desviacions es denominen Defectes / errors / problemes / incidents / errors / falles.

# 2) Tots els casos següents es poden registrar com a defectes

  • Falta requisits
  • Requisits de treball incorrectes
  • Requisits addicionals
  • Incongruències del document de referència
  • Problemes relacionats amb el medi ambient
  • Suggeriments de millora

# 3) La gravació de defectes es fa principalment en fulls Excel o mitjançant l’ús d’un programa / eina de gestió de defectes. Per obtenir informació sobre com gestionar defectes mitjançant eines, proveu d’utilitzar els enllaços següents:

Què aprendreu:

Com registrar els defectes eficaçment

Ara intentarem veure com registrar els defectes que hem trobat a l'article anterior en un full Excel. Com sempre, és important triar un format o plantilla estàndard.

implementació de la cua de prioritat c ++

Normalment, les columnes següents formen part de l'informe de defectes:

  • Identificador de defecte: Per a una identificació única.
  • Descripció del defecte: És com un títol per descriure el tema breument.
  • Mòdul / secció de l'AUT: Això és opcional, només per afegir més claredat quant a indicar l'àrea de l'automòbil on s'ha trobat el problema.
  • Passos per reproduir: Quina és la seqüència exacta d'operacions que es realitzaran a l'automàtica per recrear l'error? A més, si hi ha dades d’entrada específiques per al problema, també s’ha d’introduir informació.
  • Gravetat: Per indicar la intensitat del problema i, eventualment, l'impacte que això podria tenir en el funcionament de l'AUT. Les directrius sobre com assignar i quins valors assignar en aquest camp es poden trobar al document del pla de prova. Per tant, consulteu el document Document del pla de proves de l'article 3 .
  • Estat: Es tractarà més en l'article.
  • Captura de pantalla: Una instantània de l'aplicació per mostrar l'error quan s'ha produït.

Aquests són alguns dels camps 'imprescindibles'. Aquesta plantilla es pot ampliar (per exemple, per incloure el nom del comprovador que ha informat del problema) o contractar-la ( Per exemple, eliminat el nom del mòdul) segons calgui.

Seguint les directrius anteriors i utilitzant la plantilla anterior, un registre / informe de defectes de mostra podria tenir aquest aspecte:

Exemple d’informe de defectes per al projecte OrangeHRM Live:

Informe de defectes d

=> Feu clic aquí per descarregar l’informe de defectes del projecte en directe

A continuació es mostra l’exemple d’informe de defectes creat a l'eina de gestió de proves qTest: (Feu clic a la imatge per ampliar-la)

Exemple d’informe de defectes

Els defectes no són bons quan els registrem i els guardem per a nosaltres. Haurem d’assignar-los en l’ordre correcte perquè els equips interessats hi actuïn. El procés: a qui assignar o a quin ordre seguir també es pot trobar al document del pla de proves. És sobretot similar a (Feu clic a la imatge per ampliar-la)

Cicle de defectes:

Cicle de vida de defectes 1

A partir del procés anterior, es pot assenyalar que els errors passen per diferents persones i diferents decisions en el procés d’identificar-se fins a corregir-les. Per fer un seguiment i establir transparències quant a quin estat es troba exactament un error determinat, s'utilitza un camp 'Estat' a l'informe d'errors. Tot el procés es coneix com a 'cicle de vida d'errors'. Per obtenir més informació sobre tots els estats i els seus significats, consulteu-ho Tutorial del cicle de vida d'errors .

Alguns indicadors durant el seguiment d'errors

  • Quan som nous en un equip creatiu / projecte / AUT, sempre és millor fer-ho discutiu el tema que hem trobat amb un company per assegurar-nos que la nostra comprensió del que realment fa que sigui un defecte sigui correcta o no.
  • Per a proporcionar tota la informació això és necessari per reproduir el problema. Un defecte que torna a un equip de proves amb l'estat definit com a 'Informació insuficient' no es reflecteix molt positivament en nosaltres. Mireu aquest missatge - Com es poden resoldre tots els errors sense cap etiqueta 'Error no vàlid' .
  • Comproveu si es va plantejar un problema similar abans de crear-ne un de nou. Problemes 'duplicats' també són males notícies per a l’equip de control de qualitat.
  • Si hi ha un problema, apareix de manera aleatòria i no sabem els passos / situacions exactes en què podem recrear-lo; plantejar-ho igual. A risc que es fixi el problema 'Irreproducible / informació insuficient' - encara ens hem d’assegurar que hem gestionat tots els possibles mal funcionaments en la mesura possible.
  • La pràctica general és que l’equip de control de qualitat crea els defectes de cadascun en un full Excel durant un dia i el consolida al final del dia.

El cicle de vida complet dels defectes

Per al nostre projecte en directe, si seguíssim el cicle de vida del defecte 1,

la passarel·la per defecte no està disponible per Windows 10 wifi
  • Quan jo (el provador) el creo, el seu estat és 'Novetat'. Quan l’assigno al cap de l’equip de control de qualitat, l’estat continua sent “Nou”, però el propietari ara és el cap de control de control de qualitat.
  • El client de control de qualitat revisarà el problema i, en determinar que és un problema vàlid, s’assigna al client de desenvolupament. En aquesta fase, l'estat és 'Assignat' i el propietari és el líder de Dev.
  • El responsable de desenvolupament assignarà aquest problema a un desenvolupador que treballarà per solucionar-lo. L'estat serà ara 'Work in Progress' (o alguna cosa similar a aquest efecte), el propietari és el desenvolupador.
  • Per al defecte 1, el desenvolupador no pot reproduir l’error, de manera que l’assigna de nou a l’equip de control de qualitat i defineix l’estat com a 'No es pot reproduir'.
  • Alternativament, si el desenvolupador pogués treballar-hi i solucionar un problema, l'estat s'establiria a 'resolt' i l'assumpte es tornaria a assignar a l'equip de control de qualitat.
  • L'equip de control de qualitat el recollirà, tornarà a provar el problema i, si es soluciona, establirà l'estat a 'Tancat' . Si el problema encara existeix, l'estat s'estableix en 'Torna a obrir' i el procés continua.
  • Depenent de la resta de situacions, l'estat es pot establir com a 'Diferit' , 'No hi ha prou informació', 'Duplicat' , 'funcionant com es volia' , etc. pel desenvolupador.
  • Aquest mètode per registrar els defectes, informar-los i assignar-los, gestionar-los és una de les principals activitats realitzades pels membres de l'equip de control de qualitat durant la fase d'execució de la prova. Això es fa diàriament fins que es completa un cicle de prova concret.
  • Un cop fet el cicle 1, l'equip de desenvolupadors trigarà un o dos dies a consolidar totes les correccions i a reconstruir el codi a la següent versió que s'utilitzarà per al següent cicle.
  • El mateix procés torna a continuar també per al cicle 2. Al final del cicle, hi ha la possibilitat que encara hi hagi alguns problemes 'Oberts' o no solucionats a l'aplicació.
  • En aquesta etapa, continuem amb el cicle 3? Si és així, quan deixarem de fer proves?

Criteris de sortida per a les proves d'OrangeHRM Live Project

Aquí és on emprem el que anomenaríem 'Criteris de sortida'. Això està predefinit al document del pla de proves. És simplement en forma de llista de comprovació que determinarà si concloguem les proves després del cicle 2 o anem a fer un cicle més. Sembla que, a continuació, quan es completa, tenint en compte algunes respostes hipotètiques a les següents preguntes relatives al projecte OrangeHRM:

Criteris de sortida de la prova

Quan examinem detingudament la llista de comprovació anterior, hi ha mètriques i esmenta la sessió que no hem parlat anteriorment. Parlem-ne ara.

Mètriques de prova

Hem establert que durant la fase d’execució de les proves s’envien informes a la resta de membres de l’equip del projecte per donar-los una idea clara què està passant a la fase d'execució de QA . Aquesta informació és important per a tothom per obtenir una validació de la qualitat general del producte final.

Imagineu-vos que informeu que es van executar 10 casos de prova o es van executar 100 casos de prova; aquestes xifres són merament dades brutes i no donen una perspectiva molt bona sobre com estan passant les coses.

Les mètriques juguen un paper vital per omplir aquest buit. Les mètriques són en paraules simples, números intel·ligents que l’equip de proves recopila i manté . Per exemple, si he dit que el 90% dels casos de prova aprovats té més sentit que dir que s’han aprovat 150 casos de proves. No és així?

Hi ha diferents tipus de mètriques recopilades durant la fase d'execució de la prova. Quines mètriques s'han de recopilar i mantenir exactament durant quins períodes de temps: aquesta informació es pot trobar al document del pla de prova.

A continuació, es mostren les mètriques de prova més recopilades per a la majoria de projectes:

  • Percentatge aprovat dels casos de prova
  • Densitat de defectes
  • Percentatge de defectes crítics
  • Defectes, nombre de gravetat

Consulteu el Informe d'estat adjunt a aquest article per veure com s’utilitzen aquestes mètriques.

Informe de finalització de sessió / finalització de la prova

Com que hem de notificar a totes les parts interessades que les proves han començat, també és deure l’equip de control de qualitat comunicar a tothom que les proves s’han completat i compartir els resultats. Per tant, normalment s’envia un missatge de correu electrònic des de l’equip de control de qualitat (normalment el cap d’equip / gerent de control de qualitat) que indica que l’equip de control de qualitat ha signat el producte adjuntant els resultats de la prova i la llista de problemes oberts / coneguts.

Prova de mostra de correu electrònic de tancament de sessió:

Per a: Client, PM, equip de desenvolupament, equip de base de dades, equip de control de qualitat, equip de medi ambient (i qualsevol altra persona que calgui incloure-hi)
Correu electrònic: Hola equip,

L’equip de control de qualitat firma el programa OrangeHRM versió 3.0 després de completar amb èxit els 2 cicles de proves funcionals del lloc web.

Els casos de prova i els seus resultats d’execució s’adjunten al correu electrònic. (O bé mencioneu la ubicació on estan presents. O bé, si utilitzeu programari de gestió de proves, proporcioneu detalls sobre el mateix.)

La llista de problemes coneguts també s’adjunta al correu electrònic. (Una vegada més, es poden afegir qualsevol altra referència que tingui sentit.)

Gràcies,
Lider de l’equip de control de qualitat.

Fitxers adjunts: Informe d’execució final, informe d’expedició final / defecte, llista de problemes coneguts

Una vegada que l’equip de control de qualitat ha publicat el correu electrònic de tancament de la prova, ja acabem oficialment amb el procés STLC. Això no marca necessàriament la finalització de la fase de 'Prova' del SDLC. Encara tenim les proves UAT per acabar perquè això passi. Troba Més detalls sobre les proves UAT aquí .

Un cop finalitzada la UAT, l'SDLC passa a la fase de desplegament on es posa en funcionament i està disponible per als seus clients / usuaris finals per ser consumit.

Això és!

Aquest ha estat el nostre esforç per oferir als nostres lectors l’experiència més en directe com QA Project. Si us plau, feu-nos saber els vostres comentaris i preguntes sobre aquesta sèrie de formació gratuïta en línia sobre proves de programari.

Lectura recomanada

^