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.