10 de Abril 2021

Verdadero o falso sobre

Casos de Prueba
Un CP positivo tiene como objetivo verificar
que el software haga lo que tiene que hacer

VERDADERO FALSO
 Un CP positivo tiene como objetivo verificar
que el software haga lo que tiene que hacer

VERDADERO
Un CP negativo tiene como objetivo verificar
que el software haga lo que no tiene que hacer

VERDADERO FALSO
Un CP negativo tiene como objetivo verificar
que el software haga lo que no tiene que hacer

FALSO
Un CP negativo tiene como objetivo verificar
que el software NO haga lo que NO tiene que
hacer
La estructura básica de un CP es: ID, Título,
Pasos, Datos, Resultado esperado

VERDADERO FALSO
La estructura básica de un CP es: ID, Título,
Pasos, Datos, Resultado esperado

VERDADERO
 Si el resultado obtenido no coincide con el
resultado esperado de la prueba se reporta un
bug

VERDADERO FALSO
 Si el resultado obtenido no coincide con el
resultado esperado de la prueba se reporta un
bug

VERDADERO
 Un caso de prueba es negativo cuando la
prueba está diseñada para devolver lo que se
espera según la funcionalidad

VERDADERO FALSO
 Un caso de prueba es negativo cuando la
prueba está diseñada para devolver lo que se
espera según la funcionalidad

FALSO
 Un caso de prueba es positivo cuando la
prueba está diseñada para devolver lo que se
espera según la funcionalidad
¿Qué diferencia existe entre: Error,
Defecto (bug) y Fallo?
Error: Acción humana que produce un resultado incorrecto.

Defecto: Presencia de un error en el software

Fallo: Manifestación física o funcional de un defecto.

 “Cuando un tester declara que ha encontrado

un Bug está denunciando un defecto en el software que

salió a la luz en el momento de la ejecución de una

prueba provocando un Fallo.”

Estructura del reporte de
bugs
Un buen reporte de bug debe ser:
Reproducible 

Específico e informativo 

Si el bug se reporta eficientemente las probabilidades

de que sea solucionado rápidamente serán mayores.
Estructura del reporte de
bugs
● Título: Descripción del error.

● Pasos: Describir y detallar los pasos de cómo reproducir el error.

● Resultado Obtenido: El error de lo que obtuvimos en la prueba. Es de

utilidad adjuntar evidencia (Capturas de pantalla que le permitan al
desarrollador ver el problema más claramente).

● Resultado Esperado: Lo que deberíamos obtener según la

especificación.

● Importancia: baja, media, alta, crítica.

Estructura del reporte de
bugs
Datos adicionales:

● Nombre del tester

● Fecha

● Aplicación y versión: Es importante detallar que aplicación estamos

probando y que versión de la misma se está probando.

● Ambiente del Tester: En caso de reportar un error web diríamos que

navegador se estaba usando, en caso de ser un reporte de un incidente en un
dispositivo móvil diríamos que teléfono/modelo/versión del sistema operativo.
Ciclo de vida
de un bug y
sus diferentes
“estados”
Reconociendo un
‘Bug’
Nivel de Severidad de
un Bug
Existen 5 niveles de criticidad para adjudicar a un
defecto. Estos son: ● Baja

● Media

● Alta

● Crítica

● BLOQUEA
PRIORIDAD vs SEVERIDAD

● Baja ● Baja

● Media ● Media

● Alta ● Alta

● Crítica ● Crítica

● Urgente ● Bloqueante
PREGUNTA PARA LA CLASE

¿Qué creen que es más importante, la

severidad o la prioridad de un defecto?
Resumiendo:
la severidad tiene que ver con el impacto que tiene que ocurra un
defecto mientras que la prioridad viene dada por el negocio y está
relacionada con la urgencia de resolución. Además, la severidad la suele
asignar el tester mientras que la prioridad la suele asignar el líder o el
product owner.
Ciclo de vida de
BUG
GRACIAS POR OTRO SÁBADO MÁS
GRACIAS POR OTRO SÁBADOLudmi,MÁS
Bicho, Lu, Santi, Luis y Facu