¿Cuál es el problema?

Cualquier equipo de desarrollo de software es consciente de que las pruebas de software son cruciales para el éxito de un lanzamiento. Encontrar fallos críticos en los primeros días de un lanzamiento importante de software es embarazoso, reduce enormemente la confianza de los usuarios en la versión y retrasa la adopción de la nueva versión. Retrasar la adopción de una versión deja a los usuarios expuestos a vulnerabilidades de seguridad, errores conocidos que deberían corregirse y carencias de funciones que facilitan la vida tanto al usuario como al desarrollador.

Para combatir el lanzamiento de versiones de software defectuosas, hemos diseñado un proceso de pruebas que llamamos cariñosamente "Chaos Testing".

¿Qué es la prueba del caos?

La prueba del caos comienza con la suposición de que su software está roto. Las pruebas del caos no están diseñadas para que el software pase una lista de control de lanzamiento, sino que una prueba del caos exitosa es aquella que expone los errores. Para pasar la prueba del caos, el equipo debe descubrir un cierto número de errores. Ese número de errores debe ser determinado por el equipo de desarrollo.

^{La prueba del caos comienza con la suposición de que el software está roto.}

Las pruebas del caos son libres. No hay manuales de pruebas ni listas de comprobación. Los manuales y las listas de comprobación fomentan un patrón de uso muy específico y repetido del software. Si utiliza el software de la misma manera cada vez, sólo está probando que el software funciona de la manera que los desarrolladores quieren que funcione.

¿Cuándo debemos realizar pruebas del caos?

Las pruebas del caos deben realizarse en todas las versiones principales y secundarias. Las versiones de corrección en caliente pueden quedar exentas de las pruebas del caos, ya que el objetivo de una corrección en caliente es parchear rápidamente una versión defectuosa.

Las pruebas del caos están pensadas para reducir la necesidad de revisiones.

Pruebas previas al caos

Antes de iniciar las pruebas del caos, debe realizarse una iteración de la lista de comprobación de la versión. Ejecutar primero la lista de comprobación de la versión nos permite validar que las nuevas características funcionan y que no se han introducido errores de regresión.

No tiene sentido empezar las pruebas del caos si el software no puede pasar la lista de comprobación de la versión. Queremos que las pruebas del caos descubran errores que no se encontrarían durante una lista de comprobación de lanzamiento.

Pruebas del caos - Día de demostración

Las pruebas del caos comienzan siempre con un día de demostración. Invite a todas las partes interesadas y deje una invitación abierta a cualquier otra persona interesada. Los desarrolladores deberían turnarse para demostrar la funcionalidad en la que han trabajado personalmente.

El día de demostración ofrece dos ventajas principales:

• • Ofrece a las partes interesadas y a otros desarrolladores la oportunidad de criticar y ver un trabajo que de otro modo no habrían visto.
  • Expone posibles puntos débiles del código.

Analicemos el último punto. Cuando los desarrolladores de software hacen una demostración, siempre tienen una lista de pasos que ejecutan en un orden muy concreto. Durante la demostración, el desarrollador siempre está secretamente nervioso de que algún aspecto de la demostración vaya a fallar o de que alguien que esté viendo la demostración le pida que haga algo de lo que no está seguro. Esto expone a los principales candidatos a las pruebas del caos.

Como testigo de la demo, es tu trabajo prestar atención a estos momentos y sugerir al demostrador que se desvíe del guión para exponer nuevos fallos. Además, el demostrador debe tomar nota de las partes de la demostración que le pusieron nervioso y darles prioridad para sus propias pruebas de caos.

Al final del día de demostración, se debe haber registrado una lista de notas y errores. Termine el día revisando la lista y creando nuevos tickets en su sistema de seguimiento de incidencias.

Pruebas del caos

Una vez concluida la jornada de demostración, es el momento de iniciar las pruebas formales del caos. Una vez más, la prueba del caos es libre. Las listas de comprobación y los manuales de pruebas deben descartarse.

Durante las pruebas, los desarrolladores deben tener en cuenta la siguiente cita:

^{| Hoy en día, la programación es una carrera entre los ingenieros de software, que se esfuerzan por construir programas cada vez más grandes y mejores a prueba de idiotas, y el Universo, que intenta producir idiotas cada vez más grandes y mejores. Hasta ahora, el Universo está ganando".}

^{- Rick Cook, La Hechicería Compilada}

Nuestro objetivo durante las pruebas es convertirnos en el mayor y mejor idiota. Eso significa abusar completamente del software de cualquier forma que podamos imaginar. Algunas sugerencias:

• • ¿Qué pasa si hago clic repetidamente en un botón 1000 veces?
  • ¿Qué pasa si pulso todas las teclas del teclado en un campo de texto?
  • ¿Qué ocurre si genero configuraciones completamente irracionales?
  • ¿Qué ocurre si el hardware externo se desconecta/conecta rápidamente?
  • ¿Qué pasa si desconecto/conecto internet constantemente?
    • ¿Qué pasa si la conexión es terrible y veo grandes pérdidas de paquetes?

El cielo es el límite a la hora de probar el caos. Haz todo lo que puedas para romper el software. No importa si estás 100% seguro de que ningún usuario realizaría ciertas acciones, porque te equivocas. Lo harán.

Si quieres centrar tus esfuerzos, piensa en el día de la demostración. ¿Qué le puso nervioso durante su demostración? ¿Qué puso nerviosos a los demás presentadores? Son áreas en las que hay que centrarse.

Las pruebas de caos deben durar un mínimo de dos días, pero NO terminarán hasta que se haya encontrado un número determinado de fallos (definido por su equipo). Su software ESTÁ roto. HAY errores. Si no los encuentra, la prueba del caos continúa.

Priorización

Una vez que haya completado las pruebas de caos, es el momento de pasar a la priorización. No todos los errores que encuentre el equipo serán críticos o romperán el software. Algunos serán errores visuales menores; otros tendrán un riesgo casi nulo para el usuario.

Definan en equipo qué fallos son críticos y cuáles son menores. Todos los errores críticos deben corregirse inmediatamente (retrasando la publicación si es necesario). Los errores menores pueden corregirse antes de la publicación o trasladarse a una publicación futura, según determine el equipo.

Después del caos

Una vez finalizado el día de demostración, las pruebas de caos y la priorización, el equipo debe empezar a ejecutar las listas de comprobación de la versión y los manuales de pruebas. Si el software no pasa la lista de comprobación de lanzamiento, solucione los problemas y vuelva a ejecutar toda la lista de comprobación. Repita el proceso hasta que la lista de comprobación de la versión sea correcta.

Recuerde que los desarrolladores no deben ejecutar elementos de la lista de comprobación que se apliquen a cosas en las que hayan trabajado.

Conclusión

Las pruebas del caos han mejorado notablemente la calidad de nuestras versiones de software y firmware y han reducido en gran medida el número de problemas que descubren nuestros clientes. Sin embargo, es importante recordar el credo de las pruebas del caos. Su software está roto. Esto significa que, aunque haya superado las pruebas del caos y haya lanzado una nueva versión de su software, sigue estando roto y debe seguir esperando que lleguen informes de errores.