Expositor: Edgardo Crovetto Resumen: ¿Cuántas veces pasa que hay que hacer tests cases por el hecho de hacerlos y además hechos para ayer porque no hay tiempo?¿Qué podemos hacer para mantener el máximo cubrimiento de prueba y mínima documentación? El objetivo es realmente enfocarnos en hacer entrega de un producto de calidad, sin la obligación de crear documentación innecesaria por el hecho de hacerlo. Al mismo tiempo, poder mostrar cubrimiento de pruebas apropiado y hacer los informes necesarios para poder estar confiados que se está entregando con calidad. En esta charla trataremos de dar un enfoque para poder elegir una buena estrategía en base a algún caso práctico.

1. ¿Test cases?
¿Son siempre necesarios?
Edgardo Crovetto

2. Agenda
● Rol de QA
● Repaso de conceptos de testing
● Analisis de una feature
● Regresiones y reportes
● Conclusiones

3. Agenda
● Rol de QA
● Repaso de conceptos de testing
● Analisis de una feature
● Regresiones y reportes
● Conclusiones

4. Rol de QA
● Ejecución de pruebas
● Escribir pruebas automatizadas,
manuales y documentación de
testing.
● Comunicación con el equipo.
● Analisis, preguntas, entre otros...
Todo esto con una
cantidad de testers
insuficiente para todo lo
que hay que hacer, y con
poco apoyo del equipo de
desarrollo para tomar
control de muchas de
estas tareas.
Y en sprints de 2
semanas hacer todo...

5. Rol de QA
¿Qué se puede hacer?
Cada proyecto es distinto y el foco de la priorización
para sacar adelante un producto de
calidad con las restricciones de
tiempo que siempre hay es
ver lo más crítico de hacer
sin sacrificar en la medida de
lo posible la calidad.

6. Rol de QA
Al definir prioridades uno de los aspectos más importantes es
la comunicación, poder expresar la voz de QA para poder
definir qué es lo mejor desde el
rol para ayudar a todo el equipo
y al producto en sí. Es
extremadamente importante
escuchar para poder llegar a
un consenso.

7. Agenda
● Rol de QA
● Repaso de conceptos de testing
● Analisis de una feature
● Regresiones y reportes
● Conclusiones

8. Repaso de conceptos de testing
Como a mi me enseñaron en un principio testing, se cumple más o menos este
diagrama:
AUT/SUT (Aplicación / Sistema bajo prueba)
Feature/ReqFeature/Req
Feature/Req X
Feature/ReqFeature/Req
Feature/Req Y
Test Suite FR(X)
● Test Case 1
● Test Case 2
● …
● Test Case N
Test Suite FR(Y)
● Test Case 1
● Test Case 2
● …
● Test Case N

9. Repaso de conceptos de testing
Test Case - Caso de prueba
Un conjunto de precondiciones, entradas, acciones
(si aplica), resultados esperados y pos condiciones,
desarrollados a base de condiciones de prueba.
Esta estructura da al tester una forma de pensar que es
crucial para poder hacer las preguntas correctas para poder
criticar un producto.

10. Agenda
● Rol de QA
● Repaso de conceptos de testing
● Analisis de una feature
● Regresiones y reportes
● Conclusiones

11. Análisis de una feature
Feature Analisis Test Suite
Test
Cases
Ejecución
Aprobación
Feature
Test cases a
suite de
regresión
En teoría este tipo de análisis no parece tener
inconvenientes.

12. Análisis de una feature
Pero hay que agregar un par de factores:
- Las features son elementos "vivos".
- Potencialmente la regresión
manual solo crece.

13. Pruebas
Funcionales.
Prototipos.
Simulaciones.
Pruebas
exploratorias.
Escenarios.
Usabilidad.
UAT.
Performance
(carga,
rendimiento).
Pruebas de
seguridad.
Pruebas
Unitarias.
Pruebas de
componentes.
Automatización
Manual
Críticas al
producto
Apoyo al
equipo
Enfrentadas a la Tecnología
Enfrentadas al Negocio
Manual
HerramientasAutomatización

14. Análisis de una feature
Pruebas
Funcionales.
Prototipos.
Simulaciones.
Pruebas
exploratorias.
Escenarios.
Usabilidad.
UAT.
Performance
(carga,
rendimiento).
Pruebas de
seguridad.
Pruebas
Unitarias.
Pruebas de
componentes.
Automatización
Manual
Manual
Automatización Herramientas
Críticas al
producto
Apoyo al
equipo
Enfrentadas a la Tecnología
Enfrentadas al Negocio
¿Donde se quieren enfocar las
pruebas? si a bajo nivel
escribiendo casos de prueba
detallados o con pruebas
exploratorias y escenarios bien
definidos se cumple el propósito
de prueba?
¿Qué es un escenario?
Descripción de una línea de lo
que queremos probar.

15. Análisis de una feature - comparativa
CASO DE PRUEBA
Concepto que provee
información detallada de
qué probar, pasos a tomar y
resultado esperado.
ESCENARIO
Concepto que provee en
una línea información sobre
qué probar.

16. Análisis de una feature - comparativa
CASO DE PRUEBA
Documentación de "única
vez" de todos los casos de
pruebas es beneficioso
para poder tener
trazabilidad de miles
de rondas de regresión en
el futuro.
ESCENARIO
Ahorra tiempo y es una
actividad generadora
de ideas.
La modificación y agregado
de escenarios es simple y
no específico a una
persona en particular.

17. Análisis de una feature - comparativa
CASO DE PRUEBA
Documentación de este
nivel de profundidad es de
gran ayuda a cada nueva
incorporación al equipo o
personas que recién
entran en el mundo
del testing.
ESCENARIO
Buen cubrimiento de
pruebas puede ser obtenido
dividiendo la aplicación en
escenarios, reduce
repetición y reduce
complejidad del producto.
Da más visibilidad macro.

18. Análisis de una feature - comparativa
CASO DE PRUEBA
Consume mucho tiempo y
dinero al tener que detallar
todo lo necesario para
probar en cada caso y
además el tiempo
consumido en
mantenimiento.
ESCENARIO
Solo una línea
como escenario
hace que se requiera más
discusión y comunicación
para que cada miembro del
equipo pueda entender el
objetivo de las pruebas.

19. Ejemplo práctico
Feature llenar una dirección de envío en un sistema web de
e-commerce Analisis general
● Puntos de acceso.
● Campos por defecto
y obligatorios.
● Casos de error.
● Traducciones.
● Dependencia con
otros features.
● Entre otros...
Recomendable
un mindmap
para esta
actividad de
análisis

20. Ejemplo práctico
Analisis con test cases
Un ejemplo de test case para este feature
Titulo: Dirección de envío - Agregar dirección nueva correctamente.
Ambiente: Testing
Browser: Chrome, Firefox, IE9+
Versión: 1.02
Story asociada: ALI-4593
Prioridad: Critica
Nivel: Prueba de humo
Tiempo de ejecución estimado: 5 minutos
Precondiciónes:
- Existe un usuario y está con una sesión abierta en la aplicación.
- Idioma definido español.
- Existe al menos una dirección anteriormente.
Pasos de reproducción:
1. Ir a la página principal https://www….
2. Ir a menú de usuario
3. Click en acceso a información de cuenta de usuario.
4. En el menú lateral hacer click en "Mi dirección de entrega"
5. Hacer click en agregar nueva dirección
6. Llenar los campos de dirección con la siguiente
información:
a. Nombre:
b. Apell...
c. …
d. …
7. Hacer click en "Guardar"
Resultado esperado:
- Se ve correctamente mensaje de dirección guardada
- Se puede ver dirección ingresada en listado de direcciones
- Consultando la base de datos se puede ver dirección ingresada
correctamente con la siguiente consulta: Select … from … where ...
Este nivel de detalle para los cerca de
50 - 100 casos que pueden derivarse
fácilmente de está feature puede tomar
un tiempo considerable.

21. Ejemplo práctico
Analisis con Escenarios
Escenario a nivel de
feature
1 Escenario ~ 50 -100
Casos de prueba
1 Escenario
~ 20 Casos
de prueba
1 Escenario
~ 8 Casos de
prueba
1 Esc ~ 1 CP

22. Ejemplo práctico
Análisis con Escenarios
Escenario: Dirección de envío - Agregar dirección nueva
correctamente.
Prioridad/Nivel: Completo
# Casos de prueba: 20
Condiciones de prueba: Traducciones, campos opcionales,
pruebas geográficas.

23. Agenda
● Rol de QA
● Repaso de conceptos de testing
● Analisis de un feature
● Regresiones y reportes
● Conclusiones

24. Regresiones y reportes
La generación de una instancia de regresión para el uso de escenarios en vez de
casos de prueba no es distinto.
El elemento a pasar o fallar es el escenario y dentro del reporte se pueden ver
varias dimensiones de avance.
- Cubrimiento de los features por tiempo de ejecución.
- Cubrimiento de los features por cantidad de casos de prueba equivalente.
- Cubrimiento de los features por cantidad de escenarios executados.

25. Regresiones y reportes

26. Agenda
● Rol de QA
● Repaso de conceptos de testing
● Analisis de una feature
● Regresiones y reportes
● Conclusiones

27. Conclusiones
A la hora de elegir una estrategia de testing hay que ver que es lo más
conveniente en función del tipo de proyecto.
No existen recetas mágicas, hay opciones, una de ellas hacer casos de prueba,
otra mind maps de exploratorio o tener una base de escenarios de prueba.
Es importante priorizar todas las tareas que hay que hacer dentro del rol de
testing y a veces hay que tomar decisiones por falta de tiempo y recursos.
Es importante mantener la comunicación con el equipo completo y hacer el
trabajo de la forma más práctica posible.

28. ¿Preguntas?

29. ¡Muchas
gracias!
Referencias
http://www.softwaretestingclass.com/what-is-difference-bet
ween-test-cases-vs-test-scenarios/
https://lisacrispin.com/2011/11/08/using-the-agile-testing-q
uadrants/
http://tryqa.com/what-are-test-pyramid-and-testing-quadran
ts-in-agile-testing-methodology/
https://glossary.istqb.org/en/search/test%20case