Diseño de pruebas: una habilidad esencial de QA

Uno de los conceptos erróneos clave en el panorama actual de las pruebas es que las pruebas en producción solo requieren tres conjuntos de habilidades: experiencia en procesos, conocimientos de herramientas de pruebas automatizadas y capacidades de gestión de incidentes. Estas son importantes, pero hay algo cuya ausencia resulta evidente, no solo en esta lista, sino también en la mente de los responsables de contratación: algo que uno pensaría que sería lo más fundamental:

La capacidad de diseñar una prueba práctica para entornos de producción.

Sería cómico si no fuera tan alarmante que casi ninguna organización priorice la experiencia en habilidades clave de control de calidad al implementar estrategias de pruebas en producción.

Ya sea que una prueba se ejecute manualmente o mediante automatización en un sistema de producción en directo, primero debes saber cómo diseñar una que proporcione información práctica sin alterar la experiencia del usuario, ¿verdad?

Sería cómico si no fuera tan alarmante que casi ninguna organización priorice la experiencia en diseño de pruebas al implementar estrategias de pruebas en producción. Ya sea que una prueba se ejecute manualmente en un entorno controlado o de forma automatizada en un sistema de producción en directo, primero debes saber cómo diseñar una que proporcione información práctica sin alterar la experiencia del usuario, ¿verdad?

Hay un problema evidente al excluir la experiencia en diseño de pruebas de tu enfoque de pruebas en producción:

¿Acaso no es esencial saber que la persona que implementa las pruebas en tu entorno de producción entiende qué constituye una prueba significativa?

¿Puesto que automatizar pruebas mal diseñadas en producción te proporciona datos poco fiables con mayor rapidez y crea riesgos innecesarios? Y ser "ágil" mientras se realizan pruebas en producción de forma incompetente no me parece una mejora real, salvo quizá para el responsable de Scrum.

La importancia y la disciplina del diseño de pruebas, especialmente para las situaciones de pruebas en producción, llevan mucho tiempo necesitando una recuperación. Considera esto mi contribución a ese esfuerzo.

¿Qué es esencial para realizar pruebas eficaces en producción?

El primer paso para dominar las pruebas en producción consiste en establecer algunas distinciones esenciales que, sin duda, ya resultarán intuitivamente familiares para la mayoría de los profesionales de control de calidad, pero que rara vez se presentan de forma sistemática en los contextos de pruebas de producción.

Exploremos estos conceptos fundamentales que transformarán tu enfoque de las pruebas en producción.

Funcionalidad explícita frente a implícita en entornos de producción

Comencemos con la distinción fundamental entre la funcionalidad explícita y la implícita al realizar pruebas en producción.

La primera es lo que la mayoría de nosotros consideramos "funcionalidad". Se refiere a las características y capacidades especificadas formalmente por el área de Producto, cuya especificación formal guía su implementación en Ingeniería. Al realizar pruebas en producción, estas funciones explícitas suelen ser el centro de atención de las herramientas de monitorización y observabilidad.

Por este motivo, probar la funcionalidad explícita en producción puede parecer sencillo, pero incluso con características bien definidas, no es así, como veremos más adelante. Al menos, el nivel de especificidad que posee la funcionalidad explícita facilita la creación de una estructura de pruebas de producción a su alrededor (o de la ilusión de dicha estructura).

La funcionalidad implícita en un entorno de producción es un asunto completamente distinto.

Consiste en comportamientos y respuestas a entradas del usuario o del entorno que no se definieron ni anticiparon formalmente. No diseñar adecuadamente pruebas para esta funcionalidad implícita en producción es, con diferencia, la fuente de la mayoría de los errores críticos descubiertos después de desplegar el producto (la otra fuente son las pruebas inadecuadas en entornos periféricos de hardware/software/dispositivos).

En otras palabras:

Probar la funcionalidad implícita en producción requiere un considerable ingenio e imaginación. Es la parte verdaderamente creativa de las estrategias de pruebas de producción.

Probar la funcionalidad implícita en entornos de producción requiere cierta astucia endiablada para llegar a dominarlo y, por desgracia, eso no se puede enseñar mediante los procesos estándar de control de calidad.

Ninguna cantidad de metodología ágil ni de marcos de pruebas automatizadas te enseñará a probar eficazmente la funcionalidad implícita en producción, pero un diseño de pruebas adecuado puede fomentarlo.

Entonces, ¿cómo se define una estrategia de diseño de pruebas para la funcionalidad implícita en tu entorno de producción? Afortunadamente, se puede hacer. Pero antes de profundizar directamente en esa cuestión, exploremos algunas distinciones relevantes adicionales que son fundamentales para realizar pruebas eficaces en producción.

Pruebas positivas frente a pruebas negativas

Conclusión clave: Al realizar pruebas en producción, tanto las pruebas positivas como las negativas requieren consideraciones especiales que van más allá de los enfoques tradicionales de control de calidad.

La mayoría de las personas que trabajan en control de calidad entienden la diferencia básica entre estos dos tipos de pruebas:

• Pruebas positivas en producción: Validar que las funcionalidades funcionan según lo diseñado en entornos reales
• Pruebas negativas en producción: Probar estratégicamente cómo responde el sistema a entradas inesperadas sin interrumpir a los usuarios reales

Por qué las pruebas en producción son diferentes

Aunque estas distinciones son conceptualmente claras, las pruebas en producción introducen desafíos únicos:

• Mayores riesgos: Los casos extremos afectan a clientes reales y a las operaciones empresariales
• Complejidad del mundo real: El comportamiento de los usuarios rara vez sigue patrones predecibles
• Continuidad empresarial: Las pruebas no deben interrumpir las operaciones normales

Más allá de la especificación

Las especificaciones rara vez proporcionan todo lo necesario para realizar pruebas eficaces en producción:

Depender demasiado de la especificación, ya provenga del equipo de Producto o de Ingeniería, limita tu forma de pensar. Esto resulta especialmente problemático al probar en producción, donde los patrones de uso del mundo real suelen desviarse de las especificaciones.

Esto ilustra lo que llamo «la falacia empírica»: esperar a que algo te indique explícitamente qué hacer antes de poder comprenderlo.

El diseño de pruebas eficaz para entornos de producción requiere:

1. Parametrización adecuada de la funcionalidad
2. Razonamiento lógico sobre lo que es posible
3. Consideración de las interacciones tanto del usuario como del entorno

Ejemplo del mundo real: comportamientos inesperados

En el Cretácico del software (es decir, los años 80), probé un programa de conversión de documentos y descubrí capacidades sorprendentes:

Mostrar imagen

Ejemplo clásico: En WordPerfect, se podía insertar un comando de interlineado en mitad de un párrafo que afectaba únicamente a las líneas posteriores, creando párrafos con dos valores de interlineado diferentes.

Equivalentes modernos al probar en producción:

• Combinaciones inesperadas de permisos de usuario en aplicaciones en la nube
• Secuencias imprevistas de solicitudes de API en arquitecturas de microservicios
• Condiciones de carrera en entornos de alta concurrencia

Ahora exploremos los tres parámetros clave que mejorarán tu enfoque de las pruebas en producción:

1. Pruebas del alcance de las funcionalidades

Definición: Identificar cómo podrían los usuarios implementar funcionalidades en contextos o de formas que nunca se imaginaron durante el diseño.

Por qué es importante para las pruebas

No todas las restricciones se prevén durante el desarrollo. En entornos de producción, esta falta de previsión puede tener graves consecuencias.

Más allá de la validación sencilla

Al probar en producción, considera estos límites:

Recuerda: Validar una funcionalidad en producción no consiste únicamente en confirmar que funciona según lo diseñado, sino en verificar que no puede utilizarse de formas no previstas que puedan afectar a la estabilidad o la seguridad del sistema.

2. Pruebas de interrupción de flujos de trabajo en sistemas activos

Advertencia: Este enfoque presupone que ya estás probando flujos de trabajo definidos en producción. Si no es así, ¡aborda primero esos fundamentos!

Más allá del «camino feliz»

Al probar en producción, explora estas interrupciones críticas de los flujos de trabajo:

✅ Flujos de trabajo interrumpidos: El proceso se inicia, pero nunca se completa
✅ Operaciones canceladas: El usuario cancela explícitamente el proceso a mitad de su ejecución
✅ Procesos reiniciados: El usuario intenta realizar la misma acción varias veces
✅ Retroceso: El usuario vuelve a pasos anteriores con entradas diferentes

Consejos de implementación para las pruebas en producción

Utiliza técnicas como los indicadores de funcionalidades para controlar de forma segura la exposición de estas pruebas en entornos de producción.

Aplicaciones del mundo real

Consejo profesional: Estos escenarios rara vez se recogen en las especificaciones, pero representan el comportamiento real de los usuarios en producción.

3. Secuencialidad en las pruebas en producción

El desafío: En los sistemas de producción con múltiples procesos simultáneos, la secuencia de las operaciones puede provocar fallos inesperados que son difíciles de reproducir en entornos de prueba.

Dos patrones críticos de secuencialidad

Condiciones contribuyentes antecedentes

Mostrar imagen

• Definición: Eventos que deben ocurrir antes de un proceso que falla
• Características: Pueden manifestarse únicamente después de secuencias específicas que tardan días en producirse de forma natural
• Ejemplo en producción: Se modifican los permisos del usuario → la caché caduca → se llama a una API específica

Condiciones contribuyentes posteriores

• Definición: Fallos que solo se hacen evidentes mediante interacciones posteriores
• Manifestación: El fallo permanece oculto hasta que se realiza una operación posterior
• Ejemplo en producción: La corrupción de datos se produce silenciosamente hasta que se genera un informe

¿Por qué es tan difícil?

Definir el alcance de las pruebas de secuencialidad en producción requiere:

1. Un conocimiento profundo de las interacciones del sistema
2. Modelado de las transiciones de estado para procesos complejos
3. Comprensión de las combinaciones de estados previstas y no previstas

"Al igual que esos valores de interlineado doble en un mismo párrafo, estos estados inesperados pueden causar estragos en los entornos de producción."

Herramientas esenciales para las pruebas de secuencialidad en producción

• Herramientas de ingeniería del caos para introducir deliberadamente fallos controlados
• Herramientas de observabilidad para realizar un seguimiento de los cambios de estado en los sistemas
• Seguimiento distribuido para seguir las rutas de las solicitudes a través de los microservicios

En resumen: Los problemas de secuencialidad representan una de las fuentes más abundantes de errores graves en los sistemas de producción modernos. Da prioridad a este aspecto en tu estrategia de pruebas.

Conclusión

Los indicadores de funcionalidades transforman las pruebas en producción de una práctica arriesgada en un proceso controlado y basado en datos. Al desvincular el despliegue de la publicación y proporcionar capacidades de reversión instantánea, crean una red de seguridad que permite a los equipos validar el software en condiciones reales sin poner en riesgo la experiencia del usuario ni la estabilidad del sistema.

Plataformas de gestión de funcionalidades en las pruebas en producción

Las plataformas de gestión de funcionalidades han transformado las pruebas en producción de una iniciativa arriesgada en un proceso controlado y sistemático. Sin embargo, muchas organizaciones no aprovechan estas herramientas de forma eficaz dentro de su estrategia de diseño de pruebas.

La evolución de la gestión de riesgos en producción

Los enfoques tradicionales para las pruebas en producción implicaban decisiones binarias: una funcionalidad estaba activa para todos o para nadie. Las plataformas de gestión de funcionalidades cambian fundamentalmente este paradigma:

• Control granular: Prueba las funcionalidades con segmentos de usuarios específicos en lugar de realizar despliegues de todo o nada
• Corrección instantánea: Desactiva las funcionalidades problemáticas sin despliegues de código ni reversiones
• Exposición progresiva: Aumenta gradualmente la exposición de los usuarios en función de los datos de rendimiento en tiempo real

Más allá de los simples indicadores de funcionalidades

Aunque la activación básica de funcionalidades existe desde hace años, las plataformas modernas de gestión de funcionalidades ofrecen capacidades esenciales que transforman las pruebas en producción:

Cuando se integran correctamente en tu estrategia de diseño de pruebas, las plataformas de gestión de funcionalidades permiten:

1. Contención específica del riesgo - Limitar la exposición de las nuevas funcionalidades a segmentos de usuarios concretos
2. Validación con usuarios reales - Probar con usuarios reales en lugar de utilizar datos de prueba sintéticos
3. Corrección inmediata - Resolver problemas sin despliegues de emergencia ni reversiones

Integración con herramientas de observabilidad

El verdadero poder de las plataformas de gestión de funcionalidades surge cuando se integran con sistemas de observabilidad y monitorización:

Enfoque tradicional:

• Detectar problemas después del despliegue completo
• Verificación manual de los resultados de las pruebas
• Análisis post mortem después de los incidentes

Integración de la gestión de funcionalidades:

• Correlacionar la activación de funcionalidades con las métricas del sistema
• Monitorización automatizada del rendimiento para cada indicador de funcionalidad
• Información en tiempo real sobre el impacto de las funcionalidades

Impacto en el mundo real: transformar las pruebas en producción

Las organizaciones que implementan plataformas de gestión de funcionalidades informan de beneficios significativos:

• Menor gravedad de los incidentes: "Podemos probar las funcionalidades en producción mucho antes del lanzamiento de marketing. Y si una funcionalidad causa problemas el día del lanzamiento, podemos desactivarla con un interruptor de apagado, sin necesidad de hacer reversiones." — Chris Guidry, vicepresidente de Ingeniería de O'Reilly Media.
• Ciclos de lanzamiento acelerados: Los equipos de IBM, TrueCar y otras empresas líderes aprovechan la gestión de funcionalidades para realizar pruebas en producción y disfrutan de lo que describen como "lanzamientos seguros y sin ceremonias".
• Mayor cobertura de pruebas: Los indicadores de funcionalidad revelan casos límite que es imposible simular en entornos controlados.

Implementación práctica en el diseño de pruebas

Para incorporar eficazmente las plataformas de gestión de funcionalidades a tu estrategia de diseño de pruebas:

1. Diseña puntos de verificación que se ajusten a las transiciones de los indicadores de funcionalidad
2. Crea escenarios alternativos para cada componente controlado por indicadores de funcionalidad
3. Establece umbrales de rendimiento que activen la deshabilitación automática de funcionalidades
4. Define casos de prueba específicos para cada segmento a fin de validar el comportamiento en distintos grupos de usuarios
5. Documenta las dependencias entre indicadores para evitar fallos en cascada

Las plataformas de gestión de funcionalidades no sustituyen un diseño de pruebas bien planteado, sino que lo potencian. La calidad de las pruebas en producción sigue dependiendo fundamentalmente de lo bien que hayas diseñado tus pruebas.

Errores habituales que debes evitar

Incluso con una gestión sólida de las funcionalidades, siguen existiendo varios desafíos:

• Deuda de indicadores - Indicadores abandonados u olvidados que generan deuda técnica
• Monitorización insuficiente - No correlacionar el estado de los indicadores con el rendimiento del sistema
• Exceso de confianza - Reducir prematuramente las pruebas previas a producción
• Interdependencias entre indicadores - Crear relaciones complejas y difíciles de diagnosticar

La conclusión

Las plataformas de gestión de funcionalidades ofrecen capacidades potentes para realizar pruebas en producción, pero deben integrarse cuidadosamente en tu estrategia general de diseño de pruebas. Las organizaciones que obtienen el mayor valor no se limitan a implementar estas herramientas, sino que replantean fundamentalmente cómo funciona el diseño de pruebas en un entorno controlado por indicadores de funcionalidad.

Cuando se implementa correctamente como parte de un enfoque integral del diseño de pruebas, la gestión de funcionalidades transforma las pruebas en producción de un mal necesario en una ventaja competitiva.

Herramientas para realizar pruebas en producción: desafíos de implementación

Aunque los indicadores de funcionalidad y las plataformas de gestión constituyen la base de las pruebas en producción, el ecosistema de herramientas más amplio presenta sus propios desafíos de implementación. Seleccionar y configurar las herramientas adecuadas requiere considerar detenidamente las capacidades del equipo, la arquitectura del sistema y las necesidades de la organización.

Herramientas de monitorización y observabilidad

La eficacia de las pruebas en producción depende de disponer de una visibilidad completa del comportamiento del sistema:

• Monitorización del rendimiento de las aplicaciones (APM)
  Ventajas: Proporciona información detallada sobre el rendimiento en toda la pila de aplicaciones.
  Desafíos: A menudo requiere una instrumentación considerable y puede generar un exceso de datos que abrume a los equipos pequeños.
• Sistemas de gestión de registros
  Ventajas: Son esenciales para la depuración y el análisis forense durante las pruebas en producción.
  Desafíos: Pueden generar volúmenes abrumadores de datos sin estrategias adecuadas de filtrado e indexación.
• Seguimiento distribuido
  Ventajas: Ofrece visibilidad de extremo a extremo en arquitecturas de microservicios.
  Desafíos: La complejidad de implementación aumenta considerablemente en entornos heterogéneos con múltiples pilas tecnológicas.

Sistemas de gestión de alertas

Una alerta adecuada es fundamental al probar nuevas funcionalidades en producción:

• Plataformas de agregación de alertas
  Ventajas: Consolidan las notificaciones de varios sistemas de monitorización.
  Desafíos: Son excelentes para la gestión de incidentes, pero pueden resultar disruptivas si no se configuran cuidadosamente para evitar la fatiga por alertas.
• Sistemas de respuesta a incidentes
  Ventajas: Agilizan la comunicación durante los incidentes en producción.
  Desafíos: Requieren procedimientos operativos bien definidos y puntos de integración para ser eficaces; pueden generar una carga adicional en despliegues sencillos.

Consideraciones de implementación

Al implementar herramientas para realizar pruebas en producción, los equipos deben evaluar:

1. Requisitos de escalabilidad - ¿La herramienta podrá gestionar sus volúmenes de tráfico y el crecimiento de los datos?
2. Capacidades de integración - ¿Con qué facilidad se conecta con su conjunto de herramientas existente?
3. Consumo de recursos - ¿Qué carga adicional introduce la propia herramienta?
4. Experiencia del equipo - ¿Dispone de las habilidades necesarias para maximizar el valor de la herramienta?
5. Relación señal-ruido - ¿Puede extraer información significativa sin verse abrumado por los datos?

Errores habituales de implementación

• Proliferación de herramientas - Acumular demasiadas soluciones que se solapan
• Instrumentación incompleta - Omitir puntos críticos de monitorización
• Fatiga por alertas - Generar un exceso de notificaciones que los equipos terminan ignorando
• Contexto insuficiente - No correlacionar las métricas con el impacto en los usuarios
• Silos de datos - Crear sistemas de monitorización aislados que no comparten información

Encontrar el equilibrio adecuado

Las implementaciones más exitosas de pruebas en producción logran un equilibrio entre:

• Monitorización exhaustiva frente a complejidad gestionable
• Información detallada frente a sobrecarga de información
• Respuestas automatizadas frente a puntos de decisión humanos

Al implementar herramientas de prueba en entornos de producción, comience con objetivos concretos y de alcance reducido; después, amplíe gradualmente la cobertura a medida que su equipo adquiera experiencia tanto con las herramientas como con la interpretación de los datos resultantes.

Carga, complejidad y latencia

Considere los factores macro de carga, complejidad y latencia en el diseño de sus pruebas. Estos pueden afectar a la ejecución o finalización de una solicitud, un proceso o un evento. 

La relevancia de la carga del sistema debería ser evidente. La forma en que se procesan las solicitudes o transacciones durante periodos de alta carga de estrés del sistema puede provocar fallos (en cualquier etapa del proceso de transacción).

Esto debería formar parte de manera predeterminada de la planificación de sus pruebas. Como todos sabemos, la carga también puede generarse como resultado de la propia solicitud; por ejemplo, una consulta de datos que desencadena el procesamiento y la transmisión de enormes cantidades de datos.

La complejidad se refiere aquí principalmente a la complejidad de las solicitudes realizadas a un sistema. Esta complejidad puede consistir en el número de condiciones especificadas (y sus exclusiones y excepciones), el número de bases de datos (virtuales o no) implicadas en las solicitudes o la propia topología de procesamiento del sistema.

En el contexto de este análisis, utilizo la latencia para indicar la introducción de lapsos de tiempo en el proceso de solicitud, que no es su significado habitual. Me refiero aquí a la latencia del usuario, no a la latencia de respuesta del propio sistema. 

En otras palabras, ¿cómo se comporta la funcionalidad o capacidad si el usuario llega a un paso concreto del proceso y permanece en pausa allí, sin hacer nada? ¿El sistema agota el tiempo de espera (probablemente debería hacerlo)? ¿Debería solicitar una acción al usuario? ¿Debería permanecer en ese estado hasta el fin de los tiempos? 

Las respuestas a estas preguntas pueden estar incluidas en la especificación, pero el producto sometido a prueba puede no comportarse de esa manera, que es precisamente por lo que hacemos pruebas.

Roles de usuario

Por supuesto, los usuarios finales pueden interactuar con los sistemas de software en distintos roles. Un mismo usuario puede interactuar con el sistema en roles diferentes, según sus acciones. 

Sin embargo, los procesos y servicios también pueden tener diferentes roles y privilegios asociados. En cualquiera de los casos, asegúrate de que el diseño y la planificación de tus pruebas, ya sea para funcionalidades o capacidades, consideren y prueben todos los estados posibles de los roles.

¿Qué viene después?

¿Buscas más consejos sobre diseño de pruebas? ¿Y quieres mejorar tus habilidades de crecimiento y liderazgo en SaaS?

Suscríbete a nuestro boletín para recibir las últimas perspectivas de CTO y de aspirantes a líderes tecnológicos. 

¡Te ayudaremos a escalar de forma más inteligente y a liderar con mayor solidez mediante guías, recursos y estrategias de los mejores expertos!