1. Cada caso de prueba debe definir el resultado de salida esperado. Este
resultado esperado es el que se compara con el realmente obtenido de la
ejecución en la prueba. Las discrepancias entre ambos se consideran síntomas de
un posible defecto en el software.
2. El programador debe evitar probar sus propios programas porque desea
demostrar que funcionan sin problemas. Lo ideal sería que probara el software el
peor enemigo de quien lo ha construido, ya que así se aseguraría una búsqueda
implacable de cualquier error cometido.
3. Se debe inspeccionar a conciencia el resultado de cada prueba para descubrir
posibles síntomas de defectos. Lamentablemente es frecuente pasar por alto
síntomas bastante claros. Esto invalida todo el esfuerzo realizado en la
planificación, diseño y ejecución de pruebas.
4. Al generar casos de prueba, se deben incluir datos de entrada válidos y
esperados, asi como, datos no validos e inesperados.
5. Las pruebas deben centrarse en dos objetivos: Probar si el software no hace lo
que debe, y Probar si el software hace lo que no debe, es decir, si provoca efectos
secundarios adversos.
6. Se deben evitar los casos no documentados ni diseñados con cuidado ya que
suele ser necesario probar una y otra vez el software hasta que queda libre de
defectos. No documentar o guardar los casos significa repetir constantemente el
diseño de casos de prueba.
7. No deben hacerse planes de prueba suponiendo que no hay defectos en los
programas y dedicando pocos recursos a las pruebas. Hay que asumir que
siempre hay defectos y hay que detectarlos. Las estadísticas confirman cerca del
40% del esfuerzo de desarrollo se consume en pruebas y depuración.
8. La experiencia parece indicar que donde hay un defecto hay otros, es decir, la
probabilidad de descubrir nuevos defectos en una parte del software es
proporcional al número de defectos ya descubierto.
9. Las pruebas son una tarea más creativa que el desarrollo de software. Siempre
se han considerado las pruebas como una tarea destructiva y rutinaria. No existen
técnicas rutinarias para el diseño de pruebas y hay que recurrir al ingenio para
alcanzar un buen nivel de detección de defectos con los recursos disponibles.