Casos de prueba, ejemplos y mejores prácticas

https://www.itpedia.nl/es/2018/06/01/testcases-voorbeelden-en-best-practices/

¿Qué es un caso de prueba?

Un caso de prueba es una serie de acciones que se realizan para determinar una función o
funcionalidad particular de su aplicación.
Los casos de prueba escritos se recogen generalmente en una suite de pruebas.

1.Escenario de prueba de muestra

Un ejemplo para iniciar el diseño de casos de pruebas es “Inicio de sesión de un sistema”
Un escenario de prueba para esto se puede describir de la siguiente manera:

Caso de prueba 1: verifique la operación al ingresar un nombre de usuario válido y contraseña.

Caso de prueba 2: verifique la operación si se ingresa un nombre de usuario y una contraseña
inválidos.
Caso de prueba 3: verifique la operación si el nombre de usuario está vacío y se presiona el botón
de inicio de sesión.
Y así sucesivamente.

Este tipo de escenarios de prueba son bastante abiertos e incluyen una amplia gama de variables.
Sin embargo, las pruebas tienen mucho que ver con ser muy específico. Es por eso que
necesitamos casos de prueba detallados.

2.Grabación de casos de prueba

La identificación de casos de prueba puede llevar mucho tiempo y, a veces, debe repetir la prueba.
Es por eso que debe estar documentado. Los siguientes artículos se deben registrar por caso de
prueba:

El caso de prueba debe tener un resultado esperado.

Para nuestro caso de prueba, el resultado esperado sería que debería ser posible iniciar sesión
correctamente.
Si los resultados esperados no están predeterminados, podemos perder pequeñas diferencias en
los cálculos. Los resultados pueden verse bien, pero en realidad están equivocados. Por ejemplo, si
calcula los salarios, puede haber pequeñas diferencias. Si determina el resultado esperado de
antemano, puede ver las desviaciones cuando realice la prueba. Supongamos que el fabricante del
caso de prueba tiene la organización tienes que abandonar el caso de prueba. Entonces ayuda si el
caso de prueba está documentado.
Un caso de prueba puede tener precondiciones, por ejemplo, ciertos valores en el base de datos
eso debe estar presente de antemano. Con este caso de prueba, se debe ingresar un nombre de
usuario / contraseña de antemano.
Un caso de prueba también puede incluir condiciones de publicación que se aplican después de
que se completa el caso de prueba. Para este caso de prueba, una condición postal sería que se
guardan la fecha y la hora de inicio de sesión en la base de datos. El estado de inicio de sesión
también debe conservarse para poder trabajar con la aplicación.
Durante la ejecución del caso de prueba documenta los resultados que se han observado en la
columna de resultados reales.

3.Diseño de los casos de prueba

El formato para el caso de prueba de inicio de sesión contiene el siguiente formato:

ID del caso de prueba

Parte del escenario de prueba
Pasos de prueba a realizar
Datos de prueba
Resultados esperados
Resultados reales (obtenido)
Resultado de la prueba (exitoso o no)
Al preparar un caso de prueba, necesita la siguiente información:
La descripción de qué requisito se prueba.

La explicación sobre cómo el sistema debe ser probado.

Los principios de prueba tales como: versión de la aplicación que se probará, archivos de datos,
sistema operativo, hardware acceso de seguridad, fecha física o lógica, hora del día, requisitos
tales como otras pruebas y otra información de configuración relacionada con los requisitos que
están siendo probados.

Entradas y salidas de pruebas.

Un caso de prueba no puede contener más de 15 pasos.
Mejores prácticas para un buen caso de prueba
1. Los casos de prueba deben ser simples y transparentes
Crea casos de prueba que sean lo más simples posible. Deben ser claros y concisos, ya que el
creador del caso de prueba no puede realizarlos.

Use un lenguaje firme como ir a la página de inicio, ingrese datos, haga clic en él y así
sucesivamente. Esto facilita la comprensión de los pasos de prueba y prueba la ejecución más
rápido.

2. Haga un caso de prueba con el usuario final en mente

El objetivo final de cada proyecto de software es crear casos de prueba que cumplan con los
requisitos del usuario. Un probador debe hacer casos de prueba con la perspectiva del usuario
final en mente.

3. Evitar la repetición de casos de prueba

No repita los casos de prueba. Si se requiere un caso de prueba para llevar a cabo otro caso de
prueba, llame al caso de prueba sobre la base del ID del caso de prueba.

4. No abandone la aplicación entregada

No asuma una aplicación que funcione mientras prepara el caso de prueba. Cumpla con los
requisitos y documentos de diseño.

5. Proporcionar cobertura 100%

Asegúrese de crear casos de prueba que verifiquen todos los requisitos de software que se
enumeran. Use una matriz CRUD para asegurarse de que no se prueben funciones / condiciones.

6. Los casos de prueba deben ser identificables

Proporcione un nombre a la ID del caso de prueba para que pueda identificarse fácilmente. Esto es
útil para detectar errores o identificar un requisito en una etapa posterior.

7. Repetible e independiente
El caso de prueba debe generar los mismos resultados cada vez, independientemente de quién
ejecute la prueba.

8. Revisión por pares

Una vez que haya realizado los casos de prueba, los evaluará un colega. Sus colegas pueden
encontrar errores en sus casos de prueba, que usted mismo pasó por alto.

Recordando el objetivo de la prueba, debemos diseñar pruebas que tengan la mayor probabilidad
de encontrar el mayor número de errores con la mínima cantidad de esfuerzo y tiempo.

Videos Técnicas de diseño de casos de pruebas

Video 1 https://www.youtube.com/watch?v=Uo2xvx7zhwo&t=120s

Video 2 https://www.youtube.com/watch?v=7FMFXLmu-sw&t=1s

Video 3 https://www.youtube.com/watch?v=6g9cYF0_J7Q&t=359s

Video 4 https://www.youtube.com/watch?v=98LWGvhVSpE&t=3s

Video 5 https://www.youtube.com/watch?v=9tJbunCrOmE&t=50s

Video 6 https://www.youtube.com/watch?v=RQRkRLYujWA

Pruebas de valor límite y clases de equivalencia

https://www.itpedia.nl/es/2018/04/20/grenswaardentest-equivalentie-verdeling-huh/

http://www.lsi.us.es/~javierj/cursos_ficheros/05.SR.pdf
https://www.youtube.com/watch?v=Jegndzw3DEs

Diferencia entre escenario, caso de uso y caso de prueba

Un test case es un conjunto de condiciones bajo las cuales se determina que una parte
determinada de una aplicación funciona de acuerdo a los requerimientos, y para escribir un test
case debemos tener precondiciones, paso a reproducir, resultado esperado, datos de prueba, etc.
En cambio, para escribir un escenario solo necesitamos saber que debe realizar la aplicación.

Test Case: Como debe probarse.

Escenario: Que se deber probar.
Caso uso: múltiples rutas que el usuario puede seguir

¿Cuándo usar escenarios?

 Cuando las reglas de negocio son complejas:

Es más fácil pensar en el resultado esperando a un determinado flujo de acciones, que
tener que escribir paso a paso y además es más efectivo en cuestiones de tiempo.

 Cuando el sistema cambia de un momento a otro

Mantener los test cases involucra tiempo, durante el cual a veces esos mismos test case ya
no útiles para el estado actual de la aplicación.

 Cuando las diferentes combinaciones para probar una determinada aplicación son muchas
En este caso escribir la cantidad de test cases para probar una sola parte de la aplicación
involucra mucho tiempo y nivel de detalle para diferenciar un test cases de otro.

 Cuando no se puede reutilizar los test cases

Cuando se tiene por ejemplo una aplicación que interactúa con otras aplicaciones, pero el
paso para ejecutar determinado test case no son los mismo, lo único que es igual es el
resultado final.

Que se debe tener en cuenta a la hora de escribir escenarios

 Entender el sistema/aplicación en la cual se está trabajando, el propósito de la aplicación.

 Identificar los escenarios más comunes
 Pensar como el usuario final, el usuario final no piensa en paso o precondiciones, solo en
resultados.

Casos de uso
Los casos de uso cuentan la historia de cómo una persona interactúa con un sistema de software
para lograr un objetivo. Un buen caso de uso describe las interacciones que conducen a lograr o
abandonar el objetivo. En el caso de uso se describen múltiples rutas que el usuario puede seguir
en el caso de uso.

Un caso de uso se compone de uno o más escenarios de casos de uso. Cada camino que se puede
seguir en el caso de uso es un escenario de caso de uso. Cualquier ejemplo que se da a raíz de un
caso de uso también sigue un solo escenario. Múltiples ejecuciones del caso de uso se pueden usar
los mismos o diferentes escenarios.

El recorrido marcado en amarillo sería un Escenario

En resumen:
Un caso de uso representa la interacción (o conductas observadas) asociados con el logro o el
abandono de una meta.
Un escenario de caso de uso representa uno de los posibles caminos a través de un caso de uso.
Un caso de prueba representa un conjunto de entradas de datos (actividades) que ejecutan un
solo escenario de caso de uso para obtener unos datos de salida esperados (resultados).

Cómo escribir casos de pruebas

Paso 1:
Identifica el requerimiento a probar y escribe su nombre y/o número en el caso de pruebas. Un
análisis por lo regular genera un documento de diseño que incluye los requerimientos.

Paso 2:
Crea un nombre y/o número de prueba para el caso de prueba. Es útil crear un documento
separado con una matriz para vincular los requerimientos y los casos de prueba entre sí. Identificar
el nombre del requerimiento y su número junto con el nombre y número del caso de prueba
permite la trazabilidad entre este último y el requerimiento.

Paso 3
Escribe una descripción corta del caso de prueba. Esta descripción proporciona una visión general
de alto nivel de lo que hace el caso de prueba. Esto debe permitir que alguien sin conocimiento
previo acerca del caso tenga una comprensión clara de lo que se hace sin revisar todos los pasos
de prueba.
Paso 4
Identifica toda la información de configuración necesaria para ejecutar la prueba. Esta información
incluye los elementos que son prerrequisitos de pruebas, como los datos, el hardware, el software
y los navegadores.

Paso 5
Escribe los pasos y los resultados. Para cada paso escribe un número. Lo mejor es mantener el
número de pasos aproximadamente en 10, con un máximo de 15. Tener pruebas cortas permite
realizar un mantenimiento más fácil, hacer búsquedas de resultados de forma más simple y tener
tiempos de prueba reducidos. Escribe la descripción del paso. Esta puede incluir una entrada clara
o un conjunto de entradas si tienen relación entre sí. Otros elementos a incluir en cada paso son
los resultados esperados, una indicación de aprobación/rechazo, el resultado real, todo tipo de
notas y cualquier dato adjunto.

Taller casos de prueba

https://es.slideshare.net/agrosso/taller-casos-de-prueba

Ejemplo para Diseño de casos de pruebas para Clases de equivalencia

https://www.udemy.com/diseno-de-pruebas-de-software/

Pruebas de software: 10 pasos para elaborar el plan de pruebas

http://www.pmoinformatica.com/2016/01/elaborar-plan-pruebas-
software.html