🛃 🍽️ 👨‍👨‍👧‍👧 Simplemente diga no a las pruebas de final 2 📢 🤤 ⬆️

Probablemente tenías esto cuando tú y tus amigos realmente querían ver una película, y luego lamentaron haber pasado tiempo en ella. O tal vez recuerde el momento en que su equipo pensó que había encontrado una "característica asesina" y encontró sus "trampas" solo después del lanzamiento del producto.

Las buenas ideas a menudo fallan en la práctica, y en el mundo de las pruebas, una estrategia de prueba basada en la automatización de prueba de extremo a extremo es un buen ejemplo de esto.

Los probadores pueden invertir su tiempo escribiendo muchos tipos de pruebas automatizadas, incluidas las pruebas unitarias, las pruebas de integración y las pruebas de extremo a extremo, pero esta estrategia está dirigida principalmente a las pruebas de extremo a extremo que prueban el producto o servicio en su conjunto. Por lo general, estas pruebas imitan escenarios de usuarios reales.

Fuente

Pruebas de extremo a extremo en teoría

Si bien confiar principalmente en las pruebas de extremo a extremo es una mala idea, en teoría se pueden presentar varios argumentos a favor de esta afirmación.

Entonces, el número uno en la lista de Google de diez cosas que, como sabemos, es cierto: "Los intereses de los usuarios sobre todo". Por lo tanto, el uso de pruebas end-2-end que se centran en escenarios de usuarios reales parece una gran idea. Además, esta estrategia es generalmente atractiva para muchos participantes en el proceso.

A los desarrolladores les gusta esta estrategia, porque puedes transferir la mayoría de las pruebas, si no todas, a otros.
, , , , , , .
, , ; .

End-2-end

Entonces, si esta estrategia de prueba se ve tan bien en teoría, ¿qué tiene de malo en la práctica? Para demostrar esto, daré un escenario ficticio a continuación, pero que se basa en situaciones reales que son familiares para mí y otros probadores.

Supongamos que un equipo crea un servicio para editar documentos en línea (por ejemplo, Google Docs). Supongamos que el equipo ya tiene una infraestructura fantástica para realizar pruebas. Cada noche:

Construye la última versión del servicio,
entonces esta versión se implementa en el entorno de prueba del equipo,
luego, en este entorno de prueba, se ejecutan todas las pruebas de extremo a extremo,
El equipo recibe un informe por correo electrónico que resume los resultados de la prueba.

La fecha límite se acerca rápidamente. Para mantener un alto nivel de calidad del producto, digamos que decidimos que al menos el 90% de las pruebas exitosas de end-2-end son necesarias para que consideremos que la versión está lista. Digamos que la fecha límite llega en un día.

A pesar de numerosos problemas, las pruebas finalmente revelaron errores reales.

Lo que salió bien Los

errores que afectaban al usuario fueron identificados y corregidos antes de que lo alcanzaran.

Algo salió mal

El equipo completó su fase de programación una semana después (y trabajó mucho tiempo extra).
Encontrar la causa raíz de la prueba fallida de end-2-end lleva mucho tiempo y puede llevar mucho tiempo.
Las fallas del equipo paralelo y el mal funcionamiento del equipo movieron los resultados de la prueba por varios días.
Muchos errores menores estaban ocultos detrás de errores grandes.
Los resultados de la prueba de extremo a extremo 2 no han sido confiables a veces.
Los desarrolladores tuvieron que esperar hasta el día siguiente para averiguar si la solución funcionó o no.

Entonces, ahora que sabemos lo que salió mal en la estrategia final-2-final, necesitamos cambiar nuestro enfoque de prueba para evitar muchos de los problemas anteriores. Pero, ¿cuál es el enfoque correcto?

El verdadero valor de las pruebas.

Como regla, el trabajo del probador termina cuando la prueba falla. El error se registra y luego la tarea del desarrollador es corregir el error. Sin embargo, para determinar dónde no funciona la estrategia end-2-end, debemos ir más allá de este pensamiento y abordar el problema utilizando nuestros principios básicos. Si nos “enfocamos en el usuario (y todo lo demás sigue)”, debemos preguntarnos: ¿la prueba fallida beneficia al usuario?

Aquí está la respuesta: "Una prueba fallida no beneficia directamente al usuario".

Aunque esta afirmación, a primera vista, parece impactante, es verdad. Si el producto funciona, funciona, independientemente de si la prueba dice que funciona o no. Si un producto está roto, está roto, independientemente de si la prueba dice que está roto o no. Entonces, si las pruebas fallidas no benefician al usuario, ¿qué lo beneficia a él?

Las correcciones de errores benefician directamente al usuario.

El usuario será feliz solo cuando este comportamiento impredecible (error) desaparezca. Obviamente, para corregir un error, debe saber que existe. Para descubrir que existe un error, idealmente debe hacerse una prueba que lo detecte (porque si la prueba no detecta el error, entonces el usuario lo encontrará). Pero en todo el proceso, desde el fracaso de la prueba hasta la corrección del error, el valor agregado aparece en el último paso.

Por lo tanto, para evaluar cualquier estrategia de prueba, no puede simplemente evaluar cómo encuentra errores. También debe evaluar cómo esto permite a los desarrolladores corregirlos (e incluso prevenirlos).

Construyendo la retroalimentación correcta

Las pruebas crean un ciclo de retroalimentación que informa al desarrollador sobre si el producto funciona o no. Un ciclo de retroalimentación ideal tiene varias propiedades.

. , , . ( ), . . , .
. , , , . , , .
Debería permitirle encontrar rápidamente errores. Para corregir el error, los desarrolladores deben encontrar las líneas de código específicas que causan el error. Cuando un producto contiene millones de líneas de código, y el error puede estar en cualquier lugar, es como tratar de encontrar una aguja en un pajar.

Piensa pequeño, no grande

Entonces, ¿cómo creamos este ciclo de retroalimentación perfecto? Pensando en lo pequeño, no en lo más grande.

Pruebas

unitarias Las pruebas unitarias toman una pequeña porción de un producto y lo prueban aisladamente de todo lo demás. Casi crean el mismo ciclo de retroalimentación perfecto:

Las pruebas unitarias son rápidas. Necesitamos escribir un pequeño bloque de código y ya podemos probarlo. Las pruebas unitarias suelen ser bastante pequeñas. De hecho, una décima de segundo es demasiado larga para las pruebas unitarias.
. , , . , — , , — .
. , , , , .

Escribir pruebas unitarias efectivas requiere habilidades en áreas tales como la gestión de dependencias, escribir comprobantes / simulacros y pruebas estrictas. No describiré estas habilidades aquí, pero para empezar, el ejemplo típico ofrecido al nuevo Googler (o como se les llama en Google, el Noogler) es cómo Google crea y prueba el cronómetro.

Pruebas unitarias frente a las pruebas finales 2 finales

Para las pruebas finales 2 finales, debe esperar: primero para crear el producto completo, luego implementarlo y, finalmente, completar todas las pruebas finales 2 finales. Cuando las pruebas aún funcionan, lo más probable es que fallen periódicamente. E incluso si la prueba detecta un error, puede estar en cualquier parte del producto.

Aunque las pruebas de extremo a extremo son mejores para modelar escenarios de usuarios reales, esta ventaja se ve rápidamente compensada por todas las deficiencias del ciclo de retroalimentación de extremo a extremo:

Pruebas de integración Las

pruebas unitarias tienen un inconveniente importante: incluso si los módulos funcionan bien por separado, no sabe si funcionan bien juntos. Pero incluso entonces, no tiene que ejecutar pruebas de extremo a extremo. Puede usar la prueba de integración para esto. La prueba de integración toma un pequeño grupo de módulos, a menudo dos, y prueba su comportamiento como un todo.

Si los dos bloques no se integran correctamente, ¿por qué escribir una prueba de extremo a extremo cuando puede escribir una prueba de integración mucho más pequeña y centrada que detecte el mismo error? Por supuesto, debe comprender todo el contexto al probar, pero para probar el trabajo de dos módulos juntos solo necesita expandir un poco la perspectiva.

Pirámide de prueba

Incluso con las pruebas unitarias y de integración, es probable que necesite una pequeña cantidad de pruebas end-2-end para probar el sistema en su conjunto. Para encontrar el equilibrio correcto entre los tres tipos de pruebas, es mejor usar una pirámide de prueba visual. Aquí hay una versión simplificada de la pirámide de prueba del discurso de apertura de la conferencia 2014 de Google Test Automation .

La mayor parte de sus pruebas son pruebas unitarias en la parte inferior de la pirámide. A medida que avanzas en la pirámide, tus pruebas se vuelven más completas, pero al mismo tiempo, el número de pruebas (el ancho de tu pirámide) disminuye.

En el buen sentido, Google ofrece una separación 70/20/10: 70% pruebas unitarias, 20% pruebas de integración y 10% pruebas end-2-end. La proporción exacta será diferente para cada equipo, pero en general debe mantener la forma de la pirámide. Intente evitar los siguientes "formularios":

Pirámide invertida / cono de helado. El equipo se basa principalmente en pruebas de extremo a extremo, utilizando varias pruebas de integración y muy pocas pruebas unitarias.
Reloj de arena. El equipo comienza con una gran cantidad de pruebas unitarias y luego usa pruebas de extremo a extremo donde se deben usar las pruebas de integración. El reloj de arena tiene muchas pruebas unitarias en la parte inferior y muchas pruebas de extremo a extremo en la parte superior, pero pocas pruebas de integración en el medio.

Así como una pirámide ordinaria tiende a ser la estructura más estable en la vida real, una pirámide de prueba también tiende a ser la estrategia de prueba más estable.

Trabajos

Si amas y sabes escribir pruebas unitarias, ¡entonces eres bienvenido! La empresa LANIT ha abierto una vacante para el desarrollador de Java en el equipo de DevOps, donde encontrará personas de ideas afines.

Simplemente diga no a las pruebas de final 2