Pruebas basadas en la experiencia
En resumen: La experiencia sabe dónde suelen estar los errores: el cero, lo negativo, lo muy grande, el doble clic, la medianoche, los restos de la lógica vieja. La predicción de errores lo convierte en ataques. Las pruebas exploratorias aprenden el sistema mientras lo prueban, con una misión, en una sesión de tiempo limitado, con notas. Una lista de comprobación guarda lo que el equipo ha aprendido. Las tres encuentran lo que la regla no dice, y por eso complementan a las demás técnicas.
Problema
Diez minutos, tres errores
El envío se ha probado con particiones y límites. Los descuentos, con una tabla de decisión. El pedido, con sus transiciones. Todo pasa.
Una compañera de soporte, que ha trabajado en tres tiendas en línea, se sienta diez minutos con él. Pulsa «Pagar» dos veces seguidas: dos pedidos, dos pagos. Introduce el código con un espacio delante: «El código ha caducado», aunque no ha caducado. Pone 150 € en el carrito y paga 4,90 € de envío.
Ninguno de los tres errores sale de una regla. Salen de la experiencia de lo que suele romperse.
La idea
Técnicas basadas en la experiencia
El último grupo de técnicas no parte de la regla ni parte del código. Parte de la experiencia del tester: qué errores ha visto, dónde, en qué sistemas.
- Predicción de errores: pruebas dirigidas a los lugares donde, por experiencia, suele haber errores.
- Pruebas exploratorias: aprendes el sistema mientras lo pruebas, y cada resultado orienta la siguiente prueba.
- Pruebas con listas de comprobación: la experiencia del equipo, escrita en forma de preguntas.
Encuentran lo que la regla no dice. Su debilidad es que dependen de la persona y no dan ninguna medida de «cuánto está cubierto». Por eso complementan las técnicas de las lecciones anteriores en lugar de sustituirlas.
La idea
Predicción de errores
Los testers con experiencia llevan una lista en la cabeza: dónde suele haber un error. Una lista para una tienda:
- cero y vacío: un carrito vacío, un campo de código vacío, 0 unidades;
- negativo y absurdo: -1 unidad, un total de 999 999 €;
- muy grande: un pedido de 250 €, cuando todas las pruebas llegan hasta 80 €;
- texto escrito de otra manera: un código en minúsculas, con un espacio delante, pegado con un salto de línea;
- una acción repetida: un doble clic en «Pagar», «atrás» después de pagar, el mismo código en dos pestañas;
- tiempo: la medianoche del último día del código, zonas horarias, el 29 de febrero;
- restos: lógica vieja que nadie quitó («desde 100 € otra vez 4,90»);
- lo que queda después de un error: ¿un rechazo vacía el carrito?, ¿queda a medias un pedido?
Cuando la lista se pasa de forma sistemática contra el sistema, cada línea se convierte en un ataque (fault attack). Algunos abren preguntas que la regla no responde: ¿debe valer un código en minúsculas? Eso no lo decide el tester, lo decide el dueño.
Más precisamente, para curiosos
ISTQB CTFL v4.0.1 describe las técnicas basadas en la experiencia en la sección 4.4: predicción de errores (con los ataques de fallos como manera sistemática de aplicarla), pruebas exploratorias y pruebas con listas de comprobación. La lista de conjeturas sale de la experiencia del tester, del historial de defectos del sistema y de los tipos de error conocidos en sistemas parecidos.
Pruébalo
Ataque: cero y mucho
De la lista de ataques toma «cero» y «muy grande». Escríbelos como pruebas del envío.
La regla: El envío es gratis en un pedido desde 50 € (incluidos), si no, cuesta 4,90 €. Un carrito vacío no se puede pedir.
| Entrada | Esperado | El sistema correcto | |||
|---|---|---|---|---|---|
| # | Total del carrito | Rechazado | Envío | ||
Una celda de resultado vacía no se comprueba. Los importes se escriben como 49,99.
Solución
| Total del carrito | Rechazado | Envío |
|---|---|---|
| 0 | sí | |
| 250 | no | 0 |
0 € atrapa el carrito vacío que paga envío. 250 € atrapa el resto de la tarifa vieja, en la que desde 100 € el envío vuelve a ser 4,90 €. Según la regla 70 € y 250 € son una misma partición, así que las particiones y los límites no sugieren la segunda prueba. La experiencia sí: «todo lo que pasa de algo» a menudo tiene otro «pasa de algo» olvidado en el código.
La idea
Pruebas exploratorias
En las pruebas exploratorias no escribes los casos de prueba de antemano. Aprendes el sistema, diseñas y ejecutas las pruebas a la vez. Si ves algo raro, la siguiente prueba va allí.
No significa «hacer clic al azar». Tres cosas hacen que funcione en lugar de ser un paseo:
- Una misión (charter): un objetivo para la sesión. Una plantilla práctica: «Explora [qué] con [qué] para descubrir [qué]». Por ejemplo: «Explora el código promocional con códigos caducados, usados y en minúsculas para descubrir cómo le dice la tienda al cliente por qué el código no se aplica».
- Una sesión de tiempo limitado: normalmente de 60 a 90 minutos, sin interrupciones, solo sobre la misión. Si ves algo fuera de ella, lo anotas para una sesión posterior.
- Notas: qué probaste, cómo, qué encontraste, qué preguntas tienes. Al final hay una puesta en común (debrief) con el responsable de pruebas: qué se encontró, qué queda, cuál es la siguiente misión.
Más precisamente, para curiosos
La plantilla «Explora … con … para descubrir …» es del libro «Explore It!» de Elisabeth Hendrickson (2013). Probar en sesiones con misiones y puestas en común (session-based test management) lo describieron Jonathan y James Bach hacia el año 2000. CTFL v4.0.1 dice que las pruebas exploratorias son más útiles cuando la especificación es pobre o inadecuada, hay poco tiempo, o como complemento de técnicas más formales. Y que funcionan mejor con testers con experiencia que conocen el dominio.
Pruébalo
La misión y las notas
La idea
Pruebas con listas de comprobación
Una lista de ataques en la cabeza de una compañera ayuda a un equipo. Escrita, ayuda a todos. Las pruebas con listas de comprobación pasan una lista de preguntas o condiciones contra el sistema.
Una lista para cada formulario nuevo de la tienda:
- un campo vacío, el texto más largo permitido, un carácter más;
- espacios al principio y al final, minúsculas y mayúsculas;
- cirílico, latino, caracteres especiales;
- un doble clic en el botón, «atrás» después de enviar;
- con el teclado, sin ratón; con un lector de pantalla;
- el mensaje de error dice qué hay que corregir.
Es pariente de la lista de comprobación de las revisiones, solo que para el sistema en marcha y no para el documento. Y tiene el mismo riesgo: una lista vieja se sigue de forma mecánica, y los errores nuevos se le escapan. Por eso se actualiza con cada defecto que se coló.
Pruébalo
La sesión
Ordena una sesión exploratoria desde la misión hasta el siguiente paso.
El siguiente paso: informes de defecto, preguntas al dueño, misiones nuevasLa misión: qué, con qué y qué buscasLa puesta en común: con el responsable de pruebas, qué se encontró y qué quedaLa sesión: de 60 a 90 minutos sin interrupciones, solo sobre la misiónLas notas: qué se probó, hallazgos, preguntas, ideas
La misión va antes de la sesión, las notas durante ella, la puesta en común después. Los hallazgos de la puesta en común se convierten en informes de defecto, preguntas al dueño y misiones nuevas. Así explorar no termina en «le eché un vistazo».
Ejercicio
Ataques al límite
1. Lo negativo y lo que queda. Los dos ataques de la lista: una cantidad negativa y «qué queda en el carrito después de un rechazo».
Escribe los ataques al límite del carrito: una cantidad negativa y añadir por encima del límite. Comprueba también lo que queda en el carrito.
La regla: En el carrito puede haber como mucho 10 unidades de un producto. Añadir por encima de 10 se rechaza con un mensaje, y el carrito queda igual. Se añade al menos 1 unidad.
| Entrada | Esperado | El sistema correcto | ||||
|---|---|---|---|---|---|---|
| # | En el carrito | Añado | Rechazado | En el carrito después | ||
Una celda de resultado vacía no se comprueba. Los importes se escriben como 49,99.
Solución
| En el carrito | Añado | Rechazado | En el carrito después |
|---|---|---|---|
| 3 | -1 | sí | 3 |
| 8 | 5 | sí | 8 |
(3, añadir -1) atrapa la versión que rechaza solo el 0 y deja que una cantidad negativa quite unidades. (8, añadir 5) se rechaza, y el carrito tiene que quedarse en 8. Si no compruebas lo que queda, la versión que vacía el carrito al rechazar pasa: el rechazo está, y el cliente pierde todo lo que eligió.
Test