12135153
Descripción
Mapa Mental por Gregory Diaz, actualizado hace más de 1 año
|
Creado por Gregory Diaz
hace casi 7 años
|
|
7 Principios de las Pruebas ISTQB
Fundation Level I Nro 1.3
- 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
- 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
- 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
- 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.
- 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!
- 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.
- 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.
¿Quieres crear tus propios Mapas Mentales gratis con GoConqr? Más información.