Acerca de esta herramienta
La mayoría de los equipos saben cuántos tests automatizados tienen. Menos saben si esos tests son una señal en la que alguien confía. Esta evaluación hace doce preguntas sobre lo que ocurre realmente hoy, dos por cada una de seis áreas: estrategia y alcance, framework y calidad del código, integración en CI/CD, datos de prueba y entornos, fiabilidad e inestabilidad, e informes y responsabilidad. Cada respuesta vale de 0 a 3 puntos. Cada área se puntúa sobre 100 a partir de sus dos respuestas, y la puntuación global es la media de las seis áreas, así que un equipo con un framework precioso que solo funciona en un portátil no puede puntuar bien. La puntuación global corresponde a uno de cuatro niveles: “Ad hoc” (menos de 35), “Emerging” (de 35 a 59), “Established” (de 60 a 84) y “Optimised” (85 o más). Las áreas más débiles por debajo de 80, hasta tres, se devuelven como próximos pasos concretos con enlaces a las lecciones y herramientas que las tratan. La puntuación es una rúbrica fija, detallada en las preguntas frecuentes de abajo. Es un punto de partida para una retrospectiva o una sesión de planificación, no una comparación con otras empresas: no hay ningún conjunto de datos de otros equipos detrás, ni se pretende que lo haya.
Cómo usarla
- Responde cada pregunta con la opción que describa lo que tu equipo hace hoy. Las aspiraciones y los planes cuentan como la opción en la que estás ahora.
- Tu puntuación se actualiza en cuanto respondes las doce preguntas. Las respuestas se guardan en este navegador, así que puedes volver a ellas.
- Lee la lista “Work on next”: primero las áreas más débiles, cada una con un paso concreto y enlaces para profundizar.
- Usa “Copy share link” para enviar el resultado a tu equipo. El enlace contiene las respuestas, así que quien lo abra verá las mismas puntuaciones. “Copy summary” da texto plano para Slack, un ticket o un documento de retrospectiva.
Qué mide cada una de las seis áreas
- Estrategia y alcance: si la automatización apunta al riesgo de forma deliberada y si la mayoría de las comprobaciones están en el nivel más barato capaz de detectar el bug (unitarias y de API antes que de UI).
- Framework y calidad del código: si el código de test está estructurado (page o component objects, fixtures, configuración) y se revisa como el código de producción, y si los locators sobreviven a los cambios de marcado.
- Integración en CI/CD: si los tests se ejecutan en cada cambio sin que nadie tenga que acordarse, y cuánto espera una pull request a obtener la respuesta.
- Datos de prueba y entornos: si los tests son dueños de sus datos y pueden ejecutarse en paralelo y en cualquier orden, contra un entorno que es igual cada vez.
- Fiabilidad e inestabilidad: si un build en rojo significa un problema real. Las esperas fijas y relanzar hasta que salga verde son los culpables habituales.
- Informes y responsabilidad: si un fallo se puede diagnosticar a partir del informe del CI y si todo el equipo, no solo QA, actúa en consecuencia.
Cómo usar el resultado con un equipo
Pide a dos o tres personas (un tester, un desarrollador, quien gestione el pipeline) que la rellenen por separado y después comparad los enlaces. Donde las respuestas difieren suele ser más útil que la propia puntuación: si una persona elige “on every pull request” y otra “nightly”, el equipo no está de acuerdo sobre lo que hace el pipeline.
Elige un área de “Work on next” por trimestre. Subir un área de 33 a 67 vale más que repartir el esfuerzo entre las seis. Repetid la evaluación al final del trimestre con las mismas personas.
Preguntas frecuentes: Evaluación de madurez de la automatización de pruebas
¿Cómo se calcula la puntuación?
Cada respuesta vale 0, 1, 2 o 3 puntos, en el orden en que aparecen las opciones. Cada área tiene dos preguntas, así que se puntúa sobre 6 y se muestra como porcentaje. La puntuación global es la media de los porcentajes de las seis áreas, redondeada. Niveles: “Ad hoc” por debajo de 35, “Emerging” 35–59, “Established” 60–84, “Optimised” 85 o más.
¿Es una referencia del sector?
No. La evaluación es una rúbrica fija basada en prácticas de automatización de pruebas ampliamente aceptadas, no una comparación con otras empresas. No hay ningún conjunto de datos de otros equipos detrás, y SDETRole no recoge tus respuestas para crearlo.
¿Dónde se guardan mis respuestas?
En el almacenamiento local de tu navegador, y en el fragmento del enlace compartido (la parte tras #) cuando lo copias. Los navegadores no envían el fragmento a los servidores, así que SDETRole nunca recibe tus respuestas.
Si abro el enlace de un compañero, ¿se sobrescribirán mis respuestas?
No. Un resultado compartido se muestra sin guardarse. Si cambias una respuesta, empiezas tu propia copia a partir de sus respuestas, y esa copia se guarda en tu navegador.
Aún no tenemos automatización. ¿Sigue siendo útil?
Sí. Responde con sinceridad y puntuarás bajo en la mayoría de las áreas; la lista “Work on next” te dirá entonces por dónde empezar, que suele ser la estrategia (qué automatizar primero) y el CI (ejecutarlo automáticamente desde el primer día).