Siguiendo con el post que hablaba sobre cómo usar mindmaps para testing, en este veremos distintos modelos y heurísticas (algunos son mindmaps, otros son otras representaciones) para definir una estrategia de pruebas.
Mientras leía su resumen, también veía una asociación directa con lo que hacemos cada vez que preparamos una propuesta de trabajo para un posible cliente. Una vez que esta propuesta es aceptada, es fundamental que todo este modelo sea comprendido a la perfección por el equipo que finalmente se hará cargo del proyecto de pruebas (no siempre sucede que el que prepara la propuesta es el mismo que ejecuta el proyecto, por temas de tiempos y procesos de venta, etc.).
The Heuristic Test Strategy Model
Este modelo fue propuesto por James Bach acá, y acá veremos una aproximación al mismo. Este modelo consiste en un conjunto de elementos para diseñar una estrategia de pruebas, la cual puede ser representada con mindmaps para facilitar su visibilidad y entendimiento. El propósito inmediato de este modelo es recordar a los tester sobre qué enfocarse cuando se crean pruebas. La siguiente imagen representa la vista más global:
Este modelo tiene una serie de elementos a tener en cuenta cuando se realiza:
- El entorno del proyecto: incluye recursos, restricciones y otros elementos del proyecto que pueden permitir o dificultar nuestras pruebas. A veces un tester debe desafiar las restricciones, y a veces aceptarlas.
- Elementos del producto: son las cosas que uno tiene la intención de probar. El software es complejo e invisible, hay que tener cuidado de cubrir todo lo que importa, no sólo las partes que son fáciles de ver.
- Los criterios de calidad: son las reglas, valores y fuentes que permiten probar si el producto tiene problemas. Los criterios de calidad son multidimensionales y a menudo ocultos o contradictorios.
- Las técnicas de test: son heurísticas para crear casos de pruebas que tienen como entrada los tres puntos anteriores (tal como se representa el la imagen). Todas las técnicas implican algún tipo de análisis del entorno del proyecto, los elementos del producto y los criterios de calidad.
- La calidad percibida: es el resultado de las pruebas. Nunca se puede conocer la calidad “real” de un producto de software, pero a través de la aplicación de una variedad de pruebas, se puede hacer una evaluación informada de la misma.
Iremos viendo cada punto con más detalle.
Entorno del proyecto
Crear y ejecutar pruebas es el corazón del proyecto de pruebas. Sin embargo, hay muchos factores en el entorno del proyecto que son fundamentales para su decisión sobre qué pruebas concretas crear:
- Misión: El propósito en este proyecto, tal como lo entiende el equipo y sus clientes.
- ¿Conocemos a los clientes, sus problemas, necesidades, lo que esperan del proyecto?
- Información: Información sobre el producto o proyecto que se necesita para las pruebas.
- ¿A quiénes podremos consultar? ¿hay documentos, estadísticas, información disponible?
- Relación con desarrolladores: ¿Cómo te llevas con los programadores?
- Equipo de pruebas: Cualquier persona que realice o apoye las pruebas.
- ¿Quiénes estarán probando y qué skills tienen?
- ¿Desde dónde estarán trabajando (juntos, remoto)?
- ¿Alguien más estará ayudando o apoyando?
- Equipos y Herramientas: Hardware, software o documentos necesarios para administrar las pruebas.
- Hardware y software.
- Herramientas, automatización.
- Matrices, checklists, algún lugar donde registrar las evidencias de pruebas o bugs.
- Agenda/plan: La secuencia, duración y sincronización de los eventos del proyecto.
- ¿Cuáles son los hitos que hay que cumplir? Debemos conocer si hay una fecha de entrega o puesta en producción.
- ¿Cuándo está planificado contar con las distintas versiones del software a probar?
- ¿Cuánto tiempo disponible tenemos para probar?
- Elementos de prueba: El producto a ensayar.
- Definir el alcance, ¿qué se va a probar y qué no?
- Es necesario tener disponibilidad y acceso al sistema a probar (¿es un sistema web? ¿tenemos acceso remoto? ¿necesitamos VPN?)
- ¿El producto está estable o está constantemente cambiando? En cualquier caso, ¿se considera re-test en el alcance? ¿cuántos ciclos?
- ¿Qué tan fácil de probar es el producto?
- Entregables: Los productos observables del proyecto de prueba.
- Definir el contenido y propósito de los reportes necesarios.
- ¿Es necesario cumplir con algún estándar o norma?
- Además de reportes, ¿se reportarán los incidentes/evidencia de pruebas/etc., en alguna plataforma específica?
Elementos del producto
En este punto el modelo relevante es el de la heurística SFDIPOT (Structure, Functions, Data, Interfaces, Platform, Operations, Time, según la última actualización) de James Bach y Michel Bolton. Este modelo es una especie de inventario de aspectos del producto a tener en cuenta cuando pensamos en qué probar.
Los productos tienen muchas dimensiones, por lo tanto, para probar bien debemos examinar esas dimensiones. Los testers que se centren en sólo en algunas de estas dimensiones o elementos son propensos a perder errores importantes.
- Estructura: Todo lo que comprende el producto físico.
- Función: Todo lo que hace el producto, sus funcionalidades.
- Datos: Todo lo que el producto procesa.
- Interfaces: Cada conducto por el cual se accede o se expresa el producto.
- Plataforma: Todo de lo que depende el producto (y que está fuera del proyecto).
- Operaciones: Cómo se utilizará el producto.
- Tiempo: Cualquier relación entre el producto y el tiempo.
Este mindmap está excelente, porque refina estos elementos y alimenta con muchas ideas para pensar qué aspectos probar de un sistema:
Técnicas generales de prueba
Por “técnica general” queremos decir que la técnica es lo suficientemente simple y universal como para aplicarla a una amplia variedad de contextos. Muchas técnicas específicas se basan en uno o más de estos nueve aspectos:
- Pruebas de funcionamiento: Prueba de lo que puede hacer.
- Pruebas de afirmaciones: Desafía todas las afirmaciones sobre el producto, ya sea su manual, certificaciones, indicaciones que cumple con determinado SLA, etc.
- Pruebas de dominios: Dividir y conquistar los datos.
- Pruebas de usuario: Involucrar a los usuarios.
- Pruebas de estrés: Abrumar el producto.
- Pruebas de riesgo: Imagina un problema, luego buscalo.
- Pruebas de flujo: Hacer una cosa después de otra, pensando los distintos flujos que pueden haber (por ejemplo, pensando en la máquina de estados que representa el comportamiento del sistema).
- Comprobación automática: Comprobar un millón de hechos diferentes, apoyándose en herramientas.
- Prueba de escenario: Prueba de situaciones posibles a las que estará expuesto el producto.
Categorías de Criterios de Calidad
Un criterio de calidad es un requisito que define lo que el producto debe ser. Al pensar en diferentes tipos de criterios, se estará en mejores condiciones para planificar las pruebas que descubren problemas importantes y de forma rápida.
Esto hace un tiempo en Abstracta lo representamos en lo que le llamamos “the testing wheel”, donde vinculamos los factores y atributos de calidad (según la norma ISO 25.010, de calidad de producto de software) con los distintos tipos de testing existentes.
Volviendo a lo referido por Bach, menciona estos:
- Capacidad: ¿El producto puede realizar las funciones requeridas?
- Confiabilidad: ¿Funcionará bien y resistirá fallas en todas las situaciones requeridas?
- Usabilidad: ¿Qué tan fácil es para un usuario real utilizar el producto?
- Carisma: ¿Qué tan atractivo es el producto?
- Seguridad: ¿Qué tan bien está protegido el producto contra el uso no autorizado o la intrusión?
- Escalabilidad: ¿Qué tan bien escala el producto? o sea, ¿sigue respondiendo adecuadamente cuando los requerimientos/usuarios concurrentes aumentan?
- Compatibilidad: ¿Qué tan bien funciona con los componentes y configuraciones externos?
- Desempeño: ¿Qué tan rápido es y qué tantos recursos consume?
- Instalación: ¿Con qué facilidad puede instalarse en su(s) plataforma(s) de destino?
- Desarrollo: ¿Qué tan bien podemos crear, probar y modificar?
Cerrando
Este post también es parte de la investigación realizada por Emiliano Cruz, del equipo de Abstracta, así que ¡gracias!
Me encantaría saber si a vos también te sirven estos modelos, si le agregarías o modificarías algo.
Estimado, interesante aporte