Estrategia Prevention & Reaction – Parte I

Introducción

Con las metodologías ágiles, el software se encuentra en un desarrollo continuo, de una forma iterativa e incremental, de forma que la mayoría de empresas despliegan diariamente una o más versiones de su aplicación.

Este hecho provoca que las estrategias de aseguramiento de la calidad (de ahora en adelante QA) deban adaptarse, dado que únicamente cubrían las necesidades de las metodologías tradicionales.

Actualmente existen empresas que implementan metodologías ágiles sin la necesidad de perfiles de calidad, siendo los desarrolladores quienes la aplican, mediante el desarrollo de pruebas unitarias y de integración. Esto es debido a que los equipos de calidad pueden demorar o ser un bloqueo en dichas iteraciones de desarrollo.

Tras en análisis anterior se me ocurrió como trabajo personal desarrollar una estrategia que aplicara esa idea. La estrategia “prevención y reacción” pretende adaptarse a las metodologías y equipos ágiles garantizando la calidad del software, tanto en fases de desarrollo como en fases posteriores y puesta en producción.

Contextos de prevención y reacción

El término de prevención se refiere a evitar la inserción de bugs en el desarrollo; por el contrario, el término de reacción se refiere a la actuación de localizar los fallos y al tratamiento en caso de hacerlo.

Diferenciamos dos contextos o tiempos diferentes en los que operan las estrategias tanto de prevención como las de reacción: Tiempo de la release candidata (en ahora en adelante RC) y tiempo de producción.

Tiempo de RC

rc_time_contexts

Llamamos tiempo de RC al estado en la que la release no ha sido desplegada en producción. Comienza en la toma de requisitos del desarrollo hasta la fase de pruebas de la RC.

Prevención en tiempo de RC

strategies
Las estrategias de prevención en tiempo de RC tratan de evitar la inserción de bugs o errores en la RC, de tal forma que la RC llegue a la fase de pruebas lo menos impactada posible.

Las estrategias operan fundamentalmente en tres fases del desarrollo de la RC:

  • Fase de diseño: En la fase de diseño, el equipo de calidad debe obtener información de los criterios de aceptación por parte del equipo de producto. Se podría obtener en fase de requerimientos pero es probable que en la fase de diseño estén más definidos, por lo que aquella (la fase de requerimientos) sigue siendo una etapa temprana.
  • Fase de desarrollo: Implementación de un sistema de predicción de bugs. Nos garantizará una información objetiva de los riesgos de los desarrollos realizados en la RC, puntos conflictivos y propensos a fallo. Mediante un sistema de predicción se pueden focalizar las pruebas con mayor precisión y así reducir el tiempo de ejecución de las mismas.
  • Fase de pruebas: Antes de generar la RC (la cual se enviará a pruebas finales) es necesario que pase  pruebas de análisis estático, unitarias, integración y funcionales. El equipo de desarrollo será el encargado de desarrollarlas. La petición finalizará  una vez esté el desarrollo junto con las pruebas. Se realizarán pruebas bajo demanda por parte del equipo de calidad. Todos los resultados se analizarán y se utilizarán para el sistema de prevención y futuras retrospectivas.

Aplicación estrategias

La imagen muestra una forma de aplicar las estrategias de prevención en tiempo de RC.

  1. Se desarrolla la petición junto con las pruebas por parte del equipo de desarrollo. El sistema de predicción obtiene los datos de los cambios realizados.
  2. Se ejecutan las pruebas desarrolladas unitarias y de integración. Los resultados se almacenan para un posterior análisis. Esos datos servirán para alimentar la heurística del sistema de predicción de bugs.
  3. Se despliega la petición en un nuevo entorno.
  4. Se ejecutan las pruebas funcionales. Los resultados se almacenan tanto para el análisis como para el sistema de predicción.

Reacción en tiempo de RC

Reaction in RC time

Las estrategias de reacción en tiempo de RC tratan principalmente de localizar los errores que se nos han “pasado” en la fase de prevención. Dado que la RC ya ha sido generada, los errores ya se encuentran ella, por lo que es tiempo de reaccionar y localizarlos.

Es bien cierto que en esta fase se implementan estrategias o acciones que garantizan la calidad de la aplicación que en la fase anterior no se podrían aplicar.

Como se puede ver, la intención no es solo asegurar la calidad desde un aspecto funcional, si no que intentamos realizar pruebas que garanticen el rendimiento y la seguridad de la aplicación.

reacción rc

La imagen muestra una forma de aplicar las estrategias de reacción en tiempo de RC.

  1. Se despliega la RC en un entorno de pruebas.
  2. Se ejecutan las pruebas de calidad. (Funcionales, UAT, security, performance…) Los resultados se almacenan para un análisis posterior y como heurística del sistema de predicción de bug.
  3. Se acepta o rechaza la RC.

La fase de reacción en tiempo de RC es la última antes del despliegue en producción, lo que significa que localizar un bug en producción que se ha insertado en la RC es un caso de fracaso.

Conclusiones y adelanto

Hemos visto cómo aplicar la calidad del software en tiempo de RC en dos contextos diferentes: Preventivo y reactivo.

Entender los dos contextos nos ayudará a conocer las diferentes estrategias que aplicamos y saber el porqué. Garantizaremos la calidad del software desde etapas tempranas y focalizaremos la mayoría de nuestros esfuerzos a generar RCs validas. De esta forma ahorraremos tiempos en el testing, dado que centralizamos las pruebas y en el desarrollo, dado que minimizamos la aparición de bugs.

En esta fase es muy importante la obtención de los datos. Los resultados de las pruebas sirven para realizar retrospectivas que ayuden a valorar el éxito de la aplicación de nuestra estrategia de calidad, debido a que si en la fase de pruebas no encontramos fallos que posteriormente se encuentran en producción deberemos tomar medidas. En el caso de los datos de predicción, nos ayudarán a focalizar nuestras pruebas, por lo que tendremos más opciones de encontrar posibles fallos y reduciremos nuestro tiempo de testing.

En el próximo post de la serie analizaremos los contextos de prevención y reacción en tiempo de producción. Veremos cómo los datos de producción nos pueden ser de gran ayuda para adelantarnos a fallos y cómo nos servirán para objetivizar nuestras pruebas.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *