Los siete principios de pruebas de software.pptx

Los principios de las pruebas de software

1. Los siete principios de pruebas de software

2. Antecedentes Debugging (1947 - 1956) Todas las pruebas realizadas se encontraban dirigidas a la corrección directa del código fuente de los programas. No se tenía claro la diferencia que existía entre checkout, debugging y testing. Demostración (1957-1958) En esta fase se encargaban de utilizar de forma masiva el test para asegurar que se cumplía con la especificación. Se realizaban al finalizar el desarrollo del Software.

3. Antecedentes Destrucción (1979 – 1982) Pasaron de demostrar que un programa era correcto mediante pruebas y demostraciones teóricas a demostrar que el programa no funciona o tiene fallos. Evaluación (1983 – 1984) Esta fue una etapa donde se comenzó a integrar las pruebas de Software en el ciclo de vida del desarrollo del software.

4. Antecedentes La evolución de las pruebas, hace que se requiera cada vez más un personal con conocimientos y estudios sólidos, para profesionalizarse existen varias alternativas de cursos y certificaciones, entre ellas la más reconocida a nivel mundial son las de ISTQB, (International Software Testing Qualifications Board)

5. La ejecución demuestra la presencia de defectos Las pruebas muestran la existencia de errores, no su ausencia. Pueden mostrar que hay defectos presentes, pero no pueden probar que no haya defectos. Reduce la probabilidad de que queden defectos no descubiertos en el software. Minimiza el riesgo de un mal funcionamiento en las operaciones del sistema.

6. 2. Las pruebas exhaustivas no existen Probar todo (todas las combinaciones de entradas y condiciones previas) no es factible excepto en casos triviales. No es posible realizar una prueba que cubra todas las variables. En lugar de intentar realizar pruebas exhaustivas, se deben utilizar el análisis de riesgos, las técnicas de prueba y las prioridades para centrar los esfuerzos de prueba.

7. 3. Pruebas tempranas Para encontrar defectos temprano, las actividades de prueba (dinámicas y estáticas) deben iniciarse lo antes posible en el ciclo de vida de desarrollo de software. Ayudan a reducir costos de tiempo y dinero. Mientras más tarde se enc uentran los defectos, más costoso es arreglarlos.

8. 4. Los defectos se agrupan Una pequeña cantidad de módulos generalmente contiene la mayoría de los defectos descubiertos. No todos los componentes de un software poseen el mismo nivel de relevancia, el enfoque más propicio al elaborar la estrategia de pruebas es concentrarse en esas partes más cruciales. Las pruebas se agrupan por tipo para revisar el software.

9. 5. Paradoja del pesticida Si las pruebas se repiten una y otra vez, eventualmente estas pruebas ya no encuentran ningún nuevo defecto. Para detectar nuevos defectos, es necesario cambiar las pruebas existentes y los datos de prueba o incluso escribir nuevas pruebas. Las pruebas deben actualizarse periódicamente.

10. 6. Las pruebas dependen del contexto Las pruebas se realizan de manera diferente en diferentes contextos. Deben realizarse teniendo en cuenta el escenario, entorno y caso de uso. ¿El usuario tendrá prisa? ¿Usará la aplicación en dispositivo móvil o escritorio? Definir los objetivos de las pruebas según el contexto Por ejemplo, un software médico no será probado de la misma forma que un sistema de e-commerce.

11. 7. Falacia de ausencia de errores Algunas organizaciones esperan que los probadores puedan ejecutar todas las pruebas posibles y encontrar todos los posibles defectos, pero los principios dos y uno, nos dicen que esto es imposible. Esperar que el solo hecho de encontrar y corregir una gran cantidad de defectos garantizará el éxito de un sistema. Expectativas y necesidades del usuario

12. Ejemplos La ejecución demuestra la presencia de defectos. Considere una aplicación bancaria, esta aplicación se prueba a fondo y se somete a diferentes fases de prueba y actualmente no se identifican defectos en el sistema. Sin embargo, puede existir la posibilidad de que en el entorno de producción, el cliente real pruebe una funcionalidad que rara vez se usa en el sistema bancario y los evaluadores pasaron por alto esa funcionalidad

13. Ejemplos 2. Las pruebas exhaustivas no existen Supongamos que tenemos un campo de entrada que acepta alfabetos, caracteres especiales y números del 0 al 1000 únicamente. Imagínese cuántas combinaciones aparecen para probar, no es posible probar todas las combinaciones para cada tipo de entrada

14. Ejemplos 4. Los defectos se agrupan Se prueba para una de las aplicaciones bancarias y muestra que la mayoría de los defectos están relacionados con la funcionalidad de 'Sobregiro'. Los probadores se concentran principalmente en esta área durante la ejecución para encontrar más y más defectos

15. Referencias ISTQB Foundation Level - seven testing principles. (2021, octubre 29). ISTQB Exams at Home Worldwide - ASTQB - ISTQB in the U.S; ASTQB - ISTQB in the U.S. with Exams Worldwide. https://astqb.org/istqb-foundation-level-seven-testing-principles/ Medina, I. F. (2022, mayo 9). Los 7 principios del testing. ¿Qué dice ISTQB? Blog de Hiberus Tecnología. https://www.hiberus.com/crecemos-contigo/siete-principios-que-deben-guiar-el-testing-de-software-segun-istqb/ Pruebas de Software: Historia y Evolución. (s/f). Fyccorp.com. Recuperado el 12 de febrero de 2023, de https://www.fyccorp.com/articulo-pruebas-de-software:-historia-y-evolucion