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.

7 Principios de las pruebas de software

  1. Las pruebas muestran la presencia de defectos.
  2. No es posible realizar pruebas exhaustivas
  3. Pruebas tempranas
  4. Agrupación de defectos
  5. Paradoja del pesticida
  6. Las pruebas dependen del contexto
  7. Falacia de ausencia de errores

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

Haga clic aquí si el video no es accesible

Antecedentes

Es importante que logre resultados de prueba óptimos mientras realiza pruebas de software sin desviarse del objetivo. Pero, ¿cómo determinas que eres seguidor?wing ¿La estrategia correcta para las pruebas? Para ello, debe seguir algunos principios básicos de prueba. A continuación se detallan los siete principios de prueba 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 lo siguiente.wing 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 que su sistema operativo falle?

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

Entonces, si estuviera probando este sistema operativo, se daría cuenta de que es probable que se encuentren defectos en la actividad multitarea y que es necesario probarlos exhaustivamente, lo que nos lleva al siguiente principio. Defecto Clustering

2) Agrupación de defectos

Agrupación de defectos que establece que una pequeña cantidad 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 a fondo y arriesgaría su reputación solo para verlo fallar 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 de la presencia de defectos y no de 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 de diseño se capture en las primeras etapas. Es mucho más económico corregir un defecto en las primeras etapas de la prueba. Pero, ¿con qué antelación se deben empezar a realizar las pruebas? Se recomienda empezar a encontrar el error en el momento en que se definan los requisitos. Más sobre este principio en un later tutorial de entrenamiento.

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.