Blog

Diferentes ambientes, diferentes proyectos, diferentes cronogramas, diferentes recursos (aunque muchos de ellos se compartan), diferentes aplicaciones, interfaces y plataformas, diferentes equipos de proyectos son los actores de diferentes escenarios que debemos gestionar.

Gestionar nuestro testing en los diferentes ambientes (llamados también entornos) para realizar por ejemplo, las pruebas integrales es uno de nuestros desafíos, más que nada por la interrelación en la que debemos convivir.

Como en todo, tenemos buenas prácticas que nos pueden servir de guía para llevar a cabo dicha gestión, algunas de ellas:
-definición y manejo de las características de ambientes
-definición y manejo de las restricciones de los distintos ambientes
-definición y manejo de las reglas y procedimientos para realizar la homologación de productos
-procedimientos para implementar la gestión de ambientes
-prácticas que deben considerar los equipos de proyecto

De más esta decir que como convivimos en muchos casos, en extrecha relación con el área de desarrollo, muchas de estas prácticas también se aplican para ambientes de desarrollo.

Obviamente, dependemos mucho del área de desarrollo y de la gestión que ellos también hagan en sus ambientes, ya que por lo general «probamos donde también ellos desarrollan», aunque no es la mejor práctica, es la realidad en muchos proyectos.

También están las otras prácticas donde se preparan ambientes exclusivamente para hacer QA y en donde también prueban los desarrolladores, sus distintas construcciones sobre la cuales durante y/o después estaremos actuando nosotros.

Características de todo ambiente

1. debe localizarse en un servidor ó computador que actúe como servidor, distinto en el que trabajen los programadores y probadores
2. debe tener un nombre de dominio, nó una dirección IP, distinto al de producción y desarrollo para evitar cualquier confusión
3. debe ser lo más parecido al ambiente de producción (por lo menos eso se pretende en muchos de los casos),
3.1. aplicaciones locales, aplicaciones cliente servidor, aplicaciones web, otros
3.2. configuración de servidores
3.3. gestores de base de datos
3.4. configuración de base de datos
3.5. cuentas de usuario con sus respectivos privilegios para acceder a las bases de datos y aplicaciones
3.6. componentes de infraestructura
3.7. versiones de los distintos software
3.8. componentes para que el software se comporte tal cual como lo hará en producción (middleware, interface, demonios, ftp, servicios, tareas programadas, webservices, otros)
4. debe haber un procedimiento definido para manejar los cambios que deban desplegarse en ambiente de desarrollo, de prueba y producción, considerando que hay herramientas que permiten automatizar estos despliegues (deploy).
5. instalar y configurar las herramientas que permitan gestionar el testing integral en los entornos que correspondan, considerando que habrá algunas que deban implantarse en un servidor o computador que actúe como servidor distinto en el que se encuentren los programadores y probadores, mientras que otras se deberán implantar en determinados entornos para una mejor gestión.
6. debe poder atender a todo tipo los que integren los distintos equipos de proyectos (administradores, desarrolladores, probadores, y hasta usuarios finales).
7. debe contener software que permita la gestión de las distintas versiones que existan en los distintos proyectos.

Restricciones por gestionar

1. los desarrolladores no deberán tener privilegios para modificar ambiente de pruebas, de tenerlos deberán estar bien definidos, controlados y documentados.
2. no deberá haber herramientas o procedimientos para ejecutar desarrollos de software, de haberlos deberán estar bien definidos, controlados y documentados.
3. deberá haber un administrador que se encargue de instalar, configurar, actualizar y desplegar los distintos cambios y/o novedades en el o los ambiente/s de prueba, y que sean similares a los de producción, razón por lo cual la configuración aquí será de suma importancia.
4. deberá ser celosamente controlado para evitar cualquier error de configuración y que luego se traslade al ambiente de producción.

Homologación con ambiente productivo

1. comparar períodicamente configuraciones, aplicaciones e infraestructuras.
2. gestionar la reindexación de bases de datos vinculados con los distintos mantenimientos.
3. reconfigurar los archivos de configuración cuando se los utiliza en los distintos ambientes como procedimientos de trabajo.
4. mantener homologadas las configuraciones de las direcciones IP y/o nombres de dominio.
5. gestionar el ejercicio de esquemas de virtualización en relación con los cambios en las configuraciones.
6. homologar los cambios no previstos que pudieran ocurrir lo antes posible en el/los ambiente/s de prueba para que estén alineados con el/los de producción y evitar impactos durante los ciclos de prueba que se estén ejecutando o que se hayan planificado.

Procedimientos para implementar buenas prácticas

1. adecuar el ambiente para todas las fases vinculadas con las pruebas que se realicen, sean estas pruebas funcionales y no funcionales. Aquí cabe definir la implantación de diferentes herramientas y/o técnicas y/o procedimientos, con lo cual la gestión de la configuración es muy importante.
2. definir quién se ocupará de la planificación y estrategia de las pruebas en el/los ambiente/s.
3. definir procedimientos para solicitar requisitos de ambientes para los distintos equipos que utilicen el ambiente.
4. definir la forma de documentar todos los requerimientos de ambiente.
5. definir el uso y la disponibilidad del/los ambiente/s para los distintos equipos de pruebas, ya que muchos de ellos utilizarán diferentes herramientas y/o técnicas, con diferetnes configuraciones.
6. definir los procedimientos para la gestión de la creación, builds, actualizaciones, y soporte del/los ambiente/s.
7. definir procedimientos para la auditoria correspondiente respecto a los siguientes puntso:
7.1. disponibilidad y acceso a ambientes.
7.2. uso compartido de los recursos que se disponen en el/los ambiente/s.
7.3. disponibilidad para los accesos múltiples.
7.4. considerar SLA (Acuerdos de Niveles de Servicio)
7.5. actualizaciones de los distintos software
7.6. gestión de los datos para las pruebas
8. definir procedimientos para la modificación de datos sensiles del negocio como para que sean anónimos y no atente con la seguridad y reglas correspondientes.
9. definir procedimientos transversales que impacten en todos los ambientes implantados.
10. definir procedimientos para la emisión de reportes de uso y carga que se den en los ambientes
11. definir las herramientas que se utilizarán para el debug y diferentes tipos de testing.
12. definir las posibilidades de acceder en forma remota (p.e. por VPN)

Procedimientos de uso de los ambientes para los equipos de prueba

1. definir los requerimientos de ambiente
2. definir la configuración inicial del ambiente previo a la ejecución
3. distinguir qué pruebas se realizarán en los distintos ambientes
4. tener trazabilidad sobre los cambios de configuración y de que forma afectan las diferentes pruebas
5. definir la configuración y procedimientos para proyectos de mantenimiento o migración de plataformas
6. ajustar cronogramas de acuerdo con la disponibilidad o no disponibilidad de ambiente
7. definir procedimientos para emitir reportes de incidencias sobre el ambiente que se esté probando.

Tener en cuenta que en todo proyecto entonces, tendremos que convivir básicamente en dos entornos:
-entorno de desarrollo
con herramientas que cubran las distintas fases que componen la construcción del software
con herramientas que permitan integrar todas estas actividades
-entorno de testing
y aquí …
qué conjunto de herramientas deberemos usar?
qué herramientas que nos sirvan para la integración?

Debemos tener un conjunto de herramientas, sí o sí.
y por otra parte, con diversos niveles de integración entre sí y con el ambiente de desarrollo.

además, deberemos administrar los siguientes aspectos:
-la relación con todos los requerimientos (de testing, de software, de ambientes)
-la documentación
-la cobertura de los casos de prueba
-la independencia con las herramientas de desarrollo
-las ejecuciones y sus resultados
-los ajustes de los procesos/proyectos

sin olvidarnos, de la respectiva gestión de la configuración en cuanto a la versión (a nivel de Build) del código y de los scripts del S/O y BD (scripts, store procedures).

Algunas cuestiones básicas que podrán servirte

¿Qué es y cómo preparar una Estrategia de Prueba?
¿Qué es y cómo preparar un Plan de Prueba?
¿Cuánto nos ayuda contar con una herramienta para gestionar estas actividades?

Algunos lo piensan antes, otros durante, mientras que otros lo hacen después de…pensar y preparar una estrategia y plan de pruebas. La cosa es que contar con una herramienta para la gestión integral del testing, controlando la calidad en forma colaborativa y basada en una solución web, facilita toda planificación, verificación manual e integración con herramientas que permitan efectuar pruebas automatizadas.

Este planteo lo hago porque tendrá que ver con el entorno de prueba que debamos preparar.

Lo básico que debemos todos tener presente es que planificar una prueba es llevar a la práctica la estrategia pensada, o sea, implementarla durante un período de tiempo que puede ser una iteración, un sprint o bien, un project. Es decir que la estrategia esta antes de la planificación?

Templates

El siguiente template [ planilla excel ] puede servirte para estimar el esfuerzo cubriendo las siguientes áreas:

• Project Management
• Environment Management
• Architecture Design
• Platforms teams – Unix, AIX, …
• Database Team
• Testing Services

Este otro template [ planilla excel ], te permitirá cubrir los siguientes aspectos para que puedas hacer una correcta gestión

• Environment Name
• Host Server Name
• Server IP Adress/Port No
• Database Names
• Applications/Middleware/Interfaces
• Login/Password
• Test Data Set Provided
• Support Teams/Person

y para complementar toda esta gestión documental, en este mismo sitio [ testenvironmentsmanagement ] podrás encontrar un template vinculado con el Proceso de Administración de Ambientes, cuyo contenido es el siguiente:

1.Purpose
2.Scope
3.Related Documents
4.Tools to be used
5.Inputs to process
6.Outputs from process
7.Process defined in both diagrammatic and textual form
7.1. Process Diagram for all Environment Requests
7.2. Process Description
8.Responsibilities
9.Measurements to be taken
10.Training
11.Feedback
12.Appendix

Conclusiones: Sin lugar a dudas, estaré trabajando en la parte II donde analizaré el template relacionado con el Proceso.

Fuentes de inspiración (Parte I):
http://www.pmoinformatica.com/

http://www.360logica.com/
http://www.testenvironmentsmanagement.com/index.php