Esquema ISTQB

Fundamentos de pruebas

•Software = Factor de éxito
•Pruebas/revisión/software= calidad
•Error
•Defecto
causado por
•Fallo
•Pruebas

error humano
condiciones ambientales

mejora calidad
reduce fallos
satisface compromisos/requisitos

•Detección de error < detección de fallo ($$$)
•Software/calidad/calidad software
•Calidad Software

atributos

•Aseguramiento de la calidad(QA)
•Analíticas

Pruebas estáticas
Pruebas dinámicas

funcionales
no funcionales

Fiabilidad
Usabilidad
Eficiencia
Mantenibilidad
Portabilidad

actividades

constructivas
analíticas

caja negra
caja blanca

revisión de funcionalidad
revisión de código

•Atributos funcionales

Adecuación
Exactitud
Interoperabilidad
Seguridad
Cumplimiento de funcionalidad•Objetivos de las pruebas

Conocimiento de defectos
Confirmación de funcionalidad
Generar información
Ganar confianza

•Pruebas

prevenir defectos
detectar defectos

Riesgos
Plazos y presupuestos

basadas

•Caso de prueba

Precondiciones
Valores de entrada
Resultados esperados
Pos condiciones
Identificador único
Dependencias a otros casos
Referencia a requisitos
Forma de ejecutar yverificación de casos
Prioridad

•Base de prueba: Documentos que definen los requisitos / Fundamento para el desarrollo de casos de pruebas

Proceso de pruebas

Planificación y control

Selección de
condiciones de prueba

Diseño y ejecución de
casos de prueba

Comprobación de
resultados

Generación de
informes

Actividades de cierre

Depuración
Prueba

Detección –Identificación de
defectos

Corrección de
defectos

Repetición de
Pruebas

Siete principios del
proceso de pruebas

1.
2.
3.
4.
5.
6.
7.

El proceso demuestra la presencia de defectos, no la ausencia de ellos
No hay pruebas exhaustivas
Pruebas tempranas (detección de defectos)
Agrupamiento de defectos (hongos/cucarachas
Paradoja del pesticida (revisar/modificar pruebas)
Laspruebas dependen del concepto (entorno de prueba Vs. Entorno de producción)
La falacia de la ausencia de errores

Desarrollador
Psicología del proceso
de prueba

desarrollar

probar

Objetivo común
Tester

Código ético

Diseñar

Público
Cliente / empleador
Producto
Juicio
Gestión
Profesión
Compañeros de profesión
Individualmente

Aportar un buen producto

Modelo WDefinición de
requisitos

Pruebas de aceptación

Diseño funcional del
sistema

Pruebas de sistema

Diseño técnico del
sistema

Pruebas de
integración

Especificación de
componentes

Pruebas de
componente

Programación

Modelos de desarrollo
de Software

Verificación
Vs.
Validación

Comprobación de la conformidad con los requisitos

}construcción del sistemaComprobación de la idoneidad para el uso esperado

Sistema correcto

Modelo V

Requisitos funcionales

Planificar actividades
de pruebas

Diseño funcional del
sistema

Ejecución de prueba
de aceptación

Planificar prueba del
sistema

Diseño funcional
técnico

Ejecución de prueba
de sistema

Planificar prueba de
integración

Especificación de
componentes

Ejecución deprueba
de integración

Planificar prueba de
componentes

Ejecución de prueba
de componentes

Pruebas de aceptación

Pruebas de sistema

Pruebas de
integración

Pruebas de
componente

Programación

Ciertas actividades de aseguramiento de calidad se desarrollan en paralelo al proceso de desarrollo

Modelo prototipado 
Modelos iterativos

Desarrollo de una representacióndel sistema seguida de modificaciones
sucesivas hasta que sea finalizado

Desarrollo rápido de aplicaciones 

Las actividades se
realizan de forma
continua

Proceso unificado 
Programación extrema 

La interfaz de usuario se implementa utilizando una
funcionalidad ya construida simulando otra posteriormente
desarrollada
Modelo orientado a objetos. Aporta el lenguaje de modelado...