Software Testing

ISTQB / ISEB Foundation Exam Practice

Chapter 1

Principios de las pruebas

1 Principios
4 Tcnicas
Dinamicas

2 Ciclo de Vida

3 Pruebas estticas

5 Manejo

6 Herramientas

Principles
1

ISTQB / ISEB Foundation Exam Practice

Contenidos
Por qu es necesario realizar pruebas?
Psicologa de las pruebas
Resultados Esperados
Priorizacin de las pruebas

Terminologia de Pruebas

No se acept en general un conjunto de definiciones

de pruebas utilizados en todo el mundo.
El estandar nuevo BS 7925-1
- Glosario de trminos de prueba (con nfasis en las pruebas de
componentes)
- Mas reciente.
- Desarrollado por un grupo de trabajo del SIGIST BCS
- Adoptada por la ISEB / ISTQB

Que es un bug?

Error: una accin humana que produce un resultado

incorrecto.
Defecto: una manifestacin de un error en el software.
- tambin conocido como un defecto o fallo.
- si se ejecuta, un defecto puede provocar un fallo.
Fallo: desviacin del software desde su entrega
prevista o servicio.
- (defecto encontrado)
Si
Si no
noes
esun
unevento;
evento; fallo
falloes
esun
unestado
estadode
de
el
elsoftware,
software, causada
causada por
porun
unerror
error

Error - Defecto - Fallo

Una persona
que hace
un error ...
... Que crea un
defecto, En el
software ...

Que puede
causar ... una
falla? En
funcionamiento

Fiabilidad frente a fallos

Fiabilidad: la probabilidad de que el software

no provocar el fallo del sistema durante un
tiempo especificado en condiciones
especificadas
- Puede ser un sistema libre de errores? (cero
defectos, la primera vez a la derecha)
- Puede un sistema de software fiable, pero todava
tiene defectos?
- Es un aplicacin de software "sin fallos" siempre es
fiable?

Por qu se producen fallos en el software?

El software esta escrito por personas.

- Que saben algo, pero no todo.
- Que tienen habilidades, pero no son perfectos.
- Que comenten errores (errors).
Bajo una creciente presin para entregar a
plazos estrictos
- no hay tiempo para comprobar las hiptesis, pero
puede estar equivocado.
- Los sistemas pueden estar incompletos.
Si alguna vez ha escrito software ...

Qu costo ocacionan las falla en el software ?

Grandes sumas de dinero

- Accidente Ariane 5 ($7billion) exception de software.
- Mariner sonda espacial a Venus($250m). instrucciones del
programa.
- American Airlines ($50m).
muy poco o nada en absoluto
- inconveniente menor.
- efecto perjudicial visible o fsico.
El software no es "lineal":

Una entrada pequea puede tener un efecto muy grande.

Sistemas de seguridad crticos

Las fallas de software pueden causar la

muerte o lesiones.
- El tratamiento de radiacin mata pacientes (Therac25)
- maquinista muerto.
- impactos de los aviones (Airbus y coreano Airlines)
- Sistema de emision de cartas bancarias de sobregiro
causan suicidio.

Por qu es necesario probar?

-

porque es probable que el software que tengan defectos

para aprender acerca de la fiabilidad del software
para llenar el tiempo entre la entrega del software y la
fecha de lanzamiento
para demostrar que el software no tiene faltas
porque la prueba est incluida en el plan del proyecto
porque las fallas pueden ser muy caros
para evitar ser demandado por los clientes
para mantenerse en el negocio

Por qu no simplemente "probar todo"?

Prom. 4 menus
3 options / menu
El sistema tiene
20 pantallas

Total para prueba 'exhaustive' :

Promedio: 10 campos / pantalla

2 tipos de entrada / campo
(fecha como Enero 3 or 3/1)
(numeros integeros o decimales)
Redondeo de 100 posibles
valores

20 x 4 x 3 x 10 x 2 x 100 = 480.000 pruebas

Si 1 segundo

por prueba, 8000 minutos, 133 horas, 17.7 dias

(sin contar los problemas dedo, fallas o retest)

10 secs = 34 wks, 1 min = 4 aos, 10 min = 40 aos

Las pruebas exhaustivas?

Qu es la prueba exhaustiva?
- cuando todos los probadores se han agotado
- cuando todas las pruebas previstas se han ejecutado
- el ejercicio de todas las combinaciones de insumos y las
condiciones previas
Cunto tiempo va a tomar hacer pruebas
exhaustivas?
- Una cantidad de tiempo poco prctica
- Un tiempo infinito
- No mucho tiempo

Cuntas pruebas son suficientes?

-

nunca es suficiente
cuando hayis hecho lo que planeaste
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
- que depende de los riesgos detectados para su
sistema

Cuntas pruebas?

Esto depende del RIESGO

- riesgo de fallas importantes que faltan.
- riesgo de incurrir en los costos de fallas.
- riesgo de liberacin de software no probado o bajo
prueba.
- riesgo de perder credibilidad y cuota de mercado
- riesgo de perder una ventana de mercado
- riesgo de un exceso de pruebas, pruebas ineficaces

Tan poco tiempo, tanto para poner a prueba ..

El tiempo de prueba siempre ser limitado

El uso del RIESGO determina:
- Lo que debe probar primero
- Lo que mas debe probar
i.e. Donde hacer
enfasis
- Como probar afondo cada elemento
- qu no probar (esta vez)
Usas el RIESGO
- asignar el tiempo disponible para la prueba, dando
prioridad a las pruebas ...

El principio ms importante
Priorizar
Priorizar las
las pruebas
pruebas
de
de modo
modo que,
que,
siempre
siempre que
que se
se detenga
detenga la
la prueba,
prueba,
que
que ha
ha hecho
hecho la
la mejor
mejor prueba
prueba
en
en el
el tiempo
tiempo disponible.
disponible.

Pruebas y calidad

Pruebas para determinar la calidad del software

Las pruebas pueden encontrar fallos, y cuando se
retiran, la calidad del software (y posiblemente
fiabilidad) se mejora.
Que probar?
- la funcin del sistema, correccin de la operacin
- Cualidades no funcionales : fiabilidad, facilidad de uso,
mantenibilidad, reusabilidad, capacidad de prueba, etc

Otros factores que influyen en las pruebas

Requerimientos contractuales.
Requerimientos Legales.
Requerimeintos Industriales Especificos.
- por ejemplo industria farmacutica (FDA), pruebas
compilador estndar, de seguridad crtico o
relacionado con la seguridad, tales como ferrocarril
de conmutacin, control de trfico areo.
Es
Esdifcil
difcildeterminar
determinar
la
la cantidad
cantidadde
depruebas
pruebas que
queson
son
suficientes
suficientes
pero
pero no
no es
esimposible
imposible

Principles
1

ISTQB / ISEB Foundation Exam Practice

Contenidos
Por qu es necesario realizar pruebas?
Proceso de prueba Fundamental
Psicologa de las pruebas
Resultados Esperados
Priorizacin de las pruebas

Planificacin de prueba - los diferentes niveles

Politica
de Prueba

Estrategia
de prueba
Plan de Prueba
High Level
de alto nivel
Test Plan
Plan de
Prueba
Detailed
Detailed
Detallado
Detailed
Test
Plan
Test
TestPlan
Plan

Nivel
Compaa

Nivel de Proyecto (IEEE 829)

(uno por cada proyecto)
Nivel de Estado de Pruebas (IEEE 829)
(uno para cada etapa dentro de un
proyecto,por ejemplo Componente,

El Proceso de Prueba
Planificacion (Nivel Detallado)

especificacion

ejecucion

registro

Chequeo
Completacion

Planificando Pruebas

Como la estrategia de pruebas y el plan de

proyecto de prueba aplican al software bajo
prueba.
documentar cualquier excepcin a la estrategia
de prueba
- por ejemplo Slo en un caso de prueba de diseo
tcnica necesaria para esta rea funcional, ya que es
menos crtico
- otro software necesario para las pruebas, tales como
talones y conductores, y los detalles del entorno
establecer criterios de prueba de finalizacin

El Proceso de Prueba
Planificacion (Nivel Detallado)

especificacion

ejecucion

Identificar Condiciones
Disear Casos de Prueba
Construir Pruebas

registro

Chequeo
Completacion

Un buen caso de prueba

Eficaz

Ejemplar

Encuentra las fallas

Representa los dems

Evolucionable
Fcil de mantener

Econmico
Barato de implementar

Especificacion de Pruebas

La especificacin de la prueba se puede dividir en

tres tareas distintas:
1. Identifique: determinar "qu" se va a probar (identificar
condiciones de prueba) y priorizar.
2. Disee:
determinar "cmo" el "qu" se va a probar?
(es decir, los casos de prueba de diseo)
3. Construya: implementar las pruebas (datos, scripts, etc)

Tarea 1: Identifique Condiciones

(determinar "qu" se va a probar y priorizar)

una lista de las condiciones que nos gustara probar:
- utilizar las tcnicas de diseo de ensayo especificados en el
plan de pruebas
- puede haber muchas condiciones para cada funcin del sistema
o atributo
- e.g.
"Seguro de vida para un deportista de invierno
"Nmero de elementos ordenada> 99
fecha = 29-Feb-2004
priorizar las condiciones de ensayo
- deben garantizar las condiciones ms importantes estn
cubiertas

Seleccin de las condiciones de Prueba

Importancia

Primer Conjunto

Mejor
Conjunto

Tiempo

Tarea 2: Diseo de Casos de Prueba

(determinar "cmo" el "qu" se va a probar)

Diseo entrada de prueba y datos de prueba.

- cada prueba ejerce una o ms condiciones de prueba.
Determinar los resultados esperados.
- predecir el resultado de cada caso de prueba, lo que es la
produccin, lo que ha cambiado y lo que no se cambia.
Diseo de conjuntos de pruebas
- prueba diferentes conjuntos de objetivos diferentes, tales
como la regresin, la construccin de la confianza, y la
bsqueda de fallos

Diseando casos de prueba

Importancia

Condiciones de prueba
mas importantes

Condiciones de Prueba
menos importantes
Casos de Prueba

Tiempo

Tarea 3: Construir casos de prueba

(Implementar casos de prueba)

Preparara scripts de prueba

- En el caso que el probador tenga menos conocimiento del
sistema los scripts deben ser ms detallados.
- Los scripts de herramientas deben especificar todos los
detalles.
Preparar data de prueba
- Los datos que deben existir en los archivos y bases de datos en
el inicio de las pruebas
- preparar a los resultados esperados
- deben ser definidos antes que la prueba se ejecute

Prueba de ejecucin
Planificacion (Nivel Detallado)

especificacion

ejecucion

registro

Chequeo
Completacion

Ejecucion

Ejecutar casos de prueba prescritos

- Los ms importantes primero
- no se ejecutara todos los casos de prueba el if
pruebas slo las correcciones de fallas
demasiados fallos encontrados por los primeros
casos de prueba
La presin del tiempo

- se puede realizar manualmente o automatizado

Prueba de ejecucin
Planificacion (Nivel Detallado)

especificacion

ejecucion

registro

Chequeo
Completacion

Registrando Prueba 1

El registro de prueba contiene:

- identificacion y versiones (sin ambigedades)
Del software bajo prueba
Especificaciones de Prueba
Siga el plan de prueba
- marcan el progreso del script de prueba
- documentos reales de los resultados de la prueba
- capturar cualquier otra idea que tengas para nuevos casos de
prueba
- Ten en cuenta que estos registros se utilizan para establecer
que todas las actividades de prueba se han llevado a cabo tal
como se especifica.

Registrando Prueba 2

Comparar los resultados reales con el resultado esperado.

Entrar discrepancias en consecuencia:
- Fallas en el software .
- de prueba de fallos (por ejemplo, los resultados esperados mal)
- El medio ambiente o la versin falla
- prueba de funcionamiento incorrecto
Entrar en niveles de cobertura alcanzados (para las medidas
especificadas como criterios de terminacin de prueba)
Despus de la falla se ha solucionado, repita las actividades
de prueba requeridos (ejecutar, diseo, plan)

Chequeo de Completacion de prueba

Planificacion (Nivel Detallado)

especificacion

ejecucion

registro

Chequeo
Completacion

Chequeo de Completacion de prueba

Los criterios de prueba de finalizacin se especifica

en el plan de pruebas
Si no se cumplen, la necesidad de repetir las
actividades de prueba, por ejemplo, Especificacin
de prueba para disear ms pruebas
Cobertura insuficiente
especificacion

ejecucion

registro

chequeo
completacion

Cobertura
Aceptar

Criterios de prueba de completacion

Los criterios de completacion o de salida se

aplica a todos los niveles de la prueba - para
determinar cundo parar.
- cobertura, utilizando una tcnica de medicin, por
ejemplo:
rama de cobertura para las pruebas unitarias.
Usar requerimientos.
transacciones de uso ms frecuente
- fallas encontradas (por ejemplo, frente a lo esperado)
- Tiempo o Costos

Comparacin de las
Planificando

Especficaciones

Ejecucion

Registro

Gobierna la
tareas calidad de las pruebas

Intelectual
una sola
vez la
actividad

Es Bueno
actividad automatizar
repetida
muchas veces
habitual

Principles
1

ISTQB / ISEB Foundation Exam Practice

Contenidos
Por qu es necesario realizar pruebas?
Proceso de prueba Fundamental
Psicologa de las pruebas
Resultados Esperados
Priorizacin de las pruebas

Por que Probar?

fomentar la confianza
demostrar que el software es correcto
demostrar la conformidad con los requisitos
encontrar fallos
Reducir costos
Los sistema de demostracin cumple las
necesidades del usuario
evaluar la calidad del software

Confianza
Confianza

Fallas
Encontradas
Fault found

Tiempo
No encontrarar fallas = confianza?

La evaluacin de la calidad del software

Crees
que ests aqu

Alto

Muchos
Fallos

Few
Pocos
Faults
Fallos

Bajo

Alto
Calidad del Software
Pocos
Fallos

Prueba
de
Calidad

Usted puede
estar aqu

Bajo

Pocos
Fallos

Un enfoque de las pruebas tradicionales

Demuestre que el sistema:

- hace lo que debe
- no hace lo que no debe
Objetivo:
Objetivo: Mostrar
Mostrar el
el trabajo
trabajo
xito:
xito: funciona
funciona el
el sistema
sistema
Ms rpido logro: fciles casos de prueba
Resultado:
Resultado: Las
Las fallas
fallas que
que quedan
quedan

Una prueba mejor enfoque

Demuestre que el sistema :

- hace lo que no debe
- no hace lo que debe
objetivo
objetivo :: encontrar
encontrar fallos
fallos
xito:
sistema
xito:
sistema falla
falla
Ms rpido logro: los casos difciles pruebas
Resultado:
Resultado: menos
menos fallos
fallos que
que quedan
quedan

La paradoja de las pruebas

Propsito de la prueba: encontrar fallos
Encontrar fallas destruye la confianza
Propsito de la prueba: destruir la confianza
Propsito de la prueba: construir confianza

La
Lamejor
mejormanera
manerade
deconstruir
construir confianza
confianza
es
estratar
tratarde
dedestruirlo
destruirlo

Quin quiere ser un probador?

Un destructor de procesos
Trae malas noticias (su beb es feo)
Bajo la presin peor momento (al final)
Necesidad de tener una visin diferente, una
mentalidad diferente ("Y si no lo es?", "Qu
podra salir mal?")
Cmo debe ser comunicada la informacin
de fallos (para autores y administradores?)

El probador tienen el derecho a:

-

Tener informacin precisa sobre el progreso y los cambios

visin de los desarrolladores acerca de las reas del software
cdigo entregado certificado con el estndar acordado
considerarse como un profesional (no abuso!)
encontrar defectos!
Cambio de Especificaciones y planes de prueba
han reportado fallas tomado en serio (no reproducible)
hacer predicciones sobre los futuros niveles de fallo
mejorar su proceso de pruebas propio

El probador tienen la responsabilidad de:

- seguir los planes de pruebas, scripts .etc. como se
documenta
- Informar fallas objetivamente y de hecho (sin abuso!)
- comprobar que las pruebas son correctas antes de informar s
/ w fallas
- recuerda que es el software, no el programador, que se est
probando
- evaluar el riesgo objetivamente
- prioridad a lo que informan
- comunicar la verdad

Independencia

Pon a prueba tu propio trabajo?

- encontrar un 30% - 50% de sus propias faltas
- mismos supuestos y procesos de pensamiento
- ver lo que quieres decir o quieren ver, no lo que hay
- apego emocional
no quieren encontrar fallos
NO quiero activarme para encontrar las fallas

Los niveles de independencia

Ninguno: las pruebas diseadas por la persona que

escribi el software
Las pruebas diseadas por una persona diferente
Las pruebas diseadas por alguien de otro
departamento o equipo(por ejemplo, equipo de prueba)
Las pruebas diseadas por alguien de otra
organizacin(por ejemplo, la agencia)
Pruebas generadas por una herramienta(pruebas de
baja calidad?)

Principles
1

ISTQB / ISEB Foundation Exam Practice

Contenidos
Por qu es necesario realizar pruebas?
Proceso de prueba Fundamental
Psicologa de las pruebas
Re-testing y pruebas de regresin
Resultados Esperados
Priorizacin de las pruebas

Despus un fallo se fijan el Re-testing

Ejecutar una prueba, esta falla, reportar falla

Nueva versin de software con fallos "fijo
Vuelva a ejecutar la misma prueba (es decir,
re-test)
- debe ser exactamente repetible
- mismo entorno, versiones (excepto por el software
que ha sido intencionalmente cambiado!)
- mismos insumos y las condiciones previas
Si la prueba pasa ahora, el fallo se ha
corregido correctamente - o lo tiene?

Re-testing (re-ejecucin de pruebas fallidas)

Las fallas Nuevas introducidas por el primero
La falla arreglada no fue localizada durante el re-testing

x
x
x

Fallo ha sido arreglado

Re-test para chequeo

Prueba de Regresion

para ver si hay efectos secundarios inesperados

x
x
x

x
No se puede garantizar
para encontrar a todos

Pruebas de regresin1

nombre equivocado: "anti-retroceso" o

"progreso
conjunto estndar de pruebas - paquete de
pruebas de regresin
en cualquier nivel (unidad, integracin,
sistema, aceptacin)
bien vale la pena la automatizacin
un activo de desarrollo, pero es necesario
mantener

Pruebas de regresin2

Pruebas de regresin se realiz

- despus de los cambios de software, incluidos los
fallos corregidos
- cuando el entorno cambia, aunque la funcionalidad
de la aplicacin se mantiene igual
- para los arreglos de emergencia (posiblemente un
subconjunto)
Suites de pruebas de regresin
- evolucionar en el tiempo
- se ejecutan a menudo
- puede llegar a ser bastante grande

Pruebas de regresin3

Mantenimiento del paquete de ensayo de regresin

- eliminar las pruebas repetitivas (pruebas que ponen a prueba la
condicin misma prueba)
- combinar casos de prueba (por ejemplo, si se ejecutan siempre
juntos)
- seleccionar un subconjunto diferente de la suite de regresin
completa se ejecute cada vez que se necesita una prueba de
regresin
- eliminar las pruebas que no han encontrado un fallo durante un
tiempo largo (por ejemplo, pruebas de edad fijos de fallo)

Pruebas de regresin y automatizacin

Los instrumentos de ensayo de ejecucin (por

ejemplo, repeticin de captura) son herramientas de
pruebas de regresin - que volver a ejecutar las
pruebas que ya se han ejecutado
Una vez automatizado, las pruebas de regresin se
puede ejecutar tantas veces como se desee (por
ejemplo, todas las noches)
Automatizacin de pruebas no es trivial (por lo general
tarda de 2 a 10 veces ms tiempo para automatizar una
prueba de que ejecutarlo manualmente)
No automatizar todo - Plan para automatizar lo
primero, slo si vale la pena automatizar.

Principles
1

ISTQB / ISEB Foundation Exam Practice

Contenidos
Por qu es necesario realizar pruebas?
Proceso de prueba Fundamental
Psicologa de las pruebas
Re-testing y pruebas de regresin
Resultados Esperados
Priorizacin de las pruebas

Resultados esperados

Debera preverse con antelacin como parte del

proceso de diseo de la prueba
- "Asuncin de Oracle asume que el resultado correcto
se puede predecir.
Por qu no basta con ver lo que hace el
software y lo valora en el momento?
- subconsciente deseo de realizar la prueba
correctamente - menos trabajo que hacer, no informe
de incidente para escribir
- parece plausible, por lo que debe estar bien - menos
riguroso que calcular de antemano y comparar

Una prueba

entradas

Salidas
esperadas

Un Programa:
Read A
IF (A = 8) THEN
PRINT (10)
ELSE
PRINT (2*A)

Source: Carsten Jorgensen, Delta, Denmark

6?

10?

Principles
1

ISTQB / ISEB Foundation Exam Practice

Contenidos
Por qu es necesario realizar pruebas?
Proceso de prueba Fundamental
Psicologa de las pruebas
Re-testing y pruebas de regresin
Resultados Esperados
Priorizacin de las pruebas

Priorizacin de las pruebas

No podemos probar todo

Nunca hay tiempo suficiente para hacer todas
las pruebas que le gustara
Entonces, qu pruebas debe hacer?

El principio ms importante
Priorizar
Priorizar las
las pruebas
pruebas
de
de modo
modo que,
que,
siempre
siempre que
que se
se detenga
detenga la
la prueba,
prueba,
que
que ha
ha hecho
hecho la
la mejor
mejor prueba
prueba
en
en el
el tiempo
tiempo disponible.
disponible.

Cmo priorizar?

Posibles criterios de clasificacin (todo basado

en el riesgo)
- probar que un fracaso sera ms grave
- comprobar que las deficiencias sera ms visible
- comprobar que las deficiencias son ms propensos
- preguntar al cliente para priorizar los requisitos
- lo que es ms importante para el negocio del cliente
- Las reas cambian ms a menudo
- las zonas con ms problemas en el pasado
- Las reas ms complejas o tcnicamente crtico

Principles
1

ISTQB / ISEB Foundation Exam Practice

Resumen: Puntos claves

Las pruebas son necesarias porque la gente comete errores
El proceso de prueba: planificacin, especificacin, ejecucin,
registro, comprobacin de finalizacin
Independencia y las relaciones son importantes en las pruebas
Re-soluciones de prueba, prueba de regresin para lo inesperado
Resultados esperados de una especificacin por adelantado
Dar prioridad a hacer la mejor prueba en el tiempo que tiene