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).
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.
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?
¿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.
Read more
