3 strategies dealing with blocker defect
Els defectes del bloquejador afegeixen un munt de dramatisme als dies de prova habituals.
En aquest article, vull abordar alguns passos que pot fer un provador quan s’ocupa d’ells.
Vaig a suposar que els nostres estimats lectors ja entenen profundament la gravetat i la prioritat dels defectes. Necessiteu una recapitulació ràpida? Mira això.
Ara bé, sempre vol dir que hem de deixar de provar completament si ens trobem amb un problema de bloqueig?
En alguns casos, sí, però potser no sempre. Pot haver-hi casos en què sigui possible fer algunes proves.
imatge font
A continuació es presenten algunes situacions que he viscut a la meva carrera com a provador. Crec fermament que cal seguir els passos que es descriuen a continuació (més endavant consolidats en un diagrama de flux) per simplificar aquest procés.
Saltem directament.
Passos que heu de prendre quan us trobeu amb un defecte de bloqueig
Pas 1: Quan us trobeu amb un problema, invertiu temps per trobar la causa principal.
Crec fermament que, com a provador, el nostre treball no acaba informar de defectes . Si el temps ho permet, hauríem d’explorar què podria haver causat el problema. Pot ser que no sempre puguem assenyalar l’àrea de problema exacta, però intentem solucionar el màxim possible. Els mateixos detalls es poden actualitzar al defecte com a comentaris addicionals.
Ho he fet molt en els meus projectes, i això ha donat lloc a una solució ràpida. Els beneficis de l'anàlisi de les causes arrel són:
- Com que és un valor afegit, això sens dubte pot proporcionar una millor direcció al desenvolupador per a la correcció d’errors.
- A més, el provador de control de qualitat pot reconèixer si aquest problema és de creació pròpia (problemes d’entrada de dades o d’ús humà) i, en aquest cas, el solucionador el pot solucionar. Quan es comuniquen aquests errors als desenvolupadors sense que comprovem des del final de la QA, ho són considerat com un no problema i podria crear una reputació negativa per al provador.
Per tant, us suggereixo que comprovem sempre al final abans de registrar un defecte.
Aquí teniu alguns exemples en temps real dels meus projectes que reforçaran els punts anteriors:
Vaig treballar en un projecte on les nostres proves requeririen que deixéssim un fitxer en un lloc determinat. Canvieu el nom perquè coincideixi amb el nom de la configuració. Un treball programat recolliria el fitxer de dades i carregaria les dades al sistema. Després, validaríem les dades de la base de dades i de la portada.
preguntes sobre les funcions de Microsoft Excel i la sintaxi comuna
Abans ens trobàvem amb problemes en què s’executaria la feina, però no es carregaven les dades i, després de la investigació, va ser perquè el provador no ha canviat el nom mentre deixava el fitxer a la ubicació.
Aquest va ser un bloqueig per a nosaltres, però no una cosa que requeria atenció del desenvolupador. Vam haver de parar atenció als detalls i evitar errors tan petits.
A continuació es detallen algunes categories, causes arrels i remeis habituals:
# 1) Fitxer d'amfitrions Assumpte - Diguem que el fitxer hosts té paràmetres incorrectes i que causen el problema. En aquest cas, podeu actualitzar el fitxer d'amfitrió vosaltres mateixos o demanar ajuda a algú amb accés per actualitzar-lo i continuar amb l'execució de la prova.
per què Linux és millor que Windows
S'hauria de plantejar un defecte per tal que els desenvolupadors investigin, però amb la solució alternativa es pot continuar.
Nota: Consulteu amb els vostres equips de projecte si està bé que l'equip de control de qualitat faci aquests canvis abans de fer-ho.
# 2) Configuració - Sovint hem observat problemes de configuració, com ara no assenyalar l'entorn correcte o altres problemes de configuració, que són problemes de bloqueig. En aquests casos també, els verificadors poden fer canvis i continuar amb la prova.
Nota: Una vegada més, busqueu permís abans de fer-ho.
# 3) Problema de codi: Si creieu que el problema es deu al codi, els provadors no poden fer res. Registreu un defecte de bloqueig i espereu que la correcció continuï amb la prova.
# 4) Problema de desplegament: Un altre desplegament incorrecte és una altra causa habitual de problemes de bloqueig i es pot detectar durant la prova de seny. També aquí, les proves s’han d’aturar immediatament fins que es rebi una nova versió.
# 5) Entorn baix: Si l’entorn no funciona, diguem que la base de dades no es connecta al servidor o que l’URL no funciona en cas de llocs web; els verificadors no poden fer molt en aquests casos, a part d’informar d’un defecte i esperar que el sistema estigui en funcionament.
Per tant, si existeix una solució alternativa, utilitzeu-la per continuar provant. L'única manera de trobar, si aquesta solució existeix, és investigant la causa arrel. El més freqüent és que hi hagi una alternativa.
Pas 2: És molt fàcil caure en un bucle infinit en investigar la causa arrel. Per tant, assegureu-vos que no consumeixi tot el dia i tot l’esforç.
Aquí hi ha alguns consells:
- Busqueu un equilibri i reconegueu el punt d’aturada quan hi arribeu.
- L’experiència i l’experiència dels provadors són fonamentals per a un RCA amb èxit. No obstant això, és una bona idea involucrar l’equip i el líder de l’equip quan sigui necessari.
- Quan creieu que RCA consumeix molt de temps, primer informeu immediatament del problema i proporcioneu tota la informació que pugueu. Una captura de pantalla sempre és útil.
- Si cal, feu un seguiment. Envieu un correu electrònic al gestor o al desenvolupador per cridar l'atenció sobre el problema crític.
- Continueu resolent problemes després d’avisar les parts necessàries.
Motiu pel qual s’han d’informar immediatament dels defectes del bloqueig:
- La gestió s’hauria de fer conscient de tots els temps d’aturada si el problema és un defecte de parada. Aquesta informació s'ha de transmetre al client i també pot requerir actualitzacions del pla de projecte (terminis de control de qualitat), canvis en els lliuraments, etc.
- Cal demanar qualsevol prova de retard en els lliuraments de control de qualitat. Per tant, sempre és millor comunicar-se el més aviat possible en lloc d’esperar al final del dia.
Pas 3: Ara, passant a l'últim pas, ja que hem acabat d'analitzar el problema i comunicar-lo, què passa?
- Si el problema està bloquejant l'accés a una àrea funcional, comproveu si això afecta a altres àrees
- Si l'aplicació frontal no funciona, comproveu si es poden continuar les proves de backend / middleware / base de dades.
- Si no es pot realitzar cap activitat d'execució de proves, proveu-ho treballar alguna documentació relacionat amb el vostre projecte.
- També podeu provar-ho identificar àrees d’automatització si repeteix manualment molta feina. L’automatització no sempre ha d’utilitzar una eina. Per exemple, la generació d’informes és una tasca monòtona per a vosaltres, que és una àrea que es pot automatitzar mitjançant macros excel simples i així.
- Dediqueu temps a conèixer les eines de codi obert que es poden implementar al vostre projecte
- Per últim però no menys important , treballeu cap a la innovació, el mantra que governa el món actualment.
Finalment , el diagrama de flux que resumeix tota la discussió.
Diagrama de flux: passos per gestionar un defecte de bloqueig
Autor : Aquest impressionant article està escrit per Priya R., membre de l'equip de STH.
Quins passos heu de fer quan us trobeu amb algun defecte de bloqueig?
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
- Les millors eines de prova de programari 2021 (Eines d'automatització de proves de control de qualitat)
- Exemples d'informes d'errors per a aplicacions web i de productes
- 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)
- 7 Principis de proves de programari: agrupació de defectes i principi de Pareto