Realización de una regresión en Producción

Cuando se realiza una nueva subida a producción, el equipo de Testing siempre tiene que realizar una regresión para mantener la estabilidad del mismo y evitar que aparezcan errores que se han producido en la misma subida.











¿Donde realizamos esa regresión?

Nunca hay que hacer la regresión en el mismo entorno de producción. Nunca hay que probar en el entorno del cliente, bajo ningún concepto y todo lo que sea diferente a eso es un error.

Para realizar las pruebas tenemos que tener un entorno de "predespliegue" o en algunos sitios llamados "staging" (puesta en escena), que simplemente es un entorno clon de producción en el que podemos tocar sin problemas.



Este entorno tendrá exactamente la misma base de datos y exactamente el mismo código que se va a subir a producción y por lo tanto todo lo que probemos allí es lo que va a subir. De esta manera nos curamos en salud y podremos hacer una pequeña regresión por si existiese algún tipo de error.



¿Como realizamos la regresión?

Esta regresión tiene que tocar todos los puntos "críticos" de la aplicación y saber exactamente donde está el foco de utilización en ese momento.

La regresión tendrá puntos comunes que se tienen que pasar siempre y en cada subida entrarán pruebas específicas para comprobar los puntos que se suben en ese momento.



Cuando tengamos programada una subida a producción, hay que hacer una subida previa el día anterior a este entorno para realizar esta regresión y el equipo de testing se dedicará al 100% a estas pruebas.



El resultado de las pruebas determinará el resultado de la subida y si hay que retrasarla para arreglar algún imprevisto. Esto no debería de pasar ya que se han realizado las suficientes pruebas en entornos anteriores y los casos de prueba estarán en OK.



Nosotros, en el equipo, marcamos ciertos casos que nos resultan más "críticos" y que tenemos que probar si o si para garantizar el buen funcionamiento de la aplicación (por lo menos minimamente), así vamos sacando, sprint tras sprint, una batería de regresión contundente que nos determinará el buen estado de una subida.



Siempre recomiendo la realización de esta pequeña regresión final para asegurar más aún el resultado de una subida, ya que entre entornos se puede haber desvirtuado el código y tener algún problema, aunque en la subida posterior también podría ocurrir, por lo menos podemos quedarnos más tranquilos y que los usuarios finales no tengan ningún disgusto.

0 Comentarios