¿Cuál es el mejor sitio para aprender los principios de prueba? Educación te da un futuro mejor

El mundo está impulsado por las creencias. Puede estar en Dios o en Tecnología. Durante un período de tiempo, cada sociedad establece un conjunto de filosofías o valores para una mejor organización y operación. Del mismo modo, cualquier tecnología tiene sus propios principios fundamentales que han demostrado ser correctos a medida que transcurrió el tiempo. La ‘Prueba de software’ no es diferente: también tiene un conjunto de 7 principios fundamentales que se prueban con el tiempo.

1. Las pruebas muestran la presencia de defectos.

En términos simples: las pruebas de software son la actividad de encontrar defectos. Lanzando la moneda, no significa que después de la prueba la aplicación esté libre de defectos. Como decimos en la vida: ” Siempre hay un margen de mejora “, de manera similar, incluso después de pruebas rigurosas, siempre hay un margen de defecto que se produce o una mayor optimización de la aplicación. El objetivo de las pruebas es claro: identificar ” tantos ” defectos como sea posible.

Las pruebas de software no son una prueba de corrección, se trata de garantizar que la mayoría de los defectos se hayan identificado (y rectificado), reduciendo así la probabilidad de defectos no descubiertos que puedan ocurrir en el entorno en vivo. ¿Por qué cree que las empresas no firman un contrato para que un software esté libre de defectos después de la prueba O por qué tienen un período de garantía incluso después del lanzamiento?

Trivia : ¿Crees que Facebook no hace pruebas rigurosas? Si lo hacen, entonces ¿por qué tener el famoso programa Bug Bounty alentando a los usuarios finales a identificar defectos aún no identificados?

Tenga en cuenta que esto no significa que pueda usar este principio como una excusa para la mala calidad, sino que se centre en diseñar los casos de prueba que tengan la máxima cobertura e identificar los defectos ‘máximos’.

2. Pruebas exhaustivas no son posibles

Exhaustivo como en pruebas completas o en profundidad no es posible. ¿Por qué? No tiene todo el dinero, el tiempo y los recursos a su entera disposición: el presupuesto es limitado, los plazos están definidos, el recuento de recursos es fijo, los PyC son bastante grandes, etc. Incluso un simple cuadro de texto con 5 valores posibles necesita pruebas de datos, pruebas de IU, pruebas de seguridad, pruebas de compatibilidad, etc. Teniendo en cuenta diferentes factores, no es posible probar todas las combinaciones, flujos, datos y escenarios posibles.

¿Cuál es la salida entonces? ¡Priorizar en función del análisis de riesgos! Utilice diferentes técnicas de diseño de prueba para optimizar los casos de prueba. El objetivo es obtener la cantidad óptima de pruebas requeridas en función de los riesgos y las prioridades, de modo que descubra los defectos máximos centrándose primero en los aspectos más importantes.

Precaución : su calidad de prueba depende del análisis de riesgos, la priorización y las técnicas utilizadas.

3. Pruebas tempranas

Digamos que el cliente solicita desarrollar una página de inicio de sesión para su aplicación. Los desarrolladores crean una página con campos de Nombre de usuario y Contraseña y la implementan para realizar pruebas. Durante las pruebas, observa que no se proporciona el enlace ” Olvidé mi contraseña “. ¡Vamos, es obvio! ¿Qué haces? Simple: plantee un defecto >> el cliente dice que es obvio >> los requisitos se detallan >> el desarrollador cambia el código para corregirlo >> lo vuelve a probar y cierra.

Ahora imagine que el equipo de prueba está involucrado desde el inicio del proyecto. ¿Qué haces? Tan pronto como se reciben los requisitos, plantea un problema con el equipo comercial sobre los requisitos ambiguos, faltantes o confusos >> El equipo comercial detalla los requisitos claramente. Resultado: es más fácil y económico solucionar el problema si se identifica antes en el ciclo. Espero que hayas entendido 😉

Las pruebas de software deben comenzar lo antes posible en el ciclo de vida del desarrollo de software. Por ejemplo, es mucho más barato cambiar un requisito incorrecto que tener que cambiar una funcionalidad en un sistema grande que no funciona según lo solicitado o diseñado. Es por eso que tenemos análisis de requisitos, pruebas unitarias, discusiones de diseño, análisis de impacto, revisiones, etc.

4. Agrupación de defectos

¿Alguna vez escuchó sobre el ” principio de Pareto “, también conocido como la regla 80-20 ? Establece que para muchos eventos, aproximadamente el 80% de los efectos provienen del 20% de las causas .

El 80% de sus ventas provienen del 20% de sus clientes.
El 80% de las ventas de una empresa provienen del 20% de sus productos.
El 80% del tráfico ocurre durante el 20% del tiempo.

Se ha demostrado empíricamente que muchos fenómenos naturales (población, riqueza, deportes, negocios, tecnología, etc.) exhiben tal distribución. Aplicación de este principio a las pruebas de software : el 80% de los defectos se encuentran en el 20% de los módulos . ¡Sí! Eso es más o menos cierto. ¿Y cómo identificas tales módulos? Viene con experiencia mi niño (o niña)

Curiosidades : el consultor de gestión Joseph M. Juran sugirió el principio y lo nombró en honor al economista italiano Vilfredo Pareto . Pareto notó que el 80% de las tierras de Italia era propiedad del 20% de la población. Luego realizó encuestas en una variedad de otros países y encontró para su sorpresa que se aplicaba una distribución similar.

5. La paradoja de los pesticidas

Trivia : La paradoja de los pesticidas establece que aplicar pesticidas a una plaga puede terminar aumentando la abundancia de la plaga si el pesticida altera la dinámica natural de depredador-presa en el ecosistema, es decir, la plaga objetivo tiene un depredador natural que se ve igualmente afectado por el pesticida. .

O, en otras palabras, si sigue ejecutando el mismo conjunto de pruebas una y otra vez, el software se vuelve inmune a las pruebas, es decir, a medida que el sistema evoluciona, muchos de los defectos informados previamente se habrán solucionado y los casos de prueba anteriores no podrán encontrar ninguna nueva. defectos

¿Cuál es la salida entonces? Para superar esta ” paradoja de los pesticidas “, los casos de prueba deben revisarse y revisarse periódicamente, agregando nuevos y diferentes casos de prueba para ayudar a encontrar más defectos.

6. Las pruebas dependen del contexto

Contexto como en el entorno, es decir, tipo de aplicación. Todos los software desarrollados no son idénticos. Puede usar diferentes metodologías, enfoques, métodos, técnicas y tipos de pruebas dependiendo del tipo de aplicación , ya sea un juego, una aplicación móvil, una aplicación de escritorio basada en la nube, basada en la web, sistema integrado, etc. Después de todas las pruebas en un cajero automático la máquina será diferente de probar Flipkart.

7. Ausencia de errores falacia

Esto es un poco complicado 😉

En primer lugar, no confunda este principio con 1 y 2. En términos simples:

La prueba es para identificar defectos, no para confirmar que no hay defectos.
Incluso después de la prueba completa, los defectos pueden estar presentes en el sistema.

Ante la falacia de la ausencia de errores, imagine que desarrolló un sistema de comercio electrónico y lo probó por completo. Todos los defectos identificados han sido reparados y probados nuevamente. El 99% de los defectos han sido rectificados. La administración está bastante segura de los defectos de calidad del producto. Ahora, cuando se demuestra el sistema al cliente, ¿qué pasa si recibe un comentario que dice ” Aunque se llama libre de defectos, pero aún así esto no es lo que quería”. ¿Quería una interfaz de usuario simple que pueda manejar la carga del usuario ?

¡Sí! Todos en el equipo de prueba confiaban en la ‘calidad’ del producto (ausencia de errores) pero al final resultó ser falsa (falacia): el sistema no es utilizable, no cumple con las expectativas del cliente.

La lección : los requisitos y expectativas del cliente son tan importantes como la calidad del producto. Y puede cambiar con el tiempo. ¿Por qué crees que la metodología ágil es tan popular hoy en día? Permite la interacción continua con usuarios comerciales y la creación rápida de prototipos (función mínima comercializable o MMF) evita que los clientes descontentos al final.

Ahora que conoce los 7 principios fundamentales de las pruebas de software , no olvide la conclusión clave:

Concéntrese en diseñar los casos de prueba que tengan la máxima cobertura e identifique los defectos ‘máximos’.
Su calidad de prueba depende del análisis de riesgos, la priorización y las técnicas utilizadas.
Las pruebas de software deben comenzar lo antes posible en el ciclo de vida del desarrollo de software.
El 80% de los defectos se encuentran en el 20% de los módulos. ¡Sí! Eso es más o menos cierto. ¿Y cómo identificas tales módulos? Viene con experiencia.
Los casos de prueba deben revisarse y revisarse regularmente, agregando casos de prueba nuevos y diferentes para ayudar a encontrar más defectos.
Puede utilizar diferentes metodologías, enfoques, métodos, técnicas y tipos de pruebas según el tipo de aplicación.
Los requisitos y expectativas del cliente son tan importantes como la calidad del producto.

¡Feliz prueba!