3 worst defect reporting habits
Els defectes són un negoci greu i els petits errors poden costar.
Saps què fer quan trobes un defecte. Vostè ho denuncia; ja sigui en un Seguiment de defectes / Eina de gestió de defectes o en un full Excel. Els principis subjacents són els mateixos per a tots dos mètodes.
Les eines de gestió de defectes no garanteixen un millor informe. Són bones pràctiques les que estalvien el dia.
Per apreciar el bé, hem de reconèixer el que no ho és.
Què aprendreu:
- 3 Els pitjors hàbits d’informació de defectes i com trencar-los
- # 1) Mandra
- # 2) Pressió
- # 3) Manca de creativitat
- Lectura recomanada
3 Els pitjors hàbits d’informació de defectes i com trencar-los
Aquí va:
# 1) Mandra
No prendre's el temps per fer el millor possible.
Aquest és el procés de seguiment de defectes seguit en la majoria dels equips:
(Nota- feu clic a qualsevol imatge per ampliar-la)
Com podeu veure, el client de prova revisa els defectes abans d’enviar-los dels equips de control de qualitat.
Aquesta revisió inclou la confirmació de:
- Validesa: és un error?
- Completesa: títol, passos, dades, captura de pantalla, etc.
- Duplicats
- Reproduïble o no ... etc.
Sé de primera mà que és impossible que un client de control de qualitat sigui complet al 100%.
Per tant, l’actitud: “Informaré del problema com vull. El client QA pot tornar a comprovar. Pot decidir si el defecte és vàlid / complet o no ”és el final del vostre equip de control de qualitat i de la vostra credibilitat.
Sabíeu que alguns clients tenen un SLA pel nombre de defectes no vàlids acceptables? Un cop superat el nombre, comencen a penalitzar els contractistes per tots els defectes no vàlids reportats?
Remei: Feu la vostra diligència deguda i sigueu responsables del vostre lliurament. Va tornar un defecte per no tenir prou informació o que no és un error? No sempre és culpa de l’equip de desenvolupament. No és que no vulguin tenir els problemes de l'aplicació. Podria ser un autèntic desastre de l’equip de control de qualitat. No deixeu que passi.
# 2) Pressió
Fem-ho amb unexemple.
A continuació es mostra una captura de pantalla de OpenEMR’s pantalla de crear-pacient. És un sistema de gestió hospitalària de codi obert.
Aquesta pantalla permet a l'usuari introduir la data de naixement del pacient mitjançant una funció de calendari. El que no fa és restringir l'entrada a triar del calendari. El que vull dir és que podeu triar el DOB com a '31-març-1983' del calendari. Més tard canvieu-lo per '31-febrer-1983'.
Per què el 31 de febrer? Per implementar error en endevinar i proveu dades negatives al camp; quin és el punt complet de les proves, oi?
Un cop fet, faig clic a 'Crea pacient'. Com que la data no és vàlida, espero que el sistema mostri un error i no cregui el pacient. Però això no passa. Crea el pacient com es mostra a continuació.
Tingueu en compte els camps Edat i Data de naixement a la pantalla següent:
Quan feu la prova, podeu provar-ho diverses vegades i decidir que:
- És un error.
- És reproduïble.
- No és un duplicat (consulteu amb el vostre equip per confirmar-ho)
- Coneixeu la descripció exacta del problema
- A més, coneixeu els passos exactes per fer-ho realitat.
Ara que teniu la matèria primera, esteu bé per anar-hi.
Comenceu a informar-ne. Assignar la gravetat dels defectes és un pas obligatori i és possible que el vostre equip faci servir alguna cosa similar a la taula següent de referència:
| Gravetat | Impacte |
|---|---|
| 1 (crític) | • Aquest error és prou crític com per bloquejar el sistema, provocar la corrupció de fitxers o provocar possibles pèrdues de dades • Provoca un retorn anormal al sistema operatiu (apareix un error o apareix un missatge de fallada del sistema). • Fa que l'aplicació es pengi i requereix reiniciar el sistema. |
| 2 (alt) | • Provoca una manca de funcionalitat vital del programa amb la solució alternativa. |
| 3 (mitjà) | • Aquest error degradarà la qualitat del sistema. Tot i això, hi ha una solució intel·ligent per aconseguir la funcionalitat desitjada, per exemple mitjançant una altra pantalla. • Aquest error impedeix provar altres àrees del producte. No obstant això, altres àrees es poden provar de forma independent. |
| 4 (baix) | • Hi ha un missatge d'error insuficient o poc clar, que té un impacte mínim en l'ús del producte. |
| 5 (cosmètica) | • Hi ha un missatge d'error insuficient o poc clar que no té cap impacte en l'ús del producte. |
Com que aquest defecte no bloqueja el sistema ni bloqueja una funcionalitat vital ni impedeix que es provin les altres àrees de l'aplicació, és possible que anem amb 'Baix'.
Sembla que no?
MAL. A partir de les dades del pacient, totes les vacunes i altres recordatoris han quedat endarrerits. Això pot ser correcte o no. A més, per a un pacient la seva edat determina si veu un pediatre o un metge general, etc.
Afecta les dosis de medicaments i moltes altres àrees de tractament que potser ni tan sols coneixeríem.
Per tant, aniré amb 'Alta'. Estic d’acord que és poc probable que el personal de l’hospital entri malament en el DOB d’un pacient. Però deixeu que aquest sigui un factor que afecti la prioritat de quan s'ha de solucionar el problema.
La meva feina com a provador és assegurar-me que comunico la gravetat del problema el millor possible.
Remei: No tingueu pressa per informar. Assegureu-vos al 100% d’entendre l’impacte dels problemes des de molts angles. És el millor valor afegit que podem proporcionar als verificadors. No només diem: 'Alguna cosa no funciona'. També diem: 'Això és el que passarà si això continua sense funcionar'. Tones de diferència, oi?
# 3) Manca de creativitat
Els verificadors tenen una meravellosa oportunitat de fer suggeriments per millorar el programari.
En el vostre Eina de gestió de defectes també podeu enviar un defecte del tipus 'Suggeriment de millora'. Aquí és on podeu ser creatius.
Remei: Penseu fora de la caixa. Si creieu que a una determinada característica li falta un factor 'Vaja' i sabeu com incorporar-la, feu-la avançar. En el pitjor dels casos, es podria rebutjar i està bé. La part important és intentar-ho.
A més, utilitzeu aquest súper poder amb precaució. Intenteu no fer comentaris com ara 'Odio el color de la pancarta, si us plau, canvieu-lo'.
Aquí hi ha un béexempled'un suggeriment de millora que he trobat: En substituir l'opció 'Enviar un correu electrònic al distribuïdor' per l'opció 'Xatejar amb el distribuïdor' en un lloc de concessionaris de vehicles. Es preveu convertir més trànsit en vendes.
M’agradaria ser tan creatiu! Però potser tots hi podem treballar.
Aquí teniu un avantatge. Una llista de comprovació per alliberar aquests mals hàbits:
1. El meu títol transmet el problema de manera clara i concisa?
Per exemple:'Crear pacient no funciona' no és un bon títol. 'Crear un pacient falla fins i tot quan tots els camps d'entrada contenen valors correctes' és.
2. Quina és la taxa de reproducibilitat?
En altres paraules, sempre passa? Sé la seqüència exacta de passos que repetirà el problema?
3. Aquest problema és específic de la plataforma, el navegador o l’usuari?
4. Els passos s'han completat i us portaran al vostre problema?
5 . Tinc una captura de pantalla inclosa?
6. He d’anotar la captura de pantalla per ressaltar algunes àrees en concret?
7. El nom del fitxer d'imatge adjunt és descriptiu?
No utilitzeu alguna cosa com 'Untitled.jpg'. Poseu-li un nom descriptiu.
8. He inclòs les dades de la prova?
Per exemple:Incloeu-los si hi ha un defecte en un mòdul d'administració que necessita credencials d'autorització. L'equip de desenvolupament pot tenir accés o no a l'entorn de control de qualitat. No voleu un retard i un seguiment d’alguna cosa tan bàsica com aquesta.
9. Puc donar altres detalls per reforçar el meu defecte?
(Exemple:una referència al FRD o una conversa amb el client, etc.)
10. Entenc la gravetat del problema des de diferents perspectives?
11. Conec la causa arrel del problema? En cas afirmatiu, tinc proves (potser fitxers de registre) i puc incloure-les? Tingueu en compte que és possible que no sempre ho sàpiga o que ho hàgiu de saber. Però si ho feu, no fa mal incloure’l.
12. L’informe de defectes està lliure de problemes de gramàtica, format, ortografia i puntuació?
què és un fitxer de dades mac
13. Conec alguna manera de millorar el producte?
Creieu que això requereix molt de temps? Bé, un cop es converteixi en un hàbit, ja no ho serà.
Arrelament per a millor notificació de defectes rutines!
Sobre l'autor: Aquest article està escrit per Swati, membre de l'equip de STH.
No dubteu a publicar les vostres consultes / comentaris a continuació.
Lectura recomanada
- Per què la notificació d’errors és un art que tots els provadors haurien d’aprendre?
- Què és el cicle de vida de defectes / errors en les proves de programari? Tutorial del cicle de vida de defectes
- Exemples d'informes d'errors per a aplicacions web i de productes
- Què és la tècnica de proves basades en defectes?
- Procés de gestió de defectes: com gestionar eficaçment un defecte
- Procés de triatge de defectes i maneres de gestionar la reunió de triatge de defectes
- Com escriure un bon informe d'errors? Consells i trucs
- 3 estratègies per fer front a un defecte de bloqueig