Principio 1 – Las pruebas demuestran la presencia de defectos

Un área de aseguramiento de la calidad del software puede demostrar que en el software existen defectos, pero aún después de haber ejecutado varios escenarios de pruebas, ningún tester te puede asegurar que ya no existen bugs en la aplicación. Así mismo, si se ejecutaron pruebas y no se detectaron defectos, esto no es garantía de que el software esté libre de los mismos.

Ningún tester garantiza un software libre de defectos, ¿imaginas cuántas personas hacen pruebas en grandes empresas que crean software? ¡Y aún así se les “pasan” bugs! Si no me crees, revisa la descripción de las actualizaciones que te solicitan las aplicaciones de tu Smartphone.

Principio 2 – Las pruebas exhaustivas no existen

No es posible probar todos los diferentes escenarios de prueba de una aplicación; supongamos que tienes un sistema compuesto de 3 variables donde se pueden almacenar 2 valores diferentes en cada una, para validar que la aplicación se comporta correctamente con todas las casuísticas, tendrías que realizar la validación de 6 casos de prueba, pero ¿qué sistema se compone sólo de 3 variables? ¿Y si consideramos las pre-condiciones? ¿Qué me dices de los diferentes ambientes en donde será utilizada la aplicación?

No intentes probar todas las combinaciones del sistema, en lugar de esto, valida en donde le “duele” más al sistema o bien cuales son las zonas de mayor riesgo y enfócate en esas funcionalidades. También puedes investigar cuáles son las acciones que mayormente realizan o realizarán los usuarios para que lo consideres como estadística para formar tus matrices de prueba.

Principio 3 – Pruebas tempranas

Los defectos detectados al inicio del proceso de desarrollo resultan más baratos de corregir que los encontrados en ambiente productivo, por ello es recomendable incluir al área de testing desde el levantamiento de los requerimientos. Además de obtener el beneficio de una revisión por “pares” desde el inicio, todos aprenden al mismo tiempo sobre los requerimientos de la apliacación a desarrollar.

¿Sabías que a los requerimientos también les puedes hacer pruebas? Un requerimiento mal redactado puede ocasionar serios problemas.

Principio 4 – Agrupación de defectos

La mayoría de los defectos se detectan en una pequeña parte de la aplicación, esa zona es de alto riesgo o delicada. La experiencia nos dice que si encontraste un defecto, es probable que existan más en la misma funcionalidad. El 80% de los defectos se concentra en el 20% de la aplicación (principio de Pareto), esto porque regularmente esa zona es muy compleja o difícil de comprender.

Principio 5 – Paradoja del pesticida

¿Ya ejecutaste el mismo caso de prueba 3 veces? Es muy probable que entonces ya no descubras errores, no porque no seas un buen tester, sino porque después de haber ejecutado el mismo caso de prueba varias veces pierdes el “foco” y declaras las cosas como validadas u obvias (“esto ya lo había probado y si funcionaba”). Si se tiene que probar varias veces un caso de prueba, asegúrate que no lo haga la misma persona. Otra solución es que “renueves” tus casos de prueba, así tendrás una matriz diferente y no verás lo mismo siempre.

¿Paradoja del pesticida? Bueno, esto en relación al combate de los insectos que afectan a la agricultura; les aplican “plaguicida” que en un inicio es efectivo contra ellos, pero después de varias aplicaciones, estos desarrollan mayor resistencia y el veneno termina siendo ineficiente.

 Principio 6 – Las pruebas dependen del contexto

El testing se debe ejecutar de acuerdo a la criticidad de la aplicación, ¿cómo puedes probar una aplicación bancaria de la misma manera en que probaste un formulario de suscripción a un blog? En la segunda aplicación perderás suscriptores por un periodo de tiempo, pero en la primera las pérdidas son mayores, no podrías aplicar la misma estrategia de pruebas.

Principio 7 – Falacia de ausencia de errores

Este último principio te lo diré breve: Puedes crear un software que esté “100% libre de defectos“, pero si a tu usuario no le funciona, la aplicación se vuelve inútil… ¡Vaya pequeño defecto!

Concluyendo…

El aseguramiento de la calidad del software se debe incluir durante el proceso de desarrollo desde el inicio, ambos equipos deben estar en el “mismo entendido” de lo que se está construyendo, así evitarás defectos por mala especificación de requerimientos (o los disminuirás).

Cuando tengas un sistema muy grande o complejo y que el periodo de pruebas sea muy prolongado, opta por cambiar las funcionalidades que ya hayas probado con otros testers, de tal manera de que la misma pantalla no la verifiques más de 3 veces durante la misma semana, de lo contrario, caerás en la paradoja del “pesticida” y tus pruebas resultarán deficientes.

Jamás lograrás probar todos los escenarios de tu aplicación (si pueden existir situaciones), mejor opta por probar las funcionalidades más críticas o que el usuario utilizará mayormente. Si estás probando una aplicación y detectas un defecto, comienza a buscar exhaustivamente por la zona, seguramente existen más, te recomendaría incluso que le dieras una revisada a lo que ya probaste del mismo módulo, quizá se te “coló” alguno.

Cuando planifiques tus pruebas, considera la criticidad del negocio y así mismo haz tu matriz de casos de prueba, no dejes ningún caso importante (lo probaré después) sin meter a la matriz, recuerda que cuando estés ejecutando se te puede olvidar. Y por último, el software es para tu cliente, si a él no le funciona, entonces todo el esfuerzo para crearlo se puede considerar como derrochado.