Testing Manual, Ágil y con Herramientas

Verificar vs Validar
1.1.1 Objetivos Característicos de la Prueba
Para cualquier proyecto dado, los objetivos de prueba pueden incluir:
• ……….
• Verificar el cumplimiento de todos los requisitos especificados.
• Validar si el objeto de prueba está completo y funciona como los usuarios y otros implicados
esperan
• ……….

Debugging = Depuración
1.1.2 Prueba y Depuración
La prueba y la depuración son diferentes.
La ejecución de pruebas puede mostrar fallos causados por defectos en el software. La
depuración es la actividad de desarrollo que encuentra, analiza y corrige dichos defectos. La
prueba de confirmación posterior comprueba si las correcciones han resuelto los defectos. En
algunos casos, los probadores son responsables de la prueba inicial y la prueba de
confirmación final, mientras que los desarrolladores realizan la depuración y la prueba de
componente asociada. Sin embargo, en el desarrollo Ágil y en algunos otros ciclos de vida, los
probadores pueden estar involucrados en la depuración y la prueba de componente. La norma
ISO (ISO/IEC/IEEE 29119-1) contiene información adicional sobre conceptos de la prueba de
software.

1
Testing Manual, Ágil y con Herramientas

Independencia de las pruebas

5.1.1 Prueba Independiente
Las tareas de prueba pueden ser realizadas por personas que desempeñan un rol de prueba
específico, o por personas que desempeñan otro rol (por ejemplo, clientes). Un cierto grado
de independencia, a menudo, hace que el probador sea más efectivo para encontrar defectos
debido a las diferencias entre los sesgos asociados al conocimiento del autor y del probador
(ver sección 1.5). Sin embargo, la independencia no es un sustituto de la familiaridad, y los
desarrolladores pueden encontrar de forma eficiente muchos defectos en su propio código.
Los grados de independencia en la prueba incluyen los siguientes (desde un bajo nivel de
independencia a un alto nivel): • No hay probadores independientes; la única forma de prueba
disponible es que los desarrolladores prueben su propio código. • Desarrolladores
independientes o probadores dentro de los equipos de desarrollo o del equipo del proyecto;
esta situación podría ser que desarrolladores prueben los productos de sus compañeros. •
Equipo o grupo de prueba independiente dentro de la organización, que informa a la dirección
del proyecto o a la dirección ejecutiva. • Probadores independientes de la organización de
negocio o de la comunidad de usuarios, o con especializaciones en tipos específicos de prueba
tales como usabilidad, seguridad, rendimiento, cumplimiento/normativo o portabilidad. •
Probadores independientes externos a la organización, ya sea que trabajen en sus
instalaciones (internalización55) o fuera de ellas (externalización56).

Principios de las pruebas

1.3 Siete Principios de la Prueba
En los últimos 50 años se han sugerido una serie de principios del proceso de prueba que
ofrecen directrices generales comunes para toda prueba. 1. La prueba muestra la presencia
de defectos, no su ausencia La prueba puede mostrar la presencia de defectos, pero no puede
probar que no hay defectos. La prueba reduce la probabilidad de que queden defectos no
descubiertos en el software pero, incluso si no se encuentran defectos, el proceso de prueba
no es una demostración de la corrección. 2. La prueba exhaustiva es imposible No es posible
probar todo (todas las combinaciones de entradas y precondiciones) excepto en casos
triviales. En lugar de intentar realizar pruebas exhaustivas se deberían utilizar el análisis de
riesgos, las técnicas de prueba y las prioridades para centrar los esfuerzos de prueba. 3. La

2
Testing Manual, Ágil y con Herramientas

prueba temprana ahorra tiempo y dinero Para detectar defectos de forma temprana, las
actividades de prueba tanto estáticas como dinámicas deben iniciarse lo antes posible en el
ciclo de vida de desarrollo de software. La prueba temprana a veces se denomina
desplazamiento hacia la izquierda8. La prueba temprana en el ciclo de vida de desarrollo de
software ayuda a reducir o eliminar cambios costosos (ver sección 3.1). 4. Los defectos se
agrupan En general, un pequeño número de módulos contiene la mayoría de los defectos
descubiertos durante la prueba previa al lanzamiento, o es responsable de la mayoría de los
fallos operativos. Las agrupaciones de defectos previstas y las agrupaciones de defectos reales
observadas en la prueba o producción son una aportación importante a un análisis de riesgos
utilizado para centrar el esfuerzo de la prueba (como se menciona en el principio 2)