En ambientes ágiles, usualmente asignamos puntos de historia a todas nuestras tareas de desarrollo, entendiendo “desarrollo” como todo el trabajo necesario para entregar nuevas funcionalidades a clientes y usuarios (no solo el código fuente).
En algunos equipos, la automatización de tests relacionados a una funcionalidad está incluída en el Definition of Done, y en este caso, estimamos el esfuerzo de la automatización como parte del “desarrollo”; sin embargo, en otros equipos no todos los tests automatizados pueden ser completados en el sprint y necesitamos un backlog de tareas de automatización para continuarlos después y hacer el seguimiento correcto.
La mayoría de los equipos no estima las tareas de automatización de test, pero ¿por qué? no conllevan esfuerzo? no agregan valor a clientes/usuarios y al negocio/producto? No tengo esa respuesta así que no vamos a profundizarlo.
Lo que sí vamos a profundizar es en cómo estimar tareas de automatización de tests, teniendo en cuenta los siguientes supuestos:
- Esta guía está pensada para tests de interfaz de usuario, de API y e2e.
- This guide is for UI, API, and User Acceptance tests. Probablemente muchas más variables y riesgos/complejidad estén involucrados al estimar las tareas de automatización de performance, por ejemplo (y esta guia no los cubre).
- Aplica solo para equipos que tienen un backlog de tareas de automatización de tests (este esfuerzo no es estimado como parte de la tarea/historia/epic de desarrollo).
- Estos valores de referencia no están escritos en piedra. Escribí esta guía para mi equipo, y cada equipo define su estandar atendiendo a diversos factores como el seniority de los miembros de su equipo, el riesgo/complejidad del negocio/producto, su forma de trabajo, sus recursos y más.
Guía de Story Points para tareas de automatización de pruebas
0.5: solución fácil, sin riesgo/complejidad o característica menor
La implementación y verificación no debería llevar más de 1 hora..
Ejemplos:
- Cambiar un selector en una prueba ya existente.
- Actualizar una verificación/afirmación en una prueba ya existente.
1 – complejidad fácil y mínima; requiere unas pocas horas de esfuerzo para implementar
Una tarea sencilla. Esfuerzos menores para implementar y verificar.
Automatización de un caso de prueba sencillo con unos pocos pasos de verificación.
No requiere agregar nuevos datos (o datos simulados) ni nuevas bibliotecas.
Ejemplos:
- Modificar los scripts de automatización existentes para adaptarse a cambios menores en la interfaz de usuario.
- Escribir nuevas pruebas automatizadas para una función pequeña y aislada.
2 – sigue siendo relativamente sencillo, aunque más complejo y de mayor volumen que “1”
La implementación y verificación podrían tardar entre 1 y 2 días..
Puede requerir mock data o crear/actualizar data.
Puede ser flaky y requerir otros mecanismos para evitar o reducir flakiness.
Ejemplos:
- Similar a “1” pero agregando datos simulados o interceptación.
- Mejorar/Actualizar los scripts de automatización existentes para manejar funcionalidades adicionales o escenarios de error.
3 – complejidad o tamaño moderado
Un trabajo medio, que requiere cierto esfuerzo pero que no introduce riesgos ni deuda técnica
Puede requerir datos simulados o bibliotecas nuevas.
Puede requerir conexión a recursos externos.
Ejemplos:
- Automatizar un caso de prueba moderadamente complejo que involucra múltiples pasos y verificaciones.
- Escribir pruebas automatizadas para una función de tamaño mediano con varios casos de uso.
- Similar a “2”, pero agregando mock data o interception, que requieren otros mecanismos para evitar/reducir flakiness.
- Mantener/actualizar mock data o mock services.
5 – complejidad/tamaño moderado a alto, algunos riesgos.
Podría llevar una semana implementar y verificar, una tarea más compleja y de mayor volumen que requiere cierto análisis y una implementación exhaustiva.
uede requerir una conexión a recursos externos.
Ejemplos:
- Implementar una conexión GraphQL.
- Automatizar un flujo de trabajo complejo con múltiples interacciones en diferentes módulos..
- Escribir pruebas automatizadas para un feature grande y complejo que requiere escenarios de validación extensos.
8 – alta complejidad/tamaño, riesgos/incertidumbre moderados
Este es el tamaño máximo de una historia que es aceptable incluir en el sprint y, si es posible, debe dividirse en historias más pequeñas.
Ejemplos:
- Refactorización y optimización (actualización) de frameworks de automatización o conjuntos de pruebas existentes.
- Automatizar un escenario altamente complejo que involucra integraciones con sistemas externos, configuraciones de datos complejas y numerosas dependencias.
13 – alto riesgo/complejidad/volumen, alto riesgo/incertidumbre
Debería dividirse en historias más pequeñas y detalladas.
Ejemplos:
- Crear un nuevo framework de automatización o rediseñar significativamente uno existente.
- Escribir pruebas automatizadas para una característica extensa y multifacética con una amplia gama de casos de uso e interacciones.
¿Vale la pena estimar tareas de automatización de tests?
Para mí, SI!
Cuando estimamos tareas de automatización de tests no estamos buscando medir la velocidad de nuestros SDETs, sino más bien medir el esfuerzo de crear y mantener nuestras suites de tests automatizados.
Esto aplica solo para equipos que tienen un backlog de tareas de automatización de pruebas (y este esfuerzo no es estimado como parte de las tareas de desarrollo del feature).
Una de las ventajas de estimar y mantener límites en el alcance de las tareas así como limitar el WIP (work in progress) del equipo (o de un miembro del equipo) en un momento dado, independiente si trabajas o no en sprints.
También, estimar significa que no vamos a comenzar una tarea de automatización de tests si no está claramente definido el alcance y qué se necesita para completarlo (casos/escenarios. recursos, datos, servicios externos, etc), lo que hace que la tarea sea alcanzable reduciendo incertidumbre.
Este post está inspirado en Story Points Estimation: From Theory to Practice