Ambientes de pruebas integrales de software: Buenas prácticas

El desarrollo de software hoy en día está caracterizado por múltiples equipos de proyectos y mantenimientos trabajando de forma simultánea, bajo cronogramas cada vez más exigentes y desarrollando sistemas que interoperan con variedad de otras aplicaciones y plataformas. Bajo un escenario como este, la gestión de los ambientes (entornos) de pruebas integrales (System Integration Tests, o SIT), adquiere gran importancia para asegurar que el Software sea puesto en producción con los niveles necesarios de calidad.

En este artículo se exploran una serie de buenas prácticas en la administración de ambientes de prueba integrales de sistema (SIT). Abarcan la definición de características del ambiente de pruebas SIT, restricciones que deben aplicarse sobre el ambiente, homologación con producción, procedimientos a implementar para una buena gestión de los ambientes y prácticas que deben tener en cuenta los equipos de pruebas de los diferentes proyectos.

Muchas de estas prácticas también aplican para los ambientes de desarrollo (Ver aquí).

A continuación las buenas prácticas para la administración de ambientes de pruebas SIT:

Más Información sobre Software Testing

> Visita nuestra página de Recursos en Pruebas de Software

Características que deben tener los ambientes

Debe residir en un computador distinto al personal del desarrollador. Preferiblemente en un servidor compartido por los equipos de pruebas de software.

Utilizar nombres de dominio (no direcciones IP) distintos a los de producción y desarrollo para evitar confusión del personal de pruebas.

Ser lo más similarmente posible al ambiente de producción, incluyendo:

Aplicaciones locales, cliente servidor, web, etc.
Configuración de servidores.
Manejadores de Bases de datos de producción, de las mismas versiones.
Configuración de base de datos.
Cuentas de usuario de sistema operativo, bases de datos y aplicaciones con la misma configuración y privilegios de acceso.
Componentes de infraestructura deben ser similares (Ej. Clusters).
Versiones de software.
Replicas de todos los componentes con los que el Software desarrollado tendrá interoperación, incluyendo: Otras aplicaciones, otros middleware, interfaces, demonios (Daemons), utilidades FTP, entre otros.

Si no es posible tener instalado el mismo manejador de base de datos que en producción y desarrollo, automatizar la propagación de cambios de un ambiente a otro (Existen herramientas de software que lo permiten).

Instalar las herramientas de gestión de casos de prueba y gestión de incidencias en una maquina o servidor distinto al del ambiente de pruebas integrales, compartido por los equipos de pruebas.

Capacidad de servir a múltiples audiencias, por ejemplo administradores de sistemas, usuarios finales, desarrolladores. En todos los casos sólo para ejecución de pruebas.

Debe apoyarse en herramientas de control de versiones, especialmente cuando existen múltiples proyectos en paralelo probando distintas funcionalidades.

Curso recomendado

¿Eres administrador de ambientes de desarrollo? o ¿te gustaría convertirte en arquitecto de soluciones de software?

Cada vez más las compañías están migrando su infraestructura de tecnología de información a la nube.

Invertir en una certificación como la de arquitecto de soluciones nivel asociado de Amazon Web Services (AWS) puede ser una buena inversión para tu desarrollo profesional y futura remuneración.

Restricciones a aplicar a los ambientes

No deben ser utilizados para actividades de desarrollo o producción.

Los desarrolladores no deben poseer privilegios de acceso de modificación de ningún tipo en ambiente de pruebas, esto para evitar cambios en la configuración no informados.

No posee herramientas de software o permisos de acceso especiales para ejecutar desarrollos de software, en su lugar, tiene una configuración similar o igual a la de producción.

Sólo el administrador se encarga de instalar, actualizar o desplegar para el ambiente de pruebas, nunca el desarrollador directamente.

Requiere de estrictos controles de cambio que mantengan rastro de las modificaciones en la configuración, para así asegurar resultados controlados y también que el ambiente sea similar a producción. Cualquier ciclo de pruebas que este en proceso puede quedar invalidado por cambios en la configuración (y por ende tener que repetirse).

Una versión se instala en producción sólo después que ha sido instalada y probada en ambiente de pruebas integrales.

Homologación con el ambiente de producción

Realizar comparaciones periódicas de la configuración de ambientes, existen herramientas automatizadas capaces de comparar configuraciones, aplicaciones y la infraestructura subyacente.

Reindexación de bases de datos cuando se realiza mantenimiento en las noches, para evitar que al día siguiente las pruebas tengan fallos por timeout.

Reconfiguración de archivos de configuración al movilizarlos entre ambientes (por ejemplo los Properties de un .JAR).

Mantener homologadas las configuraciones de direcciones IP y puertos de acceso para las aplicaciones.

La virtualización puede ayudar a evitar riesgos por cambios en configuración de un entorno a otro.

Siempre que ocurran cambios planificados o no planificados en el ambiente de producción, tales como correctivos de emergencia, cambios operacionales planificados, actualizaciones (upgrades), aplicación de patches, entre otros, es necesario homologar dichos cambios lo antes posible en el ambiente de pruebas integrales, evaluando el impacto sobre ciclos de pruebas en proceso.

Procedimientos a implementar para una buena gestión de ambientes de pruebas integrales

Todas las fase de pruebas funcionales, incluyendo: Unitarias, integración, aceptación, desempeño (estrés), pruebas no funcionales, requieren de ambientes de pruebas, por lo que deben definirse procedimientos específicos de gestión de ambientes en cada etapa de los proyectos.

Encargar la labor de planeación y operación a un Gerente de Operaciones o de Cambios, preferiblemente distinto al del ambiente de desarrollo y producción.

Establecer procedimientos de solicitud de requisitos de ambiente de pruebas por parte de todos los equipos que tengan que utilizar el ambiente. Deben especificarse los requisitos de configuración y las herramientas e infraestructura requeridos.

Los requerimientos de ambientes sean incluidos en la documentación de requerimientos de todos los mantenimientos o proyectos.

Planificar el uso y disponibilidad de los ambientes de pruebas integrales e informar a los equipos de prueba para que incluyan dichas restricciones en la planificación de los requerimientos y proyectos.

Procedimientos de Gestión de la creación, build, actualización (upgrade) y soporte de ambientes.

Definir procesos auditables para:

Asignación de ambientes.
Uso compartido.
Accesos múltiples.
Acuerdos de nivel de servicio.
Actualizaciones.
Upgrades.
Instalaciones.
Desincorporación.
Preparación de datos de prueba.

Procedimientos de modificación de datos sensibles para que sean anónimos.

Procedimientos de preparación, conectividad y asistencia a los equipos de pruebas de todas las fases.

Planificar actividades de mantenimiento y actualizaciones mayores de todos los ambientes.

Emitir reportes de uso y carga que asistan a la planeación.

Contar con herramientas para debugging.

Procedimientos de uso de los ambientes por los equipos de pruebas

Definir las especificaciones de ambientes de prueba que necesita el equipo.

Antes de iniciar cualquier ciclo de pruebas, deben ejecutarse actividades para verificar que el ambiente ha sido configurado adecuadamente.

No todas las pruebas se ejecutan en el ambiente de pruebas integrales de software, por ejemplo, pruebas de componente de software, en las que se revisa el código se realizan en el ambiente de desarrollo.

Si durante la ejecución de las pruebas integrales se realizan cambios de configuración, será necesario identificar las pruebas afectadas y ejecutar nuevamente dichos casos de prueba.

Para proyectos de mantenimiento o migración de plataformas tecnológicas (por ejemplo un upgrade de base de datos), es necesario incluir pruebas operacionales, para lo cual es necesario configurar y probar un ambiente de pruebas similar al de producción.

Ajustes al cronograma de pruebas dada la disponibilidad o no disponibilidad de ambientes de pruebas.

Los reportes de incidencias deben hacer referencia al ambiente en el que se está probando y cualquier aspecto especifico de configuración.

Toda la información relacionada con los requisitos de Hardware y Software del ambiente de pruebas deberá ser documentada en el Plan de pruebas de Software Testing.

¿Interesado en un método para levantar la información y elaborar el plan de pruebas de software?, sígue el enlace: Pruebas de software: 10 pasos para elaborar el plan de pruebas.

¿Y qué opinas tu?

¿Cuáles buenas prácticas para gestión de ambientes de pruebas de software has utilizado?, ¿Cuál ha sido tu experiencia?, ¿Que buenas prácticas o recomendaciones realizarías?. Te invitamos a dejarnos comentarios en la Web de La Oficina de Proyectos de Informática (pmoinformatica) (puedes firmar tu comentario con la dirección de tu web si así lo deseas).

¿Te ha gustado este artículo?, entonces suscríbete a nuestra lista de correos?

También puedes seguirnos vía Twitter, Facebook o Linkedin:

Otros artículos relacionados:

> 10 Ventajas de la automatización de pruebas de servicios web

> Pruebas de caja negra: Ejemplos

> Alojamiento web: Definición, ventajas y desventajas

> Ambientes de desarrollo de software: Buenas prácticas

> Prácticas de desarrollo de aplicaciones web y SOA

> Acciones para evitar retraso y retrabajo en proyectos TI

> Diseño y desarrollo de software en proyectos Fastrack: Como minimizar los riesgos

> ITIL y el desarrollo de Software

Referencias externas

> ISTQB. Foundation Level Syllabus 2011