Blog

¿No me van a decir que no han tirado una prueba en ambiente de Producción porque no les creo? Aunque más no sea de consulta como para verificar el comportamiento que tiene una funcionalidad determinada cuando desde el ambiente de QA no tenemos posibilidad de reconocer cómo actúa ya que puede estar teniendo un defecto.

Este debate fue lanzado en uno de los grupos de discusión en LinkedIn, recibiendo los siguientes comentarios:

Comentario 1:
Lo mejor es NO testear el PROD ! pero si por algun motivo se debe si o si testear en prod… la mejor recomendacion es rezar. :P. He testeado en prod y hay que ser MUY
cuidadoso…

Comentario 2:
No sería lo recomendable, sin embargo si la situación lo amerita (por ejemplo por una planificación ajustada), una de las alternativas para mitigar el impacto de los bugs que no aparecieron en fase de testing podría ser la de acotar el riesgo. Por ejemplo, poner en producción en ciertas áreas o funcionalidades acotadas, en un periodo ventana, corrigiendo lo que va surgiendo y luego implementar en su totalidad.

Comentario 3:
Tal cual como indica Fabio, si no queda otra, ademas del pasaje a producción y testing sectorizado, también se podría habilitar el cambio solo para cierto tipo de usuario experto que oficie como tester y vaya dando las aprobaciones.

Comentario 4:
Para mí, Testing en Producción implica que tienes un sistema combinado de Software Development (un software que necesita versionado y mantenimiento prolongado en el tiempo) y Regression Tests para garantizar la calidad de los cambios con 100% de feature coverage (garantizar que al menos hay algún test que prueba todas las funcionalidades de manera básica). Avanzar hacia un mayor coverage en regresión, para después avanzar hacia la Continuous Integration, y más tarde, hacia el Continuous Delivery. Y dejar las pruebas manuales sólo para la User Experience en la parte de Acceptance Testing

Comentario 5:
Uhm respecto al testing en producción, he leído y puesto en práctica algunos de estos puntos:

1. Tener un ambiente muy similar al de producción, sino se puede en infraestructura es obligatorio hacerlo en cuanto a la BD.
2. Como lo indica otro compañero del post, un proceso robusto y de alta automatización de regresión.
3. Probar el despliegue de la versión.
4. Es cierto y se debe admitir como buena práctica, probar un proceso de rollback de la versión que se despliegue (Si algo sale mal en el despliegue, se tiene certeza y se ahorra tiempo, si se ejecuta el plan de rollback inmediatamente).
5. Analizar bien cual es la funcionalidad core de la aplicación desplegada. Ej. Si mi aplicación es de pagos en línea, la funcionalidad core es la que me permite realizar pagos, no más!.
6. Tomar de la regresión, una cantidad de casos automatizados clave sobre la funcionalidad del paso 1 y volverla una suite que se ejecutará en el post despliegue, la cual en su ejecución, no debe tomar más de 5 minutos. (Si algo sale mal, activar el procedimiento de rollback).
7. Si se desea se pueden tener más suite de prueba en el despliegue, sin embargo debemos considerar el nivel de profundidad que se quiere, ya que puede salir muy costoso