1.1. Muchos probadores sabemos que cuando encontramos un defecto, encontraremos muchísimos más defectos cerca. si hemos detectado un defecto en alguna pantalla y sabemos que existen muchos más, es posible que sea conveniente volver a considerar el rumbo de las pruebas posteriores, porque no es el objetivo reportar y reportar y llenar a los desarrolladores de hallazgos o inconsistencias, sino que debemos plantearnos el objetivo de ayudar a construir o generar un software de calidad con el apoyo de todos. Esto es algo que me gusta mucho del testing ágil.
2. Principio: Paradoja del Pesticida
2.1. Si repetimos las mismas pruebas una y otra vez, eventualmente la misma serie de casos de pruebas dejará de encontrar defectos nuevos. los casos de pruebas deben revisarse periódicamente y deben escribirse nuevos casos de pruebas y diferentes, con esto podremos testear distintas partes del software o del sistema con el objetivo de poder detectar más defectos. Si te quedas repitiendo las mismas pruebas en las mismas condiciones no vas a ser efectivo. Los bugs se volverán resistentes a ti, es por eso que deberás cambiar tu pesticida (tu forma de testear) constantemente para poder encontrar nuevos defectos.
3. Principio: Las pruebas dependen del contexto
3.1. Las pruebas dependen del contexto, no es lo mismo probar un software médico, a una página web. un único aplicativo dependerá su funcionamiento si está en un ambiente de pruebas a un ambiente de desarrollo. Es por esto que todo depende del contexto.
4. Principio: La falacia de la ausencia de errores
4.1. el hecho de pruebas no es solamente detectar y corregir los defectos, de nada servirá el sistema si no es usable, o si no cumple con las expectativas o las necesidades de los usuarios finales. Recuerda siempre que no se puede introducir la calidad a través de las pruebas, la calidad tiene que construirse desde el principio.
5. Principio: Las pruebas muestran la presencia de defectos.
5.1. Podemos decir que aunque hemos encontrado demasiados hallazgos durante nuestro proceso de pruebas, y aun cuando hemos realizado varias iteraciones, nunca vamos a decir que el sistema se encuentra al 100% en su calidad de software, y esto lo decimos es porque no podemos estar seguros de que la aplicación ya no tiene defectos. Y de esto se trata este principio, el hecho de que realicemos pruebas no quiere decir que se acaben los defectos. Muchas veces nos hemos encontrado que en Producción siempre sale ese caso atípico que se nos escapó a todos los integrantes del proyecto, es por esto que las pruebas demuestran la presencia de defectos.
6. Principio: Pruebas exhaustivas es imposible
6.1. Normalmente probamos lo más riesgoso o aseguramos cierto porcentaje de calidad en el software. La generalidad de los testers no probamos absolutamente todo, exceptuando creería yo los probadores de la NASA o aparatos médicos, donde la vida de las personas se ve en juego, esto ya es un tema muy delicado que te lleva a pensar que tanto debes invertir en el aseguramiento de la calidad del software, y no obstante nos encontramos con errores que nadie ha detectado, es por esto que no es posible realizar pruebas exhaustivas.
7. Principio: Pruebas Tempranas
7.1. Las pruebas no solo son sobre el software funcionando, podemos empezar desde mucho antes, desde la misma documentación, los probadores tenemos una gran capacidad de análisis, buscando todos los caminos y variantes que se pueden presentar, es por esto que apoyamos mucho con nuestra revisión temprana a la documentación, también durante el proceso de desarrollo de software. Aquí es donde entra en parte la experiencia, y es que los probadores podemos generar los casos de pruebas antes del inicio del desarrollo y allí es donde ahora se ha vuelvo muy importante trabajar con TDD, BDD y ATDD. Por favor incorpora este principio de pruebas tempranas en todos tus proyectos.
