7 principios de pruebas de software con ejemplos

Este tutorial presenta los siete principios básicos de pruebas de software que todo probador de software y profesional de control de calidad debe conocer.

Aprendamos los principios de prueba con lo siguiente ejemplo de vídeo–

Haga clic en aquí si el video no es accesible

Antecedentes

Es importante que logres resultados óptimos al realizar pruebas de software sin desviarte del objetivo. Pero, ¿cómo puedes determinar si estás siguiendo la estrategia correcta para realizar pruebas? Para eso, debes ceñirte a algunos principios básicos de pruebas. A continuación, se presentan los siete principios de pruebas comunes que se practican ampliamente en la industria del software.

Para comprender esto, considere un escenario en el que mueve un archivo de la carpeta A a la carpeta B.

Piense en todas las formas posibles de probar esto.

Además de los escenarios habituales, también puedes probar las siguientes condiciones

• Intentando mover el archivo cuando está abierto
• No tienes los derechos de seguridad para pegar el archivo en la carpeta B
• La carpeta B está en una unidad compartida y la capacidad de almacenamiento está llena.
• La carpeta B ya tiene un archivo con el mismo nombre, de hecho la lista es interminable
• O supongamos que tiene 15 campos de entrada para probar, cada uno con 5 valores posibles, el número de combinaciones a probar sería 5^15

Si tuviera que probar todas las combinaciones posibles del proyecto, el TIEMPO DE EJECUCIÓN Y LOS COSTOS aumentarían exponencialmente. Necesitamos ciertos principios y estrategias para optimizar el esfuerzo de prueba.

Aquí están los 7 principios:

1) No es posible realizar pruebas exhaustivas

¡Sí! No es posible realizar pruebas exhaustivas. En cambio, necesitamos la cantidad óptima de pruebas basadas en la evaluación de riesgos de la aplicación.

Y la pregunta del millón es ¿cómo se determina este riesgo?

Para responder esto hagamos un ejercicio.

En su opinión, ¿qué operación es más probable que provoque su Opera¿El sistema ting fallará?

Estoy seguro de que la mayoría de ustedes lo habrían adivinado: abriendo 10 aplicaciones diferentes al mismo tiempo.

Entonces, si estuvieras probando esto Operasistema de control, se daría cuenta de que es probable que se encuentren defectos en la actividad multitarea y que es necesario probarlos a fondo, lo que nos lleva al siguiente principio. Defecto ClusterIng.

2) defecto ClusterIng.

Defecto Clustering que afirma que un pequeño número de módulos contienen la mayoría de los defectos detectados. Esta es la aplicación del Principio de Pareto a las pruebas de software: aproximadamente el 80% de los problemas se encuentran en el 20% de los módulos.

Por experiencia, puede identificar dichos módulos riesgosos. Pero este enfoque tiene sus propios problemas.

Si las mismas pruebas se repiten una y otra vez, eventualmente los mismos casos de prueba ya no encontrarán nuevos errores.

3) Paradoja de los pesticidas

El uso repetitivo de la misma mezcla de pesticidas para erradicar insectos durante la agricultura hará que con el tiempo los insectos desarrollen resistencia al pesticida, por lo que los pesticidas serán ineficaces sobre los insectos. Lo mismo se aplica a las pruebas de software. Si se realiza el mismo conjunto de pruebas repetitivas, el método será inútil para descubrir nuevos defectos.

Para superar esto, los casos de prueba deben revisarse y revisarse periódicamente, agregando casos de prueba nuevos y diferentes para ayudar a encontrar más defectos.

Los evaluadores no pueden simplemente depender de las técnicas de prueba existentes. Debe buscar continuamente mejorar los métodos existentes para que las pruebas sean más efectivas. Pero incluso después de todo este sudor y arduo trabajo en las pruebas, nunca podrá afirmar que su producto esté libre de errores. Para aclarar este punto, veamos este vídeo del lanzamiento público de Windows 98

¿Crees que una empresa como MICROSOFT no habría probado su sistema operativo exhaustivamente y arriesgaría su reputación solo para ver que su sistema operativo falla durante su lanzamiento público?

4) Las pruebas muestran la presencia de defectos.

Por lo tanto, el principio de prueba establece que: Las pruebas hablan sobre la presencia de defectos y no sobre la ausencia de defectos, es decir Pruebas de software reduce la probabilidad de que queden defectos no descubiertos en el software, pero incluso si no se encuentran defectos, no es una prueba de corrección.

Pero, ¿qué pasa si trabaja muy duro, toma todas las precauciones y hace que su producto de software esté 99% libre de errores? Y el software no satisface las necesidades y requisitos de los clientes.

Esto nos lleva a nuestro siguiente principio, que establece que: Ausencia de error

5) Ausencia de Error – falacia

Es posible que un software que esté 99% libre de errores todavía no se pueda utilizar. Este puede ser el caso si el sistema se prueba minuciosamente para detectar el requisito incorrecto. Las pruebas de software no consisten simplemente en encontrar defectos, sino también en comprobar que el software satisface las necesidades del negocio. La ausencia de error es una falacia, es decir, encontrar y corregir defectos no ayuda si la compilación del sistema no se puede utilizar y no satisface las necesidades y requisitos del usuario.

Para resolver este problema, el siguiente principio de prueba establece que las pruebas tempranas

6) Pruebas tempranas

Pruebas tempranas: las pruebas deben comenzar lo antes posible en el ciclo de vida del desarrollo de software, de modo que cualquier defecto en la fase de requisitos o diseño se detecte en las primeras etapas. Es mucho más económico corregir un defecto en las primeras etapas de las pruebas. Pero, ¿cuánto antes se deben comenzar las pruebas? Se recomienda comenzar a buscar el error en el momento en que se definen los requisitos. Más información sobre este principio en un tutorial de capacitación posterior.

7) Las pruebas dependen del contexto

Las pruebas dependen del contexto, lo que básicamente significa que la forma en que prueba un sitio de comercio electrónico será diferente de la forma en que prueba una aplicación comercial lista para usar. No todos los software desarrollados son idénticos. Puede utilizar un enfoque, metodologías, técnicas y tipos de pruebas diferentes según el tipo de aplicación. Por ejemplo, probar cualquier sistema POS en una tienda minorista será diferente a probar un cajero automático.

Mito: “Los principios son sólo una referencia. No los usaré en la práctica”.

Esto es muy falso. Los principios de prueba le ayudarán a crear una prueba eficaz. Estrategia de prueba y borrador de casos de prueba para detectar errores.

Pero aprender los principios de las pruebas es como aprender a conducir por primera vez.

Inicialmente, mientras aprendes a conducir, prestas atención a todos y cada uno de los aspectos, como los cambios de marcha, la velocidad, el manejo del embrague, etc. Pero con la experiencia, solo te concentras en conducir, el resto es natural. De modo que incluso puedes mantener conversaciones con otros pasajeros del coche.

Lo mismo ocurre con los principios de prueba. Los evaluadores experimentados han internalizado estos principios a un nivel que los aplican incluso sin pensar. De ahí que el mito de que los principios no se utilizan en la práctica simplemente no sea cierto.