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

El Plan de pruebas describe la estrategia, recursos y planificación de nuestras pruebas. Esta estrategia incluye la definición del tipo de pruebas a realizar para cada iteración, la cobertura y objetivos…en definitiva, el test plan representa el proceso de pruebas. Es importante detallar lo que está dentro del “scope” de las pruebas y lo que no se testeará.

La función principal del Test Plan es ayudarnos en la realización de las pruebas…por ello debe al menos incluir:

• Definir objetivos de las pruebas.
• Definir de los elementos que se van a probar.
• Enfoque o estrategia que se usará.
• Recursos y planificación necesarios.

Adjunto una plantilla que he obtenido de la “IEEE” que os puede servir como ejemplo. A partir de ella podreís crear vuestra propia plantilla que se adapte a las necesidades de vuestra empresa.

Test Plan Template

Podemos implantar un sistema de la calidad, partiendo de documentos de requerimientos y/o de casos de uso, podemos escribir los planes de pruebas, hacer el diseño y escribir al detalle todos los casos de prueba, podemos ejecutarlos en paralelo al desarrollo e ir manteniéndolos con los cambios.

Con todo eso puede valer para tener un producto de calidad, pero ¿qué pasa si añadimos un ingrediente más a la receta: el análisis y gestión de riesgos?

La actividad de la gestión de riesgos no es un trámite o formalismo a cumplimentar para superar una certificación: es algo útil. La gestión de riesgos cierra el círculo, vinculando requerimientos, riesgos y casos de prueba que controlan la mitigación de estos riesgos.

¿Qué aporta este ingrediente?

En primer lugar implica la revisión exhaustiva de los requerimientos (con la consecuente detección de incoherencias, lagunas o indefiniciones).

También nos obliga a pensar y definir el uso previsto de la aplicación, determinando exactamente el entorno de uso y los potenciales afectados en caso de fallo (operadores, clientes/pacientes, medio ambiente, empresa, etc.), así como el nivel de criticidad de la aplicación.

Tras el análisis tenemos identificados, evaluados y categorizados los riesgos. Esto nos proporciona una visión clara de cuáles son los módulos o áreas más críticas de la aplicación y de aquellas funcionalidades que implican mayores riesgos. Esto es de vital importancia a la hora de planificar cada una de las fases de verificación a lo largo del ciclo de vida de desarrollo del proyecto. Nos ayuda a priorizar nuestros casos de prueba, sobretodo en aquellas fases finales en las que los plazos se acortan, el tiempo apremia y hay que asumir ciertos riesgos con el máximo de cobertura.

Cuando decidimos atacar los riesgos que más impacto pueden tener, definimos mitigaciones para cada uno de ellos, teniendo en cuenta el balance entre el coste de la implementación de la mitigación, el beneficio que aporta esa funcionalidad y el daño o impacto real del error en caso de producirse.
Los riesgos se tienen que mitigar tanto como sea posible, dentro de lo razonablemente práctico (‘As Low As Reasonably Practicable-‘ALARP principle’).

Las mitigaciones previenen errores que podríamos haber pasado por alto en nuestros casos de prueba. Al definir nuevos casos de prueba que verifican que las mitigaciones se han implementado como se esperaba, estamos evitando que esos errores aparezcan una vez la aplicación esté en su uso final. Tenemos así enlazados los requerimientos, con los riesgos que pueden entrañar y con las pruebas que verifican las mitigaciones.

Cada vez que se introduce una petición de cambio en los requerimientos o aparece un error en la aplicación, podemos evaluar y categorizar el riesgo que implica, desde esta perspectiva, teniendo así más argumentos para decidir sobre su implementación o corrección. Y así durante toda la vida del proyecto.

¿Es bueno tu proceso de testing? Esta es una pregunta muy fácil de hacer y muy dificil de contestar. Las pruebas de software amenudo consumen mucho tiempo y dinero. Muchas organizaciones se han dado cuenta que mejorando sus procesos de pruebas pueden solucionar estos problemas. Sin embargo, en la practica resulta mucho más dificil saber que medidas tomar para mejorar y controlar el proceso.

El modelo TPI está basado en las mejores prácticas de la industria relativas a la mejora del proceso de pruebas. El modelo incluye guías prácticas para evaluar el nivel de madurez de prueba de una organización así como los pasos para mejorar el proceso.

El modelo se compone de 20 Áreas Clave, que constituyen la base para mejorar y estructurar el proceso de Test. Esta es la lista completa:

-Test strategy
-Life-cycle model
-Moment of involvement
-Estimating and planning
-Test specification techniques
-Static test techniques
-Metrics
-Test automation
-Test environment
-Office environment
-Commitment and motivation
-Testing functions and training
-Scope of methodology
-Communication
-Reporting
-Defect management
-Testware management
-Test process management
-Evaluation
-Low-level testing

Niveles de Madurez
Los requisitos para cada nivel están definidos en forma de Checkpoints, que son preguntas que necesitan ser respondidas afirmativamente para poder calificar a dicho nivel. A partir de las listas de verificación se puede evaluar un proceso de pruebas y se puede determinar para cada Área Clave el Nivel alcanzado. A medida que se considera mejorada cada Área Clave, los checkpoints son acumulables.

Para poder clasificar para el nivel B, el proceso de pruebas necesita responder afirmativamente tanto a los Puntos de Verificación del nivel B como del nivel A.

Matriz de madurez
Cada área con diferentes niveles de madurez. Los niveles de todas las Áreas Clave están integrados en una Matriz de Madurez. Por consiguiente, los niveles de madurez indican el estado de cada área clave.

La matriz de madurez viene determinada por una escala que va del 1 al 13:

- Controlada (1 al 5)

- Eficiente (6 al 10)

- Optimizada (11 al 13)

El modelo TPI ofrece el soporte necesario para mejorar el proceso de test a través de la obtención de rápida manera, se considera el modelo como una herramienta de estructuración de acciones de mejora del proceso de test.

Referencias:
“Test Process Improvement, a practical step-by-step guide to structured testing”

Addison-Wesley, ISBN 0 201 59624 5