• 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.
  • Libros benéficos

    En 2016 publiqué, “Aseguramiento de la Calidad”, cuyo beneficio es destinado a la Fundación Aladina, después le siguió: “Seis en 75”, destinado a la Fundación Menudos Corazones y “Asegurar la Calidad en dispositivos móviles...y no morir en el intento”, a la fundación Soñar Despierto. También he publicado una recopilación íntegra de los tres libros anteriores, llamada "Fundamentos de la calidad del software".

    Merchandising benéfico

    Desde la tienda de Cultura de Calidad se pueden adquirir diferentes artículos cuyo beneficio es destinado íntegramente a las tres fundaciones con las que colaboro actualmente: Fundación Aladina, Fundación Menudos Corazones y Fundación Soñar Despierto.

    Acciones benéficas futuras

    Esto no va a parar aquí. Mi cabeza no se está quieta, tengo muchas ideas que dar forma y convertirlas en realidad. Desde aquí, hago un llamamiento a diferentes fundaciones y ONGs para poder colaborar juntos y poder hacer cosas grandes que ayuden a personas o animales en todo el mundo. Si te apetece, ponte en contacto conmigo y hablamos.

    0
    Publicaciones
    0
    Seguidores
    0
    Visitas únicas
    0
    Me gusta