Uno de los trabajos en Grupo, en la Universidad Catolica de Honduras, Campus San Isidro en La Ceiba.

3. • La prueba es un proceso
de ejecución de un
programa con la intención
de descubrir un error.
• Un buen caso de prueba
es aquel que tiene una alta
probabilidad de mostrar un
error no descubierto hasta
entonces.
• Una prueba tiene éxito si
descubre un error no
detectado hasta entonces.

4. • A todas las pruebas se les debería
poder hacer un seguimiento has los
requisitos del cliente.
• Las pruebas debería planificarse
mucho antes de su inicio.
• El principio de Pareto es aplicable a
la prueba del Software: el 80% de
todos los errores descubiertos
durante las pruebas surgen al hacer
un seguimiento de sólo el 20% de
todos los módulos del programa.
• Las pruebas deberían empezar por lo pequeño y progresar
hacia lo grande.
• No son posible las pruebas exhaustivas.
• Para ser más efectivas, las pruebas deberían ser conducidas
por un equipo independiente.

5. • Es simplemente lo fácil que se puede probar un programa de
computadora. Como la prueba es tan profundamente difícil, merece
la pena saber que puede hacer para hacerlo más sencillo.
Debe existir una lista de comprobación que proporcione un
conjunto de características que llevan a un software fácil de probar.

6. • Operatividad: Cuanto mejor funcione más
eficientemente se pude probar.
• Observabilidad: Lo que ves es lo que pruebas.
• Controlabilidad: Cuanto mejor podamos controlar el
software, más se puede automatizar y optimizar.
• Capacidad de Descomposición: Controlando el
ámbito de las pruebas, podemos aislar más
rápidamente los problemas y llevar a cabo mejores
pruebas de regresión.

7. • Simplicidad: Cuanto menos haya que probar,
más rápidamente podremos probarlo.
• Estabilidad: Cuanto menos cambios, menos
interrupciones a las pruebas.
• Facilidad de comprensión: Cuanta más información
tengamos, más inteligentes serán las pruebas.

9. Cualquier programa puede ser probado bajo 2 esquemas diferentes:
1) Conociendo la función del producto (programa), demostrar que
esa función anda bien. Este caso se realiza sobre las interfaces y se
lo denomina prueba de caja negra.

10. 2) Demostrar que la operación interna del modulo se ajusta a lo
especificado y que los componentes internos andan bien, (esta
prueba se desarrolla en base a los caminos lógicos del modulo, se
denomina prueba de caja blanca). Es la prueba que mejor nos
deja ver las dificultades.