Escribir escenarios de atributos de calidad que se puedan probar

Por qué escenarios

La Sección 2.2 te dio el vocabulario de las cualidades; esta sección te da la gramática. El nombre de una cualidad por sí solo, como rendimiento o seguridad, no permite diseñar ni probar nada. Ni siquiera basta con un número por sí solo: '2 segundos' no significa nada hasta que sabes para qué operación, con qué carga, medido dónde y para qué proporción de solicitudes. El escenario de atributo de calidad, desarrollado en el Software Engineering Institute (SEI) y expuesto por Len Bass, Paul Clements y Rick Kazman en Software Architecture in Practice, resuelve esto obligando a que todo requisito de calidad adopte la misma forma de seis partes.

La idea es sencilla. Toda cualidad se manifiesta cuando algo le ocurre a un sistema: una avalancha de usuarios, una caída, una solicitud de cambio, un ataque. Un escenario nombra ese evento, las circunstancias, la parte del sistema afectada, lo que debe ocurrir y cómo sabrás que ocurrió lo bastante bien. Es breve (normalmente de una a tres frases), concreto y comprobable. Y como todas las cualidades usan la misma forma, los escenarios de rendimiento, seguridad y modificabilidad pueden figurar uno junto a otro en una sola lista priorizada.

Las seis partes

Las seis partes son la fuente del estímulo, el estímulo, el artefacto, el entorno, la respuesta y la medida de la respuesta. Apréndelas en ese orden, porque juntas cuentan una pequeña historia: alguien o algo hace algo a una parte del sistema en ciertas condiciones; el sistema hace algo, y lo medimos así. El estímulo y la medida de la respuesta son las dos partes que más a menudo se olvidan, y son las dos que más importan.

El entorno merece especial atención porque el mismo estímulo puede exigir respuestas muy distintas en condiciones distintas. La caída de un servidor durante el funcionamiento normal puede requerir una conmutación por error automática en menos de un minuto; la misma caída durante una ventana de mantenimiento planificada puede ser aceptable con una recuperación manual. Una solicitud de cambio en tiempo de diseño (antes del lanzamiento) cuesta mucho menos que el mismo cambio cuando ya se han acumulado datos en producción. Escribir el entorno de forma explícita evita que se comparen escenarios que en realidad tratan de situaciones distintas.

El artefacto importa por una razón parecida. 'El sistema responde en menos de 200 ms' oculta qué parte es responsable. Nombrar el artefacto (el servicio de búsqueda, el API gateway, el cliente móvil) indica al equipo dónde deben hacerse el trabajo de diseño y la medición. Para algunas cualidades, como la modificabilidad y la desplegabilidad, el artefacto puede ser el código, la configuración o el pipeline de entrega en lugar de un componente en ejecución.

Escenarios generales y concretos

Bass, Clements y Kazman distinguen dos tipos. Un escenario general es independiente del sistema: para un atributo de calidad, enumera los valores típicos que puede tomar cada parte. Para la disponibilidad, por ejemplo, las fuentes pueden ser internas o externas, personas, hardware, software o infraestructura; los estímulos pueden ser una caída, una omisión, una temporización incorrecta o una respuesta incorrecta; las respuestas pueden ser detectar, registrar, recuperar, enmascarar o degradar; y las medidas pueden ser el tiempo de detección, el tiempo de reparación, el porcentaje de disponibilidad o la proporción de solicitudes atendidas.

Un escenario concreto elige valores específicos para un sistema determinado: 'la base de datos principal de pedidos se cae durante el funcionamiento normal; la réplica toma el relevo y las escrituras se reanudan en menos de 60 segundos sin perder ningún pedido confirmado'. Los escenarios generales son plantillas y listas de comprobación; los escenarios concretos son requisitos. Usas el escenario general para asegurarte de haber considerado las fuentes, los estímulos y las medidas adecuados, y luego escribes el puñado de escenarios concretos que importan para tu sistema.

De afirmaciones vagas a escenarios comprobables

La mayoría de los requisitos de calidad nacen como adjetivos. La habilidad consiste en hacer las preguntas que convierten cada adjetivo en un escenario: ¿qué operación?, ¿provocada por quién?, ¿con qué frecuencia o en qué cantidad?, ¿en qué condiciones?, ¿qué debe ocurrir?, ¿qué número nos dice que funcionó? La tabla muestra pares típicos de antes y después. Observa que las versiones de 'después' a veces revelan que la parte interesada quería decir varias cosas distintas, que pasan a ser varios escenarios.

Ejemplos de escenarios para seis cualidades

Los ejemplos siguientes usan una misma tienda en línea para que veas cómo se ven distintas cualidades en el mismo formato. Cada uno está escrito de forma compacta, con las seis partes etiquetadas; en la práctica, los equipos suelen escribirlos en una o dos frases.

Vale la pena fijarse en dos rasgos de estos ejemplos. Primero, los escenarios no tratan solo del software en ejecución. Los escenarios de modificabilidad y desplegabilidad tienen como fuentes a desarrolladores y product owners, y sus medidas son el esfuerzo, el tiempo transcurrido y el alcance del cambio. Segundo, las buenas medidas suelen combinar un número de velocidad con un número de corrección: 'en menos de 60 segundos' y 'ningún pedido confirmado perdido'. Una conmutación por error rápida que pierde datos no es lo que quería el negocio.

Errores comunes

Al revisar cientos de escenarios escritos por equipos aparecen los mismos errores una y otra vez. Cada uno hace que un escenario sea imposible de probar o engañoso.

De los escenarios a las pruebas de aceptación y las funciones de aptitud

Un escenario bien escrito ya es la mayor parte de una prueba. La fuente y el estímulo te dicen qué carga o qué evento generar, el entorno te dice cómo preparar la prueba, el artefacto te dice qué observar y la medida de la respuesta da la condición para aprobarla. Un escenario de rendimiento se convierte en una prueba de carga; un escenario de disponibilidad, en un simulacro de conmutación por error o un experimento de caos; un escenario de modificabilidad, en una revisión de cuánto código tocó un cambio de muestra y cuánto tardó; un escenario de seguridad, en un caso de prueba de penetración.

El siguiente paso es seguir comprobando. Una función de aptitud (fitness function), término popularizado por Neal Ford, Rebecca Parsons y Patrick Kua en Building Evolutionary Architectures, es cualquier comprobación automatizada o repetible de en qué medida el sistema cumple un objetivo arquitectónico. Ejecutada en el pipeline de entrega o sobre la telemetría de producción, convierte un escenario de una prueba de aceptación puntual en una protección permanente: la compilación falla, o salta una alerta, cuando la cualidad se desvía. El Capítulo 11 trata las funciones de aptitud en profundidad en Funciones de aptitud y arquitectura evolutiva.

# A performance scenario expressed as an automated check (illustrative)
# Scenario: at 300 searches/s, p95 <= 400 ms and p99 <= 1000 ms.
import statistics

def check_search_latency(latencies_ms, p95_target=400, p99_target=1000):
    cuts = statistics.quantiles(latencies_ms, n=100)  # 99 cut points
    p95, p99 = cuts[94], cuts[98]
    assert p95 <= p95_target, f"p95 {p95:.0f} ms exceeds {p95_target} ms"
    assert p99 <= p99_target, f"p99 {p99:.0f} ms exceeds {p99_target} ms"
    return p95, p99

# latencies_ms comes from a load test that replays 300 searches per second
# for ten minutes against a production-like environment.

Cómo usan los escenarios los profesionales

En la práctica, los equipos rara vez escriben largas tablas de escenarios de seis partes para todo. Escriben un número reducido, a menudo de diez a treinta para un sistema de cierta envergadura, para las cualidades que son arquitectónicamente significativas, y los guardan donde todos puedan verlos: en el documento de arquitectura (la sección 10 de arc42 pide exactamente esto), en el backlog como criterios de aceptación o en un tablero de calidad compartido. Algunos equipos usan una forma más corta; el proyecto Q42 de Gernot Starke, por ejemplo, recomienda una estructura compacta de contexto, desencadenante y criterios de aceptación. La forma importa menos que la disciplina: toda cualidad importante tiene un estímulo, un contexto y un número.

Los escenarios también sirven de motor a los métodos de evaluación. El Quality Attribute Workshop y el Architecture Tradeoff Analysis Method (ATAM), ambos del SEI, recogen y priorizan escenarios con las partes interesadas y después ponen a prueba la arquitectura frente a los más importantes. La Sección 2.8 muestra cómo se recogen los escenarios y se clasifican en un árbol de utilidad.