Mejora la calidad del software y ahorra tiempo con las pruebas de infraestructura
Nota del editor: Te damos la bienvenida a la serie Liderazgo en pruebas del gurú y consultor de pruebas de software Paul Gerrard. La serie está diseñada para ayudar a los probadores con algunos años de experiencia, especialmente a quienes forman parte de equipos ágiles, a sobresalir en sus funciones de liderazgo y gestión de pruebas.
En un artículo anterior, te expliqué cómo gestionar las pruebas de rendimiento. Ahora hablaremos del software de infraestructura de TI, la infraestructura de pruebas y los entornos de prueba.
Suscríbete al boletín de The QA Lead para recibir una notificación cuando se publiquen nuevas partes de la serie. Estas publicaciones son extractos del curso Leadership In Test de Paul, que recomendamos encarecidamente para profundizar en este y otros temas. Si lo haces, 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 utilizamos para describir todo el hardware, los servicios en la nube, las redes, el software de soporte y nuestra aplicación bajo prueba necesarios para desarrollar, probar, implementar y operar nuestros sistemas.
Aun así, tiene sentido no limitar nuestra definición a la tecnología. Los centros de datos, los espacios de oficina, los escritorios, los equipos de sobremesa, los portátiles, las tabletas y los teléfonos móviles con sus propias pilas de software instaladas forman parte del ecosistema necesario para desarrollar, probar e implementar sistemas.
Si incluimos las herramientas de desarrollo, las herramientas y los procedimientos de DevOps, las herramientas de prueba y los procesos empresariales y conocimientos especializados necesarios, el alcance es aún mayor.
¿Quieres más de The CTO Club?
Crea una cuenta gratuita para terminar de leer este contenido y unirte a una comunidad de CTOs y líderes de ingeniería que comparten marcos, herramientas y conocimientos reales para diseñar, desplegar y escalar tecnología impulsada por IA.
Have an account? Log In
Incluso los aspectos más mundanos, como los códigos de acceso o las tarjetas inteligentes utilizadas para acceder a los edificios, pueden convertirse en elementos críticos si no están disponibles.
La infraestructura, en toda su variedad, existe para respaldar el desarrollo, las pruebas, la implementación y las operaciones de tus sistemas. Es fundamental para las pruebas o necesita ser probada.
En el próximo artículo analizaremos las herramientas para el desarrollo, las pruebas y la colaboración. En este artículo, consideraremos lo que la mayoría de las personas considera entornos de prueba y veremos brevemente lo que suele denominarse pruebas de infraestructura. Trataré los siguientes temas:
- Entornos de prueba
- Entornos de desarrollo
- Entornos de prueba a nivel de sistema
- Entornos de datos
- Pruebas de infraestructura
Comencemos.
Entornos de prueba
Todas las pruebas parten de una suposición implícita, fundamental y simplificadora: que nuestras pruebas se ejecutarán en un entorno conocido.
¿Qué es un entorno?
Todos los sistemas deben probarse en un contexto. Para que una prueba sea significativa, el sistema debe instalarse, configurarse, implementarse o construirse en un entorno realista que simule el mundo real en el que se utilizará.
Podemos 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 estas son propiedades de las pruebas, no del entorno.
Un entorno realista reproduciría todos los entornos empresariales, técnicos y organizativos. Gran parte de este entorno está compuesto por datos utilizados para impulsar los procesos empresariales, configurar el sistema y proporcionar datos de referencia.
Sin embargo, los entornos perfectamente realistas suelen ser poco prácticos o demasiado costosos (incluso los probadores de sistemas de alta criticidad, como aviones, reactores nucleares o escáneres cerebrales, tienen que hacer concesiones en algún momento). Casi todas las pruebas se llevan a cabo en entornos que simulan el mundo real con algún nivel aceptable de compromiso.
Los automóviles se prueban en bancos de rodillos, túneles de viento, plataformas de vibración y pistas de pruebas privadas antes de probarse en la vía pública. Los sistemas informáticos se prueban en laboratorios de software por programadores y probadores de software antes de que se invite a los usuarios finales a probarlos en un entorno similar al de producción.
Para garantizar que tus entornos de prueba cumplan con los estándares del sector, considera integrar una de estas plataformas de gestión de pruebas mejor valoradas.
Pruebas en entornos realistas
Los entornos simulados son falibles, al igual que nuestros requisitos y modelos de prueba, pero debemos aceptar esa realidad.
Debemos planificar pruebas significativas en los entornos que tenemos disponibles, y los resultados de las pruebas significan aquello 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.
Por supuesto, ambas situaciones son altamente indeseables.
Configuración y entrega oportuna de los entornos
Incluso con la aparición de la 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 evaluadores solicitan entornos de prueba (y quizá varios). Más adelante, durante las pruebas, los equipos de soporte suelen tener demandas contrapuestas.
Los entornos de desarrollo o cualquier actividad de prueba posterior pueden entregarse tarde o no entregarse en absoluto, o quizá no estén configurados ni controlados según lo requerido. Inevitablemente, esto retrasará las pruebas o socavará la confianza en cualquier resultado de estas.
Una tarea crítica es establecer la necesidad y los requisitos de un entorno que se utilizará para las pruebas, incluido un mecanismo para gestionar los cambios en dicho entorno, lo antes posible.
La infraestructura como código es una evolución reciente en la forma de construir entornos, mediante herramientas que siguen procedimientos y utilizan código declarativo para definir la configuración del entorno.
Aunque las plataformas de sistemas operativos base (servidores) pueden crearse fácilmente en la nube o como máquinas virtuales en su propio entorno, los servidores especializados completamente especificados, con todo el software, los datos, las configuraciones y las interfaces necesarios, requieren más esfuerzo.
Al configurar su infraestructura de pruebas, es fundamental integrar software fiable de gestión de bases de datos para obtener un rendimiento óptimo
Sin embargo, una vez configurados, proporcionan un medio altamente eficiente para crear entornos. El código de la infraestructura puede controlarse en cuanto a su origen, al igual que cualquier código de aplicación, y gestionarse mediante cambios.
Un principio fundamental de la entrega continua es que, lo antes posible, algún software —aunque no sea útil— debe pasar por el flujo de entrega para demostrar que los procesos funcionan.
Por supuesto, esto requiere entornos viables para compilaciones, herramientas de integración continua, pruebas a nivel de sistema y despliegues. El objetivo es desplegar entornos de prueba y de producción sin restricciones. Una vez definidas las especificaciones de los entornos y establecidos los procesos de despliegue, generar entornos se convierte en una tarea automatizada y rutinaria.
En cualquier circunstancia, las especificaciones de estos entornos son uno de los primeros entregables del proyecto.
Entornos de desarrollo
Las pruebas realizadas por 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 de presentación.
Las pruebas suelen estar guiadas por el conocimiento de la estructura interna del código, y es posible que no utilicen ni requieran datos «realistas» para ejecutarse. Las pruebas de componentes o servicios de bajo nivel suelen ejecutarse mediante una API utilizando controladores o herramientas personalizados o propietarios.
La variedad de herramientas de desarrollo, plataformas y los llamados entornos de desarrollo integrados (IDE) es enorme. En este artículo, solo podemos abordar algunos de los principales requisitos y características de los entornos relacionados con las pruebas.
Para respaldar el desarrollo y las pruebas contempladas para los desarrolladores, los entornos deben admitir las siguientes actividades. Esta es solo una selección; en su situación puede haber actividades adicionales o variaciones de estas:
- Un entorno aislado para experimentar con software nuevo. Los entornos aislados se utilizan a menudo para probar bibliotecas nuevas, desarrollar código de prototipos desechables o practicar técnicas de programación. Todos los lenguajes de programación habituales cuentan con cientos o miles de bibliotecas de software. Los entornos aislados se utilizan para instalar y probar software que aún no forma parte del flujo principal de desarrollo, con el fin de evaluarlo y practicar su uso. Estos entornos pueden tratarse como entornos desechables.
- Entorno de desarrollo local. Aquí los desarrolladores mantienen una copia local de una parte o de todo el código fuente de su aplicación, obtenida de un repositorio de código compartido, y pueden crear compilaciones del sistema para realizar pruebas locales. Este entorno permite a los desarrolladores realizar cambios en el código de su copia local y probarlos. Algunas pruebas son improvisadas y quizá nunca se repitan. Otras pruebas están automatizadas. Las pruebas automatizadas suelen conservarse indefinidamente, especialmente si siguen un enfoque basado en pruebas.
- Entorno de integración (continua) compartido. Cuando los desarrolladores confían en que su código está listo, envían sus cambios al repositorio de código compartido y controlado. El entorno de CI realiza compilaciones automatizadas y ejecuta pruebas automatizadas utilizando 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 todo el equipo recibe notificaciones y puede consultar el estado de las pruebas de la compilación integrada más reciente. Los fallos se detectan rápidamente y se resuelven con carácter urgente.
Un entorno de desarrollo o de CI permite realizar pruebas para desarrolladores, pero es posible que otros servidores de aplicaciones, servicios web, sistemas de mensajería o servidores de bases de datos que completan el sistema no estén disponibles.
Si estos sistemas de interfaz no existen porque aún no se han creado, o porque pertenecen a una empresa asociada y solo existe un sistema en producción sin una versión de prueba, los desarrolladores tienen que crear simulaciones o sustitutos para estas interfaces con el fin de poder probar al menos su propio código.
Las herramientas de simulación pueden ser sofisticadas, pero las interfaces simuladas normalmente no pueden admitir pruebas que requieran datos integrados entre varios sistemas.
Si los desarrolladores tienen acceso a una interfaz para un servidor de bases de datos de prueba, sus datos de prueba podrían ser mínimos, no estar integrados o ser incoherentes, y no representar los datos de producción.
Las bases de datos de desarrollo compartidas por un equipo suelen ser insatisfactorias. Si no existe un buen régimen para gestionar este recurso compartido, los desarrolladores podrían reutilizar, dañar o eliminar los datos de los demás.
Entornos de pruebas a nivel de sistema
Las pruebas a nivel de sistema se centran en la integración colaborativa de componentes y subsistemas.
Estos entornos proporcionan una plataforma para respaldar los objetivos de la integración a mayor escala, la validación de la funcionalidad y las operaciones del sistema en el contexto de los procesos de los usuarios o de la empresa.
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 problemas más comunes en las pruebas ocurre cuando un probador del sistema experimenta algún tipo de fallo en su entorno, pero, por mucho que lo intenten, el desarrollador o el probador no pueden reproducirlo en el entorno de desarrollo.
«¡Funciona en mi máquina!»
«Sí, por supuesto que funciona.»
Esto casi con toda seguridad se debe a una falta de coherencia entre los dos entornos. La diferencia de comportamiento puede deberse a la configuración, a algunas diferencias entre las versiones del software o a la diferencia en los datos de la base de datos.
Lo primero que se debe comprobar son las diferencias en los datos que causan problemas. Normalmente son fáciles de identificar y a menudo se pueden resolver rápidamente.
Cuando existe una discrepancia en la versión del software o en la configuración, los probadores y desarrolladores pueden perder mucho tiempo rastreando la causa de la diferencia de comportamiento.
Cuando surgen estos problemas, a menudo significa que existe un fallo de comunicación entre el desarrollador y el entorno de pruebas. También podría indicar una pérdida de control de la configuración en la preparación del entorno de desarrollo o de pruebas, o en el proceso de implementación.
La infraestructura como código y el aprovisionamiento automatizado de entornos harán que los problemas de coherencia entre entornos sean cosa del pasado.
Tipos de entornos de pruebas dedicados
Para admitir las pruebas del sistema, de aceptación y no funcionales, los entornos deben admitir las siguientes actividades (puede haber más en su organización):
- Entorno de pruebas del sistema (funcional). En este entorno, el sistema se valida conforme a los requisitos documentados para el sistema en su conjunto. Los requisitos pueden ser documentos extensos con casos de prueba tabulados definidos para una prueba del sistema. En los proyectos ágiles, este entorno puede ser necesario para permitir que los evaluadores exploren el sistema integrado sin limitarse a funcionalidades específicas.
- Entorno de pruebas de extremo a extremo. Mientras que el entorno de integración continua permite integrar componentes con subsistemas, los procesos empresariales pueden requerir que estén disponibles otros sistemas de interfaz (que no están bajo el control de los desarrolladores). Se necesitan entornos de alcance completo para llevar a cabo pruebas de integración a gran escala, de procesos empresariales o de aceptación general. Por lo general, los datos son una copia de los datos reales o, al menos, tienen una escala adecuada. Cuando es necesario demostrar una integración a gran escala, los flujos de datos y de control se prueban mediante recorridos de usuario más largos y conciliaciones independientes de los datos entre los sistemas integrados. La gestión de datos en entornos de prueba es fundamental. Si ya utilizas 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 representativa para evaluar el rendimiento de un sistema (o de determinados subsistemas). Puede ser posible hacer concesiones en la arquitectura cuando existe redundancia o clonación de servidores. Sin embargo, los volúmenes de datos deben tener una escala equivalente a la de producción, aunque los datos sean sintéticos. Sin duda, el entorno debe tener una escala suficiente para admitir los volúmenes de transacciones de producción y permitir una predicción útil del 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, las variaciones pueden ser inevitables. Las pruebas de disponibilidad tienen como objetivo verificar que el sistema puede funcionar durante períodos prolongados sin fallar. Las pruebas de resiliencia (a menudo denominadas pruebas de conmutación por error) comprueban que, cuando fallan componentes del sistema, no provoquen una interrupción inaceptable del servicio prestado. Las pruebas de gestionabilidad u operaciones tienen como objetivo demostrar que los procedimientos administrativos, de gestión y de copia de seguridad y recuperación del sistema funcionan de manera eficaz.
Datos en los entornos
En algunos proyectos muy grandes, puede haber hasta 20 o incluso 30 entornos de gran escala dedicados a distintos aspectos de las pruebas, la formación, la migración de datos y las transiciones de prueba. En los proyectos más pequeños habrá menos, quizá 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 único uso y después se desmantelan.
Todos los entornos necesitan datos, pero la escala y el grado de realismo de esos datos pueden variar. Estos son algunos patrones habituales en la forma de adquirir y gestionar los datos de prueba. Estos patrones se centran en la propiedad (local o compartida), el medio de creación (manual, automatizado o copiado de producción) y la escala:
- Datos locales, creados manualmente y de pequeña escala, adecuados para pruebas ad hoc por parte de desarrolladores o evaluadores.
- Datos locales, automatizados y sintéticos. Adecuados para pruebas automatizadas de desarrolladores o para entornos en los que se puede cubrir la funcionalidad de módulos o características específicas.
- Datos compartidos creados manualmente. Se utilizan en entornos de pruebas de integración y del sistema, a menudo cuando los datos de prueba han evolucionado en paralelo con las pruebas ejecutadas manualmente. Se realizan copias de seguridad y se restauran cuando es necesario.
- Datos compartidos creados automáticamente. Se utilizan en entornos de pruebas de integración y del sistema cuando los datos de prueba han evolucionado en paralelo con pruebas automatizadas o ejecutadas manualmente. Se generan o restauran a partir de copias de seguridad cuando es necesario.
- Datos sintéticos o aleatorios compartidos de gran escala. Las pruebas de rendimiento y ARM requieren datos coherentes en grandes volúmenes. Por lo general, estos datos no necesitan ser significativos; los datos aleatorizados funcionan correctamente y se generan cuando es necesario, o se generan inicialmente y se restauran a partir de copias de seguridad.
- Datos significativos compartidos de gran escala. Las pruebas de extremo a extremo, de aceptación o de usuario suelen necesitar datos significativos a escala. En ocasiones se utilizan copias o extractos de datos reales. Sin embargo, si no los ofuscas o anonimizas, ten cuidado de no incumplir la normativa sobre datos.
- Repetición de pruebas y pruebas de regresión. Necesitarás un conjunto de datos conocido y controlado, en un estado conocido, por lo que normalmente se restaura a partir de copias de seguridad. Esto se aplica a cualquiera de los entornos anteriores, ya que estas pruebas deben volver a ejecutarse con los datos en un estado conocido para reproducir los fallos de forma fiable.
Pruebas de infraestructura
Al principio de este artículo, analizamos qué incluye la infraestructura y, desde entonces, nos hemos centrado principalmente en los componentes técnicos, concretamente en los sistemas de software, y hemos dado por supuesto que el hardware, real o virtual, está disponible.
Cuando construimos sistemas inicialmente, suponemos que la infraestructura existe y que funciona correctamente, ofrece un buen rendimiento, es segura y resiliente, etc.
Podemos probar todos estos aspectos cuando hayamos integrado nuestra aplicación y, sin duda, poner de manifiesto deficiencias en la infraestructura en una etapa relativamente avanzada de nuestros proyectos. Pero encontrar problemas de infraestructura tan tarde en un proyecto suele ser extremadamente disruptivo.
- Los cambios para solucionar fallos en la infraestructura podrían requerir un rediseño significativo y cambios en nuestra aplicación.
- Será necesario repetir los resultados de las pruebas de nuestra aplicación o de todo el sistema.
- Si fallan componentes de terceros, como servicios de bases de datos, web, redes o mensajería, quedamos a merced de los proveedores (o de la comunidad de código abierto) que les dan soporte.
Para asegurarnos de que nuestra confianza en los componentes de infraestructura está bien fundamentada, podemos basarnos en nuestra experiencia (o en la de otros) al utilizarlos en el pasado. O bien debemos evaluar —mediante pruebas— su fiabilidad antes de comprometernos a utilizarlos en el diseño y la construcción de nuestro sistema.
Dependiendo de la infraestructura que se esté investigando, el entorno que utilicemos puede variar, desde un único servidor hasta una plataforma de infraestructura casi completa.
Aunque algunas pruebas serán manuales, en su mayoría utilizaremos herramientas, controladores o robots para simular la carga de transacciones que generaría nuestra aplicación. Tendríamos que simular o sustituir estas interfaces:
- Interfaces que actualmente no están disponibles
- Interfaces de componentes en los que confiamos y que son fáciles de simular
- Interfaces fuera del alcance que no afectan a la infraestructura sometida a prueba.
La infraestructura, como es lógico, normalmente no funciona mediante una interfaz de usuario o una interfaz gráfica de usuario.
La integración de nuestra aplicación con la infraestructura adoptará principalmente la forma de mensajería o llamadas a servicios remotos. A menudo, el tráfico que se debe simular requiere llamadas a API a servidores web o de aplicaciones, servidores de mensajes o de bases de datos, o servicios proporcionados a través de la nube o de ubicaciones remotas.
Es posible que se conozcan los objetivos de rendimiento y ARM, en cuyo caso pueden realizarse pruebas para garantizar que se cumplan.
Sin embargo, la infraestructura suele compartirse con aplicaciones distintas de la nuestra, por lo que conocer su capacidad máxima ayuda a evaluar cuánta capacidad quedará disponible cuando se implemente nuestra aplicación.
En este caso, las pruebas de infraestructura abordan el riesgo para nuestras propias aplicaciones y, posiblemente, para otras aplicaciones que se basen en ella en el futuro.
Suscríbete al boletín de The QA Lead para recibir una notificación cuando se publiquen nuevas partes de la serie. Estas publicaciones son extractos del curso de liderazgo en pruebas de Paul, que recomendamos encarecidamente para profundizar en este y otros temas. Si lo haces, utiliza nuestro código de cupón exclusivo QALEADOFFER para obtener un descuento de 60 $ sobre el precio total del curso.
Lectura recomendada: 10 MEJORES HERRAMIENTAS DE CÓDIGO ABIERTO PARA LA GESTIÓN DE PRUEBAS
