Por qué pronto
En resumen: Un defecto en un requisito cuesta una palabra si se caza al leer, y una semana de trabajo si se caza después del lanzamiento. Las pruebas estáticas (revisiones y análisis estático) buscan defectos sin ejecutar el programa. Encuentran el propio defecto, mientras que las pruebas dinámicas ven el fallo. Las dos no se sustituyen, se complementan.
Problema
Una palabra, cinco veces
Recuerda el requisito «envío gratis para más de 50 €», cuando el dueño quería «desde 50 € inclusive». El defecto es una palabra. Veamos cuánto cuesta según cuándo lo encuentres.
- Al leer el requisito: el analista pregunta «¿y con exactamente 50,00 €?». El arreglo es una palabra. Cinco minutos.
- En la conversación sobre la historia: se añade el ejemplo «50,00 € → gratis». Cinco minutos más.
- Al probar el programa terminado: el programador corrige el código, el tester vuelve a probar, el lanzamiento se retrasa un día.
- Después del lanzamiento: los clientes han pagado 4,90 € que no debían. Se reembolsa dinero, sale un correo, la corrección es urgente, y algunos ya no confían en la tienda.
El defecto es el mismo. El trabajo construido encima crece con cada paso.
La idea
El coste de un defecto según la fase
Cuanto más tarde se encuentra un defecto, más cosas hay que arreglar junto con él. El requisito ya se ha convertido en código, el código en pruebas, las pruebas en un informe, y el programa recibe pedidos. Esto se llama el coste de un defecto según la fase.
| Cuándo se encuentra | Qué hay que rehacer |
|---|---|
| al leer el requisito | la palabra en el documento |
| en la conversación sobre los criterios | la palabra y un ejemplo |
| al probar el programa terminado | el código, las pruebas, un lanzamiento nuevo |
| después del lanzamiento | todo lo anterior, más el dinero, los clientes y la confianza |
Por eso las pruebas empiezan pronto. No cuando hay un programa, sino cuando está la primera frase. Es también uno de los siete principios: las pruebas tempranas ahorran tiempo y dinero.
Más precisamente, para curiosos
ISTQB CTFL v4.0.1 dice en el capítulo sobre las pruebas estáticas que los defectos encontrados pronto suelen ser mucho más baratos de arreglar que los encontrados tarde en el ciclo de vida. La misma idea está detrás de la palabra shift-left, que encontrarás más adelante en el curso.
Se citan a menudo multiplicadores exactos: «10 veces en el código, 100 veces después del lanzamiento». Ten cuidado con ellos. Vienen de estudios de hace décadas (el más conocido se asocia a Barry Boehm), y sus números se discuten. Por ejemplo, Laurent Bossavit en «The Leprechauns of Software Engineering» rastrea de dónde vienen y qué pocos datos hay detrás. La dirección es la experiencia de todos los equipos. El multiplicador exacto depende del proyecto.
La idea
Estáticas y dinámicas
Hay dos formas de buscar defectos.
- Pruebas dinámicas: ejecutas el programa y miras qué hace. El tester pone 50,00 € en el carrito y ve 4,90 €. Eso es un fallo. Después alguien tiene que encontrar el defecto que lo causa.
- Pruebas estáticas: compruebas un producto de trabajo sin ejecutarlo. Lees el requisito, el modelo, el código o las pruebas, y encuentras el propio defecto, directamente.
Las pruebas estáticas tienen dos formas. Una revisión: la gente lee y comenta. Un análisis estático: una herramienta lee el código o el modelo y busca problemas conocidos, por ejemplo una variable que nunca se usa, o código al que el programa no puede llegar nunca.
Algunas cosas solo se cazan de forma estática: un defecto en un requisito antes de que haya código; dos requisitos que se contradicen; código que funciona pero que nadie puede mantener. Otras solo se cazan de forma dinámica: una página lenta con 500 clientes, o dos sistemas que no se entienden. Por eso las dos se complementan.
Más precisamente, para curiosos
CTFL v4.0.1 (capítulo 3) enumera las diferencias: las pruebas estáticas encuentran defectos directamente, mientras que las dinámicas provocan fallos a partir de los cuales se rastrea después el defecto. Las pruebas estáticas pueden aplicarse también a productos de trabajo que no se pueden ejecutar (documentos, modelos), y pueden cazar cualidades que no dependen de la ejecución, como la mantenibilidad. Las pruebas dinámicas pueden cazar cosas que solo se muestran al ejecutar, como el desempeño.
El análisis estático suele ejecutarse automáticamente con cada cambio del código. El compilador que dice «esta variable no está inicializada» ya es una herramienta así.
Pruébalo
¿Estáticas o dinámicas?
La idea
Qué se revisa
Casi todo lo que se puede leer y entender:
- requisitos, historias y criterios de aceptación;
- modelos: procesos, máquinas de estados, tablas de decisión;
- código;
- casos de prueba y escenarios;
- planes, contratos, manuales de usuario.
Revisar un requisito es especial. Es a la vez verificación (¿está escrito correctamente, sin ambigüedad, de forma verificable?) y validación (¿es esta la necesidad?). Cuando el dueño lee «más de 50 €» y dice «no, yo quería desde 50 €», eso es validación. Cuando el tester pregunta «¿y con exactamente 50,00 €?», eso es verificación.
Una revisión tiene también un límite. Compara el producto de trabajo con lo que la gente sabe. Si nadie sabe decir qué tiene que hacer el sistema, la revisión no tiene con qué comparar. Entonces lo primero es la conversación, no la lectura.
Pruébalo
Revisa los criterios
Los criterios para cancelar un pedido, antes de empezar el trabajo. Marca los problemas y elige el tipo de cada uno.
Pulsa las palabras que son un problema; otra vez para quitar la marca. Con las flechas se pasa de palabra en palabra.
Los problemas del texto
- «en cualquier momento» contradictorio: C-2 dice que un pedido enviado no se puede cancelar. Las dos cosas no pueden ser ciertas para el mismo pedido enviado. El programador construirá una, el tester comprobará la otra.
- «no se puede cancelar» contradictorio: Contradice a C-1. La regla de la tienda es «un pedido pagado se puede cancelar antes de enviarse», así que es C-1 el que hay que corregir: «hasta que se envíe».
- «rápido» no verificable: ¿En cuántos días? Sin un número ninguna prueba puede fallar. Por ejemplo: «dentro de los 14 días siguientes a la cancelación».
Dos minutos de lectura salvaron el error de la lección «Criterios de aceptación»: cancelar un pedido que ya está con la mensajería. Arreglado: «C-1. El cliente puede cancelar su pedido mientras no se haya enviado». C-2 se queda. «C-3. Cuando se cancela un pedido pagado, el dinero se reembolsa dentro de los 14 días siguientes».
La idea
Retroalimentación temprana
Hay una forma aún más sencilla de cazar pronto el defecto «más de 50 €»: enseñar algo al dueño. Un ejemplo, un prototipo del carrito, una tabla de costes de envío para 49,99, 50,00 y 50,01 €. Lo mira y dice «este está mal».
La retroalimentación frecuente de las partes interesadas protege del defecto más caro: un producto bien construido, pero que no es el que hacía falta. Cuanto menos a menudo preguntas, más trabajo va en la dirección equivocada antes de que nadie lo note.
Por eso las revisiones no son solo cosa de QA. El dueño, el almacén y contabilidad leen los requisitos que les conciernen. Verán cosas que tú no puedes ver.
Más precisamente, para curiosos
CTFL v4.0.1 llama a esto retroalimentación temprana y frecuente de las partes interesadas (sección 3.2). Ayuda a que los requisitos se entiendan de la misma manera y a ver pronto los problemas. Sin ella, el equipo corre el riesgo de construir un producto que no cubre la necesidad, y de descubrirlo solo en la aceptación.
Ejercicio
Lo que cuesta
1. El camino del defecto. Ordena los momentos en que se puede cazar el defecto «más de 50 €», del más barato al más caro.
Ordena del lugar más barato al más caro donde se puede cazar el defecto.
Al leer el requisito: «¿y con exactamente 50,00 €?»Después del lanzamiento: la queja de un cliente que pagó 4,90 €En la revisión del código: «> 50» no es «desde 50 inclusive»Al probar el programa terminado: un carrito de 50,00 €En la conversación sobre los criterios: el ejemplo «50,00 € → gratis»
Cada línea carga con todo lo de la anterior. En la primera, el defecto solo está en el texto. En la última, está en el código, en las pruebas, en los pedidos y en los correos de los clientes.
Test