La experiencia te va mostrado diferentes formas de estimar el tiempo de las pruebas, aquí algunas:
1️⃣ Estimación basada en el conocimiento
Por ejemplo, un ingeniero de pruebas que está familiarizado con un producto durante un mes daría una evaluación que diferirá de un tester que conoce el producto hace un año, solo porque el segundo analista conoce más detalles, trucos y trampas. Esto basado en el supuesto que tenemos, en el segundo caso a una persona valiente para explorar mas allá de la superficie.
2️⃣ Estimación basada en sesiones de prueba
Suena sospechoso cuando un ingeniero de pruebas, de entrada, dice con exactitud cuanto tiempo tomará realizar algo; seguramente le hace falta la experiencia de enfrentarse a la incertidumbre de los proyectos, más en entornos ágiles.
La respuesta correcta sería: en caso de que no haya errores, se necesita este rango de tiempo para probar esta funcionalidad. Dependiendo del nivel de completitud del producto variarán el tiempo de pruebas, la elaboración de informe de errores y las pruebas de regresión. Todos sabemos que no existe un producto libre de bugs. Incluso cuando crea que ha encontrado todos los hallazgos, no significa que el producto no tenga bugs. En cualquier caso, la lista de defectos encontrados durante la primera ronda (o la cantidad de rondas que sea necesaria) de prueba detiene como mínimo ese día de pruebas. Por lo tanto, nombre el rango de tiempo que necesita, no la cantidad de tiempo concreta.
Dentro de este rango, se debe incluir las actividades previas a la prueba real:
- Leer la documentación (si existe).
- Hablar con el equipo para conocer el producto.
- Preparar todo para las pruebas (datos de prueba, herramientas de prueba, casos de prueba, configuraciones del entorno, obtener acceso a los servicios que necesita para las pruebas, etc.).
- Realizar la primera ronda de pruebas y crear tickets para algún defecto encontrado. Una prueba puede estar compuesta de varias rondas de 30, 60 o 90 minutos.
- Esperar la solución, realizar la segunda ronda de pruebas, cerrar los defectos, crear nuevos defectos.
- Atender reuniones del proyecto o sociales del equipo u oficina.
- Tomar pausas para combatir la disminución de la atención en tareas repetitivas
- Repetir los pasos 4 al 7 hasta que el producto aporte el valor esperado.
Las pruebas puras podrían demorar dos días, pero deben extenderse en el tiempo para que sean más eficientes y productivas. El analista de pruebas debe dar a conocer a todo el equipo, el manager en especial, los enfoques de prueba y, como experto, defender su posición al respecto.
3️⃣ Estimación basada en el tipo de prueba
El tipo de prueba que aplique tiene un impacto directo en la estimación del tiempo de prueba. El rango de tiempo varía dependiendo del nivel de profundidad o del tipo de prueba que se realizará. O es una prueba de interfaz de usuario o una prueba de API, pruebas de humo, de aceptación o de regresión.
4️⃣ Estimación basada en experiencia del ingeniero de pruebas
Si es un experto en pruebas de API, el tiempo de ejecución será menor que el de un tester que sabe menos en ese tipo de prueba o es generalista (que sabe de varias al tiempo). Lo mismo ocurre con las pruebas de seguridad, rendimiento o cualquier otro tipo. El concepto del especialista en forma de T se vuelve cada vez más popular. Es importante asegúrese de que la tarea la realizará la misma persona que la estimó; de lo contrario, si la estimación fue proporcionada por otra persona (por ejemplo, el líder de control de calidad), debe considerar el nivel profesional de cada ingeniero de control de calidad del equipo.
Cualesquiera que sean las estimaciones, hay algo que debemos tener en cuenta:
- Mantenga siempre un búfer (colchón) de tiempo (20% o 30%).
- Analizar condiciones que permitan acelerar las pruebas, esto beneficia a los usuarios.
- Estar preparados para que las pruebas puedan ir mucho más allá de la estimación (pero este es otro tema).
5️⃣ Estimación basada en correcciones de errores
Cuando se detectan hallazgos, se tienen intervalos de tiempo para que se corrijan los errores. No puede estimar y predecir el tiempo para cada corrección de errores. Por lo tanto, no puede predecir cuándo obtendrá una nueva versión del software después de su primera sesión de prueba. Incluso aunque se conozca muy bien al equipo de desarrolladores y en el pasado hayan tenido una buena racha de gestión de estos hallazgos. El QA debe estar preparado para utilizar el tiempo de espera adelantando otras actividades.
Conclusiones
Necesitamos distinguir el tiempo de prueba y el tiempo para estabilizar la versión del software. El tiempo de corrección y estabilización puede variar y todo el esfuerzo del equipo está enfocado en eso. En la práctica, el búfer de tiempo que cada miembro del equipo pone en su estimación debe representar parcialmente el tiempo de estabilización de la versión. La pregunta principal es ¿cuánto tiempo puede permitirse el equipo considerando los cortos calendarios de lanzamiento del mundo Agile?
Seguramente hay otros enfoques para hacer estimaciones precisas o estrechas. En este artículo se incluyeron los mas comunes. Si tienes otras técnicas útiles, me encantaría leer sobre ellas en la sección de comentarios.
Fuentes
5 Ways for Testing Time Estimation por Yuliia Kuprii.
Foto por Markus Spiske en Unsplash.