STLC - Principios fundamentales de prueba

El objetivo común de las pruebas es encontrar errores lo antes posible. Y, una vez que se solucionen los errores, asegúrese de que esté funcionando como se esperaba y no interrumpa ninguna otra funcionalidad.

Para lograr estos objetivos, se dan siete principios básicos para las pruebas de software:

¿Qué muestra la prueba?

Las pruebas pueden mostrar que hay defectos, pero no hay forma de probar que no hay ningún defecto en el producto. Las fases de prueba garantizan que la aplicación bajo prueba esté funcionando según el requisito dado y ayuda a reducir la probabilidad de defectos no descubiertos en la aplicación. Pero, incluso si no se encuentran defectos, no significa que sea absolutamente correcto. Podemos suponer que AUT coincide con nuestros criterios de salida y mantiene los requisitos de acuerdo con SRD.

¿Es posible realizar pruebas exhaustivas?

La cobertura del 100% o la prueba de todas las combinaciones de entradas y posibles combinaciones no son posibles excepto en casos triviales. En lugar de pruebas exhaustivas, se utilizan análisis de riesgos y prioridades para definir el alcance de las pruebas. Aquí, la mayoría de los escenarios en tiempo real pueden considerar incluir también el escenario negativo más probable. Esto nos ayudará a rastrear el error.

Pruebas tempranas

Las actividades de prueba deben comenzar lo antes posible y centrarse en los objetivos definidos en la estrategia de prueba y los resultados esperados. Las primeras etapas de las pruebas ayudan a identificar los defectos de los requisitos o las discrepancias en el nivel de diseño. Si estos tipos de errores se capturan en la etapa inicial, nos ayuda a ahorrar tiempo y también es rentable. La respuesta a por qué las pruebas deben comenzar en una etapa temprana es muy simple: tan pronto como se recibe el SRD, los evaluadores pueden analizar el requisito desde la perspectiva de la prueba y pueden notar una discrepancia en los requisitos.

Agrupación de defectos

Basado en análisis de defectos de productos anteriores, se puede decir que la mayoría de los defectos se identifican a partir de un pequeño conjunto de módulos que son críticos para la aplicación. Estos módulos se pueden identificar en función de la complejidad, la interacción del sistema diferente o la dependencia de otros módulos diferentes. Si los evaluadores pueden identificar estos módulos cruciales, pueden centrarse más en estos módulos para identificar todos los errores posibles. En un estudio, se encontró que 8 de cada 10 defectos se identifican a partir del 20% de funcionalidad de AUT.

Paradoja del pesticida

¿Qué es la paradoja de los pesticidas? Si los pesticidas se usan con frecuencia en los cultivos, llega cuando los insectos desarrollan un cierto tipo de resistencia y gradualmente los pesticidas así rociados parecen ser ineficaces sobre los insectos.

El mismo concepto se aplica también a las pruebas. Aquí, los insectos son bichos, mientras que los pesticidas son casos de prueba que se utilizan para funcionar una y otra vez. Si los mismos conjuntos de casos de prueba se ejecutan una y otra vez, estos casos de prueba se vuelven ineficaces después de cierto período de tiempo y los probadores no podrán identificar ningún defecto nuevo.

Para superar estas condiciones, los casos de prueba deben revisarse y revisarse de vez en cuando y se pueden agregar casos de prueba nuevos y diferentes. Esto ayudará a identificar nuevos defectos.

Las pruebas dependen del contexto

Este principio establece que no se pueden probar dos tipos diferentes de aplicaciones utilizando el mismo enfoque hasta que ambas aplicaciones sean de la misma naturaleza. Por ejemplo, si un evaluador usa el mismo enfoque para la aplicación basada en web y la aplicación móvil, eso es completamente incorrecto y existe un alto riesgo de que el lanzamiento del producto sea de baja calidad. Los evaluadores deben utilizar diferentes enfoques, metodologías, técnicas y cobertura para diferentes tipos y naturaleza de aplicaciones.

Ausencia de error - Falacia

Este principio establece encontrar defectos y corregirlos hasta que la aplicación o el sistema sea estable, lleve mucho tiempo y también consuma recursos. Incluso después de corregir el 99% de los defectos, existe un alto riesgo de aplicación inestable. Lo primero esencial es verificar la estabilidad de la aplicación y los requisitos previos del entorno. Si se cumplen estas dos condiciones, solo entonces podemos comenzar con las pruebas detalladas.