1 JB Istqb P01 PDF

ING, CFTL
ALEX VIDAURRE
Curso Taller
ISTQB Foundation
“Taller de Preparación para la Certificación”
Módulo 01
Fundamentos de Pruebas de Software
P-1
www.jbenterprisegroup.com
Agenda
• Fundamentos de Pruebas de SW
– Conceptos y definiciones.
– ¿Por qué es necesario probar?
– ¿Qué son las pruebas?
– Problemática de la comprobación y las pruebas.
– Siete principios de las pruebas.
– Proceso de pruebas fundamental.
– Psicología de las pruebas.
– Código de buenas prácticas.
¿POR QUÉ ES NECESARIO PROBAR?
• ¿QUÉ ES UN “BUG"?
– Error: Acción humana que produce un resultado incorrecto. [Según IEEE

610].
– Defecto: Una manifestación de un error en el software.

• También conocido como bug.
• Si se ejecuta, un defecto puede causar un fallo.
– Fallo: Desviación del componente o del sistema respecto de prestación,

servicio o resultado esperado. (defecto encontrado)
El fallo es un evento; defecto es un

estado de
el software, causado por un error
P-2
ERROR - DEFECTO - FALLA
Una persona comete un

error ...
… que crea un defecto en

el software ...
… que puede causar un

fallo en el funcionamiento
• FIABILIDAD VS. FALLOS
– Fiabilidad: Habilidad de un producto software para llevar a cabo

aquellas funciones requeridas en condiciones establecidas para un
período de tiempo específico, o para un número específico de
operaciones. [ISO 9126]
• ¿Puede estar un sistema libre de errores? (cero defectos,
correcto desde la primera vez)
• ¿Puede ser un sistema de software fiable, pero aún tener fallas?
• ¿Es un software "libre de fallas" siempre fiable?
P-3
• ¿POR QUÉ SE PRODUCEN FALLAS EN EL SOFTWARE?
– Un software está escrito por personas

• Saben algo, pero no todo
• Tienen habilidades, pero no son perfectos
• Cometen errores (fallas)
– Bajo presión creciente para entregar SW en plazos estrictos

• No hay tiempo para comprobar las hipótesis, pero puede ser
errónea
• Los sistemas pueden estar incompletos
– Alguna vez ha escrito software...
• ¿CUÁNTO CUESTAN LAS FALLAS DEL SOFTWARE?
– Enormes sumas de dinero

• Ariane 5 ($ 7 billones)
• Mariner sonda espacial a Venus (250 millones de dólares)
• American Airlines (50 millones de dólares)
– Muy poco o nada en absoluto

• Inconvenientes menores
• Un efecto perjudicial no visible o físico
– El software no es "lineal":
• Una entrada pequeña puede tener un efecto muy grande
P-4
• SISTEMAS DE SEGURIDAD CRÍTICOS
– Las fallas del software pueden provocar la muerte o lesiones

• Un tratamiento de radiación mata a pacientes (therac-25)
• Accidentes de aviones (Aerolíneas Airbus & Korean)
• Sistema de emisión de cartas de un banco (aparentes
sobregiros causan suicidios)
• ¿ENTONCES, POR QUÉ SON NECESARIAS LA PRUEBAS?
– Porque es probable que el software tenga fallas
– Conocer la fiabilidad del software
– Para cubrir el tiempo entre la entrega del software y la fecha de

lanzamiento
– Para demostrar que el software no tiene fallas
– Porque las pruebas está incluidas en el plan del proyecto
– Debido a que las fallas pueden ser muy costosas
– Para evitar ser demandado por los clientes
– Permanecer en el negocio
P-5
¿POR QUÉ NO "PROBARLO TODO"?
3 opcionesProm. 4 menús
/ menú
Un sistema tiene Promedio: 10 cajas de entrada por pantalla

20 pantallas 2 tipos de entrada / campo
(fecha como: 3 de enero o 3/1)
(número como un número entero
o decimal)
Alrededor de 100 valores posibles
• Total de pruebas “exhaustivas” :

20 x 4 x 3 x 10 x 2 x 100 = 480,000 pruebas
• Si un segundo por prueba, 8.000 minutos, 133 horas,
17,7 días
(sin contar los problemas de “dedo”, fallas o re-test)
10 seg = 34 semanas, 1 min = 4 años, 10 min = 40 años
• PRUEBAS EXHAUSTIVAS
– ¿Cuándo es una prueba exhaustiva?

• Cuando todos los probadores están exhaustos
• Cuando todas las pruebas planificadas se han ejecutado
• Realizar pruebas de todas las combinaciones de entradas y
precondiciones
– ¿Cuánto tiempo va a tomar una prueba exhaustiva?

• Tiempo infinito
• No mucho tiempo
• Cantidad de tiempo poco práctica
P-6
• ¿CON CUÁNTAS PRUEBAS ES SUFICIENTE?
– Nunca es suficiente
– Cuando se hizo lo planificado
– Cuando el cliente/usuario es feliz
– Cuando se ha demostrado que el sistema funciona
correctamente
– Cuando se tiene la certeza de que el sistema funciona
correctamente
– Depende de los riesgos del sistema
• ¿CUÁNTAS PRUEBAS REALIZAR?
– Depende del RIESGO

• Riesgo de no identificar fallas importantes
• Riesgo de incurrir en costos de fallas
• Riesgo de liberar el software sin pruebas o con pruebas
insuficientes
• Riesgo de perder la credibilidad y la participación en el
mercado
• Riesgo de perder una ventana de mercado
• Riesgo de un exceso de pruebas, pruebas ineficaces
P-7
• TAN POCO TIEMPO, TANTO POR PROBAR…
– El tiempo asignado a las pruebas siempre será limitado

– Utilizar el RIESGO para determinar :
• Qué vamos a probar primero
• Qué probar más
• Qué tan exhaustivamente probar cada elemento
} Es decir: ¿Dónde
poner énfasis?
• Lo que no se va a probar (esta vez)
– Usamos el RIESGO para

• Asignar el tiempo disponible para las pruebas, según
prioridad para probar…
• PRINCIPIO MÁS IMPORTANTE
Priorizar las pruebas

de modo que,
siempre que se detenga la prueba,
se haya hecho la mejor prueba
en el tiempo disponible.
P-8
CALIDAD
DEFINICIONES DE CALIDAD
Grado en que un conjunto de características inherentes cumple ISO

9000:
con los requisitos 2000
El grado en que un sistema, componente o proceso cumple

IEEE
(1) requerimientos especificados y (2) necesidades o expectativas del 610.12
cliente o usuario.
Totalidad de características de una entidad (actividad, producto, persona,

ISO
organización) que le confieren la aptitud para satisfacer las 8402
necesidades explícitas e implícitas de sus clientes
P-9
CALIDAD
Calidad
Propiedades
(facilidad de
Cumplir requerimientos mantenimiento, Producto libre de defectos
confiabilidad, rendimiento,
etc.)
Actitud para el uso genera

valor agregado

PRUEBAS Y CALIDAD (ISO 9126)
– Algunos atributos de la calidad de un producto software se influyen mutuamente.
– Debido a esta interdependencia y en función del objeto de prueba, los atributos deberán
ser caracterizados por una prioridad a los efectos de ser tenida en cuenta. Por ejemplo
eficiencia versus portabilidad.
– Se realizarán distintos tipos de pruebas con el objeto de medir cada tipo de atributo.
P-10
• PRUEBAS Y CALIDAD
– Las pruebas miden la calidad del software.
– Las pruebas pueden encontrar defectos;

cuando son eliminados, la calidad del software (y posiblemente la
fiabilidad) mejora.
– ¿Qué evaluar en las pruebas?

• La funcionalidad del sistema, operatividad correcta.
• Características no funcionales: fiabilidad, facilidad de uso,
mantenimiento, reutilización, capacidad de prueba, etc.
• OTROS FACTORES QUE INFLUYEN EN LAS PRUEBAS

– Requisitos contractuales
– Requisitos legales
– Requerimientos específicos de la industria
• Ejemplos:
– industria farmacéutica (FDA),
– compilador de pruebas estándar,
– seguridad crítica (relacionada con la seguridad tales
como: el cambio de vía de ferrocarril, el control del
tráfico aéreo, etc.)
Es difícil determinar la cantidad de pruebas

que es suficiente
pero no es imposible
P-11
07 PRINCIPIOS DE LAS PRUEBAS
• PRINCIPIO 1: LAS PRUEBAS DEMUESTRAN LA PRESENCIA DE DEFECTOS
– Las pruebas muestran que los defectos están presentes, pero no pueden
comprobar su ausencia.
– Las pruebas reducen la probabilidad de la presencia de defectos no
descubiertos pero eso no demuestra su ausencia, incluso cuando no se
encontraron defectos durante las pruebas.
– La ausencia de fallos no demuestra que un producto software es correcto.
– El mismo proceso de pruebas puede contener errores.
– Las condiciones de las pruebas pueden ser inapropiadas para detectar
errores.

• PRINCIPIO 2: LAS PRUEBAS EXHAUSTIVAS SON IMPOSIBLES
– Probar todo (todas las combinaciones de entrada y precondiciones) no es

factible, excepto para casos triviales. En lugar de pruebas exhaustivas, se
utilizan técnicas basadas en riesgos y prioridades para orientar el esfuerzo de
las pruebas.
– Pruebas exhaustivas
– Enfoque del proceso de pruebas en el cual el juego de pruebas abarca todas las
combinaciones de valores de entrada y precondiciones.
– Test case explosion (Explosión de casos de prueba )
– El incremento exponencial del esfuerzo y costos para la aplicación de pruebas
exhaustivas.
– Pruebas por muestreo
– La prueba incluye solamente a un subconjunto (generado de forma sistemática o
aleatoria) de todos los posibles valores de entrada.
– En condiciones normales, se utilizan generalmente muestras para probar. Probar todas
las combinaciones posibles de entradas y precondiciones sólo es económicamente
viable en casos triviales.
P-12
• PRINCIPIO 3: PROBAR LO MÁS TEMPRANAMENTE POSIBLE
– Las actividades de pruebas deben comenzar tan pronto como sea posible
en el ciclo de vida del desarrollo del software o sistema y deben ser
orientados sobre objetivos definidos.
– La corrección de un defecto es menos costosa en la medida en que su
detección se realice en fases tempranas del proceso software.
– Se obtiene una máxima rentabilidad cuando los errores son corregidos
antes de la implementación.
– Los conceptos y especificaciones pueden ser probados.
– Los defectos detectados en la fases iniciales son corregidos con menor
esfuerzo y costos.
– La preparación de una prueba también consume tiempo.
– El proceso de pruebas implica más que sólo la ejecución de pruebas.
– Las actividades de pruebas pueden ser preparadas antes de que el
desarrollo se haya completado.
– Las actividades de pruebas (incluidas las revisiones) deben ser ejecutadas
en paralelo a la fase de requerimientos y diseño software.

PRINCIPIO 3: PROBAR LO MÁS TEMPRANAMENTE POSIBLE
Diseño acorde Construcción Producto que

Requerimiento 1 Requerimiento
con los acorde con el trabaja según lo
correcto
requerimientos Diseño esperado
Diseño acorde
Requerimiento Construcción Producto con
Requerimiento 2 con los
correcto con errores bugs
requerimientos
Construcción Producto con

Requerimiento Diseño con
Requerimiento 3 correcto errores
acorde con el fallas en el
Diseño diseño
Error en la
Diseño acorde Construcción Producto
especificación
Requerimiento 4 del
con los acorde con el entregado con
requerimientos Diseño deficiencias
requerimiento
P-13
PRINCIPIO 3: PROBAR LO MÁS TEMPRANAMENTE POSIBLE
COSTO
Costo de Reparación
1X 10X 100X
TIEMPO
Requerimientos Diseño Construcción Pruebas Tiempo de Uso

• PRINCIPIO 4: AGRUPAMIENTO DE DEFECTOS
– Un número pequeño de módulos contienen la mayoría de los defectos

descubiertos durante la prueba, o muestran la mayoría de los fallos
operacionales.
– ¡Encuentre un defecto y encontrará más defectos "cerca"!
– Los defectos aparecen agrupados.
– Cuando se detecta un defecto es conveniente investigar el mismo módulo en el que ha
sido detectado.
– Los probadores (testers) deben ser flexibles

– Habiendo sido detectado un defecto es conveniente volver a considerar el rumbo de
las pruebas siguientes.
– La identificación de un defecto puede ser investigada con un mayor grado de detalle,
por ejemplo, realizando pruebas adicionales o modificando pruebas existentes.
P-14
• PRINCIPIO 5: LA PARADOJA DEL PESTICIDA
– Si el mismo test se repite una y otra vez, eventualmente el mismo grupo de casos
de prueba ya no encontrará nuevos errores. Para vencer esta “paradoja del pesticida”,
los casos de prueba necesitan ser regularmente revisados y estudiados, y se necesitan
escribir nuevos casos de prueba para ejercitar diferentes partes del software o
sistema para encontrar mas defectos potenciales.
– Repetir pruebas en las mismas condiciones no es efectivo.
– Cada caso de prueba debe contar con una combinación única de parámetros de
entrada para un objeto de pruebas particular, de lo contrario no se podrá obtener
información adicional.
– Si se ejecutan las mismas pruebas de forma reiterada no se podrán encontrar
nuevos defectos.
– Las pruebas deben ser revisadas/modificadas regularmente para los distintos
módulos (código).
– Es necesario repetir una prueba tras una modificación del código (corrección de
defectos, nueva funcionalidad).
– La automatización de pruebas puede resultar conveniente si un conjunto de casos
de prueba se deben ejecutar frecuentemente.

• PRINCIPIO 6: LA PRUEBA DEPENDE DEL CONTEXTO
– La prueba se realiza de manera diferente en diferentes contextos. Por ejemplo, el
software de seguridad crítico se prueba de forma diferente a la de un sitio de
comercio electrónico.
– Objetos de prueba diferentes son probados de forma diferente.
– El firmware del motor de un coche requiere pruebas diferentes respecto de aquellas
definidas para una aplicación de e-commerce.
– Entorno de pruebas vs. entorno de producción.
– Las pruebas tienen lugar en un entorno distinto del entorno de producción. El entorno
de pruebas debe ser similar entorno de producción.
– Siempre habrá diferencias entre el entorno de pruebas y el entorno de producción.
Estas diferencias introducen incertidumbre con respecto a las conclusiones que se
pudieran obtener luego de las pruebas.
P-15
• PRINCIPIO 7: LA FALACIA DE LA AUSENCIA DE ERRORES
– Encontrar y reparar defectos no permite prevenir que el sistema
construido no satisfaga las necesidades y expectativas de los usuarios.
– Un proceso de pruebas adecuado detectará los fallos más importantes.
– En la mayoría de los casos el proceso de pruebas no encontrará todos los defectos del
sistema (ver Principio 2), pero los defectos más importantes deberían ser detectados.
– Esto en sí no prueba la calidad del sistema software.
– La funcionalidad del software puede no satisfacer las necesidades y expectativas de los
usuarios.
– No se puede introducir la calidad a través de las pruebas, ella tiene que
construirse desde el principio.
EL PROCESO DE PRUEBAS DURANTE EL PROCESO DE DESARROLLO DE SOFTWARE
‒ Las actividades del Proceso

de Pruebas generalmente se
desarrollan de manera
secuencial, pero en algunos
proyectos, toman lugar de
manera concurrente o
incluso se repiten.
‒ El Proceso de Pruebas es
más que la ejecución de
pruebas
‒ Cada fase del Proceso de
Pruebas tiene lugar de forma
concurrente con las fases del
proceso de Desarrollo de
software.
P-16
PROCESO DE PRUEBAS FUNDAMENTAL
Implementación y Evaluación de
Planificación Análisis y Diseño Cierre
Ejecución Criterios de Salida
•Determinar el alcance, •Revisar la base de pruebas •Desarrollar, implementar •Comprobar los registros •Confirmar los entregables
riesgos, objetivos y y priorizar casos de de las pruebas contra los de pruebas
•Identificar y priorizar las prueba
estrategia criterios de salida
condiciones y requisitos •Finalizar y archivar el
•Determinar los recursos •Crear datos de prueba •Evaluar si son necesarias testware
•Evaluar la “testability” de más pruebas o si los
•Implementar estrategia los requisitos •Crear procedimientos •Entregar el testware
criterios de salida
•Crear cronograma •Diseñar y priorizar casos •Preparar suites especificados deben ser •Mejorar los procesos
de pruebas modificados.
•Determinar criterios de •Verificar el entorno de
salida •Identificar los datos de pruebas •Elaborar y distribuir los
prueba Informes de Pruebas
•Ejecutar pruebas
•Diseñar el entorno de •Registrar resultados
pruebas
•Analizar los resultados
•Identificar la
infraestructura y •Elaborar los informes y el
herramientas análisis de las incidencias
•Ejecutar las pruebas de
confirmación y regresión
Monitoreo y Control
•Medir y analizar los resultados

•Monitorear y documentar el progreso, la cobertura y los criterios de salida
•Iniciar acciones correctivas
•Tomar decisiones
PLANIFICACIÓN
Monitoreo y control
Planificación
Evaluación de
Análisis y Diseño Ejecución Cierre
Criterios
P-17
PLANIFICACIÓN
– Determinar el alcance y riesgos
– Identificar los objetivos de las pruebas y el criterio de finalización de
pruebas
– Determinar el test approach (enfoque de pruebas)
– técnicas de pruebas, elementos a probar, cobertura, identificación
de las interfaces entre los equipos involucrados en las pruebas, y
testware (productos de trabajo producidos durante el proceso de
pruebas)
– Implementar las políticas de pruebas y/o la estrategia de pruebas
– Planificar las tareas de: análisis y diseño; implementación y ejecución de
pruebas; y evaluación
– Adquirir / obtener y programar recursos requeridos por las pruebas:
– Personal, entorno de pruebas, herramientas, presupuesto de
pruebas
– Definir los exit criteria (criterios de salida)

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
P-18
PLANIFICACIÓN DE LAS PRUEBAS

– Cómo el “plan de pruebas del proyecto” y la “estrategia de pruebas”
se aplican al software bajo prueba.
– Documentar cualquier excepción a la estrategia de prueba
• Por ejemplo: sólo una técnica de diseño de caso de prueba es
necesaria para esta área funcional, ya que es menos crítico.
– Otro software necesario para las pruebas,
• tales como: stubs, drivers o características del ambiente.
– Establecer los criterios de finalización de las pruebas.
MONITOREO Y CONTROL
– El monitoreo y control de pruebas es una actividad continua que influye
en la planificación de las pruebas.
• El plan de pruebas puede ser modificado en función de la
retroalimentación proporcionada por esta actividad
– El estado del proceso de pruebas se determina comparando el progreso
logrado con respecto a lo planificado en el plan de pruebas. Se
iniciarán aquellas actividades que se consideraran consecuentemente
necesarias.
– Actividades:
• Medir y analizar los resultados de las revisiones y pruebas
• Proveer información de las pruebas
• Iniciar medidas correctivas
• Tomar decisiones
P-19
ANALISIS Y DISEÑO
Monitoreo y control
Evaluación de
Criterios
Planificación
Identificar las condiciones
Diseñar Casos de prueba
Construir pruebas
UN BUEN CASO DE PRUEBA

Encuentra fallas
• Efectivo
Representa a los demás

• Ejemplificador
• Evolucionable
Fácil de mantener
• Económico
Barato de usar
P-20
ANALISIS Y DISEÑO DE LAS PRUEBAS
– La especificación de las pruebas se puede dividir en tres tareas

diferentes:
• 1. Identificar: determinar "qué" se va a probar (identificar las

condiciones de prueba) y priorizar.
• 2. Diseñar: determinar "cómo" el "qué" se va a probar (es decir,

diseño de casos de prueba )
• 3. Construir: implementación de las pruebas (datos, scripts, etc.)
TAREA 1: IDENTIFICAR LAS CONDICIONES
– (Determinar "qué" se va a probar y priorizar)

– Listar las condiciones a probar:
• Utilizar las técnicas de diseño especificadas en el plan de pruebas.
• Puede haber muchas condiciones para cada función del sistema o
atributo.
• Por ejemplo:
– “Seguro de vida para un deportista de invierno”
– “Número de productos ordenados > 99”
– “Fecha = 29-feb-2016”
– Priorizar las condiciones de prueba

• Se debe garantizar que las condiciones de pruebas más importantes
están cubiertas.
P-21
SELECCIÓN DE CONDICIONES DE PRUEBA
Importancia
4 Mejor
grupo
8
Primer grupo Tiempo
TAREA 2: DISEÑO DE CASOS DE PRUEBA (Determinar el "cómo" el "qué" se va a

probar)
– Diseño de las entradas a las pruebas y datos de pruebas.

• Cada prueba ejecuta una o más condiciones de pruebas.
– Determinar los resultados esperados.

• Predecir el resultado de cada caso de prueba, la salida, lo que ha
cambiado y lo que no ha cambiado.
– Diseñar sets de pruebas.

• Conjunto de pruebas diferenciados para objetivos diferentes, tales
como: regresión, aseguramiento de la fiabilidad, y la búsqueda de
fallas.
P-22
Condiciones de Prueba
más importantes
EL DISEÑO DE CASOS DE PRUEBA
Condiciones de Prueba menos
importantes
Importancia
Casos de prueba
Tiempo
TAREA 3: CREAR CASOS DE PRUEBA (Implementar los casos de prueba)
– Preparar los scripts de prueba

• A menos conocimientos sobre el sistema tenga el tester, mayor detalle
debe tener el script de prueba.
– Las secuencias de comandos para las herramientas se tienen que

especificar al detalle.
• Preparar los datos de prueba
– Datos que deben existir en los archivos y bases de datos al inicio de

las pruebas.
• Preparar a los resultados esperados
– Debe definirse antes que la prueba sea ejecutada.
P-23
EJECUCIÓN DE LAS PRUEBAS
Monitoreo y control
Planificación
Evaluación de
Criterios
EJECUCIÓN
– Ejecutar los casos de prueba prescritos.

• Primero los más importantes.
• No ejecutar todos los casos de prueba si:
– Sólo se prueba corrección de fallas.
– Muchas fallas encontradas por los primeros casos de
prueba.
– La presión del tiempo .
• Puede realizarse manualmente o de forma automatizada.
P-24
REGISTRO DE PRUEBAS 1
– El registro de la prueba contiene:

• Identificadores y versiones (sin ambigüedades) de:
– Software bajo prueba.
– Especificaciones de la prueba.
– Siga el plan
• Marcan el progreso en el script de pruebas.
• Documentar los resultados actuales de la prueba.
• Capturar cualquier otra idea que se tenga para los casos de prueba nuevos.
• Observemos que estos registros se utilizan para establecer que todas las
actividades de prueba se han llevado a cabo tal como se especifica.
REGISTRO DE PRUEBAS 2
– Comparar los resultados reales con los resultados esperados.

Registrar discrepancias:
• Falla del software.
• Falla en la prueba (por ejemplo, los resultados esperados están mal).
• Fallas en el Entorno o versión.
• Ejecución de prueba incorrecta.
– Registrar la cobertura de niveles alcanzada (de las medidas

especificadas en los criterios de terminación de las pruebas)
– Después de que la falla se ha solucionado, repita las actividades de
prueba necesarias (ejecutar, diseñar, planificar)
P-25
EVALUACIÓN DE CRITERIOS
Monitoreo y control
Planificación
Evaluación de
Criterios
COMPRUEBE LA FINALIZACIÓN DE LA PRUEBAS
– Los criterios de finalización de las pruebas se especifican en el plan de

pruebas.
– Si no se cumplen los criterios de finalización es necesario repetir las
actividades de prueba, por ejemplo: diseñar más pruebas
La cobertura muy baja
Comprobar
Especificación Ejecución Registro
termino
Cobertura
OK
P-26
CRITERIOS DE FINALIZACIÓN DE LAS PRUEBAS
– Los criterios de finalización o de salida se aplica a todos los niveles de

prueba - para determinar cuándo parar.
• Cobertura, utilizando una técnica de medición, por ejemplo:
– Cobertura de decisiones para las pruebas unitarias.
– Requerimientos de usuario.
– Las transacciones de uso más frecuente.
• Los fallos encontrados (por ejemplo frente a lo esperado).

• El costo o tiempo.
CIERRE
Monitoreo y control
Planificación
Evaluación de
Criterios
P-27
CIERRE
‒ Comprobar qué entregables planificados han sido entregados

‒ Informe de las incidencias cerradas y diferidas
‒ Cerrar y archivar los testware (artefactos generados en el proceso e
pruebas), tales como:
• scripts, entorno de pruebas y la infraestructura de pruebas
‒ Analizar y registrar las lecciones aprendidas para futuros proyectos
‒ Otras actividades:
• Documentar la aceptación del sistema

Regula la calidad
COMPARACIÓN DE LAS ACTIVIDADES de las pruebas
Intelectual
Planificación
Actividad
única
Análisis y Diseño
Es bueno
Actividades automatizar
repetidas
Ejecución muchas
veces
Evaluación de Criterios Administrativo
P-28
PSICOLOGÍA DE LAS PRUEBAS
¿POR QUÉ PROBAR?
– Crear confianza
– Demostrar que el software es correcto
– Demostrar conformidad con los requisitos
– Encontrar defectos
– Reducir costos
– Demostrar que el sistema cumple con las necesidades del
usuario
– Evaluar la calidad del software

CONFIANZA
Confianza
Error encontrado
Tiempo
¿sin fallas encontradas = confianza?
P-29
¿Crees que
está aquí?
LA EVALUACIÓN DE LA CALIDAD DEL SOFTWARE
Muchas Alto Pocas

Fallas Fallas
Bajo Pocas Alto

Calidad del Software Fallas
Pocas Pocas
Fallas Fallas
Usted puede
estar aquí
Bajo
Calidad de las pruebas
ENFOQUE TRADICIONAL DE LAS PRUEBAS

– Demuestre que el sistema:
• Hace lo que debe
• No hace lo que no debe
Objetivo: demostrar que trabaja

Éxito: el sistema funciona
Más rápido: los casos de prueba fáciles.
Resultado: fallas no
identificadas
P-30
ENFOQUE DE PRUEBAS MEJORADO
– Demostrar que el sistema:

• Hace lo que no debe.
• No hace lo que debe.
Objetivo: Encontrar fallas

Éxito: Fallo del sistema
Más rápido: los casos de pruebas difíciles.
Resultado: un menor número

de fallas no identificadas
LA PARADOJA DE LAS PRUEBAS
Propósito de la prueba: encontrar fallas

Encontrar fallas destruye la confianza
Propósito de la prueba: destruir la confianza
Propósito de la prueba: Incrementar la confianza
La mejor manera de construir la confianza

es tratar de destruirla
P-31
¿QUIÉN QUIERE SER UN TESTER?
– Es un proceso destructivo.
– Lleva malas noticias (“tu bebé es feo")
– Se trabaja bajo presión (al final).
– Necesidad de tener una visión diferente, una mentalidad diferente
("¿Qué pasa si no lo es?", "¿Qué podría salir mal?")
– ¿Cómo deben ser comunicadas las fallas? (a los autores y gestores).

EL TESTER TIENE DERECHO A:
– Información precisa sobre el progreso y los cambios.

– Visión de los desarrolladores acerca de las áreas del
software.
– Que el código liberado para pruebas siga el estándar
acordado.
– Ser considerado un profesional (¡sin abuso!).
– ¡Encontrar fallas!
– Observar especificaciones y planes de pruebas.
– Que las fallas reportadas sean tomadas en serio (no
reproducible).
– Hacer predicciones sobre fallos futuros.
– Mejorar su propio proceso de pruebas.
P-32
• LOS PROBADORES TIENEN LA RESPONSABILIDAD DE:
– Seguir los planes de pruebas, scripts, etc. tal y como están
documentados.
– Informar de manera objetiva y con evidencias las fallas (¡sin abuso!)
– Comprobar si las pruebas son correctas antes de informar sobre las
fallas.
– Recordar que es el software, no al programador, el objeto bajo
pruebas.
– Evaluar el riesgo de manera objetiva.
– Priorizar lo que se informa.
– Comunicar la verdad.
• INDEPENDENCIA
– ¿Poner a prueba su propia construcción?
• Se encuentra entre un 30% a 50% de las fallas propias.

• Mismas hipótesis y procesos de pensamiento.
• Ve lo qué quiso expresar o quiere ver, no es lo que es.
• Apego emocional
– No quieren encontrar defectos.
– Activamente desea NO encontrar las fallas.
P-33
NIVELES DE INDEPENDENCIA
– Ninguno: las pruebas son diseñadas por la persona que escribió el

software.
– Las pruebas son diseñadas por una persona diferente.
– Las pruebas son diseñadas por alguien de otro departamento o
equipo (equipo de prueba).
– Las pruebas son diseñadas por alguien de otra organización (agencia).
– Las pruebas son generadas por una herramienta (¿pruebas de baja
calidad?)
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.
P-34
Gracias por su
atención!
Preguntas?
P-35

1 JB Istqb P01 PDF

Cargado por

Información del documento

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 P01 PDF

Cargado por

Copyright:

Formatos disponibles

ING, CFTL

¿POR QUÉ ES NECESARIO PROBAR?

– Error: Acción humana que produce un resultado incorrecto. [Según IEEE

– Defecto: Una manifestación de un error en el software.

– Fallo: Desviación del componente o del sistema respecto de prestación,

El fallo es un evento; defecto es un

Una persona comete un

… que crea un defecto en

… que puede causar un

¿POR QUÉ ES NECESARIO PROBAR?

• FIABILIDAD VS. FALLOS

– Fiabilidad: Habilidad de un producto software para llevar a cabo

• ¿POR QUÉ SE PRODUCEN FALLAS EN EL SOFTWARE?

– Un software está escrito por personas

– Bajo presión creciente para entregar SW en plazos estrictos

– Alguna vez ha escrito software...

¿POR QUÉ ES NECESARIO PROBAR?

• ¿CUÁNTO CUESTAN LAS FALLAS DEL SOFTWARE?

– Enormes sumas de dinero

– Muy poco o nada en absoluto

• SISTEMAS DE SEGURIDAD CRÍTICOS

– Las fallas del software pueden provocar la muerte o lesiones

¿POR QUÉ ES NECESARIO PROBAR?

• ¿ENTONCES, POR QUÉ SON NECESARIAS LA PRUEBAS?

– Porque es probable que el software tenga fallas

– Conocer la fiabilidad del software

– Para cubrir el tiempo entre la entrega del software y la fecha de

– Para demostrar que el software no tiene fallas

– Porque las pruebas está incluidas en el plan del proyecto

– Debido a que las fallas pueden ser muy costosas

– Para evitar ser demandado por los clientes

Un sistema tiene Promedio: 10 cajas de entrada por pantalla

• Total de pruebas “exhaustivas” :

¿POR QUÉ ES NECESARIO PROBAR?

– ¿Cuándo es una prueba exhaustiva?

– ¿Cuánto tiempo va a tomar una prueba exhaustiva?

• ¿CON CUÁNTAS PRUEBAS ES SUFICIENTE?

¿POR QUÉ ES NECESARIO PROBAR?

• ¿CUÁNTAS PRUEBAS REALIZAR?

– Depende del RIESGO

• TAN POCO TIEMPO, TANTO POR PROBAR…

– El tiempo asignado a las pruebas siempre será limitado

• Lo que no se va a probar (esta vez)

– Usamos el RIESGO para

¿POR QUÉ ES NECESARIO PROBAR?

• PRINCIPIO MÁS IMPORTANTE

Priorizar las pruebas

¿POR QUÉ ES NECESARIO PROBAR?

Grado en que un conjunto de características inherentes cumple ISO

El grado en que un sistema, componente o proceso cumple

Totalidad de características de una entidad (actividad, producto, persona,

Actitud para el uso genera

¿POR QUÉ ES NECESARIO PROBAR?

– Las pruebas miden la calidad del software.

– Las pruebas pueden encontrar defectos;

– ¿Qué evaluar en las pruebas?

¿POR QUÉ ES NECESARIO PROBAR?

• OTROS FACTORES QUE INFLUYEN EN LAS PRUEBAS

Es difícil determinar la cantidad de pruebas

07 PRINCIPIOS DE LAS PRUEBAS

– Probar todo (todas las combinaciones de entrada y precondiciones) no es

07 PRINCIPIOS DE LAS PRUEBAS

Diseño acorde Construcción Producto que