Tomado de ISQTB

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

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

5. Cuidado con la paradoja del pesticida

Si las mismas pruebas se repiten una y otra vez, eventualmente estas pruebas ya no encontrarán ningún defecto nuevo. Para detectar nuevos defectos, es posible que sea necesario cambiar las pruebas y los datos de prueba existentes, y es posible que sea necesario redactar nuevas pruebas. (Las pruebas ya no son efectivas para detectar defectos, de la misma manera que los pesticidas ya no son efectivos para matar insectos después de un tiempo). En algunos casos, como la prueba de regresión automatizada, la paradoja del pesticida tiene un resultado beneficioso, que es el número relativamente bajo de defectos de regresión.

6. La prueba depende del contexto

La prueba se realiza de manera diferente en diferentes contextos. Por ejemplo, el software de control industrial de seguridad crítica se prueba de forma diferente a una aplicación móvil de comercio electrónico. Como ejemplo adicional, la prueba en un proyecto Ágil se realiza de manera diferente a la prueba en un proyecto que se desarrolla según un ciclo de vida secuencial.

7. La ausencia de errores es una falacia

Algunas organizaciones esperan que los probadores puedan realizar todas las pruebas posibles y encontrar todos los defectos posibles, pero los principios 2 y 1, respectivamente, nos dicen que esto es imposible. Además, es una falacia (es decir, una creencia equivocada) esperar que sólo con encontrar y corregir un gran número de defectos se asegure el éxito de un sistema. Por ejemplo, la realización de pruebas exhaustivas de todos los requisitos especificados y la reparación de todos los defectos encontrados podrían dar lugar a un sistema difícil de utilizar, que no satisface las necesidades y expectativas de los usuarios o que es peor en comparación con otros sistemas de la competencia. Consultar Myers 2011, Kaner 2002 y Weinberg 2008 para ejemplos de estos y otros principios del proceso de prueba.