Por qué fallan los programas
En resumen: Una persona comete un error, el error deja un defecto en el requisito o en el código, y un defecto que se ejecuta se convierte en un fallo que ve el cliente. Las pruebas buscan fallos, pero no pueden demostrar que no hay defectos.
Problema
¿Quién se equivocó?
La tienda lanza el código promocional «OTONO10»: 10 € de descuento, una vez por cliente. Una semana después, contabilidad ve a un cliente que lo usó en tres pedidos. 30 € en vez de 10 €.
El programador dice: «Lo hice como estaba escrito». En el requisito dice «una vez por pedido». La analista dice: «Así me lo dijo el dueño». El dueño está seguro de que dijo «por cliente».
¿Quién se equivocó? Esa es la pregunta equivocada. Es más útil ver que son tres cosas distintas que ocurren una detrás de otra.
La idea
Error, defecto, fallo
- Un error (error, mistake) es una acción humana: alguien entiende, escribe o hace algo mal. La analista anota «por pedido».
- Un defecto (defect, también bug o fault) es una imperfección en un producto de trabajo, dejada por el error. El defecto aquí está en el requisito. Después pasa al código, porque el programador construye fielmente lo escrito.
- Un fallo (failure) es el momento en que el sistema hace algo distinto de lo esperado mientras funciona. El cliente usa el código tres veces.
La dirección es siempre esta: error → defecto → fallo. El cliente solo ve el fallo. Las pruebas empiezan por él y van hacia atrás.
No todo defecto se convierte en fallo. Si nadie prueba el código una segunda vez, el defecto sigue ahí sin que se vea.
Más precisamente, para curiosos
Así los da el programa de ISTQB CTFL v4.0.1 (sección 1.2.3, «Errores, defectos, fallos y causas raíz»). Un fallo también puede venir de las condiciones del entorno, sin error humano: la radiación o un campo electromagnético pueden dañar el firmware. En la tienda es raro.
En el trabajo, la palabra «bug» significa las tres cosas, y por eso las conversaciones se enredan. «Hay un bug en el código promocional» puede ser el fallo que vio el cliente, o la línea de código que lo causa. En este curso, defecto es siempre la imperfección en el producto de trabajo.
La idea
La causa raíz
¿Por qué se equivocó la analista? Porque el cliente lo dijo por teléfono y nadie lo anotó. Tampoco había un ejemplo: «María hace un pedido hoy con el código y otra vez mañana. ¿Qué pasa?». Con un ejemplo así, «una vez por cliente» y «una vez por pedido» habrían dado respuestas distintas en voz alta.
Esa es la causa raíz (root cause): por qué ocurrió el error. Corregir el requisito y el código arregla este defecto. Corregir la causa raíz (los requisitos se escriben con ejemplos y el dueño los confirma) protege también de los siguientes del mismo tipo.
El objetivo del análisis no es encontrar a un culpable. El objetivo es un proceso que no permita el error una segunda vez.
Pruébalo
Ordena la cadena
Ordénalo desde la causa hasta lo que ve contabilidad.
El cliente dice por teléfono «el código vale una vez por cliente», nadie lo anotaUn cliente usa el código en tres pedidos y recibe tres descuentosEl requisito dice «una vez por pedido»La analista escribe de memoria «una vez por pedido»
Primero está la causa raíz (no hay un requisito anotado), después el error de la analista, después el defecto en el requisito, y por último el fallo que se ve en funcionamiento.
Pruébalo
¿Error, defecto o fallo?
La idea
Un caso de prueba
¿Cómo se detecta el fallo antes que el cliente? Pones el sistema en una situación determinada, haces algo y comparas con lo que debería pasar. Escrito, eso es un caso de prueba (test case):
| Parte | Para el código promocional |
|---|---|
| Precondiciones | El cliente ya usó «OTONO10» en un pedido pagado. |
| Entrada y acciones | Un pedido nuevo de 40 €, con el mismo código. |
| Resultado esperado | Se rechaza el código: «Este código ya se usó». El total sigue en 40 €. |
La parte más importante es el resultado esperado, y viene del requisito, no del programa. Si lo copias de lo que hace hoy el programa, el test confirmará también sus errores.
En el módulo de escenarios el mismo caso se escribirá como «Dado … Cuando … Entonces …». La idea es la misma: un inicio, una acción, una expectativa.
Más precisamente, para curiosos
El glosario de ISTQB define el caso de prueba como un conjunto de precondiciones, entradas, acciones (cuando corresponda), resultados esperados y postcondiciones, desarrollado a partir de una condición de prueba. Una condición de prueba es lo que compruebas («el código promocional vale una vez por cliente»), y los casos de prueba son los ejemplos concretos de ella. Aquí un caso de prueba es algo que también puede ejecutar una persona. Los tests en código de los otros cursos son la misma idea, escrita para una máquina.
La idea
Una prueba muestra, no demuestra
La tienda tiene 200 tests para el carrito y todos pasan. ¿Significa eso que el carrito no tiene defectos?
No. Significa que esos 200 casos funcionan. Prueba a enumerarlos todos: 10 unidades de cada uno de 500 productos, con código promocional o sin él, con cada total, con cada forma de envío. Hay más combinaciones de las que ejecutarás en toda tu vida.
Este es el primero de los siete principios de las pruebas (testing principles): las pruebas pueden mostrar que hay defectos, pero no que no los hay. Un test que pasa reduce la probabilidad de un defecto oculto. No la deja en cero.
La idea
Seis principios más, seis historias
2. Las pruebas exhaustivas son imposibles. No se pueden ejecutar todas las combinaciones del carrito. Por eso se eligen las más importantes: por riesgo, por límites (49,99 €, 50,00 €), con las técnicas del módulo «Técnicas de diseño de pruebas».
3. Probar pronto ahorra tiempo y dinero. La pregunta «¿y con justo 50 €?» en la reunión cuesta un minuto. Después del lanzamiento cuesta una corrección, un test nuevo, una versión nueva y clientes enfadados.
4. Los defectos se agrupan. La mayoría de los defectos de la tienda están en los códigos promocionales y en la cancelación de pedidos: donde hay muchas reglas. Ahí pruebas más.
5. Las pruebas se desgastan. Los mismos tests, ejecutados durante meses, solo detectan lo que siempre han detectado. Los defectos nuevos están en otra parte. Los tests se actualizan y se añaden otros nuevos.
6. Las pruebas dependen del contexto. Una tienda y el software de un hospital no se prueban igual. Incluso el sitio web y la aplicación móvil de una misma tienda tienen riesgos distintos.
7. La falacia de la ausencia de defectos. Un sistema sin defectos conocidos aún puede estar equivocado: si hace lo escrito y lo escrito no es lo necesario. Aquí la verificación pasó, y la validación nunca se hizo.
Más precisamente, para curiosos
Los principios son de ISTQB CTFL v4.0.1, sección 1.3. En inglés: testing shows the presence, not the absence of defects; exhaustive testing is impossible; early testing saves time and money; defects cluster together; tests wear out; testing is context dependent; absence-of-defects fallacy.
En los programas más antiguos, el quinto se llamaba «paradoja del pesticida» (pesticide paradox): como los insectos que se acostumbran al veneno. La agrupación de defectos (el cuarto) es un ejemplo del principio de Pareto: una pequeña parte de los módulos contiene una gran parte de los defectos.
Ejercicio
¿Qué principio?
1. Reconoce el principio. Cada historia es de la tienda. ¿Cuál de los siete principios describe?
Test