Liderazgo en Pruebas: Modelado y Cobertura
En el mundo de las pruebas de software, un liderazgo efectivo sabe cómo establecer una dirección clara para que las estrategias de prueba se alineen con los objetivos de desarrollo. A medida que los sistemas de software se vuelven cada vez más complejos, los métodos tradicionales de prueba tienen dificultades para mantenerse al día.
Es aquí donde los enfoques innovadores como la modelización de pruebas y el análisis de cobertura se vuelven cruciales. Estas prácticas aseguran que los equipos cubran caminos críticos y casos extremos, y permiten una mejor colaboración, menor riesgo y una entrega más rápida.
En este artículo, exploraremos qué significa liderar teniendo en cuenta los modelos y la cobertura. Analizaremos cómo los líderes de pruebas pueden aprovechar estas estrategias para optimizar sus procesos, mejorar la calidad del producto y garantizar una cobertura de pruebas exhaustiva, todo ello fomentando una cultura de excelencia y responsabilidad. Ya sea que seas un gerente de QA, un líder de equipo o simplemente quieras profundizar tu comprensión sobre el liderazgo en pruebas, esta guía te aportará conocimientos y técnicas prácticas para elevar tus habilidades de prueba.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Vamos a sumergirnos.
¿Qué es un Modelo de Pruebas?
Probar es un proceso en el que creamos modelos mentales del entorno, el programa, la naturaleza humana y las propias pruebas. Cada modelo se utiliza hasta que aceptamos que el comportamiento es correcto o hasta que el modelo ya no es suficiente para su propósito.
Boris Beizer, Software Test Techniques, 1990
El diseño de pruebas es el proceso mediante el cual seleccionamos, de entre la galaxia de opciones disponibles, las pruebas que creemos que serán más valiosas para nosotros y nuestros interesados. Los modelos de prueba nos ayudan a seleccionar pruebas de manera sistemática y son fundamentales en el testing.
La forma en que los testers usan los modelos:
- Identificamos y exploramos Fuentes de Conocimiento para construir modelos de prueba.
- Usamos estos modelos para cuestionar y validar nuestras fuentes, mejorando nuestras fuentes y nuestros modelos.
- Usamos estos modelos para informar tanto al testing como al desarrollo.
Dada una misión de pruebas, nuestra primera tarea es identificar Fuentes de Conocimiento. Estas pueden ser:
- Documentación: especificaciones, diseños, requisitos, normas, directrices, etcétera.
- Personas: interesados, usuarios, analistas, diseñadores, desarrolladores y otros.
- Experiencia: tu propio conocimiento y experiencia en sistemas similares (o diferentes), tus preferencias, prejuicios, suposiciones, corazonadas, creencias y sesgos.
- Sistema Nuevo: el sistema bajo prueba, si existe, está disponible y accesible.
- Sistema Antiguo: el sistema que se va a reemplazar es obviamente una fuente; puede, en algunas áreas funcionales, proporcionar un oráculo de comportamiento esperado.
Es importante señalar que todas nuestras fuentes de conocimiento son falibles e incompletas, y lo mismo ocurre con nuestros modelos. Los testers usan experiencia, habilidad y juicio para filtrar estas fuentes, compararlas, contrastarlas, desafiarlas y llegar a un consenso.
Todos los modelos son incorrectos, algunos son útiles
George Box, Economista.
Un modelo de pruebas puede ser una lista de verificación o un conjunto de criterios. También puede ser un diagrama derivado de un documento de diseño o un análisis de texto narrativo. Muchos modelos de prueba nunca se plasman en papel; pueden ser modelos mentales construidos específicamente para guiar al tester mientras explora el sistema bajo prueba.
El propósito de los modelos es simplificar situaciones complejas omitiendo detalles que no son relevantes en ese momento. Usamos modelos para simplificar un problema – seleccionar cosas para probar, por ejemplo. El modelo guía nuestro pensamiento, y seleccionamos pruebas identificando la aparición de algún aspecto clave del modelo.
Podríamos seleccionar ramas en un diagrama de flujo o de control, transiciones de estado en un modelo de estados, límites en un modelo de dominio de entrada (o salida), y escenarios derivados de historias de usuario escritas en el lenguaje específico de dominio Gherkin.
Pero cuidado, a veces los modelos omiten aspectos que no son seguros—quizás el modelo simplifica en exceso una situación—y debemos estar atentos a esto. Para hacer tus modelos de prueba más eficientes, es fundamental utilizar software especializado de gestión de pruebas.
Si no tenemos modelos directamente de nuestras fuentes, debemos inventarlos. Por ejemplo, cuando los requisitos se presentan como texto narrativo, debemos usar el lenguaje de los requisitos para derivar funcionalidades y la lógica de su comportamiento. Esto puede ser difícil para desarrolladores y testers, y a menudo es un esfuerzo colaborativo, pero debemos persistir.
Usar Modelos para Probar
Usamos modelos de prueba para:
- Simplifica el contexto de la prueba. Los detalles irrelevantes o insignificantes se ignoran en el modelo.
- Enfoca la atención en una perspectiva del comportamiento del sistema. Estos pueden ser características críticas o riesgosas, aspectos técnicos, operaciones de usuario de interés o aspectos de la construcción o arquitectura del sistema.
- Genera un conjunto de pruebas únicas (dentro del contexto del modelo) que sean diversas (con respecto a ese modelo).
- Permite que las pruebas sean estimadas, planificadas, monitorizadas y evaluadas por su integridad (cobertura).
Desde el punto de vista del tester, un modelo nos ayuda a reconocer aspectos del sistema que podrían ser objeto de una prueba.
Modelos y Cobertura
La cobertura es el término que usamos para describir la exhaustividad o completitud de nuestras pruebas con respecto a nuestro modelo de pruebas. Un elemento de cobertura es algo que queremos ejercitar en nuestras pruebas.
Idealmente, nuestro modelo de pruebas debería identificar los elementos de cobertura de manera objetiva. Cuando hemos planificado o ejecutado pruebas que cubren elementos identificados por nuestro modelo, podemos cuantificar la cobertura lograda y, como proporción de todos los elementos del modelo, expresar esa cobertura como un porcentaje.
Cualquier modelo que permita identificar elementos de cobertura puede ser utilizado.
Los modelos suelen ser gráficos, con ejemplos como diagramas de flujo, casos de uso, diagramas de secuencia, etc. Estos y muchos otros modelos tienen elementos (o "blobs") conectados por líneas o flechas. Estos suelen llamarse grafos dirigidos.
Imagina un modelo gráfico que compone "blobs" y flechas. Al menos dos objetivos de cobertura podrían definirse:
- Cobertura de todos los blobs
- Cobertura de todas las flechas
- Y así sucesivamente
Así que, cualquier modelo que sea un grafo dirigido puede ser tratado de la misma forma.
Un modelo formal permite identificar elementos de cobertura de forma fiable. Por lo tanto, se puede definir una medida cuantitativa de cobertura y utilizarla como objetivo mensurable.
Los modelos informales tienden a ser listas de comprobación o criterios utilizados para hacer una lluvia de ideas sobre elementos de cobertura, generar ideas para pruebas o para realizar pruebas en una sesión exploratoria. Estas listas o criterios pueden estar predefinidos o elaborados como parte de un plan de pruebas o adoptados en una sesión de pruebas exploratorias.
Los modelos informales son diferentes de los modelos formales en que la creación de los elementos de cobertura depende de la experiencia, intuición e imaginación del profesional, por lo que la cobertura con estos modelos nunca puede ser cuantificada. Nunca podemos saber qué significa la cobertura completa con respecto a estos modelos.
Las pruebas derivadas de un modelo informal son tan válidas como las derivadas de un modelo formal si aumentan nuestro conocimiento del comportamiento o la capacidad de nuestro sistema.
Los Modelos Simplifican, Así Que Usa Más De Uno
Un buen modelo proporciona un medio para entender la complejidad y lo logra en parte excluyendo detalles que no son relevantes. Tu modelo podría emplear el concepto de estado, modos de fallo o flujos, combinaciones de entradas, valores de dominio, etc.
Un solo modelo nunca es suficiente para probar completamente un sistema. Todos los modelos son un compromiso, por lo que necesitamos múltiples modelos. Este concepto se conoce normalmente como «medidas parciales diversas». Esto significa que necesitamos una diversidad de modelos parciales para probar adecuadamente un sistema.
Aunque normalmente no se describa en estos términos, las etapas de prueba en un proyecto en cascada usan modelos desde diferentes perspectivas. Las pruebas unitarias, de integración de subsistemas, a nivel del sistema y de usuario tienen distintas metas; cada una usa un modelo y perspectiva diferente – de aquí proviene la diversidad.
Usar Modelos para Gestionar
Los modelos están en el corazón de las pruebas y también de la gestión de pruebas. Hay cuatro aspectos clave:
- Participación de los interesados
- Alcance
- Cobertura
- Estimación y Monitoreo de Progreso
Participación de los Interesados
Cuando planificamos y delimitamos las pruebas y explicamos el progreso y el significado de la cobertura a los interesados, debemos usar modelos que sean comprensibles y relevantes para los objetivos de los interesados.
Si planeamos una prueba de usuario, probablemente adoptaremos el flujo de procesos de negocio como nuestro modelo y como plantilla para rastrear caminos que ejerciten las funciones del sistema importantes para el usuario. Si estamos probando la integración de componentes de servicio en nombre de un arquitecto técnico, usaremos el modelo arquitectónico, diagramas de colaboración, especificaciones de interfaces, y demás como base para nuestras pruebas. Si estamos probando funciones definidas por los usuarios, utilizaremos las historias de usuario que resultaron del trabajo colaborativo de requisitos anterior.
Si las partes interesadas no comprenden tus modelos, no comprenderán, confiarán ni invertirán en tus pruebas. Incluso puede que no confíen en ti.
Gestión del alcance
La primera actividad en una disciplina de pensamiento sistémico es definir el límite de un sistema. En las pruebas, el primer modelo que definas te ayudará a delimitar el alcance de las pruebas. El siguiente diagrama es un esquema de la arquitectura del sistema – un ‘sistema de sistemas’ – en una organización.
Cada sistema (los círculos concéntricos) se ubica dentro de un área de aplicación como CRM, contabilidad o el sitio web. Todos los sistemas y áreas de aplicación se encuentran dentro del ‘sistema de sistemas’. Por supuesto, no hay detalles en el modelo, pero es evidente cómo cada sistema encaja en la arquitectura general.
Podríamos definir fácilmente el alcance de nuestras pruebas para que sean, por ejemplo, los sistemas ERP.
En el segundo diagrama a continuación, hemos añadido algo más de detalle a la arquitectura de sistemas y sugerido tres formas de definir el alcance de manera más específica.
- Los sistemas sombreados en amarillo son los llamados sistemas de registro. Estos sistemas podrían, por ejemplo, compartir una base de datos, y los cambios en el esquema de la base de datos podrían afectar negativamente a cualquiera de estos sistemas – y estar en el alcance de la prueba.
- Los sistemas encerrados por la línea púrpura podrían compartir alguna funcionalidad o infraestructura común – quizás todos usan un conjunto común de servicios web, el mismo sistema de mensajería o funcionan en el mismo servidor.
- La línea azul discontinua denota un recorrido de usuario que utiliza los sistemas conectados por la línea. Quizá el recorrido de usuario ha cambiado, y nuestro enfoque está en la consistencia y precisión del flujo de datos entre estos sistemas.
Un modelo puede mostrar qué está dentro del alcance de la prueba, pero, igual de importante, qué está fuera del alcance también.
Un modelo ayuda a definir el alcance de una prueba y también a explicar el alcance a las partes interesadas en términos que entiendan, aprecien y (esperemos) aprueben.
Cuando usamos un modelo para definir el alcance, el modelo define el territorio y los elementos dentro del alcance identifican los lugares que pensamos explorar y probar.
Gestión de la cobertura
La medición de la cobertura puede ayudar a que las pruebas sean más manejables. Si no tenemos una noción de cobertura, puede que no podamos contestar preguntas como, '¿qué se ha probado?', '¿qué no se ha probado?', '¿ya hemos terminado?', '¿cuántas pruebas quedan?'. Esto es especialmente problemático para un responsable de pruebas.
La cobertura que planeamos alcanzar es el siguiente paso natural una vez que se define el alcance.
Usamos el modelo de alcance para definir los lugares que probaremos. Nuestro modelo de cobertura dice a las partes interesadas cuán a fondo planeamos probar en esos lugares.
Los modelos de prueba y las medidas de cobertura pueden utilizarse para definir objetivos cuantitativos o cualitativos para el diseño y ejecución de pruebas. En distintos grados, podemos usar estos objetivos para planificar y estimar. También podemos medir el progreso e inferir el nivel de exhaustividad o integridad de las pruebas que planeamos o ejecutamos. Sin embargo, debemos tener mucho cuidado con cualquier medida cuantitativa de cobertura o porcentaje que utilicemos.
Una medida de cobertura (basada en un modelo de prueba formal) puede ser calculada objetivamente, pero no existe ninguna fórmula o ley que diga que X cobertura implica Y calidad o Z confianza. Todas las medidas de cobertura solo dan información indirecta, cualitativa y subjetiva sobre la exhaustividad o integridad de nuestras pruebas. No existe una relación significativa entre la cobertura y la calidad o aceptabilidad de los sistemas.
Los objetivos cuantitativos de cobertura suelen usarse para definir criterios de salida para la finalización de las pruebas, pero estos criterios son arbitrarios. Un objetivo de cobertura más estricto podría generar el doble de elementos a cubrir. Sin embargo, el doble de pruebas a un coste doble no hace que un sistema esté el doble de probado ni el doble de fiable. Tal interpretación es absurda y carente de sentido.
A veces, los modelos formales utilizados para definir y construir un sistema pueden imponerse a los testers para que los utilicen al definir los objetivos de cobertura. En otras ocasiones, los testers pueden contar con poca documentación y tener que inventar sus propios modelos. La selección de cualquier modelo de pruebas y objetivo de cobertura es en cierta medida arbitraria y subjetiva. En consecuencia, los modelos informales de prueba y las medidas de cobertura pueden ser tan útiles como los modelos formales y establecidos.
Ejercicio rápido de creación de modelos
Un ejercicio rápido para finalizar. En los siguientes ejemplos, haz un boceto de cómo crees que se vería el modelo – solo su forma – ya sea como un dibujo/diagrama, una tabla o una lista:
- Los usuarios están interesados en los recorridos de extremo a extremo dentro del sistema.
- Un servicio de mensajería puede estar en cuatro estados: apagado, en funcionamiento, iniciándose y apagándose.
- Un calculador de primas de seguros tiene 40 valores de entrada que, en combinación, influyen en el cálculo; hay dependencias entre algunos valores de entrada.
- Un proceso de extracción/transformación/carga tiene siete etapas. Después de la extracción, cada etapa puede rechazar registros, enviarlos a un archivo de pendientes o transformar y pasar los registros a la siguiente etapa. La última etapa es un proceso de carga, que se encarga de los rechazos. Verifica que se contabilicen todos los registros extraídos.
Suscríbete al boletín de The CTO Club para recibir más ideas sobre pruebas de software.
