El documento resume 6 principios generales de las pruebas de software: 1) Las pruebas demuestran la presencia de defectos pero no su ausencia, 2) No es posible realizar pruebas exhaustivas debido a la gran cantidad de combinaciones posibles, 3) Es importante realizar pruebas tempranas incluso antes del desarrollo, 4) Cuando se encuentra un defecto es probable que haya otros agrupados cerca, 5) Al repetir las mismas pruebas dejarán de encontrar defectos por lo que es necesario variar las pruebas, y 6) Las p

1. z 1.2. PRINCIPIOS
GENERALES DE LAS
PRUEBAS DE SW
UNIDAD 1
1. Las pruebas
demuestran la
presencia de
defectos.
2. No es posible
realizar pruebas
exhaustivas
3. Pruebas temprana
(Early testing)
4. Agrupamiento de
defectos (Defect
Clustering)
5. Paradoja del
pesticida
6. Las pruebas
dependen del
contexto

2. 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”

3. 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.

4. 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.

5. 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.

6. 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.

7. 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.

8. 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.