Mejore la Calidad del Software y Ahorre Tiempo con Pruebas de Infraestructura
Nota del editor: Bienvenido a la serie Liderazgo en Pruebas del gurú de pruebas de software y consultor Paul Gerrard. La serie está diseñada para ayudar a los testers con algunos años de experiencia, especialmente a quienes forman parte de equipos ágiles, a sobresalir en sus roles de líder de pruebas y gestión.
En un artículo anterior, te mostré cómo gestionar las pruebas de rendimiento. Ahora hablaremos sobre software de infraestructura IT, infraestructura de pruebas y entornos de pruebas.
Suscríbete al boletín de The QA Lead para recibir notificaciones cuando se publiquen nuevas partes de la serie. Estas publicaciones son extractos del curso Liderazgo en Pruebas de Paul, que recomendamos para profundizar más en este y otros temas. Si decides hacerlo, usa nuestro código de cupón exclusivo QALEADOFFER para obtener $60 de descuento en el precio total del curso.
Infraestructura es el término que usamos para describir todo el hardware, servicios en la nube, redes, software de soporte y nuestra aplicación bajo prueba que se requiere para desarrollar, probar, desplegar y operar nuestros sistemas.
Tiene sentido no limitar nuestra definición únicamente a la tecnología. Los centros de datos, el espacio de oficinas, escritorios, ordenadores de sobremesa, portátiles, tabletas y teléfonos móviles con sus propias pilas de software instaladas, forman parte del ecosistema necesario para desarrollar, probar y desplegar sistemas.
Si incluyes herramientas para desarrolladores, herramientas y procedimientos DevOps, herramientas de prueba y los procesos de negocio y la experiencia de los especialistas que se requiere, hay aún más implicado.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Las cosas más mundanas —los códigos de acceso o las tarjetas inteligentes que se utilizan para acceder a los edificios— pueden volverse críticas si no están disponibles.
La infraestructura, en toda su variedad, existe para respaldar el desarrollo, pruebas, implementación y operaciones de tus sistemas. O bien es crítica para las pruebas o necesita ser probada.
Veremos herramientas para desarrollo, pruebas y colaboración en el próximo artículo. En este, consideraremos lo que la mayoría de la gente entiende por entornos de prueba y analizaremos brevemente lo que a menudo se denomina pruebas de infraestructura. Cubriré:
- Entornos de Prueba
- Entornos de Desarrollo
- Entornos de Prueba a Nivel de Sistema
- Entornos de Datos
- Pruebas de Infraestructura
Vamos allá.
Entornos de Prueba
Toda prueba hace una suposición implícita, crítica y simplificadora: que nuestras pruebas se ejecutarán en un entorno conocido.
¿Qué es un entorno?
Todos los sistemas deben probarse en contexto. Para que una prueba tenga sentido, el sistema debe estar instalado, configurado, desplegado o construido en un entorno realista que simule el mundo real donde se utilizará.
Podríamos utilizar escenarios de prueba que lleven al límite la capacidad de los sistemas en términos de funcionalidad, rendimiento o seguridad, por ejemplo, pero esas son propiedades de las pruebas, no del entorno.
Un entorno realista replicaría todos los entornos empresariales, técnicos y organizacionales. Gran parte de esto consiste en los datos que se usan para impulsar procesos empresariales, configurar el sistema y proporcionar datos de referencia.
Pero los entornos perfectamente realistas suelen ser imprácticos o demasiado costosos (incluso quienes prueban sistemas de alta criticidad como aviones, reactores nucleares o escáneres cerebrales tienen que hacer concesiones en algún punto). Casi todas las pruebas se realizan en entornos que simulan el mundo real con un nivel de compromiso aceptable.
Los coches se prueban en bancos de rodillos, túneles de viento, plataformas vibratorias y pistas de pruebas privadas antes de ser probados en la carretera abierta. Los sistemas informáticos se prueban en laboratorios de software por programadores y testers antes de que los usuarios finales los prueben en un entorno similar al de producción.
Para garantizar que tus entornos de prueba cumplen con los estándares de la industria, considera integrar una de estas plataformas líderes en gestión de pruebas.
Prueba en entornos realistas
Los entornos simulados son falibles, igual que nuestros requisitos y modelos de pruebas, pero debemos aceptarlo.
Debemos planificar pruebas significativas en los entornos que tenemos disponibles, y los resultados de las pruebas significan lo que interpretamos que significan.
La fiabilidad de los resultados de las pruebas depende del entorno en el que se ejecutan. Si una prueba se ejecuta en un entorno configurado incorrectamente:
- Una prueba que falla puede implicar que el sistema es defectuoso cuando, en realidad, es correcto.
- Una prueba que pasa puede implicar que el sistema es correcto cuando, en realidad, es defectuoso.
Ambas situaciones son, por supuesto, altamente indeseables.
Configurar y Entregar Entornos a Tiempo
Incluso con la aparición de infraestructura en la nube, los entornos de prueba pueden ser difíciles y costosos de configurar y mantener.
Cuando los equipos de soporte trabajan en el nuevo entorno de producción, los testers requieren entornos de prueba (y, quizás, varios de ellos). Más adelante, durante las pruebas, los equipos de soporte suelen enfrentarse a demandas en competencia.
Los entornos de desarrollo o cualquier actividad de prueba posterior pueden entregarse tarde, no entregarse en absoluto, o bien no estar configurados ni controlados como se requiere. Inevitablemente, esto retrasará las pruebas y/o minará la confianza en cualquier resultado de las pruebas.
Una tarea crítica es establecer la necesidad y los requisitos de un entorno para ser usado en pruebas, incluyendo un mecanismo para gestionar los cambios en ese entorno—lo antes posible.
La infraestructura como código es una evolución reciente en la forma en que se pueden construir entornos utilizando herramientas que siguen procedimientos y emplean código declarativo para definir la configuración del entorno.
Aunque las plataformas básicas del sistema operativo (servidores) pueden crearse fácilmente en la nube o como máquinas virtuales en tu propio entorno, los servidores totalmente especificados y de propósito especial, con todo el software, datos, configuraciones e interfaces necesarios, requieren más esfuerzo.
Al configurar tu infraestructura de pruebas, es crucial integrar un software de gestión de bases de datos fiable para un rendimiento óptimo
Sin embargo, una vez configurados, proporcionan un medio altamente eficiente para la creación de entornos. El código de infraestructura puede ser controlado por versiones igual que cualquier código de aplicación y gestionado frente a los cambios.
Un principio fundamental de la entrega continua es que, tan pronto como sea posible, algún software—aunque no sea útil—debe ser enviado a través del pipeline de entrega para probar que los procesos funcionan.
Por supuesto, esto requiere entornos viables para las construcciones (builds), herramientas de integración continua, pruebas a nivel de sistema y despliegue. El objetivo es desplegar entornos de prueba y producción sin restricciones. Una vez que se han definido los entornos y los procesos de despliegue, la generación de entornos se vuelve una tarea automatizada y rutinaria.
Bajo cualquier circunstancia, las definiciones de estos entornos son una entrega temprana del proyecto.
Entornos de Desarrollo
Las pruebas de los desarrolladores se centran en la construcción de componentes de software que proporcionan funcionalidades internamente a la aplicación o en la capa de usuario o presentación.
Las pruebas suelen estar impulsadas por el conocimiento de la estructura interna del código, y puede que no utilicen o requieran datos "realistas" para ejecutarse. Las pruebas de componentes o servicios de bajo nivel suelen ejecutarse a través de una API usando controladores o herramientas propietarias o hechas a medida.
La variedad de herramientas de desarrollo, plataformas y los llamados Entornos de Desarrollo Integrados (IDEs, por sus siglas en inglés) es enorme. En este artículo, solo podemos abordar algunos de los requisitos y características principales relacionados con las pruebas en los entornos.
Para apoyar el desarrollo y las pruebas en el alcance de los desarrolladores, los entornos deben facilitar las siguientes actividades. Esta es solo una selección; puede haber actividades adicionales o variaciones de estas en tu situación:
- Un entorno "Sandbox" para experimentar con nuevo software. Los "sandboxes" se utilizan a menudo para probar nuevas librerías, desarrollar prototipos de código desechables o practicar técnicas de programación. Todos los lenguajes de programación comunes tienen cientos o miles de librerías de software. Los sandboxes se usan para instalar y probar software que aún no forma parte del desarrollo principal con el fin de evaluarlo y practicar su uso. Estos entornos pueden ser tratados como entornos desechables.
- Entorno de desarrollo local. Aquí es donde los desarrolladores mantienen una copia local de una parte o de la totalidad del código fuente de su aplicación desde un repositorio de código compartido y pueden crear compilaciones del sistema para pruebas locales. Este entorno permite que los desarrolladores realicen cambios en su copia local y prueben sus cambios. Algunas pruebas son ad hoc y quizás nunca se repiten. Otras pruebas están automatizadas. Las pruebas automatizadas usualmente se retienen para siempre, especialmente si siguen un enfoque de Desarrollo Guiado por Pruebas (TDD).
- Entorno de Integración Compartida (Continua). Cuando los desarrolladores consideran que su código está listo, suben sus cambios al repositorio de código compartido y controlado. El entorno de CI realiza compilaciones automáticas y ejecuta pruebas automatizadas usando el repositorio. En este punto, el código nuevo o modificado se integra y se prueba. El sistema de CI ejecuta pruebas automatizadas bajo demanda, cada hora o diariamente, y el equipo completo recibe notificaciones y puede ver el estado de las pruebas del último build integrado. Los fallos se exponen rápidamente y se abordan con urgencia.
Un entorno de desarrollo o CI da soporte a las pruebas de los desarrolladores, pero puede que otros servidores de aplicación, servicios web, mensajería o servidores de bases de datos que completan el sistema no estén disponibles.
Si estos sistemas de interfaz no existen porque no se han construido, o porque pertenecen a una empresa asociada y solo hay un sistema en vivo y no una versión de prueba, entonces los desarrolladores tienen que simular o falsear estas interfaces para al menos poder probar su propio código.
Las herramientas de simulación pueden ser sofisticadas, pero las interfaces simuladas normalmente no pueden soportar pruebas que requieran datos integrados entre varios sistemas.
Si los desarrolladores disponen de una interfaz a un servidor de base de datos de prueba, sus datos de prueba podrían ser mínimos, no integrados ni consistentes, y no representativos de los datos de producción.
Las bases de datos de desarrollo compartidas en un equipo generalmente son insatisfactorias. Si no existe un buen régimen de gestión de este recurso compartido, los desarrolladores podrían reutilizar, dañar o borrar los datos de los demás.
Entornos de Prueba a Nivel de Sistema
Las pruebas a nivel de sistema se centran en la integración de componentes y subsistemas trabajando en colaboración.
Estos entornos proporcionan una plataforma para apoyar los objetivos de la integración a mayor escala, la validación de funcionalidades y la operación de sistemas en el contexto de procesos de usuario o de negocio.
Los entornos también pueden estar dedicados a los aspectos no funcionales del sistema, como el rendimiento, la seguridad o la gestión de servicios.
Uno de los errores más comunes en las pruebas es cuando un tester del sistema experimenta algún tipo de fallo en su entorno, pero por más que lo intenten, el desarrollador o el tester no pueden reproducir ese fallo en el entorno de desarrollo.
“¡En mi máquina sí funciona!”
“Sí, claro que sí.”
Esto casi con toda seguridad es causado por una falta de coherencia entre los dos entornos. La diferencia en el comportamiento puede deberse a la configuración, a diferencias en la versión del software o a la diferencia en los datos de la base de datos.
Las diferencias en los datos que causan problemas son lo primero que se debe revisar. Por lo general, son fáciles de identificar y muchas veces pueden resolverse rápidamente.
Cuando existe una discrepancia de versión de software o de configuración, los testers y desarrolladores pueden perder mucho tiempo rastreando la causa de la diferencia en el comportamiento.
Cuando ocurren estos problemas, suele significar que existe una falla en la comunicación entre el desarrollador y el equipo de pruebas. También podría indicar una pérdida de control de la configuración en la configuración del entorno de desarrollo o pruebas, o en el proceso de despliegue.
La infraestructura como código y el aprovisionamiento automatizado de entornos harán que los problemas de consistencia de los entornos sean cosa del pasado.
Tipos de Entornos de Prueba Dedicados
Para dar soporte a las pruebas de sistema, aceptación y no funcionales, los entornos deben permitir las siguientes actividades (puede que haya más en tu organización):
- Entorno de pruebas (funcionales) del sistema. En este entorno, el sistema se valida contra los requisitos documentados para el sistema en su conjunto. Los requisitos pueden ser grandes documentos de texto con casos de prueba tabulados definidos para una prueba de sistema. En proyectos ágiles, este entorno puede ser necesario para permitir que los evaluadores exploren el sistema integrado sin limitarse a funciones específicas.
- Entorno de pruebas de extremo a extremo. Cuando el entorno de integración continua (CI) permite que los componentes se integren con subsistemas, los procesos de negocio pueden requerir que otros sistemas interfaz (no controlados por los desarrolladores) estén disponibles. Se requieren entornos de alcance total para realizar integraciones a gran escala, pruebas de procesos de negocio o pruebas generales de aceptación. Normalmente, los datos son una copia de los datos en vivo o al menos de una escala adecuada. Cuando se necesita demostrar la integración a gran escala, los flujos de datos y control se ejercitan mediante recorridos de usuario más largos y conciliaciones independientes de los datos a través de los sistemas integrados. Gestionar los datos en los entornos de prueba es crucial. Si ya usas Jira, considera mejorar tus capacidades de gestión de datos con herramientas avanzadas de gestión de pruebas diseñadas para Jira.
- Entorno de rendimiento. Estos entornos deben proporcionar una plataforma significativa para evaluar el rendimiento de un sistema (o de determinados subsistemas). Puede haber compromisos en la arquitectura en caso de redundancia o clonación de servidores. Sin embargo, los volúmenes de datos deben ser a escala de producción aunque los datos sean sintéticos. Por supuesto, el entorno debe tener la envergadura suficiente para soportar volúmenes de transacciones de producción y así permitir prever el rendimiento de los sistemas en producción.
- Entornos de disponibilidad, resiliencia y gestionabilidad (ARM). En algunos aspectos, estos entornos son similares a los entornos de rendimiento, pero dependiendo del objetivo de la prueba, pueden ser inevitables ciertas variaciones. Las pruebas de disponibilidad buscan verificar que el sistema puede operar durante periodos prolongados sin fallar. Las pruebas de resiliencia (a menudo llamadas pruebas de conmutación por error) comprueban que, cuando fallan los componentes del sistema, no se produzca una interrupción inaceptable en el servicio entregado. Las pruebas de gestionabilidad u operativas tienen como objetivo demostrar que los procedimientos administrativos, de gestión y de respaldo y recuperación del sistema funcionan eficazmente.
Datos en los entornos
En algunos proyectos muy grandes, puede haber hasta 20 o incluso 30 entornos a gran escala dedicados a diferentes aspectos de pruebas, formación, migración de datos y cortes de prueba. En proyectos más pequeños habrá menos, quizás solo un entorno compartido o un régimen de entrega continua—y todas las pruebas podrían implementarse automáticamente en entornos que se instancian para un solo uso y luego se eliminan.
Todos los entornos necesitan datos, pero la escala y el grado de realismo de esos datos pueden variar. Aquí tienes algunos patrones comunes en la forma en que se adquieren y gestionan los datos de prueba. Estos patrones se centran en la propiedad (local o compartida), los medios de creación (manual, automática o copiada de producción) y la escala:
- Datos locales, creados manualmente, a pequeña escala—adecuados para pruebas ad hoc por parte de desarrolladores o evaluadores.
- Datos locales, automáticos y sintéticos. Adecuados para pruebas automatizadas de desarrolladores o entornos donde se puede cubrir la funcionalidad de módulos o características específicas.
- Datos compartidos, creados manualmente. Usados en entornos de integración y pruebas de sistema, a menudo cuando los datos de prueba han evolucionado en paralelo con pruebas manuales. Se respaldan y restauran cuando es necesario.
- Datos compartidos, creados automáticamente. Usados en entornos de integración y pruebas de sistema donde los datos de prueba han evolucionado en paralelo con pruebas automatizadas o manuales. Se generan y/o restauran desde respaldos, cuando se requiere.
- Datos sintéticos/aleatorios a gran escala y compartidos. Las pruebas de rendimiento y ARM requieren datos coherentes en gran volumen. Estos datos normalmente no necesitan ser significativos: los datos aleatorizados funcionan bien y se generan cuando es necesario, o se generan inicialmente y se restauran a partir de respaldos.
- Datos significativos a gran escala y compartidos. Las pruebas de extremo a extremo, de aceptación o de usuario suelen necesitar datos significativos a escala. A veces se utilizan copias o extractos de datos en vivo. Sin embargo, ten cuidado de no infringir las regulaciones de datos si no los anonimizas o alteras adecuadamente.
- Re-pruebas y pruebas de regresión. Requerirás un conjunto de datos conocido y controlado, en un estado predecible, por lo que generalmente se restaura desde respaldos. Esto se aplica a cualquiera de los entornos anteriores, ya que estas pruebas deben repetirse con los datos en un estado conocido para reproducir los fallos de manera fiable.
Pruebas de infraestructura
Al principio de este artículo, examinamos qué incluye la infraestructura y desde entonces nos hemos centrado principalmente en los componentes técnicos, es decir, los sistemas de software, y hemos supuesto que el hardware—real o virtual—está disponible.
Cuando construimos sistemas inicialmente, presumimos que la infraestructura existe y que funciona correctamente, es eficiente, segura, resiliente, etc.
Podemos probar todos estos aspectos cuando hemos integrado nuestra aplicación y, sin duda, expondremos carencias en la infraestructura en una etapa relativamente tardía de nuestros proyectos. Pero encontrar problemas de infraestructura en una fase tan avanzada del proyecto suele ser sumamente disruptivo.
- Los cambios para solucionar fallos en la infraestructura podrían requerir un rediseño importante y modificaciones en nuestra aplicación.
- Los resultados de nuestras pruebas de aplicación o de todo el sistema tendrán que repetirse.
- Si fallan componentes de terceros como bases de datos, servicios web, de red o de mensajería, dependemos de los proveedores (o de la comunidad open source) que los mantienen.
Para garantizar que nuestra confianza en los componentes de infraestructura esté bien fundamentada, podemos basarnos en nuestra experiencia (o la de otros) usándolos en el pasado. O necesitamos evaluar —mediante pruebas— su fiabilidad antes de comprometernos a utilizarlos en el diseño y construcción de nuestro sistema.
Dependiendo de la infraestructura que se esté investigando, el entorno puede variar: desde un solo servidor hasta una plataforma de infraestructura casi completa.
Aunque algunas pruebas serán manuales, la mayoría de veces utilizaremos herramientas, drivers o robots para simular la carga de transacciones que generaría nuestra aplicación. Necesitaremos simular o crear versiones mock o stub de estas interfaces:
- Interfaces que actualmente no están disponibles
- Interfaces con componentes en los que confiamos y son fáciles de simular
- Interfaces fuera del alcance y que no afectan a la infraestructura bajo prueba.
La infraestructura, por supuesto, normalmente no funciona a través de un usuario o una interfaz gráfica.
La integración de nuestra aplicación con la infraestructura tomará principalmente la forma de mensajería o llamadas a servicios remotos. A menudo, el tráfico a simular requiere llamadas API a servidores web o de aplicaciones, servidores de mensajes o bases de datos, o servicios entregados a través de la nube o ubicaciones remotas.
Los objetivos de rendimiento y ARM pueden ser conocidos, en cuyo caso se pueden realizar pruebas para asegurar que se cumplan estos objetivos.
Sin embargo, la infraestructura suele compartirse con otras aplicaciones además de la nuestra, por lo que conocer su capacidad máxima ayuda a calcular cuánto quedará disponible cuando se despliegue nuestra aplicación.
En este caso, las pruebas de infraestructura buscan reducir el riesgo para nuestra propia aplicación y quizás para otras que en el futuro también se basarán en ella.
Suscríbete al boletín de The QA Lead para recibir notificaciones cuando se publiquen nuevas partes de la serie. Estas publicaciones son extractos del curso Leadership In Test de Paul, que recomendamos encarecidamente si quieres profundizar en este y otros temas. Si lo haces, usa nuestro cupón exclusivo QALEADOFFER y consigue $60 de descuento en el precio completo del curso.
Lectura sugerida: 10 MEJORES HERRAMIENTAS OPEN SOURCE PARA LA GESTIÓN DE PRUEBAS
