Tengo la suerte de experimentar cambios de procesos y aplicación de nuevas metodologías en mi actual trabajo. Todo ello desde mi posición de Responsable de QA en una Software Factory. Pero siempre se presentan dudas, y mucho más si por parte del equipo experimentado (entiéndase que lleva toda una vida trabajando de una “forma”), hay una posición inicial y permanente del No a todo cambio.

Es el caso que presento hoy, y que me gustaría recibir vuestro punto de vista.

Antecedentes:
Una de nuestras aplicaciones ERP, ampliamente extendida en el mercado, ha evolucionado de solución-cliente (instalación en el entorno del cliente) a SaaS (Software as a Service), instalación y BBDD en nuestro Centro de Cómputo. Nosotros como equipo de QA, debemos certificar la versión SaaS (previamente se ha certificado la versión-a-cliente (VaC) con todas las nuevas funcionalidades y modificaciones/correcciones. La versión SaaS será la misma (funcionalmente hablando) que sale a la calle VaC, con las adaptaciones del propio entorno SaaS (principalmente gestión de ficheros, comunicación externa, entradas y salidas de la aplicación, gestión de usuarios, entre otras menores).


La vSaaS se gestiona a través de un tercer equipo (Sistemas e IT), independiente de Dev y de QA. El protocolo a seguir es:

  1. QA certifica VaC y se publica a la calle.
  2. QA solicita a Dev que genere la vSaaS
  3. Dev genera la versión y solicita a “Sistemas e IT) la instalación en los servidores de prueba de QA
  4. “Sistemas e IT” confirma a QA que ya tenemos la vSaaS instalada en nuestro entorno
  5. QA empieza las pruebas, con diferentes ciclos hasta lograr la certificación.

Dudas:

  1. ¿Qué se considera una “Versión Cerrada” a entregar a QA en el entorno SaaS?
  2. ¿Dónde termina el trabajo de Desarrollo y donde empieza el trabajo de QA de dicha versión?

Problema:

  • La instalación en entorno de pruebas la realiza el equipo de Sistemas e IT (quién no conoce la aplicación), de forma conjunta con el equipo de Dev (quién si conoce la aplicación). Ello conlleva a que algunas instalaciones no sean ESTABLES para el inicio de trabajo de QA.
  • Se realizan continuas modificaciones en la implementación de la aplicación en entorno SaaS, a la vez que ya el equipo de QA va ejecutando el plan de pruebas y certificando ciertas funcionalidades, que podrían verse afectadas con esas “últimas modificaciones de la versión instalada”

Solución alternativa propuesta por Desarrollo:

  • Dev argumenta que da una vSaaS “cerrada”
  • Que QA ejecute paralelamente un proceso de “comparación” de versiones entorno QA y entorno Dev de las aplicaciones SaaS.
  • Dev argumenta que forma parte de la Certificación de la Instalación, por lo tanto, es responsabilidad de QA

Posición de QA:

  • No iniciar las pruebas hasta que se garantice que la versión a probar es ESTABLE
  • Que sea el equipo de Dev el responsable de ejecutar el proceso de comparación, a priori de que QA empiece la certificación.
  • QA argumenta que no es problema de la instalación, sino de la implementación y adaptación de la aplicación en un entorno SaaS, previsible para Dev pero no para “Sistemas e IT” ni para QA

Objetivo:

  • Reducir los ciclos de re-test
  • Reducir el coste de reporte y gestión de incidencias no del aplicativo sino de error en la implementación
  • Reducir el coste de solución de incidencias del tipo de “versión mal implementada en entorno de pruebas”
  • Implementar una fase de “Development testing” o Implementation Testing (que no una “Instalation testing” , ya que QA no es responsable de la instalación ni tiene atributos/perfil sobre ese entorno de pruebas)
  • Optimizar el proceso de certificación
  • Certificar una vSaaS completamente cerrada


¿qué opciones o alternativas véis?


Saludos,
Juan Carlos Peláez

Be Sociable, Share!