Ilovepdf Merged

ISTQB Foundation Level
_____________________________________________________________
Introducción a la Certi cación
Juan Luis Restituyo

Software Quality Assurance Engineer
juanluisrestituyo@gmail.com
fi
Qué es ISTQB?
_____________________________________________________________
ISTQB: International Software

Testing Quali cations Board.
fi

Objetivos de aprendizaje
_____________________________________________________________
K1: Recordar, reconocer

K2: comprender, explicar, dar
razones, comparar, clasi car,
categorizar, dar ejemplos, resumir
K3: Aplicar, Usar
K4: Analizar

fi

Estructura del exámen: (65%)

_____________________________________________________________
Número de preguntas: 40
Duración del examen: 60 mins
Duración Idioma No nativo: 75 mins

_____________________________________________________________
Introducción a la Certi cación
Juan Luis Restituyo

fi
_____________________________________________________________
Qué son las pruebas?
Juan Luis Restituyo

_____________________________________________________________
Pruebas de software y Ejecución de

pruebas.

Objetivos de las pruebas.

_____________________________________________________________
• Prevenir la aparición de defectos.

• Veri car el cumplimiento de los requerimientos.
• Generar con anza sobre el nivel de calidad del
objeto bajo prueba.
• Encontrar defectos y fallos para corregirlos.
• Proveer información para la toma de decisiones.
• Cumplir estándares o requerimientos regulatorios.
fi
fi

Objetivos de las pruebas

_____________________________________________________________
Los objetivos de las pruebas

pueden variar dependiendo del
contexto, del componente o
sistema bajo prueba y del
modelo de desarrollo.
Objetivos en pruebas de componente.
_____________________________________________________________
• Identi car tantos fallos como sea

posible.
• Incrementar la cobertura de
código.
fi

Objetivos Pruebas de aceptación

_____________________________________________________________
• Veri car si el objeto bajo pruebas

funciona acorde lo esperado.
• Brindar información a los involucrados
para la toma de decisiones.
fi


_____________________________________________________________
Juan Luis Restituyo

_____________________________________________________________
Pruebas vs Depuración
Juan Luis Restituyo

Pruebas
_____________________________________________________________
Depuración
_____________________________________________________________
_____________________________________________________________
Pruebas vs Depuración
Juan Luis Restituyo

_____________________________________________________________
Error, defecto y fallo.
Juan Luis Restituyo

Aseguramiento de Calidad y Pruebas
_____________________________________________________________
Error Defecto Fallo

(Equivocación) (Causa) (Efectos)

_____________________________________________________________
Error, defecto y fallo.
Juan Luis Restituyo

_____________________________________________________________
Causa raíz de un defecto y sus efectos.
Juan Luis Restituyo

Causa raíz de un defecto y sus
efectos.
_____________________________________________________________
_____________________________________________________________
Causa raíz de un defecto y sus efectos.
Juan Luis Restituyo

_____________________________________________________________
Proceso de pruebas
Juan Luis Restituyo

Proceso de pruebas
_____________________________________________________________
• No hay un proceso universal de pruebas.
• El proceso de pruebas dependerá de

diversos factores.
Proceso de pruebas en contexto
_____________________________________________________________
• Modelo de desarrollo utilizado.
• Niveles y tipos de pruebas considerados.
• Riesgos del producto y del proyecto
• Dominio de negocio
• Restricciones operaciones (presupuesto, tiempos, complejidad, etc)
• Políticas y procedimientos
• Estandares internos y externos

Actividades y tareas de prueba
_____________________________________________________________
• Planeación
• Monitoreo y control
• Analisis
• Diseño
• Implementación
• Ejecución
• Finalización
Planeación
_____________________________________________________________
• Objetivos
• Enfoque
• Restricciones del contexto

Monitoreo y control
_____________________________________________________________
• Progreso actual vs plani cado.
• Tomar acción enfocado en los objetivos.

fi
Análisis
_____________________________________________________________
• Qué probar?
• Analizar requerimientos/necesidades
• Documentación técnica
• Reporte de análisis de riesgos

Diseño
_____________________________________________________________
• Cómo probar?
• Diseñar casos de prueba
• Identi cación de data de prueba
• Identi car el ambiente de prueba y

herramientas
fi
fi
Implementación
_____________________________________________________________
• Está todo listo para empezar a probar?
• Crear suite de pruebas y agendar su

ejecución.
• Construir el ambiente de prueba.
• Preparar y cargar la data de prueba.

Ejecución
_____________________________________________________________
• Ejecutar las pruebas manuales/automaticas.
• Comparar resultado actual vs resultado

esperado.
• Reportar dejectos o anomalias detectadas.
Finalización
_____________________________________________________________
• Veri car que todos los defectos hayan sido cerrados.
• Crear un reporte de resumen de los resultados de las

pruebas.
• Noti car a los involucrados los resultados.
• Usar la información para mejorar el proceso de

pruebas.
fi
fi
_____________________________________________________________
Proceso de pruebas
Juan Luis Restituyo

_____________________________________________________________
Artefactos de prueba
Juan Luis Restituyo

_____________________________________________________________
• Son creados como parte del proceso de

prueba.
• ISO/IEC/IEEE 29119-3 puede servir como

guía.
Artefactos
_____________________________________________________________
• Planeación: Uno o más planes de prueba.
• Monitoreo y control: Distintos reportes de pruebas y estatus.
• Análisis: De nición y priorización de condiciones de pruebas.
• Diseño: Casos de prueba
• Implementación: Procedimientos de pruebas, suite de pruebas.
• Ejecución: Resultados de prueba, reporte de defectos y documentación.
• Finalización: Resumen reporte de pruebas.

fi
_____________________________________________________________
Juan Luis Restituyo

_____________________________________________________________
La psicología de las pruebas
Juan Luis Restituyo

_____________________________________________________________
• Colaboración en lugar de batallas.
• Enfatiza los bene cios de las pruebas.
• Comunicar resultados de manera neutral.
• Empatia.
• Comunicación efectiva.
• Mentalidad desarrollador vs probador.

fi
_____________________________________________________________
Juan Luis Restituyo

_____________________________________________________________
Pruebas durante el ciclo de vida de desarrollo
Juan Luis Restituyo

Modelos de desarrollo de software
_____________________________________________________________
• Describe el tipo de actividades realizadas

en cada etapa en un proyecto de
desarrollo de software.
• Describe la relación entre estas actividades

y su cronología.
Características para unas buenas
pruebas
_____________________________________________________________
• Para cada actividad de desarrollo, hay una

actividad de prueba asociada.
• Cada nivel de pruebas tiene objetivos

especí cos.
• Probadores participan en discusiones y

re namientos.
fi
fi
Modelos de desarrollo comunes
_____________________________________________________________
Ejemplos de modelos iterativos
_____________________________________________________________
• Rational Uni ed Process (RUP)
• Scrum
• Kanban
• Spiral
fi
Consideraciones
_____________________________________________________________
• Son seleccionados y adaptados al contexto

del producto y el proyecto.
• Multiples unidades de negocio pueden ser

parte del mismo proyecto.
• COTS (commercial o -the-shelf) se enfocan

en integration e interoperatividad.
ff
_____________________________________________________________
Pruebas durante el ciclo de vida de desarrollo
Juan Luis Restituyo

_____________________________________________________________
Niveles de prueba
Juan Luis Restituyo

Niveles de prueba
_____________________________________________________________
Aceptación
Sistema
Integración
Componente
Características
_____________________________________________________________
• Objetivos especí cos
• Base de prueba
• Objeto de prueba
• Defectos típicos
• Enfoque y responsabilidades
fi
_____________________________________________________________
Niveles de prueba
Juan Luis Restituyo

_____________________________________________________________
Niveles de prueba: Pruebas de componente
Juan Luis Restituyo

Objetivos
_____________________________________________________________
• Reducir el riesgo
• Veri car el comportamiento funcional y no funcional.
• Crear con anza sobre la calidad de los componentes.
• Encontrar defectos.
• Prevenir que los defectos pasen a etapas posteriores.

fi
fi
Base de prueba
_____________________________________________________________
• Diseño detallado.
• Código.
• Modelo de datos.
• Especi caciones de componente.

fi
Objeto bajo prueba
_____________________________________________________________
• Componentes, unidades o módulos.
• Código y estructuras de datos.
• Clases y archivos.
• Módulos de BD.
Defectos Típicos
_____________________________________________________________
• Funcionalidad incorrecta.
• Problemas de ujo de datos.
• Código o lógica incorrecta.

fl
_____________________________________________________________
Niveles de prueba: Pruebas de componente
Juan Luis Restituyo

_____________________________________________________________
Niveles de prueba: Pruebas de integración
Juan Luis Restituyo

Objetivos
_____________________________________________________________
• Veri car el funcionamiento de las interfases.
• Crear con anza sobre la calidad de las interfases.
• Prevenir que los defectos pasen a etapas posteriores.

fi
fi
Base de prueba
_____________________________________________________________
• Diseño de sistema.
• Diagrama de secuencia.
• Especi caciones de comunicación y protocolos.
• Casos de uso.
• Arquitectura a nivel de componente o sistema.
• Flujos de datos.
• De niciones de interfases externas.

fi
fi
Objeto bajo prueba
_____________________________________________________________
• Subsistemas.
• Bases de Datos.
• Infraestructura.
• Interfases
• APIs.
• Microservicios.
Defectos típicos
_____________________________________________________________
• Data incorrecta, ausente o formato incorrecto.
• Secuencia de llamadas incorrectas.
• Fallos en comunicación entre componentes.
• Asunciones incorrectas sobre las medidas de

los datos pasados entre componentes.
_____________________________________________________________
Niveles de prueba: Pruebas de integración
Juan Luis Restituyo

_____________________________________________________________
Niveles de prueba: Pruebas de sistema
Juan Luis Restituyo

Objetivos
_____________________________________________________________
• Veri car el comportamiento funcional y no funcional.
• Crear con anza sobre la calidad del sistema.
• Prevenir que los defectos pasen a etapas posteriores

o producción.
fi
fi
Base de pruebas
_____________________________________________________________
• Especi caciones de sistema (funcionales y no funcionales)
• Reporte de análisis de riesgo
• Casos de uso
• Epics e historias de usuario
• Modelos de comportamiento del sistema
• Diagrama de estados
• Manual de usuario y de sistema

fi
Objeto bajo prueba
_____________________________________________________________
• Aplicaciones
• Sistemas de hardware/software
• Sistemas operativos
• Sistema bajo pruebas (SUT)
• Sistema de con guración y data

fi
Defectos típicos
_____________________________________________________________
• Cálculos incorrectos
• Comportamiento no esperado (funcional o no funcional)
• Flujo de datos incorrecto
• Fallo en realizar tareas solicitadas por el usuario
• Fallo del sistema en el ambiente de pruebas
• No funciona igual que lo descrito en las especi caciones y/o

manual de usuario.
fi
_____________________________________________________________
Niveles de prueba: Pruebas de sistema
Juan Luis Restituyo

_____________________________________________________________
Niveles de prueba: Pruebas de aceptación
Juan Luis Restituyo

Objetivo
_____________________________________________________________
• Establecer niveles de con anza en la calidad

del sistema bajo pruebas.
• Veri car que el sistema este completo y si

funciona acorde a lo esperado.
• Veri car que los ujos de negocio de los

usuarios nales están completos.
fi
fi
fi
fl
fi
Usos comunes
_____________________________________________________________
• Pruebas de aceptación de usuario
• Pruebas de aceptación operacional
• Pruebas de aceptación contractuales o

regulatorias
• Pruebas alfa y beta

Base de pruebas
_____________________________________________________________
• Procesos de negocio
• Requerimientos de usuario
• Regulaciones, contratos y estandares
• Casos de uso / historias de usuario
• Requerimientos de sistema
• Documentación de usuario y sistema
• Procedimientos de instalación
• Reporte de análisis de riesgos

Objeto bajo prueba
_____________________________________________________________
• Sistema bajo pruebas (SUT)
• Con guración de sistema y datos
• Procesos de negocio
• Sistemas de recuperación
• Procesos de mantenimiento y operaciones
• Formularios
• Reportes
• Datos existentes y convertidos de producción

fi
Defectos típicos
_____________________________________________________________
• Flujo del sistema no cumple las necesidades del

negocio.
• Reglas de negocio no implementadas correctamente.
• Sistema no satisface regulaciones contractuales.
• Fallos no funcionales (vulnerabilidades de seguridad,

bajo rendimiento, operación incorrecta bajo una
plataforma soportada)
_____________________________________________________________
Niveles de prueba: Pruebas de aceptación
Juan Luis Restituyo

_____________________________________________________________
Tipos de prueba
Juan Luis Restituyo

Tipo de prueba
_____________________________________________________________
• Es un grupo de actividades de prueba

destinadas a probar características
especí cas de un software, basado en
objetivos de prueba especí cos.
fi
fi
Pruebas de caja negra vs caja blanca
_____________________________________________________________
Pruebas funcionales
_____________________________________________________________
• Evaluar lo el software debe hacer.
• Se realizan en todos los niveles de prueba.
• Se le llama pruebas de caja negra.
• Requieren cierto conocimiento del software y los procesos de negocio.
• La cobertura de pruebas se mide en base a las funcionalidades

probadas vs el total.
• Ejemplo: 7/10 —> 70%

Pruebas no funcionales
_____________________________________________________________
• Evaluan caracteristicas o atributos de calidad

no funcional.
• Se pueden realizar en cualquier nivel de

pruebas.
• Requieren conocimiento sobre debilidades en

el diseño o tecnología usada.
Pruebas de caja blanca
_____________________________________________________________
• Evalúan el sistema en base a su estructura interna.
• En las pruebas de componente su cobertura se

mide por la cantidad total de componentes vs
componentes probados.
• Se enfocan mucho en la arquitectura del sistema.
• Requieren conocimiento sobre el código.

Pruebas relacionadas a cambios
_____________________________________________________________
• Deben hacerse siempre que ocurren cambios en

el sistema.
• Pruebas de con rmación
• Pruebas de regresión
• Ambas se realizan en todos los niveles de prueba.

fi
Tipos de prueba y niveles de prueba
_____________________________________________________________
• Todos los tipos de prueba mencionados se

pueden llevar a cabo en todos los niveles
de prueba.
• No es obligatorio o necesario para todos

los sistemas implementar todos los tipos
de prueba.
_____________________________________________________________
Tipos de prueba
Juan Luis Restituyo

_____________________________________________________________
Pruebas de mantenimiento
Juan Luis Restituyo

_____________________________________________________________
• Los cambios son inevitables.
• Cada vez que ocurren cambios deben

hacerse las pruebas de mantenimiento.
• El alcance de las pruebas va a depender del

nivel de riesgo de los cambios, del tamaño
del sistema y del tamaño de los cambios.
Activadores de mantenimiento
_____________________________________________________________
• Modi caciones en el código.
• Migraciones.
• Actualizaciones de versiones.
• Agregar o retirar componentes o

interfases.
fi
Análisis de impacto
_____________________________________________________________
• Evaluar el impacto de los cambios.
• Basado en las especi caciones
• Casos de prueba
• Documentación
• Conversaciones
• Dominio de las personas involucradas
• Herramientas
fi
_____________________________________________________________
Juan Luis Restituyo

_____________________________________________________________
Pruebas estáticas
Juan Luis Restituyo

Pruebas estáticas vs dinámicas
_____________________________________________________________
Pruebas estáticas
_____________________________________________________________
• Examinar artefactos de software.
• Análisis estático.
• Es importante para sistemas críticos

(aviación, médicas, software nuclear)
_____________________________________________________________
Pruebas estáticas
Juan Luis Restituyo

_____________________________________________________________
Artefactos examinables por pruebas estáticas
Juan Luis Restituyo

Artefactos
_____________________________________________________________
• Especi caciones
• Epics, historias de usuario, criterios de aceptación.
• Especi cación y diseño de arquitectura.
• Código fuente.
• Productos de trabajo de prueba
• Guías de usuario
• Páginas web
• Contratos, planes de proyecto
• Con guraciones
fi
fi
fi
_____________________________________________________________
Artefactos examinables por pruebas estáticas
Juan Luis Restituyo

_____________________________________________________________
Bene cios de las pruebas estáticas
Juan Luis Restituyo

fi
_____________________________________________________________
• Detección temprana de defectos.
• Mayor e ciencia detectando y corrigiendo defectos.
• Identi ca defectos que en pruebas dinámicas son más difíciles de encontrar.
• Previene aparición de defectos.
• Reduce el tiempo y costo de las pruebas.
• Reduce el tiempo y costo de desarrollo.
• Mejora la comunicación entre el equipo.

fi
fi
fi
_____________________________________________________________
Juan Luis Restituyo

fi
_____________________________________________________________
Diferencias entre pruebas estáticas y dinámicas
Juan Luis Restituyo

Diferencias
_____________________________________________________________
Pruebas Estáticas Pruebas dinámicas
Encuentran defectos en los artefactos Encuentran fallos en tiempo de ejecución.
Se puede encontrar el defecto con menos Hay que reproducir las condiciones puntuales bajo
esfuerzo. las que se muestra el defecto.
Se enfoca en aspectos visibles y de

Mejora la consistencia de los artefactos.
comportamiento.
Los defectos encontrados son más baratos de Los defectos encontrados son más caros para
corregir. corregir.
Defectos típicos: pruebas estáticas
_____________________________________________________________
• Defectos en las especi caciones
• Defectos en el diseño
• Defectos en el código
• Desviación de estándares
• Vulnerabilidades de seguridad
• Defectos de mantenimiento
fi
_____________________________________________________________
Diferencias entre pruebas estáticas y dinámicas
Juan Luis Restituyo

_____________________________________________________________
Proceso de revisión
Juan Luis Restituyo

Proceso de Revisión (Review)
_____________________________________________________________
• Varían de informal a formal.
• Las revisiones formales se caracterizan por la participación

del equipo y documentación de resultados.
• La formalidad se deriva del modelo de desarrollo utilizado, su

madurez, complejidad y cualquier requerimiento regulatorio.
• Estándar ISO (ISO/IEC 20246) incluye más detalles sobre los

procesos de revisión.
Principales actividades
_____________________________________________________________
• Planeación
• Inicio de revisión
• Revisión individual
• Análisis y comunicación de problemas.
• Corrección y reporte
Planeación
_____________________________________________________________
• De nir el alcance
• Estimar tiempo y esfuerzo
• Identi car características de la revisión
• Seleccionar los participantes
• De nir el criterio de entrada y salida
fi
fi
fi
Inicio de revisión
_____________________________________________________________
• Distribuir los artefactos o productos de

trabajo.
• Explicar el alcance, objetivos, proceso,

roles y artefactos a los participantes.
• Responder preguntas a los participantes.

Revisión individual
_____________________________________________________________
• Revisar todo o parte de los productos de

trabajo.
• Registrar potenciales defectos,

recomendaciones y preguntas.
Análisis y documentación de
problemas
_____________________________________________________________
• Comunicar potenciales problemas identi cados.
• Analizar potenciales defectos
• Evaluar y documentar características de calidad.
• Evaluar los hallazgos contra los criterios de

salida.
fi
Corrección y reporte
_____________________________________________________________
• Crear el reporte de defectos/problemas.
• Corregir defectos encontrados.
• Comunicar los defectos a los involucrados.
• Levantar métricas
• Revisar si los criterios de salida se cumplen.
• Aceptar el artefacto cuando se cumple el criterio de salida.

_____________________________________________________________
Proceso de revisión
Juan Luis Restituyo

_____________________________________________________________
Roles y responsabilidades
Juan Luis Restituyo

_____________________________________________________________
• Autor
• Administración
• Facilitador (moderador)
• Líder de revisión
• Revisores
• Escriba (Secretario)
_____________________________________________________________
Juan Luis Restituyo

_____________________________________________________________
Tipos de revisión
Juan Luis Restituyo

Tipos de revisión
_____________________________________________________________
• Revisión informal
• Tutorial (Walkthrough)
• Revisión técnica
• Inspección
Revisión informal
_____________________________________________________________
• Detectar potenciales defectos.
• No se basa en un proceso formal documentado.
• No requiere reuniones de revisión.
• Uso de cheklist es opcional
• De uso muy común en entornos de desarrollo ágil.

Tutorial (Walkthrough)
_____________________________________________________________
• Se enfoca en encontrar defectos.
• Preparación individual antes de la revisión es opcional.
• La reunión de revisión usualmente la dirige el autor.
• Escriba (secretario) es obligatorio.
• Uso de checklist es opcional.
• Potenciales defectos son registrados y revisados.
• Varía en la práctica de muy informal a muy formal.

Revisión técnica
_____________________________________________________________
• Se enfoca en hacer consensos y detectar potenciales problemas.
• Revisores son roles similares al autor y en ocaciones expertos en

la disciplina en cuestión.
• La preparación individual es requerida.
• Uso de check list son opcionales.
• Producen como resultado registro de potenciales defectos.

Inspección
_____________________________________________________________
• Se enfoca en detectar potenciales defectos.
• Sigue un proceso formal de nido, documenta el proceso y los resultados.
• Usa roles claramente de nidos.
• Preparación individual antes de la revisión es obligatoria.
• Revisores son roles similares al autor y en ocaciones expertos en la disciplina en cuestión.
• Se especi can los criterios de entrada y salida.
• La revisión es liderada por un facilitador (moderador) entrenado.
• Autor no puede ser líder de revisión, ni escriba.

fi
fi
fi
_____________________________________________________________
Tipos de revisión
Juan Luis Restituyo

_____________________________________________________________
Aplicando revisiones y factores de éxito
Juan Luis Restituyo

Aplicando revisiones
_____________________________________________________________
• Ad hoc
• Check list
• Escenarios
• Perspectiva
• Roles
Factores de éxito
_____________________________________________________________
• Cada revisión debe tener objetivos claros.
• Las técnicas de revisión se deben seleccionar acorde a los objetivos.
• Grandes documentos se revisan y trabajan en fragmentos pequeños.
• Los participantes deben tener tiempo de prepararse.
• La administración debe apoyar el proceso de revisión.
• Las revisiones se deben integrar en las políticas de calidad de la

empresa.
Consideraciones sobre los
participantes
_____________________________________________________________
• Utilizar las personas apropiadas para los objetivos propuestos.
• Los probadores son revisores muy valiosos.
• Participantes deben enfocarse en los detalles.
• Los defectos encontrados son comunicados, apreciados y manejados de

manera objetiva.
• La revisión se debe en un ambiente de con anza.
• Participantes deben comunicarse de manera neutral.
• Una cultura de aprendizaje y de mejora continua debe promoverse.

fi
_____________________________________________________________
Aplicando revisiones y factores de éxito
Juan Luis Restituyo

_____________________________________________________________
Categorías de técnicas de diseño de pruebas
Juan Luis Restituyo

Categorías de técnicas de prueba
_____________________________________________________________
• Complejidad del sistema o componente.
• Estandares regulatorios.
• Requerimientos contractuales o de usuario.
• Niveles y tipos de riesgo.
• Documentación disponible.
• Conocimiento y habilidades de los probadores.
• Herramientas disponibles.
• Tiempo y presupuesto.

Categorías de técnicas de prueba
_____________________________________________________________
• Técnicas de prueba de caja negra.

(Basadas en especi caciones)
• Técnicas de prueba de caja blanca.

(Basadas en estructura)
• Técnicas de prueba basadas en experiencia.

fi
_____________________________________________________________
Categorías de técnicas de diseño de pruebas
Juan Luis Restituyo

_____________________________________________________________
Técnicas de prueba de caja negra
Juan Luis Restituyo

_____________________________________________________________
• Particiones equivalentes
• Análisis de valor límite
• Tablas de decisión
• Pruebas de transición de estados
• Pruebas de casos de uso

_____________________________________________________________
Juan Luis Restituyo

_____________________________________________________________
Técnica de particiones equivalentes
Juan Luis Restituyo

Técnicas de particiones equivalentes
_____________________________________________________________
Una cuenta de ahorros ene diferentes tasas de interés

dependiendo del balance de la cuenta. Para una cuenta
con balance entre $0.00 y $100.00 genera 3%, 5% si la
cuenta está entre $100.01 y $1000.00 y 7% si la cuenta
está por encima de $1000.00
ti
_____________________________________________________________
Partición
Válida (3%) Válida (5%) Válida (7%)
inválida
<0 0.00 - 100.00 100.01 - 1,000.00 > 1,000.00

_____________________________________________________________
• Se identi caron 4 particiones, aunque en las

especi caciones solo se mencionaron 3.
• Identi car una partición inválida a la derecha.
• Una entrada no numérica también puede ser una

partición inválida.
• Se debe cubrir cada partición (válida/inválida) al menos

una vez.
fi
fi
fi
_____________________________________________________________
Técnica de particiones equivalentes
Juan Luis Restituyo

_____________________________________________________________
Técnica de análisis de valor límite
Juan Luis Restituyo

Técnicas de análisis de valor límite
_____________________________________________________________
Especi caciones: Un estudiante puede tener una

cali cación entre 0 y 100:
• U lizamos el valor mínimo y máximo para
establecer los límites.
• Adicional al mínimo y máximo agregamos el valor
anterior y siguiente.
ti
fi
fi

Técnicas de análisis de valor límite

_____________________________________________________________
Mínimo Máximo
-1 0 1 99 100 101
Límite abierto
_____________________________________________________________
• Es cuando un límite no tiene un valor mínimo o

máximo o no ha sido de nido.
• Son más difíciles de probar.
• Un enfoque puede ser indagar en la estructura interna.
• Se puede aplicar esta técnica a otros tipos de datos,

ej campos alfanuméricos.
fi
_____________________________________________________________
Técnica de análisis de valor límite
Juan Luis Restituyo

_____________________________________________________________
Técnica de tablas de decisión
Juan Luis Restituyo

_____________________________________________________________
• Es una técnica de prueba basada en especi cación.

• Está más enfocada en la lógica y reglas de negocio.
• Es una buena forma de lidiar con combinaciones.
• Proporciona una forma sistemá ca de establecer
reglas de negocio complejas.
ti
fi

Cómo usar tablas de decisión

_____________________________________________________________
• Iden car un sistema o subsistema que reaccione a

una combinación de entradas.
• El sistema no debe contener demasiadas
combinaciones de lo contrario sería inmanejable.
• Colocar los aspectos a combinar en una tabla.
ti
fi

Ejemplo
_____________________________________________________________
• Una aplicación de préstamos en la que se recibe

como entrada el monto a pagar mensual y la
can dad de años del préstamo. Las dos condiciones
serían el pagaré y la nalización del préstamo.
ti
fi
Ejemplo
_____________________________________________________________
•Iden camos los valores de las combinaciones de (V y F).
◦Con 2 condiciones, que ambas pueden ser verdaderas o falsas
tendríamos 4 combinaciones. (valor de la condición ^ número de cosas
a combinar).
Condiciones Regla 1 Regla 2 Regla 3 Regla 4
Monto a pagar
Fin del préstamo

ti
fi
 

Ejemplo
_____________________________________________________________
•Iden camos los valores de las combinaciones de (V y F).
◦Con 2 condiciones, que ambas pueden ser verdaderas o falsas
tendríamos 4 combinaciones. (valor de la condición ^ número de cosas
a combinar).
Monto a pagar V V F F
Fin del préstamo V F V F

ti
fi
 

Ejemplo
_____________________________________________________________
•Lo siguiente es iden car las salidas.

Monto a pagar V V F F
Fin del préstamo V F V F
Acciones / Salidas
Procesar Monto V V
Procesar Fin préstamo V V
ti
fi
Puntos clave
_____________________________________________________________
• Esta técnica es muy buena para descubrir omisiones

o ambigüedades en las especi caciones.
• El paso nal es escribir casos de prueba contra cada
una de las reglas desglosadas en la tabla.
fi
fi

Ejemplo 2
_____________________________________________________________
•Si eres un nuevo cliente y quieres solicitar una tarjeta de lealtad,

ob enes un 15% de descuento en tus compras de hoy. Si eres un
cliente existente y enes una tarjeta de lealtad ob enes un 10%
de descuento. Si enes un cupón ob enes 20% de descuento
(pero no puede ser usado con el nuevo cliente).
•Construir la tabla de decisión para este caso

ti
ti
ti
ti

ti
Ejemplo2
_____________________________________________________________
Condiciones Regla 1 Regla 2 Regla 3 Regla 4 Regla 5 Regla 6 Regla 7 Regla8
Nuevo cliente (15%)
Tarjeta lealtad (10%)
Cupón (20%)
Resultado
% Descuento
Ejemplo2
_____________________________________________________________
Condiciones Regla 1 Regla 2 Regla 3 Regla 4 Regla 5 Regla 6 Regla 7 Regla8
Nuevo cliente (15%) V V V V F F F F
Tarjeta lealtad (10%) V V F F V V F F
Cupón (20%) V F V F V F V F
Resultado
% Descuento X X 20% 15% 30% 10% 20% 0%

_____________________________________________________________
Juan Luis Restituyo

_____________________________________________________________
Técnica de transición de estados
Juan Luis Restituyo

_____________________________________________________________
• Se aplica para sistemas que enen un número nito de
diferentes estados.
• Cualquier sistema en que ob enes resultados diferentes
con las mismas entradas dependiendo que pasó antes
es un sistema de estados nito.
• Puede ser representado en un diagrama de estados.
• El modelo puede ser tan abstracto o tan detallado como
necesites.

fi
ti
ti

fi

Partes básicas de un modelo de

transición de estados
_____________________________________________________________
• Los estados en que puede estar el so ware.

• Transición de un estado a otro.
• Los eventos que causan las transiciones.
• Las acciones que resultan de una transición.

ft

Ejemplo
_____________________________________________________________
• Re rar dinero de un ATM

ti
_____________________________________________________________
Juan Luis Restituyo

_____________________________________________________________
Técnica de casos de uso
Juan Luis Restituyo

_____________________________________________________________
• Un caso de uso es una descripción de uso par cular del
sistema por un actor.
• Ayuda a iden car casos que cubren el sistema de inicio
a n.
• Los actores son generalmente personas (usuarios) pero
también pueden ser otros sistemas o sub-sistemas.
• Los casos de uso se de nen en términos del autor, de lo
que puede y no puede hacer.
fi

ti
fi

fi
ti


_____________________________________________________________
• Generalmente usan un lenguaje de negocio y no técnico.
• Sirven de base para creación de casos de prueba de
aceptación.
• Cada caso debe especi car cualquier pre-condición que
se deba cumplir para ejecutar dicho caso.
• Cada caso debe especi car cualquier post-condición o
resultados y descripciones de estados nales luego de
ser ejecutado.

fi
fi
fi

Ejemplo
_____________________________________________________________
_____________________________________________________________
Juan Luis Restituyo

_____________________________________________________________
Técnicas de prueba de caja blanca
Juan Luis Restituyo

_____________________________________________________________
• Cobertura de sentencia (Statement

coverage)
• Cobertura de decisión (Decision coverage)

_____________________________________________________________
Juan Luis Restituyo

_____________________________________________________________
Cobertura de sentencia (Statement coverage)
Juan Luis Restituyo

Cobertura de sentencia
_____________________________________________________________
• También conocido como Line coverage o

Segment coverage.
• Prueba las sentencias potencialmente

ejecutables.
• La cobertura se mide en base a la cantida de de

sentencias probadas vs el total de sentencias.
Ejemplo
_____________________________________________________________
READ X
READ Y
I F X>Y THEN Z = 0
ENDIF

Ejemplo 2
_____________________________________________________________
READ X •
•
Casos de prueba:
Test A: X= 2, Y = 3 El valor de Z = 8
READ Y • Test B: X =0, Y = 25 El valor de Z = 50
• Test C: X =47, Y = 1 El valor de Z = 49
Z=X+2*Y
• Cobertura: 83% (5/6 statements cubiertos)
IF Z > 50 THEN
PRINT large Z • Test D: X = 20, Y = 25 El valor de Z = 70
ENDIF • Cobertura: 100% (6/6 statements cubiertos)

🡪
🡪
🡪

Ejemplo 3
_____________________________________________________________
_____________________________________________________________
Cobertura de sentencia (Statement coverage)
Juan Luis Restituyo

_____________________________________________________________
Cobertura de decisión
Juan Luis Restituyo

_____________________________________________________________
• Tambien conocido como branch coverage

(cobertura de ramas)
• Cubre tanto las condiciones verdaderas

como las falsas.
• Una decisión puede ser una condicional o

bucle.
Ejemplo
_____________________________________________________________
READ X
READ Y
I F X>Y THEN Z = 0
ENDIF

Ejemplo 2
_____________________________________________________________
_____________________________________________________________
Juan Luis Restituyo

_____________________________________________________________
Valor de cobertura de sentencia y de decisión
Juan Luis Restituyo

Valor de cobertura de sentencia y de
decisión
_____________________________________________________________
• 100% cobertura de sentencia implica todas las

sentencias probadas al menos 1 vez.
• 100% cobertura de decisión implica ejecutar todas

las deciones o ramas incluso si no hay una rama de
sentencia falsa explicita.
• 100% cobertura de decisión garantiza 100%

cobertura de sentencia.
_____________________________________________________________
Valor de cobertura de sentencia y de decisión
Juan Luis Restituyo

_____________________________________________________________
Técnicas basadas en la experiencia
Juan Luis Restituyo

Técnicas basada en la experiencia
_____________________________________________________________
• El conocimiento y experiencia de las personas es de suma

importancia para aplicar esta técnica.
• La experiencia de personas técnicas y de negocio es

requerida.
• Pruebas basadas en la experiencia son pruebas basadas en

la estructura del Sistema.
• Este tipo de prueba se da más para sistemas de bajo riesgo.

Técnicas basada en la experiencia
_____________________________________________________________
• Predicción de errores (Error guessing)
• Pruebas exploratorias
• Pruebas basadas en listas de

comprobación (check lists)
_____________________________________________________________
Técnicas basadas en la experiencia
Juan Luis Restituyo

_____________________________________________________________
Gestión de pruebas y equipos de prueba
Juan Luis Restituyo

_____________________________________________________________
Gestión de pruebas y equipos de prueba
Juan Luis Restituyo

_____________________________________________________________
Gestión de pruebas: Nivel de independencia
Juan Luis Restituyo

Nivel de independencia
_____________________________________________________________
• Probadores no independientes.
• Probadores/desarrolladores independientes
dentro del equipo.
• Equipo de pruebas dentro de la organización.
• Equipo de pruebas fuera de la organización.

Bene cios de las pruebas
independientes
_____________________________________________________________
• Usan otro enfoque y son roles con

habilidades diferentes.
• Veri ca, cuestiona y refuta suposiciones

durante la especi cación de requerimientos.
• No hay presión de la compañía o

compañeros.
fi
fi
fi
Inconvenientes de las pruebas
independientes
_____________________________________________________________
• Aislamiento del equipo de desarrollo.
• Desarrolladores pueden perder sentido de

la calidad.
• Son vistos como cuellos de botella.
• Pueden no tener cierta información a mano.

_____________________________________________________________
Gestión de pruebas: Nivel de independencia
Juan Luis Restituyo

_____________________________________________________________
Tareas del líder de pruebas y probadores
Juan Luis Restituyo

Tareas del líder de pruebas
_____________________________________________________________
• Desarrollar o revisar una política y una estrategia de prueba para

la organización.
• Plani car las actividades de prueba.
• Escribir y actualizar el plan de pruebas.
• Seguimiento al proceso de pruebas.
• Seleccionar / diseñar métricas para seguimiento del proceso.
• Motivar, promover y desarrollar las habilidades de los probadores.

fi
Tareas del probador (tester)
_____________________________________________________________
• Revisar y contribuir al plan de pruebas.
• Analizar y revisar los requerimientos e historias de usuario.
• Diseñar e implementar casos de prueba.
• Preparar y buscar datos de prueba.
• Ejecutar las pruebas.
• Automatizar las pruebas según sea necesario

_____________________________________________________________
Tareas del líder de pruebas y probadores
Juan Luis Restituyo

_____________________________________________________________
Propósito y contenido del plan de pruebas
Juan Luis Restituyo

Plan de pruebas
_____________________________________________________________
• Es una actividad continua durante el ciclo de

vida de proyecto.
• Se puede documentar en un plan maestro de

prueba y otros separados por niveles de
prueba.
Plan de pruebas
_____________________________________________________________
• Alcance, objetivos y riesgos de las pruebas.
• De nición del enfoque de pruebas.
• Integrar y coordinar actividades de prueba.
• Seleccionar métricas para monitoreo y control.
• Presupuesto para actividades de prueba.
• Determinar el nivel de detalle y estructura de la documentación.

fi
Plan de pruebas: ISO/IEC/IEEE 29119-3
_____________________________________________________________
• Alcance, objetivos y riesgos de las pruebas.
• De nición del enfoque de pruebas.
• Integrar y coordinar actividades de prueba.
• Seleccionar métricas para monitoreo y control.
• Presupuesto para actividades de prueba.
• Determinar el nivel de detalle y estructura de la documentación.

fi
_____________________________________________________________
Propósito y contenido del plan de pruebas
Juan Luis Restituyo

_____________________________________________________________
Estrategia y enfoque de pruebas
Juan Luis Restituyo

_____________________________________________________________
• Analítica
• Basada en modelos
• Metodica
_____________________________________________________________
• Cumplimiento de procesos
• Aversión a la regresión
• Dirigida (o consultada)
• Reactiva
_____________________________________________________________
Juan Luis Restituyo

_____________________________________________________________
Criterios de entrada y salida
Juan Luis Restituyo

_____________________________________________________________
• De nición de listo (DoR)
• De nición de completado (DoD)

fi
fi
_____________________________________________________________
Juan Luis Restituyo

_____________________________________________________________
Cronograma de ejecución de pruebas
Juan Luis Restituyo

_____________________________________________________________
• De ne cuándo se van a ejecutar las pruebas.
• Cual es el orden de ejecución según

prioridad.
• Tomar en cuenta la prioridad relativa de los

casos de prueba.
fi
Ejemplo de prioridad
_____________________________________________________________
Caso de prueba Prioridad Dependencias Orden de ejecución
Caso-01 3 NA Caso-01
Caso-04 7 Caso-03 Caso-04
Caso-05 9 Caso-01 Caso-02

_____________________________________________________________
Juan Luis Restituyo

_____________________________________________________________
Factores que in uencian el esfuerzo de pruebas
Juan Luis Restituyo

fl
Factores que in uencian el esfuerzo
de pruebas
_____________________________________________________________
• Características del producto:
• Riesgo asociado al producto
• Calidad de las bases de prueba
• Tamaño del producto
• Complejidad del dominio del producto
• Requerimientos funcionales, no funcionales y regulatorios.
• Nivel requerido de documentación.

fl
de pruebas
_____________________________________________________________
• Características del proceso de desarrollo:
• Estabilidad y madurez de la organización.
• Enfoque de pruebas.
• Herramientas
• Proceso de pruebas
• Presión de tiempo
fl
de pruebas
_____________________________________________________________
• Características de las personas:
• Habilidades
• Experiencia
• Cohesión y liderazgo del equipo

fl
de pruebas
_____________________________________________________________
• Resultado de las pruebas
• Cantidad y severidad de defectos

encontrados.
• Cantidad de retrabajo requerida.

fl
_____________________________________________________________
Factores que in uencian el esfuerzo de pruebas
Juan Luis Restituyo

fl
_____________________________________________________________
Técnicas de estimación de pruebas
Juan Luis Restituyo

_____________________________________________________________
• Basada en métricas
• Basada en expertos
_____________________________________________________________
Juan Luis Restituyo

_____________________________________________________________
Monitoreo y control de pruebas
Juan Luis Restituyo

Monitoreo y control
_____________________________________________________________
• Re-priorización de las pruebas
• Cambiar el cronograma de pruebas
• Re-evaluar cuando un elemento de

prueba cumple un criterio de entrada/
salida.
Métricas usadas
_____________________________________________________________
• Porcentaje de trabajo completado en preparación de ambientes
de prueba.
• Porcentaje de trabajo completado en ejecución de casos de

prueba.
• Información de defectos
• Cobertura de prueba de requerimientos
• Costo de las pruebas

Reportes de prueba
_____________________________________________________________
Propósito Contenido Audiencia
* Resumen de las pruebas

realizadas.
* Desviaciones con respecto al
Equipo de pruebas
plan.
Resumir y comunicar información de Equipo de desarrollo
las actividades de prueba, durante y * Estatus del producto y calidad.
Usuarios de negocio
al nalizar las pruebas. * Impedimentos.
Involucrados en el proyecto
* Metrics de defectos, casos de
(stakeholders).
prueba, cobertura, etc.
* Riesgos residuales
* Artefactos de trabajo producidos.
fi


_____________________________________________________________
Monitoreo y control de pruebas
Juan Luis Restituyo

_____________________________________________________________
Gestión de con guración
Juan Luis Restituyo

fi
_____________________________________________________________
• Elementos del software únicos, versionados y
con seguimiento.
• Elementos de prueba gestionados únicos,

versionados y con seguimiento.
• Documentación y elementos del software

referenciados de manera clara.
fi
_____________________________________________________________
Juan Luis Restituyo

fi
_____________________________________________________________
Pruebas basadas en riesgos
Juan Luis Restituyo

_____________________________________________________________
• Riesgos del producto
• Riesgos del proyecto

_____________________________________________________________
• Se enfoca centralmente en el análisis de

riesgo para:
• Priorizar las pruebas.
• Determinar las técnicas de prueba.
• Niveles de prueba.
_____________________________________________________________
Juan Luis Restituyo

_____________________________________________________________
Gestión de defectos
Juan Luis Restituyo

Reporte de defectos
_____________________________________________________________
• Identi cador
• Un título y una descripción
• Fecha y autor
• Identi cación del elemento de prueba
• Fase de ciclo de vida de desarrollo
• Detalles para reproducirlo (paso a paso, screenshots, video)
• Resultado actual y resultado esperado
• Impacto (que tanto afecta)
• Prioridad (urgencia para corregir)
• Estado
• Referencia (relación con otros defectos/casos de prueba/problemas)

fi
fi
_____________________________________________________________
Gestión de defectos
Juan Luis Restituyo

_____________________________________________________________
Herramientas de apoyo a las pruebas
Juan Luis Restituyo

Herramientas de pruebas
_____________________________________________________________
• La idea es usar el computador para realizar tareas

en las que es bueno.
• Es muy útil para tareas repetitivas.
• Siempre ejecutará la misma secuencia de pasos.
• Es más e ciente en términos de tiempo y uso de

tiempo muerto.
fi
_____________________________________________________________
Herramientas de apoyo a las pruebas
Juan Luis Restituyo

_____________________________________________________________
Clasi cación de las herramientas de prueba
Juan Luis Restituyo

fi
Aspectos generales
_____________________________________________________________
• Una herramienta puede medir los tiempos de respuesta de un

software, para lo cual interactua muy de cerca con este software.
• Establece un tiempo de inicio y un tiempo de n para determinar

el tiempo de respuesta.
• Probe E ect (Efecto sonda): Tiempo adicional a la tarea por el

hecho de estar midiendo la misma.
• Heizenbug: es un defecto que parece desaparecer o

comportarse de otro modo al intentar observarlo en detalle.
ff
fi
Clasi cación
_____________________________________________________________
• Herramientas de gestión de pruebas
• Herramientas de gestión de pruebas y ciclo de vida de

desarrollo (ALM)
• Herramientas de gestión de requerimientos.
• Herramientas de gestión de defectos
• Herramientas de gestión de con guración
• Herramientas de integración contínua (Dev)

fi
fi
Clasi cación
_____________________________________________________________
• Herramientas para pruebas estáticas
• Herramientas de análisis estático

fi
Clasi cación
_____________________________________________________________
• Herramientas para pruebas diseño e

implementación:
• Herramientas de prueba basada en

modelos (Model-base)
• Herramientas de preparación de datos

fi
Clasi cación
_____________________________________________________________
• Herramientas de ejecución de pruebas:
• Herramientas de ejecución de pruebas.
• Herramientas de medición cobertura (D)
• Arnés de prueba (Marco de pruebas

automatizado)
fi
Clasi cación
_____________________________________________________________
• Herramientas para pruebas de rendimiento
• Herramientas para pruebas de

rendimiento
• Herramienta de análisis dinámico

fi
_____________________________________________________________
Clasi cación de las herramientas de prueba
Juan Luis Restituyo

fi
_____________________________________________________________
Bene cios y riesgos de la automatización
Juan Luis Restituyo

fi
Bene cios
_____________________________________________________________
• Reducción de trabajo repetitivo.
• Mayor consistencia.
• Evaluación más objetiva.
• Facilidad de acceso a la información sobre

pruebas.
fi
 
Riesgos
_____________________________________________________________
• Expectativas poco realistas de la herramienta.
• La gente a menudo comete errores al subestimar el tiempo, el costo y el

esfuerzo para la introducción inicial de una herramienta.
• Frecuentemente las personas calculan mal el tiempo y el esfuerzo necesarios

para obtener beneficios significativos y continuos de la herramienta.
• La mayoría de las personas subestiman el esfuerzo requerido para mantener

los activos de prueba generados por la herramienta.
• La gente depende mucho de la herramienta.
• El proveedor de la herramienta podría cerrar, retirar la herramienta o venderla

a otra empresa.


_____________________________________________________________
Bene cios y riesgos de la automatización
Juan Luis Restituyo

fi
_____________________________________________________________
Enfoques de automatización de pruebas
Juan Luis Restituyo

Enfoques y consideraciones
_____________________________________________________________
• Captura de pruebas
• Pruebas guiadas por datos (data-driven)
• Pruebas guiadas por palabras clave

(keyword-driven)
 
_____________________________________________________________
Enfoques de automatización de pruebas
Juan Luis Restituyo

_____________________________________________________________
Principios para la selección de herramientas de prueba
Juan Luis Restituyo

Consideraciones
_____________________________________________________________
• Evaluar la madurez de la organización.
• Identi car oportunidades.
• Entender la tecnología usada por el objeto de pruebas.
• Entender las herramientas de construcción y despliegue.
• Evaluar la herramienta contra requerimientos claros.
• Modelo de licenciamiento (comercial, código abierto, SaaS)
• Evaluar al proveedor
• Evaluar necesidades de entrenamiento o mentoría.
• Implementación de un proyecto piloto

fi
 
_____________________________________________________________
Principios para la selección de herramientas de prueba
Juan Luis Restituyo


Ilovepdf Merged

Cargado por

Información del documento

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

Ilovepdf Merged

Cargado por

Copyright:

Formatos disponibles

ISTQB Foundation Level

Juan Luis Restituyo

ISTQB: International Software

K1: Recordar, reconocer

Estructura del exámen: (65%)

ISTQB Foundation Level

Juan Luis Restituyo

Juan Luis Restituyo

Pruebas de software y Ejecución de

Objetivos de las pruebas.

• Prevenir la aparición de defectos.

Objetivos de las pruebas

Los objetivos de las pruebas

• Identi car tantos fallos como sea

Objetivos Pruebas de aceptación

• Veri car si el objeto bajo pruebas

ISTQB Foundation Level

Juan Luis Restituyo

Juan Luis Restituyo

Juan Luis Restituyo

Juan Luis Restituyo

Error Defecto Fallo

ISTQB Foundation Level

Juan Luis Restituyo

Juan Luis Restituyo

Causa raíz de un defecto y sus efectos.

Juan Luis Restituyo

Juan Luis Restituyo

• No hay un proceso universal de pruebas.

• El proceso de pruebas dependerá de

• Niveles y tipos de pruebas considerados.

• Riesgos del producto y del proyecto

• Restricciones operaciones (presupuesto, tiempos, complejidad, etc)

• Estandares internos y externos

• Restricciones del contexto

• Progreso actual vs plani cado.

• Tomar acción enfocado en los objetivos.

• Reporte de análisis de riesgos

• Diseñar casos de prueba

• Identi cación de data de prueba

• Identi car el ambiente de prueba y

• Está todo listo para empezar a probar?

• Crear suite de pruebas y agendar su

• Construir el ambiente de prueba.

• Preparar y cargar la data de prueba.

• Ejecutar las pruebas manuales/automaticas.

• Comparar resultado actual vs resultado

• Reportar dejectos o anomalias detectadas.

• Veri car que todos los defectos hayan sido cerrados.

• Crear un reporte de resumen de los resultados de las

• Noti car a los involucrados los resultados.

• Usar la información para mejorar el proceso de

Juan Luis Restituyo

Juan Luis Restituyo

• Son creados como parte del proceso de

• ISO/IEC/IEEE 29119-3 puede servir como

• Planeación: Uno o más planes de prueba.

• Monitoreo y control: Distintos reportes de pruebas y estatus.

• Análisis: De nición y priorización de condiciones de pruebas.

• Diseño: Casos de prueba

• Implementación: Procedimientos de pruebas, suite de pruebas.

• Ejecución: Resultados de prueba, reporte de defectos y documentación.

• Finalización: Resumen reporte de pruebas.

Juan Luis Restituyo