Este tutorial presenta los siete principios básicos de prueba de software que todo probador de software y profesional de control de calidad debe conocer.
7 principios de las pruebas de software
- Las pruebas muestran la presencia de defectos.
- No es posible realizar pruebas exhaustivas
- Pruebas tempranas
- Agrupación de defectos
- Paradoja del pesticida
- Las pruebas dependen del contexto
- Falacia de ausencia de errores
Aprendamos los principios de prueba con el siguiente video de ejemplo:
Haga clic aquí si el video no es accesible
Fondo
Es importante que obtenga resultados de prueba óptimos mientras realiza pruebas de software sin desviarse del objetivo. Pero, ¿cómo determina que está siguiendo la estrategia correcta para las pruebas? Para eso, debe ceñirse a algunos principios básicos de prueba. Estos son los siete principios de prueba comunes que se practican ampliamente en la industria del software.
Para comprender esto, considere un escenario en el que está moviendo un archivo de la carpeta A a la Carpeta B.
Piense en todas las formas posibles en que puede probar esto.
Además de los escenarios habituales, también puede probar las siguientes condiciones
- Intentando mover el archivo cuando está abierto
- No tiene 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 suponga 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 probaras todas las combinaciones posibles del proyecto, el TIEMPO Y COSTOS DE EJECUCIÓN 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 de dólares es, ¿cómo se determina este riesgo?
Para responder a esto, hagamos un ejercicio.
En su opinión, ¿qué operación es más probable que provoque la falla de su sistema operativo?
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 deben probarse a fondo, lo que nos lleva a nuestro próximo principio de agrupación de defectos.
2) Agrupación de defectos
Agrupación de defectos, que indica 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 estos 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) La paradoja de los plaguicidas
El uso repetido de la misma mezcla de plaguicidas para erradicar insectos durante el cultivo conducirá con el tiempo a que los insectos desarrollen resistencia al plaguicida. Por lo tanto, los plaguicidas serán ineficaces para 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 probadores no pueden depender simplemente 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 llevar a casa este punto, veamos este video del lanzamiento público de Windows 98
¡Cree que una empresa como MICROSOFT no habría probado su sistema operativo a fondo y arriesgaría su reputación solo para ver su sistema operativo fallar durante su lanzamiento público!
4) Las pruebas muestran la presencia de defectos.
Por lo tanto, el principio de prueba establece que: La prueba habla de la presencia de defectos y no habla de la ausencia de defectos. es decir, la prueba 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 la corrección.
Pero, ¿qué pasa si trabaja más 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 el software que está 99% libre de errores aún no se pueda utilizar. Este puede ser el caso si el sistema se prueba a fondo para detectar el requisito incorrecto. La prueba de software no consiste simplemente en encontrar defectos, sino también en comprobar que el software satisface las necesidades comerciales. La ausencia de errores es una falacia, es decir, encontrar y corregir defectos no ayuda si la construcción del sistema no se puede utilizar y no cumple con las necesidades y requisitos del usuario.
Para resolver este problema, el siguiente principio de prueba establece que la prueba temprana
6) Pruebas tempranas
Pruebas tempranas: las pruebas deben comenzar lo antes posible en el ciclo de vida del desarrollo de software. Para que cualquier defecto en los requisitos o en la fase de diseño se capture en las primeras etapas. Es mucho más económico reparar un defecto en las primeras etapas de la prueba. Pero, ¿qué tan temprano se debe comenzar a realizar la prueba? Se recomienda que comience a encontrar el error en el momento en que se definan los requisitos. Más 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 solo una referencia. No los usaré en la práctica".
Esto es muy falso. Los principios de prueba le ayudarán a crear una estrategia de prueba eficaz y a redactar casos de prueba de detección de 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, te concentras en conducir, el resto es algo natural. De tal manera que incluso mantienes conversaciones con otros pasajeros en el automóvil.
Lo mismo ocurre con los principios de prueba. Los probadores experimentados han internalizado estos principios a un nivel que los aplican incluso sin pensar. Por tanto, el mito de que los principios no se utilizan en la práctica simplemente no es cierto.