1.

Las pruebas
demuestran la
presencia de defectos.

2. No es posible realizar
pruebas exhaustivas
UNIDAD 4 3. Pruebas temprana
(Early testing)

z PRINCIPIOS 4. Agrupamiento de
defectos (Defect
GENERALES DE LAS Clustering)

PRUEBAS DE SW 5. Paradoja del

pesticida
6. Las pruebas
dependen del contexto

7. La falacia de la
ausencia de errores.
z
1. LAS PRUEBAS DEMUESTRAN LA
PRESENCIA DE DEFECTOS
 Aún cuando se hayan encontrado varios hallazgos de
problemas durante nuestro proceso de pruebas, y se hayan
realizado varias iteraciones, nunca se podrá decir que el
sistema se encuentra al 100% en su calidad de software, y esto
es porque no podemos estar seguros de que la aplicación ya no
tiene defectos.
 El hecho de que realicemos pruebas no quiere decir que se
acaben los defectos.
“Las pruebas muestran los defectos, no la ausencia de ellos”
z
2. NO ES POSIBLE REALIZAR
PRUEBAS EXHAUSTIVAS
 Es muy complicado hacer absolutamente todas las
combinaciones de casos posibles para poder probar un
aplicativo, aunque quizás no sea imposible.
 Normalmente se realizan pruebas de lo más riesgoso o se
asegura cierto porcentaje de calidad en el software.
 Existen áreas que manejan vidas o los costos serían excesivos
(NASA) por lo que las pruebas deberían ser muy amplias, sin
embargo, se encuentran errores que nadie ha detectado, es por
esto que no es posible realizar pruebas exhaustivas.
z
3. PRUEBAS TEMPRANAS (EARLY
TESTING)

 Las pruebas no se realizan solo sobre el software funcionando,

ya que incluso se puede hacer una revisión temprana de la
documentación.
 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 y BDD.
 Actualmente es muy importante incorporar este principio de
pruebas tempranas en todos tus proyectos.
z
4. AGRUPAMIENTO DE DEFECTOS
(DEFECT CLUSTERING)

 Cuando se encuentra un defecto, encontraremos muchísimos

más defectos cerca.
 Se recomienda a los tester ser flexibles en estos casos, es
decir, si se ha detectado un defecto en alguna pantalla y se
sabe que existen muchos más, es posible que sea conveniente
volver a considerar el rumbo de las pruebas posteriores.
z
5. PARADOJA DEL PESTICIDA

 Si repetimos las mismas pruebas una y otra vez, eventualmente la

misma serie de casos de pruebas dejará de encontrar defectos nuevos.
 Para superar esta “paradoja del pesticida”, 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.
z
6. LAS PRUEBAS DEPENDEN DEL
CONTEXTO

 Las pruebas dependen del contexto, es decir, no es lo mismo

probar un software médico, a una página web o hasta un carrito
de compras.
 Por ejemplo, dependerá su funcionamiento si está en un
ambiente de pruebas a un ambiente de desarrollo. Es por esto
que todo depende del contexto, no es lo mismo caminar 1
Kilómetro subiendo una montaña rocosa o si es solo un paso
por la playa.
z
7. LA FALACIA DE LA AUSENCIA
DE ERRORES
 Este punto es uno de los más importantes, porque 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. 
 Por favor nunca digas que por el mero hecho de que el software que
estés probando ya no le encuentres errores quiera decir que todo está
bien, porque no nos podemos olvidar nunca del usuario final, que es lo
que quiere, si le sirve la aplicación que se ha construido, y algo muy
personal que deseo añadir, es si cumplimos con la experiencia de usuario
que se desea. Recuerda siempre que no se puede introducir la calidad a
través de las pruebas, la calidad tiene que construirse desde el principio.