Blog

Definición y Alcance

Este principio afirma que no existe un enfoque único y universal para realizar pruebas de software. Las pruebas deben adaptarse al contexto del proyecto, lo que incluye factores como el tipo de software, la criticidad del sistema, los requisitos del negocio y el ciclo de vida de desarrollo del software (SDLC). Dependiendo del contexto, los enfoques de prueba pueden variar significativamente para cumplir con los objetivos y necesidades específicas.

Explicación

Cada proyecto tiene sus propias particularidades, por lo que no todas las técnicas de prueba serán aplicables o útiles en todos los contextos. Por ejemplo, las pruebas de un sistema crítico de seguridad (como un sistema médico o de aviación) requieren un enfoque mucho más riguroso y formal en comparación con un desarrollo ágil para una aplicación móvil en el que no existe riesgo de vida humana como puede ser en el caso del sistema médico o de aviación. En algunos casos, puede ser necesario realizar pruebas formales exhaustivas con documentación detallada, mientras que en otros contextos, como en proyectos ágiles, se puede priorizar la rapidez y la flexibilidad con una menor carga documental.

Ejemplo

Imagina que estás probando una aplicación web para la búsqueda de venta de paquetes turísticos. Si el contexto del proyecto es un desarrollo ágil para una aplicación comercial estándar, probablemente no necesitarás hacer pruebas de seguridad exhaustivas o aplicar pruebas de rendimiento de alto nivel. En cambio, te enfocarías en pruebas funcionales rápidas y regresiones automáticas que puedan realizarse en cada iteración. Sin embargo, si esa misma aplicación estuviera destinada a usuarios corporativos con requisitos específicos de seguridad o alta disponibilidad, el enfoque de pruebas tendría que ajustarse para incluir pruebas más detalladas de seguridad, rendimiento y cumplimiento normativo.

Momento para reflexionar:

Este principio resalta la importancia de adaptar el proceso de prueba a los factores del proyecto, tales como la naturaleza del software, el presupuesto, los plazos de entrega, el equipo y los riesgos involucrados. En un proyecto con alto riesgo, como un sistema financiero o un sistema crítico para la vida, las pruebas serán más exhaustivas y formales. En cambio, para una aplicación de entretenimiento o un juego, las pruebas pueden ser más informales y ágiles. Aquí es importante mencionar que se pueden / deben aplicar dos técnicas de prueba: pruebas de seguridad y pruebas bajo riesgo, ambas están descritas no sólo en el programa de estudios sino además que podemos complementar nuestro conocimiento al respecto en la correspondiente norma, por ejemplo en la OWASP para el caso de aspectos de seguridad a tenerse en cuenta.