Cuando comenzamos a realizar pruebas, nos solemos
centrar en el camino feliz del desarrollo, cubriendo las acciones correctas o
las que deben de realizarse en el software que vamos a validar.
El valor más importante a la hora de realizar
pruebas son los caminos que no son felices y que nos pueden ocasionar problemas
si un usuario no hace lo que debe o toquetea más de la cuenta.
Si hablamos de Testing unitario, debemos de
centrarnos en no duplicar las pruebas, que es algo bastante complicado si
llevamos tiempo ya con el software o tenemos una batería importante de pruebas.
Si nos liamos a realizar miles de test y empezamos a duplicarlos, la cobertura
de test descenderá de manera exponencial, ya que, los porcentajes serán altos,
pero el código validado será mucho menor. Eso, sin contar, el esfuerzo invertido
para “nada”.
Para tener cierto orden a la hora de realizar test
unitarios, se puede comenzar con TDD, cubriendo primero lo que queremos hacer
con el código realizado y después cubrir casuísticas extrañas o inesperadas.
Con cada error descubierto, se realizan nuevas pruebas que cubrirán todos esos
trozos de código para que no tengamos el mismo fallo reiteradamente y creemos
regresiones.
Si seguimos esa estrategia, que es bastante
aceptable, lo que haremos es cubrir los caminos felices del software, ya que,
por cada error, realizamos un test unitario para comprobar que no sucede, pero,
¿que pasa con algún otro movimiento o casuística que no tengamos contemplada? Pues aparecen los caminos infelices, aquellos que,
habitualmente no se prueban y que contienen una cantidad de agujeros negros que
no os podéis ni imaginar. Pueden suceder errores si no tenemos un conjunto de
datos excelente, si introducimos cosas que no debemos en los campos adecuados,
si hacemos algo inusual en el software…etc, etc… Esas coberturas de código con Testing
unitario son el verdadero valor de las mismas.
Si hablamos de pruebas funcionales o exploratorias,
es muy importante el obtener esa diferencia. Siempre debemos de cubrir un caso
de prueba de camino feliz, pero tenemos que realizar todas las casuísticas
posibles que se salgan de este camino para descubrir toda la cantidad de
errores que tiene el software.
La realización de la documentación de este tipo de
casuísticas es algo tedioso y pesado, así que es casi mejor, trabajar con pruebas
exploratorias que nos ayuden a probar mucho más rápido y ágil. Estas pruebas
exploratorias se pueden grabar y crear los pasos de manera automática para
automatizar después y de esta manera, cubriremos dos pájaros de un tiro.
Para realizar estas labores, es muy importante que la
persona de QA tenga acceso a toda la documentación y que tenga la habilidad de
sacar toda la información de ella, con todas las casuísticas, caminos, pasos y
casos de prueba adecuados. Por ejemplo, si contamos con una buena batería de
requisitos, podremos sacar una gran cantidad de información para probar y de
esta manera, adecuarla para hacer test automático, unitario, de integración,
exploratorio o ejecuciones funcionales manuales, esto siempre, según se
considere en el proyecto y en nuestra manera de trabajar.
Si queremos mantener la calidad excelente en un producto,
nos debemos de salir de los caminos felices y andar por todo lo que exista a su
alrededor, permitiéndonos ver todos los errores y dar a nuestros clientes una
experiencia de usuario de calidad y con garantía.
Comentarios
Publicar un comentario