Gestionar Defectos - Diferencia entre error, defecto y fallo - Parte 1
a sea que estés iniciándote en la actividad del software #testing o bien, que tengas algunos proyectos encima, gestionar #defectos es una de las principales prácticas que tenemos como #testers y que debemos estar atentos a las actualizaciones, o a tomar nuevas formaciones y/o talleres, que nos permitan seguir mejorando. El término ‘gestionar’ es amplio y dependerá su alcance del rol o función que tengas en un determinado proyecto, ya que un Tester Jr o Sr tendrá una administración diferente a la de un Lider o Jefe de Testing.
¿Cómo es ésto? Te lo explicaré en el artículo
Para la gestión de los defectos debemos saber acerca de:
- Parte 1) Diferencia que existe entre errores, defectos y fallos.
- Parte 2) Ciclo de vida de todo defecto.
- Parte 3) Reportar un defecto.
- Parte 4) Seguimiento y Monitoreo.
Respecto del punto (1) Saber la diferencia entre errores, defectos y fallos, en el ISTQB CTFL 2018 – Sección 1.2.4. Errores, Defectos y Fallos, se trata el tema de la diferencia entre los conceptos.
Una persona puede cometer un error (equivocación) que puede dar como consecuencia un defecto (bug) en el código de software o en algún otro producto de trabajo relacionado.
Un defecto puede desencadenar otro u otros defectos.
Un error durante la obtención de información de requisitos en base a entrevistas (educción) o como se suele entender, durante el levantamiento de un requerimiento, puede conducir a un defecto en el requisito, lo que a su vez trae como consecuencia un error de programación que conduce a un defecto en el código.
Si llegara a ejecutarse ese fragmento de código que contiene el defecto que no se haya detectado, esto puede dar origen a un fallo, pero no necesariamente en todos los casos.
Síntesis
En síntesis, un error es una acción humana que provoca un resultado incorrecto. Un defecto es un desperfecto en un componente de software que puede causar que el mismo falle cuando una cierta función debe actuar. Un fallo es cuando se manifiesta física o funcionalmente un defecto.
Esto útimo se debe a que algunos defectos para que se produzca su ocurrencia requieren de ciertas entradas o precondiciones muy particulares, es decir que puede encontrarse en el código un defecto por así decirlo oculto, no activo, y que a partir de la presencia de determinados eventos son activados.
¿Porqué podemos cometer errores?
Algunas de las razones pueden ser:
- por no tener suficiente tiempo para desarrollar y entregar el incremento al final de nuestro Sprint (por causas internas o ajenas al proyecto) puede originar un cierto grado de presión que muchas veces no es correctamente administrado.
- por la sencilla razón que no somos infalibles, siempre existe el riesgo o la posibilidad de cometer un error. Somos humanos, no una inteligencia artificial. Por añadidura, todo producto de software es falible y ese es uno de los motivos de nuestra existencia como Software Testers.
- por no tener suficiente experiencia en la posición o estar poco calificados. La inexperiencia en cuanto al desarrollo de productos de software puede presentarse durante la toma de requirimientos, el desarrollo del código que luego se convierte en el producto de software y/o en el testing que hagamos.
- por la insuficiente o falta de comunicación (a) entre ciertos miembros del equipo por diversas situaciones y/o (b) respecto del diseño y/o requisito a desarrollar.
- por la complejidad que implica el desarrollo del código , su diseño, su arquitectura, sus integraciones con otros productos de software y/o otras tecnologías.
- por confusiones vinculadas con el entendimiento de las interfaces que deben ser implementadas.
- por tener que desarrollar el producto de software en una tecnología nueva y muy poco conocida con lo cual varios de los aspectos enunciados antes pueden darse.
Por suerte, en marcos de trabajo como Scrum, aplicando determinadas métodologías ágiles, muchas de estas razones pueden ‘trabajarse’ y mejorarse para reducir la ocurrencia de errores y por ende, de defectos y fallos.
Claro que hay que ‘trabajar’ mucho en la comunicación interna del equipo por sobre todas las cosas para empoderarlo y mejorar así su capacidad de autogestionarse.
No hay que dejar de considerar en todo ésto los factores externos, y me refiero a las condiciones mediambientales como las radiaciones y/o campos magnéticos provocados por elementos naturales y/ artificiales, que pueden causar fallos en el firmware* e incluso traer consecuencias anómalas en la ejecución del software al verse afectado su hardware.
>>[‘Parando la pelota’] ¿Te pusiste a pensar que condiciones debería diseñar y el tipo de prueba que debería ejecutar para validar el comportamiento del producto de software frente a este tipo de situaciones?
También es importante que tengas presente que no todos los resultados que vayamos obteniendo de nuestras pruebas serán fallos.
Podemos estar originando los 'falsos positivos' por las siguientes razones:
- error en la forma de ejecutar una prueba;
- defectos en los datos que usamos para nuestra prueba;
- defectos en el entorno de prueba (puede estar inestable);
- defectos en alguno de los productos de trabajo que usamos para conducir nuestra prueba;
- datos corruptos de la base de datos que usamos;
Y también podemos estar originando los 'falsos negativos':
- pruebas que no detectan defectos que deberían haber detectado, es decir damos como válida una funcionalidad o módulo cuando en realidad tiene un defecto.
Las posibles causas de estos ‘falsos’ pueden derivarse de la persona misma que esta testeando o bien por no haber suficiente datos que cubran toda la cobertura de prueba que debiera contemplarse.
>>[‘Parando la pelota’] ¿Podemos darnos cuenta la diferencia entre un ‘falso positivo’ y un ‘falso negativo’? Deberíamos tener presente que este tipo de ‘falsos’ ocurren en los programas antivirus y que bien puede trasladarse el concepto a las pruebas de software.
Cabe mencionar algo para que lo tengas presente: Puede ocurrirnos que detectemos un defecto que oculte otro y no lo podamos identificar. A esta situación se la denomina ‘enmascaramiento de error’, defect masking. (IEEE 610)
Sólo a modo informativo para que puedas profundizar en tus estudios del tema, encontrarás en las siguientes secciones del ISTQB CTFL el concepto de ‘defecto’:
- 1.1.1. Objetivos Característicos de la Prueba.
- 1.1.2. Prueba y Depuración.
- 1.2.1. Contribuciones de la Prueba al Éxito.
- 1.2.2. Aseguramiento de la Calidad y Procesos de Prueba.
- 1.2.4. Errores, Defectos y Fallos (tema tratado en este artículo).
- 1.2.5. Defectos, Causas Raíz y Efectos.
- 1.3. Siete Principios de la Prueba.
- 1.4.2. Actividades y Tareas de Prueba / Análisis de la prueba / Diseño de la Prueba / Ejecución de la Prueba /
- 1.4.3. Productos de Trabajo de la Prueba / Productos de Trabao del Análisis de la Prueba / Productos de Trabajo de la Ejecución de la Prueba
- 1.5.1. Psicología Humana y el Proceso de Prueba.
- 1.5.2. Formas de Pensar del Probador y del Desarrollador.
- 2.2. Niveles de Prueba.
- 2.2.1. Prueba de Componente.
- 2.2.2. Prueba de Integración / Objetivos / Defectos y Fallos Característicos / Enfoques y Responsabilidades Especificos
- 2.2.3. Prueba de Sistema / Objetivos / Defectos y Fallos Característicos / Enfoques y Responsabilidades Especificos
- 2.2.4. Prueba de Aceptación / Objetivos / Pruebas Alfa y Beta / Defectos y Fallos Característicos
- 2.3. Tipos de Prueba
- 2.3.2. Prueba No Funcional
- 2.3.4. Prueba Asociada al Cambio
- 2.4. Prueba de Mantenimiento
- 2.4.1. Activadores para el Mantenimiento
- 3.1.2. Ventajas de la Prueba Estática
- 3.1.3. Diferencias entre la Prueba Estática y la Prueba Dinámica
- 3.2.1. Proceso de Revisión de Productos de Trabajo
- 3.2.2. Roles y Responsabilidades en una Revisión Formal
- 3.2.3. Tipos de Revisión / Revisión Informal / Revisión guiada / Revisión Técnica / Inspección
- 3.2.4. Aplicación de Técnicas de Revisión / Basada en Lista de Comprobación / Escenarios y Ensayos
- 3.2.5. Factores de Éxito para las Revisiones
- 4.3.2. Prueba y Cobertura de Decisión
- 4.3.3. El valor de la Prueba de Sentencia y Decisión
- 4.4.1. Predicción de Errores
- 5.1.1. Prueba Independiente
- 5.2.5. Factores que influyen en el Esfuerzo de Prueba / Resultado de la Prueba.
- 5.2.6. Técnicas de Estimación de la Prueba
- 5.3.1. Métricas utilizadas en la Prueba
- 5.3.2. Objetivos, Contenidos y Audiencias de los Informes de Prueba
- 5.5.2. Riesgos de Producto y Riesgos de Proyecto
- 5.5.3. La Prueba basada en el Riesgo y la Calidad de Producto
- 5.6. Gestión de Defectos
- 6.1. Consideraciones sobre las Herramientas de Prueba
- 6.1.2. Beneficios y Riesgos de la Automatización de la Prueba
También encontrarás referencias al concepto ‘defecto’ en el Programa de Estudios de ISTQB CTFL-AT
- 1.2.4. Integración Continua
- 2.1.1. Actividades de Prueba y Desarrollo
- 2.1.4. Prueba y Gestión de la Configuración
- 2.1.5. Opciones de Organización para Pruebas Independientes
- 2.2.1. Comunicar el Estado de la Prueba, el Avance y la Calidad del Producto
- 2.2.2. Gestión del Riesgo de Regresión con Casos de Prueba Manuales y Automatizados en Evolución
- 2.3.2. El Rol de un Tester en un Equipo Ágil
- 3.1. Métodos de Prueba Ágil / Desarrollo Guiado por Pruebas de Aceptación
- 3.1.2. La Pirámide de Prueba
- 3.1.4. El Rol de un Tester / Sprint Cero
- 3.2.1. Evaluación de los Riesgos de Calidad en Proyectos Ágiles
- 3.3.1. Criterios de Aceptación, Cobertura Adecuadas y otra información para probar / Niveles de Prueba / Prueba de Integración / Prueba de Sistema / Prestación / Iteración / Entrega
- 3.4. Herramientas en Proyectos Ágiles
Si te ha parecido útil este artículo, seguime en LinkedIn y dejame un Comentario y si ves que vale la pena… anímate y comparte el mismo a tus amigos y tus Redes Sociales, te lo agradecería y mucho, ya que me ayuda a que esta red posicione mejor el contenido y llegue a más.
¡¡Muchas gracias por seguirme!!
