7 Principios de las Pruebas ISTQB Fundation Level I Nro 1.3

7 Principios de las Pruebas ISTQB Fundation Level I Nro 1.3

1. Principio 1-Las Pruebas Demuestran la Presencia de Defectos: Reducen la posibilidad de que existan defectos en el software pero no de que no exista ninguno

2. Principio 2-Las Pruebas Exahustivas no Existen: Probar todas las combinaciones es imposible excepto en casos triviales. en vez de enfocarse en pruebas exahustivas se debe realizar un analisis de riesgo y prioridades para centralizar los esfuerzos de las pruebas

3. Principio 3 - Pruebas Tempranas: para identificar los defectos en etapas tempranas se deben iniciar las actividades de pruebas lo antes posiblecentrnadose entonces en los objetivos del proyecto

4. Principio 4- Agrupacion de Defectos: Los bugs por lo general tienden a estar en grupos en conclusion si encuentras un bug en un componente, es muy probable que hayan más. Con lo que una posible estrategia sería centrarse en mejorar las pruebas de aquellos componentes para los que se han reportado un número mayor de bugs, para ser más eficaces a la hora de cazarlos en fases tempranas.

5. Principio 5- Paradoja del Pesticida: la necesidad de ajustar continuamente tu plan de pruebas… porque según este principio un plan de pruebas va perdiendo efectividad conforme se ejecuta sucesivas veces. Con lo que cada vez tenderá a encontrar menos bugs… ¡lo que no significa que no hayan!

6. Principio 6 - Las Pruebas dependen del Contexto: Si tu producto se centra en el ámbito de la seguridad deberás adaptar tus casos de prueba para intentar forzar situaciones o posibles escenarios no amistosos. Si quieres probar una intranet donde los servicios más vitales son los de imputación de horas y el de vacaciones, es lógico centrarse en estos servicios y no invertir tiempo en otros componentes infrautilizados. Además, hay que tener en cuenta que los recursos en los proyectos son siempre escasos, con lo que en el inicio del proyecto hay que preguntarse… qué estrategia debemos seguir para encontrar y corregir lo antes posible los bugs en las funcionalidades de mayor valor para nuestros usuarios.

7. Principio 7 - Falacia de Ausencia de Errores: Para terminar, nos encontramos con la satisfacción del usuario y con el hecho de que los usuarios elijan tu software para resolver sus necesidades.Que hayas corregido muchos bugs no significa que finalmente tu software sea un éxito. En ocasiones hay que primar un buen time to market, para luego corregir los problemas de calidad que quedaron por el camino. Y esto si se hace de manera consciente y con una buena estrategia, a priori, no debe ser un problema.