1 JB Istqb P07

ING, CFTL
ALEX VIDAURRE
Curso Taller
ISTQB Foundation
“Taller de Preparación para la Certificación”
Módulo 07
REPASO
REP-1
www.jbenterprisegroup.com
¿POR QUÉ ES NECESARIO PROBAR?
ERROR - DEFECTO - FALLA
Una persona comete un

error ...
… que crea un defecto en

el software ...
… que puede causar un

fallo en el funcionamiento
CICLO DE VIDA DESARROLLO Y PRUEBAS
REP-2
NIVELES DE PRUEBAS – MODELO V
PROCESO DE PRUEBAS - NIVEL
REP-3
PROCESO DE PRUEBAS
PROCESO DE PRUEBAS FUNDAMENTAL

PLANIFICACIÓN DE LAS PRUEBAS - DIFERENTES NIVELES
Política de
Pruebas
A Nivel de Empresa
Estrategia de
Pruebas
Plan de Nivel de proyecto (IEEE 829)

(uno para cada proyecto)
pruebas
High Level
de Alto
Test Nivel
Plan
Nivel de pruebas (IEEE 829)

Plan de (una para cada nivel dentro de un proyecto,
pruebas
Detailed por ejemplo componentes, sistema, etc.)
Detailed
detallado
Test Plan
Detailed
Test Plan
Test Plan
REP-4
CRITERIOS DE ENTRADA - EJEMPLO
CRITERIOS DE SALIDA - EJEMPLO
*Parámetro: Variable de entrada/salida de los métodos de una unidad de código y /o configuración.

*Interfaz: Elemento para la conexión física o funcional entre dos sistemas, componentes o dispositivos.
*Fallas conocidas: Fallos comunes y frecuentes en los proyectos que deben ser consideradas incidencias
potenciales. Se encuentran registrados en la base de conocimiento de las Pruebas.
REP-5
CRITERIOS DE SALIDA - EJEMPLO
*Parámetro: Variable de entrada/salida de los métodos de una unidad de código y /o configuración.

*Interfaz: Elemento para la conexión física o funcional entre dos sistemas, componentes o dispositivos.
*Fallas conocidas: Fallos comunes y frecuentes en los proyectos que deben ser consideradas incidencias
potenciales. Se encuentran registrados en la base de conocimiento de las Pruebas.
INDEPENDENCIA DE PRUEBAS
REP-6
PROCESO DE REVISIÓN
EL PROCESO DE INSPECCIÓN
Requerimiento
Etapa Cambio
Desarrollo
Software
Mejora de
Procesos
.
Entrada Planeación
Salida
Revisión Reunión
Kickoff de Edición
individual
revisión
Siguiente etapa del

desarrollo de
software
13
PROCESO DE REVISIÓN
TIPOS DE REVISIONES (IEEE 1028)
– El proceso básico de una revisión – tal y como se esquematiza aquí –
se aplica a las siguientes variaciones de revisión:
• Inspección,
• walkthrough,
• revisión técnica,
• revisión informal
– Los tipos de revisión difieren en algunos aspectos del proceso
descrito
– Una diferencia adicional entre las revisiones se presenta
dependiendo de la naturaleza del objeto de la revisión
14
REP-7
TÉCNICAS DE PRUEBAS
PRUEBAS DE CONFIRMACIÓN Y REGRESIÓN
REP-8
PROCESO DE ATENCIÓN DE INCIDENCIAS
17
GESTIÓN DE INCIDENCIAS
REP-9
CONTROL DE VERSIONES - EJEMPLO
19
ANÁLISIS ESTÁTICO
COMPLEJIDAD CICLOMÁTICA
‒ Métrica que mide la complejidad

estática de un programa basado en su
grado de flujo de control.
‒ Mide los caminos linealmente
independientes, como índice de la
testeabilidad y mantenibilidad.
‒ El número ciclomático se define de la
siguiente forma:
• e: número de aristas
• n: número de nodos
• p: número de partes de
programas independientes
inspeccionados (normalmente 1)
‒
20
Valores mayores que 10 indican que
el código debe ser mejorado
REP-10
ANÁLISIS ESTÁTICO
¿QUÉ GRÁFICO DE FLUJO ES MÁS COMPLEJO?
¿Cuál es el valor de la complejidad ciclomática?
1
2 3 4
21
CATEGORIZACIÓN DE LAS
TÉCNICAS DE DISEÑO DE PRUEBA
TRES TIPOS DE TÉCNICAS SISTEMÁTICAS
– Estática (no ejecución)

Evaluación de la documentación,
los listados de código fuente, etc.
– Funcionales (Black Box)

Basado en el comportamiento/
funcionalidad del software
– Estructural (White Box)

Basado en la estructura del
software
REP-11
TIPOS DE TÉCNICAS DE PRUEBAS
Estática Dinámica
Revisiones etc.
Comportamiento
Inspección Analisis Estático
Walkthroughs Estructural Non-funcional Funcional
Desk-checking etc.
etc.
Partición
Control de Usabilidad Equivalente
Control de Flujo
Datos Performance
etc. Análisis de
Valores Límite
etc.
Sentencias
Ejecución Grafo causa-efecto
Simbólica Bifurcación/ Decisión Arcs
Aleatorio
Definición Bifurcación Condición LCSAJ
-Uso Transición de
Combinación
De Bifurcación Estados
Condición
CAJA BLANCA VS. CAJA NEGRA
Caja Negra, apropiada para todos

Aceptación
los niveles pero domina en los
niveles más altos de las pruebas.
Sistema
Caja blanca, utilizada
predominantemente en los
niveles inferiores, para Integración
complementar las pruebas de
Caja Negra.
Componente
REP-12
AUTOMATIZACIÓN DE PRUEBAS
NORMAS Y ESTÁNDARES
 IEEE 829: Estándar para la documentación de pruebas de

software.
 IEEE 1028: Norma para la revisión y la auditoría del software.
 IEEE 1044: Guía para la clasificación de las anomalías.
 ISO 9000: Sistemas de gestión de la calidad.
 ISO 9126: Calidad del producto.
26
REP-13
CÓDIGO DE BUENAS PRÁCTICAS
– El ISTQB establece el siguiente código de ética:

EL PÚBLICO Los probadores de software certificados actuarán en coherencia con el interés público.
EL CLIENTE Y Los probadores de software certificados deberían actuar de una manera que esté en coherencia con el mejor
EMPLEADOR interés de su cliente, empleador e interés público.
EL PRODUCTO Los probadores de software certificados deberían asegurar que los entregables que proporcionan (en
referencia a los productos y sistemas que prueban) cumplan con los mas altos estándares posibles.
EL JUICIO Los probadores de software certificados deberían mantener la integridad e independencia en su juicio
profesional.
LA GESTIÓN Los jefes y líderes de pruebas de software certificados suscribirán y promoverán un método ético para la
gestión de pruebas de software.
LA PROFESIÓN Los probadores de software certificados deberían promover la integridad y reputación de la profesión en
conformidad con el interés público.
LOS COLEGAS Los probadores de software certificados deberían ser justos con sus colegas además de ser de gran ayuda
para ellos y promover la cooperación con los desarrolladores de software.
UNO MISMO Los probadores de software certificados deberían participar en el aprendizaje permanente con relación a la
práctica de su profesión y debería promover la adopción de un enfoque ético en la práctica de la profesión.
27
Gracias por su
atención!
Preguntas?
REP-14

1 JB Istqb P07

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

1 JB Istqb P07

Cargado por

Copyright:

Formatos disponibles

ING, CFTL

Una persona comete un

… que crea un defecto en

… que puede causar un

CICLO DE VIDA DESARROLLO Y PRUEBAS

PROCESO DE PRUEBAS - NIVEL

PROCESO DE PRUEBAS FUNDAMENTAL

Plan de Nivel de proyecto (IEEE 829)

Nivel de pruebas (IEEE 829)

CRITERIOS DE SALIDA - EJEMPLO

*Parámetro: Variable de entrada/salida de los métodos de una unidad de código y /o configuración.

*Parámetro: Variable de entrada/salida de los métodos de una unidad de código y /o configuración.

Siguiente etapa del

PRUEBAS DE CONFIRMACIÓN Y REGRESIÓN

‒ Métrica que mide la complejidad

– Estática (no ejecución)

– Funcionales (Black Box)

– Estructural (White Box)

Walkthroughs Estructural Non-funcional Funcional

Caja Negra, apropiada para todos

 IEEE 829: Estándar para la documentación de pruebas de

– El ISTQB establece el siguiente código de ética:

También podría gustarte