Ambientes del ciclo de vida del software

En cada proyecto de software, independientemente del ciclo de vida utilizado, será necesario analizar cuál será la mejor configuración de ambientes a fin de alcanzar los objetivos de calidad establecidos. Es fundamental poder realizar una correcta gestión de los ambientes para que las pruebas se ejecuten en un contexto adecuado, asegurando así que los resultados sean predecibles, representativos y se puedan validar. A continuación, presentamos una recomendación de los ambientes a considerar incorporar dentro de un proyecto de desarrollo de software, tomando en cuenta principalmente el objetivo de cada uno de ellos más allá de los nombres, que pueden variar según las características de cada proyecto. Recomendamos entonces, tener en cuenta la creación de los siguientes ambientes:

• Desarrollo: Es el ambiente más inestable, el que utilizan los desarrolladores para pruebas diarias en relación al desarrollo que estén realizando en ese momento. Es local a cada desarrollador, a no ser que se requieran integraciones complejas con determinados componentes. En muchas ocasiones puede ser la máquina de cada desarrollador. 
• Integración: En este ambiente se combinan (se realizan los "merge") de los componentes implementados por los desarrolladores de forma local. En este ambiente es deseable que se ejecuten las pruebas de regresión y chequeos automatizados tanto a nivel funcional,  como de seguridad, de accesibilidad, de performance, etc. Es en este ambiente donde los desarrolladores prueban en forma integrada su trabajo, analizando los resultados de las actividades automáticas como insumo principal para el cumplimiento de los objetivos de calidad y evolución del producto. Este ambiente puede opcionalmente generar un build periódicamente (por ejemplo todas las noches) con los cambios generados por los desarrolladores durante el día.
• Testing/Pruebas: Ambiente desde el cual se promueven los cambios de manera controlada, sólo si pasaron los chequeos y pruebas en el ambiente anterior. En este ambiente se realizan las pruebas funcionales no automatizadas y exploratorias. El equipo de desarrollo promueve el incremento a este ambiente con el propósito de que el equipo de Testing, QA o un tercero lleve adelante las pruebas necesarias. Incluso puede ser el propio equipo de desarrollo quien sea el encargado de realizar pruebas en este ambiente, ya que resulta menos inestable (cambia con menos frecuencia) que los ambientes anteriores o puede tener datos, contexto o herramientas específicas para realizar cierto tipo de pruebas. 
• Staging/UAT/Pre-producción: En este ambiente se llevan adelante las pruebas de aceptación de usuario de la versión. Se lo conoce también como UAT (User Acceptance Testing) o Pre-producción. Por lo general tiene datos que fueron obtenidos de los ambientes de producción, con el objetivo de probar la versión en condiciones lo más similares posibles al entorno productivo en el que ejecutará el software. Muchas veces se utiliza este ambiente para las pruebas de performance de aceptación (simulando una carga esperada), en el caso que no se haya definido un ambiente separado para este fin.
• Integración con sistemas externos/Pre-producción: Este ambiente tiene por objetivo servir como ambiente de pruebas a los organismos, por lo cual debe estar conectados con todos los servicios externos que la aplicación requiera para ejecutarse adecuadamente. Al mismo tiempo, es un ambiente que permite un acercamiento distinto en lo que respecta a las pruebas, ya que el mismo puede permitir carga real de usuarios de forma restringida (por ejemplo, beta-testers).
• Producción: Ambiente donde se disponibiliza el sistema a los usuarios. Este ambiente es controlado y restringido. No se suele utilizar para pruebas a menos que esté claramente controlado y focalizado el impacto que puedan ocasionar.

Es altamente recomendable que las pruebas de aceptación se lleven adelante en un ambiente controlado y separado del resto. Es allí donde el ambiente de UAT marca una diferencia importante en los controles de calidad profesionales, y es fundamental su adecuada gestión. En ciertas ocasiones se puede, con criterio y fundamentación, reducir la cantidad de ambientes, de acuerdo al riesgo del proyecto o a los recursos de hardware y software con los que se cuenta, entre otros.

Actividades por Ambiente

En la siguiente tabla que se muestra una recomendación de los tipos de pruebas a ejecutar en cada uno de los ambientes según los objetivos descritos previamente para cada uno de ellos en esta guía:

Es conveniente agregar herramientas que realicen análisis de código estático a los ambientes de desarrollo local y de integración. Algunas opciones pueden ser SonarQube o CodeClimate.

En la siguiente tabla que se muestran las actividades del proceso de integración que generalmente se ejecutan en cada uno de los ambientes:

(*) Ambientes manejados por el equipo de desarrollo

(**) Ambientes manejados por el organismo