El objetivo fundamental de las pruebas es aportar información objetiva sobre la calidad del producto para que las personas responsables puedan tomar decisiones informadas. Entre los objetivos habituales se incluyen la detección de defectos, el aumento de la confianza en el nivel de calidad, la provisión de datos para la toma de decisiones y la prevención de errores futuros.^[4]​

La naturaleza y el alcance de la información requerida varían entre proyectos, por lo que el proceso de prueba depende en gran medida del contexto.^[5]​ En consecuencia, las prácticas, la documentación y las técnicas de prueba deben seleccionarse y adaptarse al entorno específico: no existen «mejores prácticas» universales, sino buenas prácticas en contexto.

La independencia entre el equipo de pruebas y el de desarrollo contribuye a la objetividad de los resultados y minimiza sesgos potenciales.^{[cita requerida]}

Los enfoques de desarrollo condicionan el momento y la forma en que se realizan las pruebas:

• Desarrollo en cascada: las etapas se suceden de manera secuencial y, en teoría, sin retrocesos. Las pruebas se sitúan tradicionalmente al final del ciclo, lo que puede dificultar la corrección temprana de errores.
• Desarrollo iterativo e incremental: divide los requisitos en subconjuntos y los construye en ciclos sucesivos; cada incremento incluye su propio conjunto de pruebas.
• Desarrollo iterativo (proceso espiral, por ejemplo): permite revisar los requisitos a lo largo de todo el ciclo, incorporando pruebas en cada iteración.
• Métodos ágiles: procesos iterativos e incrementales con iteraciones cortas que integran pruebas continuas. Entre las metodologías más extendidas se encuentran Scrum y Extreme Programming.

Son las pruebas que se realizan sin ejecutar el código fuente. Incluyen la revisión de documentos, inspecciones de diseño y análisis estático de código.

Requieren la ejecución de la aplicación. Permiten aplicar técnicas de caja negra y caja blanca, y medir con precisión el comportamiento del sistema durante su funcionamiento.

Las Especificaciones de Requerimientos de Software (ESRE) describen de forma completa lo que el sistema debe hacer, sin detallar el cómo. Sirven de base para que los probadores (incluidos los probadores beta) validen si el software se comporta conforme a los requisitos funcionales y no funcionales definidos. A partir de las ESRE se pueden derivar casos de prueba detallados.

• Pruebas manuales
• Pruebas automáticas

• Pruebas de caja blanca
• Pruebas de caja negra
• Pruebas exploratorias o aleatorias^[6]​

Evalúan funciones específicas del software basadas en los requisitos funcionales. Entre los tipos más comunes se incluyen:

El flujo habitual va desde las pruebas unitarias, pasando por la integración y el sistema, hasta las pruebas de aceptación. Las pruebas de regresión consisten en volver a ejecutar casos existentes tras una modificación para comprobar que no se han introducido defectos.

Verifican requisitos de calidad tales como disponibilidad, usabilidad, seguridad o rendimiento.^{[cita requerida]}

Las pruebas cuentan con numerosas herramientas —libres, de código abierto o propietarias— que abarcan gestión de pruebas, automatización funcional y pruebas de carga, entre otros ámbitos.^[7]​

1. Gestión de pruebas

1. Pruebas funcionales

1. Pruebas de carga y rendimiento

• Ingeniería de software
• Automatización de pruebas
• Pruebas de humo (informática)
• Pruebas de remojo (informática)

• La importancia de las pruebas en aplicaciones digitales
• Nueva tendencia y posible futuro del testing: el Crowd Testing
• Context-Driven Testing
• Testing Education
• ISO/IEC/IEEE 29119 Pruebas de Software (Grupo de Trabajo de AENOR AEN/CTN71/SC7/GT26)
• MÉTRICA v3 en el CSAE
• Functional Testing Types Explained With Examples
• STELA Automation made simple