Los principios de las pruebas son directrices comunes aplicables a todas las pruebas de software. Estos son siete:
1. Las pruebas muestran la presencia de defectos, no su ausencia
Se puede demostrar la presencia de defectos en un software, sin embargo, aunque se realice una cantidad considerable de pruebas no es posible asegurar que un sistema se encuentra libre de defectos. Las pruebas simplemente ayudan a reducir la cantidad de defectos que pueden ser hallados, lo cual minimiza el riesgo de un mal funcionamiento en las operaciones del sistema.
2. Las pruebas exhaustivas son imposibles
Probar todas las combinaciones de entradas y precondiciones no es posible, excepto en casos triviales. Debido a esta situación, lo correcto es realizar un análisis de riesgo y así priorizar y ejecutar los casos de prueba que tienen mayor importancia.
3. Las pruebas tempranas ahorran tiempo y dinero
Encontrar defectos en etapas tempranas del proyecto equivale a reducir costos de tiempo y dinero, mientras más tarde se encuentran los defectos, más costoso es arreglarlos. Por esta razón las pruebas tanto dinámicas como estáticas deben empezar tan pronto como sean posibles de realizar.
4. Agrupación de defectos
Por lo general, la mayoría de los defectos tienden a concentrarse en un pequeño número de módulos, existen distintas razones por lo que esto sucede, una de ellas es que los cambios se hacen regularmente en un solo módulo, o porque al arreglar un defecto, es posible introducir otro.
5. Cuidado con la paradoja del pesticida
Cuando se ejecutan los mismos casos de pruebas una y otra vez y sin ningún cambio, eventualmente estos dejarán de encontrar defectos nuevos. Es necesario cambiar las pruebas y los datos de prueba existentes para poder encontrar nuevos defectos. La paradoja del pesticida solo resulta beneficiosa en las pruebas de regresión.
6. Las pruebas dependen del contexto
Es necesario adecuar las pruebas según el contexto del objeto que se está probando, por ejemplo, no es igual probar una aplicación web para uso médico, que una aplicación móvil e-commerce.
7. La falacia de ausencia de errores
Es posible que la mayoría de los defectos críticos de una aplicación hayan sido corregidos, pero esto no asegura que el software sea exitoso. Se puede dar el caso de que este no cumpla con las expectativas del cliente o tal vez, que sea peor en comparación a sistemas similares.
Fuente: Syllabus ISTQB Foundation Level