<<Fundamentos de Pruebas>>

Curso: Proceso de Pruebas de Software

NDICE DE CONTENIDOS
NDICE DE CONTENIDOS

01. Por qu son necesarias las Pruebas?

02. Qu son las Pruebas de Software?

03. Principios generales de las Pruebas

04. Procesos fundamentales de las Pruebas

05. Sicologa de las Pruebas

06. Cdigo de tica

Ing. Alejandro Bartra

01
POR QU SON NECESARIAS LAS
PRUEBAS?

01 POR QU SON NECESARIAS LAS PRUEBAS?

CONTEXTO DE LAS PRUEBAS

La economa mundial es cada vez ms

dependiente del software.

Los negocios demandan mayor productividad

y CALIDAD en menos tiempo.

Ing. Alejandro Bartra

Las aplicaciones crecen en tamao,

complejidad y distribucin.

Las pruebas y las revisiones mejoran la

CALIDAD del software

01 POR QU SON NECESARIAS LAS PRUEBAS?

FALLOS DE SOFTWARE
AT&T
Una falla en una Central Telefnica impidi comunicaciones de larga distancia en
EE.UU. durante casi 24 horas. La solucin requiri cambiar una sola lnea de
cdigo.
Aeropuerto de Denver
Una falla de software signific demorar la apertura del aeropuerto en
aproximadamente 9 meses, con un costo de medio milln de dlares diarios.
RAYOS X LETALES
Pacientes recibieron una dosis letal de rayos gamma debido a un fallo de
software.
El Therac-25 era una mquina para radiacin teraputica producida por la
empresa Atomic Energy of Canad Limited. Estuvo involucrada en, al menos, seis
accidentes entre 1985 y 1987, en los cuales los pacientes fueron objeto de una
sobredosis masiva de radiacin. En algunos casos fueron del orden de centenas
de gray. Al menos cinco pacientes murieron por sobredosis.
Este accidente destaca los riesgos del software de control de sistemas crticos en
trminos de seguridad (safety-critical systems).

Ing. Alejandro Bartra

01 POR QU SON NECESARIAS LAS PRUEBAS?

Qu es un Error?: Una accin humana que produce un resultado

incorrecto

Qu es un Defecto? : Una manifestacin de un error en software

Tambin conocido como un defecto o bug (bicho, insecto).
De ser ejecutado, un defecto puede causar un fallo.

Qu es un Fallo? : Una desviacin del software de su entrega esperada o

servicio.
Defecto encontrado

El fallo es un acontecimiento; el defecto es un

estado del software, causado por un error

Ing. Alejandro Bartra

01 POR QU SON NECESARIAS LAS PRUEBAS?

Error - Defecto - Fallo

Una persona
comete un error ...

que crea un defecto

en el software

que puede causar

un fallo en la
operacin

Ing. Alejandro Bartra

01 POR QU SON NECESARIAS LAS PRUEBAS?

Fiabilidad versus Defectos

Fiabilidad: la probabilidad que el software no causar el fracaso del sistema
durante un tiempo especificado en condiciones especificadas
Puede un sistema estar sin defecto? (cero defectos, la primera vez todo ok)
Puede un sistema de software ser confiable, pero todava tener defectos?
Una aplicacin de software "sin defecto" es siempre confiable?

Ing. Alejandro Bartra

01 POR QU SON NECESARIAS LAS PRUEBAS?

CAUSAS DE LOS DEFECTOS EN EL SOFTWARE

Error humano
Uso incorrecto del software
Diseo o construccin del software.
Causas de los errores humanos:
Plazos, demandas excesivas debido a la complejidad, distracciones, etc.
Complejidad tcnica del software.

Condiciones ambientales
Cambios en las condiciones ambientales.
Causas de condiciones ambientales negativas/adversas:
Radiacin, campos electromagnticos, polucin, fallo de discos duros, fluctuaciones en el
suministro de energa elctrica.

LOS DEFECTOS Y FALLOS PROVIENEN DE:

Errores en especificacin, diseo e implementacin del software.

Errores en el uso del sistema.
Condiciones ambientales.
Dao intencional.
Consecuencia de errores tempranos, defectos y fallas.

Ing. Alejandro Bartra

01 POR QU SON NECESARIAS LAS PRUEBAS?

CUNDO APARECEN LOS DEFECTOS?

Requerimiento 1

Requerimiento
correcto

Diseo acorde
con los
requerimientos

Construccin
acorde con el
Diseo

Producto que
trabaja segn lo
esperado

Requerimiento 2

Requerimiento
correcto

Diseo acorde
con los
requerimientos

Construccin
con errores
(origen)

Producto con
bugs

Requerimiento 3

Requerimiento
correcto

Diseo con
errores

Construccin
acorde con el
Diseo

Producto con
fallas en el
diseo

Requerimiento 4

Error en la
especificacin
del
requerimiento

Diseo acorde
con los
requerimientos

Construccin
acorde con el
Diseo

Producto
entregado con
fallas

Ing. Alejandro Bartra

10

01 POR QU SON NECESARIAS LAS PRUEBAS?

COSTO DE LOS DEFECTOS

COSTO

Costo de Reparacin

1X

10X

100X

TIEMPO
Requerimientos

Diseo Construccin

Pruebas

Tiempo de Uso

Ing. Alejandro Bartra

11

01 POR QU SON NECESARIAS LAS PRUEBAS?

CALIDAD

Ing. Alejandro Bartra

12

01 POR QU SON NECESARIAS LAS PRUEBAS?

CALIDAD

Grado en que un conjunto de caractersticas inherentes cumple

con los requisitos

ISO
9000:
2000

El grado en que un sistema, componente o proceso cumple

(1) requerimientos especificados y (2) necesidades o expectativas
del cliente o usuario.

IEEE
610.12

Totalidad de caractersticas de una entidad (actividad, producto,

persona, organizacin) que le confieren la aptitud para satisfacer las
necesidades explcitas e implcitas de sus clientes

ISO
8402

Ing. Alejandro Bartra

13

01 POR QU SON NECESARIAS LAS PRUEBAS?

CALIDAD
Calidad

Cumplir requerimientos

Propiedades
(facilidad de
mantenimiento,
confiabilidad,
rendimiento, etc.)

Producto libre de
defectos

Actitud para el uso

genera valor agregado
Ing. Alejandro Bartra

14

01 POR QU SON NECESARIAS LAS PRUEBAS?

PRUEBAS Y CALIDAD
Las pruebas ayudan a medir la calidad del software en trminos de:
cantidad de defectos encontrados,
pruebas ejecutadas y
cobertura lograda con las pruebas.
La calidad se puede medir a travs de caractersticas funcionales (ejemplo: imprimir un
reporte correctamente) y no funcionales (ejemplo, impresin rpida del reporte)
cubiertas por el software (ISO 9126).

Ing. Alejandro Bartra

15

01 POR QU SON NECESARIAS LAS PRUEBAS?

PRUEBAS Y CALIDAD (ISO 9126)

Algunos atributos de la calidad de un producto software se influyen mutuamente.
Debido a esta interdependencia y en funcin del objeto de prueba, los atributos debern
ser caracterizados por una prioridad a efectos de ser tenida en cuenta. Por ejemplo
eficiencia versus portabilidad.
Se realizarn distintos tipos de pruebas con el objeto de medir cada tipo de atributo.

Ing. Alejandro Bartra

16

Por qu son importantes las Pruebas?

Porque el software es probable que tenga fallas

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 fallos
Porque la prueba est incluida en el plan del proyecto
Debido a las fallas que pueden ser muy costosas
Para evitar ser demandado por los clientes
Permanecer en el negocio

Ing. Alejandro Bartra

17

01 POR QU SON NECESARIAS LAS PRUEBAS?

No es una actividad secundaria:

30-40% del esfuerzo de desarrollo

En aplicaciones crticas (p.ej. control de vuelo, reactores nucleares),
de 3 a 5 veces ms que el resto de pasos juntos de la ingeniera del software!
El coste aproximado de los errores del software (bugs) para la economa americana es
el equivalente al 0,6% de su PIB, unos 60.000 millones de dlares

Ing. Alejandro Bartra

18

01 POR QU SON NECESARIAS LAS PRUEBAS?

Costos de Calidad:
Segn Joseph Juran existe la siguiente clasificacin de los costos de la calidad:
Costos de Prevencin
Costos de Evaluacin
Costos por Fallas Internas
Costos por Fallas Externas

Ing. Alejandro Bartra

19

01 POR QU SON NECESARIAS LAS PRUEBAS?

Costos de Prevencin:
Son los costos de todas las actividades especficamente diseados para prevenir fallas
de calidad en productos o servicios
Por ejemplo:
Revisin de nuevos productos
Planeacin de la calidad (manuales, procedimientos, etc.)
Evaluacin de capacidad de proveedores
Esfuerzos de mejora a travs de trabajo en equipo
Proyectos de mejora continua
Educacin y entrenamiento en calidad.......etc.

Ing. Alejandro Bartra

20

01 POR QU SON NECESARIAS LAS PRUEBAS?

Costos de Evaluacin
Son los costos asociados con las actividades de medir, evaluar y auditar los productos o
servicios para asegurar su conformidad con los estndares de calidad y requerimientos
de desempeo.
Por ejemplo:
Inspecciones con el proveedor y en recibo
Pruebas e inspecciones en proceso y al producto terminado
Auditorias al producto, proceso o servicio
Calibracin de equipos de prueba y medicin
Costos de materiales de prueba

Ing. Alejandro Bartra

21

01 POR QU SON NECESARIAS LAS PRUEBAS?

Costos de Falla Interna:

Son los costos resultantes de productos o servicios no conformes a los requerimientos o
necesidades del cliente, antes del embarque del producto o la realizacin del servicio.
Por ejemplo:
Desperdicio
Re-trabajos
Re-inspeccin y repeticin de pruebas
Revisin de materiales no conformes
Reduccin de precio por calidad reducida

Ing. Alejandro Bartra

22

01 POR QU SON NECESARIAS LAS PRUEBAS?

Costos de Falla Externa:

Son los costos resultantes de productos o servicios no conformes a los requerimientos o
necesidades del cliente, despus de la entrega del producto o durante y despus de la
realizacin del servicio.
Por ejemplo:
Proceso de quejas y reclamaciones
Devoluciones del cliente
Garantas
Campaas por productos defectivos

Ing. Alejandro Bartra

23

01 POR QU SON NECESARIAS LAS PRUEBAS?

Costos Totales de Calidad :

Es la suma de los costos de prevencin, evaluacin, falla interna y falla externa.
Los sistemas contables en general no son capaces de identificar estos costos.
Es muy difcil ir al detalle del costo de calidad.
La Distribucin tpica de costos directos en las empresas actuales es el siguiente:
Prevencin 5%
Evaluacin 30%
Fallas internas / externas 65%.

Ing. Alejandro Bartra

24

02
QU SON LAS PRUEBAS DE
SOFTWARE?

02 QU SON LAS PRUEBAS DE SOFTWARE?

DEFINICIN:
Testing como proceso:
Proceso, con una serie de actividades involucradas.
Incurre en todas las actividades del ciclo de vida del software.
Tiene tcnicas estticas y dinmicas.
Que obedece a una planificacin con actividades antes y despus de la ejecucin
de las pruebas como: actividades de ejecucin, control, reporte del avance y
estado de las pruebas; y cierre de las mismas.
Que tiene una preparacin, con la eleccin del tipo de pruebas a realizar, las
condiciones de las mismas y los casos de prueba a ejecutar.
Que est sometido a evaluacin, en la que verificamos los resultados y
comprobamos que el software bajo prueba cumple con los criterios de xito
establecidos.
En el que se evala los productos software y productos de trabajo relacionados.
Y con objetivos definidos:
Determinar que (los productos software) satisfacen los requerimientos
especificados.
Determinar que (los productos software) cumplen su propsito.
Detectar defectos.

Ing. Alejandro Bartra

26

02 QU SON LAS PRUEBAS DE SOFTWARE?

OBJETIVOS DE LAS PRUEBAS

Determinar que el producto software satisface los requerimientos especificados.
Confirma que los productos trabajados apropiadamente reflejan los requerimientos
especificados. En otras palabras, la verificacin asegura que se construye el
producto correctamente.
Confirmacin, a travs de la provisin de objetivos evidenciables, que los
requerimientos especificados han sido cumplidos a cabalidad.
Determinar que el producto de software cumple su propsito.
Confirma que el producto, como condicin rutinaria, cumplir a cabalidad con su
uso propuesto. En otras palabras, la validacin asegura que se construye el
producto correcto.
Detectar Defectos.
Para descubrir fallas o defectos en el software donde su comportamiento no est
en conformidad con su especificacin.

Ing. Alejandro Bartra

27

02 QU SON LAS PRUEBAS DE SOFTWARE?

DEFINICIONES: TEST CASE / TEST BASE

Test Case (Caso de Prueba)
La definicin de un caso de prueba incluye la siguiente informacin (IEEE Std
610):

Precondiciones
Conjunto de valores de entrada
Conjunto de resultados esperados
Forma en la cual se debe ejecutar el caso de prueba y verificacin de resultados
Post condiciones

Test Base o Test Basis (Base de Pruebas / Fundamentos de pruebas)

Conjunto de documentos que definen los requisitos de un componente o sistema,
utilizado como referencia para el desarrollo de casos de prueba.

Ing. Alejandro Bartra

28

02 QU SON LAS PRUEBAS DE SOFTWARE?

DEFINICIONES: CODE / DEBUGGING / SOFTWARE DEVELOPMENT

Code o Source Code (cdigo fuente)
Programa de computadora escrito en un lenguaje de programacin que puede ser
ledo por una persona.
Debugging (Depuracin)
Localizacin y correccin de defectos en el cdigo fuente.
Software Development (Desarrollo de Software)
Es un proceso / secuencia de actividades cuyo objetivo es desarrollar un sistema
basado en un computador (ordenador).

Ing. Alejandro Bartra

29

02 QU SON LAS PRUEBAS DE SOFTWARE?

DEFINICIONES: REQUIREMENT / REVIEW

Requirement (Requisito)
Un requisito describe un atributo funcional o no funcional deseado o considerado
obligatorio.
Review (Revisin)
Evaluacin de un producto o estado de un proyecto con el objeto de detectar
discrepancias con respecto a los resultados esperados (planificados) y para
recomendar mejoras (lEEE Std 1028).

Ing. Alejandro Bartra

30

03
PRINCIPIOS GENERALES DE
LAS PRUEBAS

03 PRINCIPIOS GENERALES DE LAS PRUEBAS

PRINCIPIO 1: LAS PRUEBAS MUESTRAN LA PRESENCIA DE DEFECTOS

La prueba puede mostrar que los defectos estn presentes, pero no pueden probar que
no existen defectos.
La prueba reduce la probabilidad de existencia de defectos no descubiertos, pero eso no
demuestra su ausencia; incluso cuando los defectos no son encontrados.
Las pruebas reducen la probabilidad de la presencia de defectos que permanecen sin ser
detectados. La ausencia de fallos no demuestran que el producto software es correcto.
El mismo proceso de pruebas puede contener errores.
Las condiciones de las pruebas pueden ser inapropiadas para detectar errores.

Ing. Alejandro Bartra

32

03 PRINCIPIOS GENERALES DE LAS PRUEBAS

PRINCIPIO 2: LA PRUEBA EXHAUSTIVA ES IMPOSIBLE

Probar todo (todas las combinaciones de entrada y precondiciones) no es factible,
excepto para casos triviales. En lugar de test exhaustivos, utilizamos tcnicas basadas
en riesgos y prioridades para enfocar los esfuerzos de las pruebas.
Pruebas exhaustivas ("exhaustive testing).
Enfoque del proceso de pruebas donde el conjunto de pruebas abarca todas las
combinaciones de valores de entrada y precondiciones.
Explosin de casos de prueba ("test case explosin").
Define el incremento exponencial de esfuerzo y costo en el caso de pruebas
exhaustivas.
Muestras para probar ("sample test").
La prueba incluye solamente a un subconjunto (generado de forma sistemtica 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 slo es
econmicamente viable en casos triviales.

Ing. Alejandro Bartra

33

Pruebas exhaustivas?

Qu es una prueba exhaustiva?

cuando todos los probadores se han agotado
cuando todas las pruebas previstas se han ejecutado
el ejercicio de todas las combinaciones de los insumos y las condiciones previas

Cunto tiempo toma las pruebas exhaustivas?

tiempo infinito

no mucho tiempo
cantidad de tiempo prctico

Ing. Alejandro Bartra

34

03 PRINCIPIOS GENERALES DE LAS PRUEBAS

PRINCIPIO 3: PROBAR LO MS 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 enfocadas sobre objetivos
definidos.
La correccin de un defecto es menos costosa en la medida en la cual su deteccin se
realiza en fases ms tempranas del proceso software.
Se obtiene una mxima rentabilidad cuando los errores son corregidos antes de la
implementacin.
Los conceptos y especificaciones pueden ser probados.
Los defectos detectados en la fase de concepcin son corregidos con menor esfuerzo y
costo.
.
El proceso de pruebas implica preparacin de una prueba tambin consume tiempo ms
que slo la ejecucin 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 especificacin y diseo software.

Ing. Alejandro Bartra

35

Cuntas pruebas son suficientes?

nunca es suficiente.
cuando usted ha hecho lo que estaba previsto.
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 para su sistema.

Ing. Alejandro Bartra

36

03 PRINCIPIOS GENERALES DE LAS PRUEBAS

PRINCIPIO 4: AGRUPAMIENTO DE DEFECTOS

Un nmero pequeo de mdulos contienen la mayora de los defectos descubiertos
durante la prueba, o muestran la mayora de los fallos operacionales.
Encuentre un defecto y encontrar ms defectos "cerca"!
Los defectos aparecen agrupados.
Cuando se detecta un defecto es conveniente investigar el mismo mdulo 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 identificacin de un defecto puede ser investigada con un mayor grado de detalle. Por
ejemplo, realizando pruebas adicionales o modificando pruebas existentes.

Ing. Alejandro Bartra

37

03 PRINCIPIOS GENERALES DE LAS PRUEBAS

Cunto probar?

Depende del RIESGO

Riesgo de perder las fallas importantes.

Riesgo de incurrir en los costes de fallos.
Riesgo de liberacin de software no probado o pruebas de baja calidad.
Riesgo de perder credibilidad y la participacin en el mercado.
Riesgo de perder una ventana de mercado.
Riesgo de un exceso de pruebas, las pruebas ineficaces.

Ing. Alejandro Bartra

38

03 PRINCIPIOS GENERALES DE LAS PRUEBAS

Tan poco tiempo, mucho para probar...

Tiempo de prueba siempre ser limitado

Utilice el

RIESGO para determinar lo siguiente:

Qu probar primero?
Qu pruebas son ms importantes?
Qu no se debe probar (en este momento)?

Dnde poner
nfasis?

Utilice el RIESGO para :

Asignar el tiempo disponible para probar y priorizar las pruebas.

Ing. Alejandro Bartra

39

03 PRINCIPIOS GENERALES DE LAS PRUEBAS

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 probar diferentes partes del software o sistema a
fin de encontrar ms defectos potenciales.
Repetir pruebas en las mismas condiciones no es efectivo.
Cada caso de prueba debe contar con una combinacin nica de parmetros de entrada
para un objeto de pruebas particular, de lo contrario no se podr obtener informacin
adicional.
Si se ejecutan las mismas pruebas de forma reiterada no se podrn encontrar nuevos
defectos.
Las pruebas deben ser revisadas/modificadas regularmente para los distintos mdulos
(cdigo)
Es necesario repetir una prueba tras una modificacin del cdigo (correccin de defectos,
nueva funcionalidad).
La automatizacin de pruebas puede resultar conveniente si un conjunto de casos de
prueba se deben ejecutar frecuentemente.

Ing. Alejandro Bartra

40

03 PRINCIPIOS GENERALES DE LAS PRUEBAS

PRINCIPIO 6: LA PRUEBA DEPENDE DEL CONTEXTO

La prueba se realiza de manera diferente en diferentes contextos. Por ejemplo, el
software de seguridad crtico se prueba de forma diferente a la de un sitio de comercio
electrnico.
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 aplicacin de e-commerce.
Entorno de pruebas vs. entorno de produccin.
Las pruebas tienen lugar en un entorno distinto del entorno de produccin. El
entorno de pruebas debera ser similar al entorno de produccin.
Siempre habr diferencias entre el entorno de pruebas y el entorno de produccin.
Estas diferencias introducen incertidumbre con respecto a las conclusiones que se
pudieran obtener tras las pruebas.

Ing. Alejandro Bartra

41

03 PRINCIPIOS GENERALES DE LAS PRUEBAS

PRINCIPIO 7: LA FALACIA DE LA AUSENCIA DE ERRORES

Encontrar y solventar defectos no ayuda si el sistema construido est inutilizado y no
satisface las necesidades y expectativas de los usuarios.
Un proceso de pruebas adecuado detectar los fallos ms importantes.
En la mayora de los casos el proceso de pruebas no encontrar todos los
defectos del sistema (ver Principio 2), pero los defectos ms importantes deberan
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 travs de las pruebas; la calidad tiene que construirse
desde el principio.

Ing. Alejandro Bartra

42