MANEJO DE BUGS

ING. ADRIANA SANDOVAL

UNM MODULO 6
MARZO ABRIL 2023
Ing. Adriana Sandoval Velarde
Senior Quality Engineer
Trainer
Speaker

CEL: 60348910
ADY.J.S.V@GMAIL.COM
  Nombre
Ahora es su turno  De donde son
 A que se dedican
 Porque quieren aprender Testing
 Ingles?
 Haz encontrado un bug
ultimamente?
Participar

Hacer las actividades

Agenda
 Introduccion
 Sistema bajo pruebas
 Que son los bugs?
 Reporte de bugs
 Defect core
 RIGMEN
 Replicar, Isolar, Generalizar, Maximizar, Externalizar, Tono Neutral

 Validacion de bugs
 Bugs irreproducibles
 aparece un mensaje de error o una pantalla azul
inutiliza pantallas de información, estamos ante un
problema de calidad del software.
Entrenando…
 https://app.seesaw.me/
Objetivo

 Reportar un bug de manera coherente

Ciclo de vida del software
Metodologia del Proyecto

 Cascada
Metodologia del Proyecto

 Iterativa
Metodologia del Proyecto

 Agile
Actores Scrum agile
 Product owner/ product manager

 Son los encargados de poner los requerimientos de forma escrita y de la parte

del analisis
Actores Scrum agile

 Diseño
Actores Scrum agile
 Developers/Programadores

Se encargan del codigo, arreglar los bichos, se encargan de la infrastructura

Investigacion
Actores Scrum agile
 Tester/ quality engineer

Verificar la funcionalidad
* Encontrar y Reportar bugs
Reproducir bugs reportados por customers
Actores Scrum agile

 Tech support/customer service

Se encargan de recepcionar los bugs de los clientes o usarios finales.
Escala los bugs donde se puede solicitor nuevos requerimientos y mejoras
Herramientas manejo del proyecto
Sistema bajo
pruebas
SYSTEM UNDER TEST (SUT)
Sistema bajo pruebas
 Para realizar buenas pruebas necesitamos enternder el proposito del
software
 Arquitectura
 Documentacion
Version del producto
<Major> . <Minor> . <Revision> . <Build>

Major release cambios grandes en base de datos UI o cambio de arquitectura

windows 7, windows 10
Minor release  nueva funcionalidad, cambio api
Hotfix, Updates regulares
Version del producto

<Major> . <Minor> . <Revision> . <Build>

Revision usualmente usado para distribucion interna

alpha, beta releases
Build  codigo compilado que resuelve un bug o añade funcinalidad y que se envia a ser
probado
¿Que es un bicho?
¿Que es un bug?
“Cualquier cosa que provoque una reducción innecesaria o irrazonable de la
calidad de un producto de software.”

 resultado inesperado durante la ejecución de un programa

¿Que es un bug?

 Es un comportamiento no esperado dentro de un Programa o

aplicacion.

 Es un defecto encontrado en una aplicacion o software

 Es la manifestacion de un error dentro del codigo de una

aplicacion o Software
Sinonimos de “bug”

 Fault
 Failure
 Error
 Issue
 Defect
 PR (problem report)
error, bug, y falla

 error, bug, y falla no son lo mismo.

 Comprender las diferencias entre estos conceptos y usarlos
adecuadamente simplifica y estandariza la comunicación.

 El glosario de la Junta Internacional de Aptitudes de Pruebas de

Software (ISTQB, por sus siglas en inglés) define los términos de la
siguiente manera:
error, bug, y falla

 Error: Acción humana que produce un resultado incorrecto.

 Bug: Imperfección en un componente o sistema que puede causar

que el componente o sistema falle en desempeñar las funciones
requeridas.

 Falla: Desviación del componente o del sistema respecto de

prestación, servicio o resultado esperado
defecto, problema y falta son
sinónimos de bug

 La ISTQB señala que las palabras defecto, problema y falta son sinónimos de
bug y que es preferible el uso de la palabra defecto sobre los otros términos
a pesar de que el término bug es más utilizado.
equivocación es sinónimo de error

 De manera similar, la palabra equivocación es sinónimo de error, y error es

el término preferido.
error, bug, y falla

 Una persona comete un error e introduce un defecto en el código del

programa.
 Si durante el uso del programa, se ejecuta la línea de código con el
defecto, el programa funciona de manera inesperada, es decir, el defecto
causa una falla.
Ejemplo…

 Un programador tiene la tarea de implementar un programa que controle

el acceso a un sitio web permitiendo el acceso sólo a usuarios de 18 o más
años de edad.

 El programa solicita al usuario introducir su edad y si ésta es de 18 o más, le

da la bienvenida al sitio web, si no, se le niega el acceso por ser menor de
edad.

 El programador implementa el software y decide probarlo utilizando los

siguientes casos de prueba:
Ejemplo…

 El programador implementa el software y decide probarlo utilizando los

siguientes casos de prueba:
 Ejemplo…
el programa autoriza correctamente el
acceso al sitio web, cuando se introduce la
edad de 18 años.

Sin embargo falla en los otros dos casos.

En el caso en el que la edad es de 17 años el

programa debió de negar el acceso al sitio
pero el acceso fue autorizado

y en el caso en el que la edad es de 19 años

el programa debió permitir el acceso pero lo
negó.
Ejemplo…

El programador inspecciona el código y detecta

un defecto en la línea 3.
La condición utiliza el operador menor o igual que
(<=), es decir, verifica que la edad sea de 18 años o
menos.
En lugar de utilizar el operador <=, debería utilizar el
operador mayor o igual que (>=) para que la
condición verifique que la edad sea de 18 años o más.

El programador introdujo por error el defecto en la

condición.
los defectos no son la única fuente
de fallas

 Cabe destacar que los defectos no son la única fuente de fallas, otros
factores como cambios inesperados en librerías o sistemas de los que se
depende también resultan en fallas.
Reporte de bugs
audiencia

 Al repotar un bug se va a tener personas que revisen el bug

 QA lead/team
 Dev lead
 Dev
 Scrum master
 PO
Reporte de Bugs

 Los bugs pueden ser clasificados de acuerdo a su severidad y su prioridad

 Bichos tienen que ser reportados en la fase en la que sean encontrados

Severidad y Prioridad

 Severidad: Impacto del defecto en la aplicacion

 Prioridad: Importancia que Development le asigna al bug

Severidad

 El Ingeniero de QA es el que determina el nivel de gravedad del problema encontrado

 Su valor es objetivo y es poco probable que cambie en el tiempo

 Critical

 Major

 Medium

 Minor

 Low/Trivial/enhancement
Clasificacion por severidad
Prioridad

 Determina el orden en el que los desarrolladores deben resolver los bugs

 El estado de la prioridad se basa en los requisitos del cliente

 Su valor es subjetico y puede cambiar durante un period de tiempo

dependiendo del cambio en la situacion del proyecto
Clasificacion por prioridad
REPORTE de bug

 Titulo

 prioridad

 Descripcion

 Requisitos

 Pasos para reproducirlo

 Resultado Actual

 Resultado Esperado

 Informacion extra
REPORTE de bug

 Titulo

 Severidad

 Descripcion

 Requisitos

 Pasos para reproducirlo

 Resultado Actual

 Resultado Esperado

 Informacion extra
Un Bug, ahora que hago?

 RIGMEN nos ayuda a escribir los bugs de forma clara

 Replicar,
 Isolar,
 Generalizar,
 Maximizar,
 Externalizar,
 Tono Neutral
RIGMEN -- Replicar

 Reproducir el Bug siguiendo los mismos pasos en diferentes ambientes

isolar

 Aislar. Encontrar el conjunto mas pequeño de acciones necesarias para replica

el error e informar

 Estos pasos ayudaran a reproducer el bug en cualquier momento

 Determinar si no es reproducible el 100% de las veces y que factores

incrementan la probabilidad de que aparezcan

 Comprobar si el Bug encontrado se reproduce en diferentes lugares en la

aplicacion

 Comprobar si el Bug se reproduce en diferentes versions de la aplicacion

 Asegurar que no es comportamiento esperado

GENERALIZAR

 Determinar el rango de circunstancias bajo las cuales este error causara

una falla.

 Mostrar los problemas causados por este bug, en cuentas configuraciones

comunes y con data realisticos pasa pasa el problema

 Verificar que el comprotamiento no es solo parte de un defecto mas

grande (verificar que el defecto no es solo un sintoma)
Maximizar

 Cuantificar el impacto del Bug encontrado dentro del producto

 Encontrar los sintomas mas grandes del bug

 Se expresa en la severidad
Externalizar

 considerar las consecuencias del BUG

 se pone en perspectiva y se describe el impacto de las areas que van a
aser afectadas.
 Como va a fectar a las personas? Afectara la reputacion de la compañia?

 Compartir el bug encontrado y su efecto sobre el producto en general al

Cliente
Tono neutral
 Al escribir los bugs tienen que ser de mnera constructiva, usar las palabras
adecuadas.
Workaround

 Encontrar otra forma de completer el Test case que esta siendo

ejecutado
Test Around

 Ejecutar pruebas al rededor del Fix del bug que fue Fixeado o del
nuevo feature que esta bajo testing
Ciclo de vida de un bug
Validacion de un Bug
 Cuando se valida un bug se debe revisar que ya no se reproduzca y que
funcionalidad a su alrededor no haya sido rota
Validacion de un Bug

 De acuerdo a el equipo se creara

 Subtask dentro del ticket  revison QA y esta sera asignada al QA que hara
la verificacion
 Se añadira comentarios en el ticket principal indicando si el ticket paso o
no la verificacion
Validacion de un Bug

 Notas de testeo
 ESTIMACION
 Se ha realizado la verificacion en el ambiente de QA
 Con los usuarios
 Con el Browser: Chrome
 El issue ya no se reproduce RESULTADO DE TODA LA VALIDACION

 Lista de test cases ejecutados

 Screenshots
Bugs Irreproducibles

 Como QA nuestro rol es reportar cualquier comportamiento que no

cumple con el requerimiento

 Nuestro desafio es escribir un reporte que ayude en la toma de

decisiones
Bugs Irreproducibles

 Estrategia  nuestro reporte tenga informacion completa

 Pero que pasa si un bug es irreproducible?

 Analizamos, tratamos de reproducir y colectar toda la informacion
 Mostrar un numero de veces en las que el bug se puede reproducir
Bugs Irreproducibles

 Encontrar el Bug
 Tratar de reproducirlo  no se puede reproducir?

 Escribir un ticket con toda la informacion revisar si hay bugs

similares
 Avisar a los devs, al PO para analizar el tiempo a invertir en ese bug
Bugs Irreproducibles

 No se puede reproducir?
 Identificar la condicion critica (algo que haga reproducer el bug)
suele ser lo mas dificil

 Trabajar con el dev, agregar manejo de errores logs

Error de efecto retardado

 Error de efecto retardado: se reproduce pero no de Inmediato

 Horas, dias
 Campos o condiciones ocultas
 Consumo de recursos
 Desinstalacion incompleta
Follow up test

 Pruebas de seguimiento