Sin categoría
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.
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.
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.
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.
