Captulo 1:

Error: Accin humana que produce un resultado incorrecto.

Defecto: Desperfecto en un componente o sistema que puede ser la causa el sistema o
componente no logre llevar a cabo su funcin especfica.
Fallo: Manifestacin fsica o funcional de un defecto.

Norma
IEEE 610 Definicin de error, defecto y fallo.
Definicin de calidad-Definicin software
Definicin de caso de prueba
Definicin de pruebas de aceptacin.

ISO 9126 Definicin de calidad del Software (Atributos funcionales y no

funcionales)
IEEE 1028 Tipos de Revisiones
IEEE 828 Estndar gestin de la configuracin (incluyendo el plan de GC)
IEEE 829 Guin de pruebas
Descripcin de un caso de prueba
Estructura del plan de pruebas
Informe de estado de pruebas
Informe de incidencias (Informe de errores)
ISO 9000 Definicin de Verificacin y Validacin
IEEE 730/IEEE Estructura y contenidos de un plan de aseguramiento de la calidad.
983 Est conformado por: Documentos que cubren el ciclo de vida de
desarrollo, Organizacin del proyecto, Proceso de pruebas.
BS7925 - 1 Glosarios de los trminos de prueba de software. (Definicin de
verificacin, validacin y pruebas).
BS7925 - 2 Estndar Pruebas de componentes.

Definiciones segn BS7925 - 1:

Verificacin: El proceso de evaluar un sistema o componente para determinar si los productos
entregados en la fase de desarrollo satisfacen las condiciones acordadas al inicio de esa fase. se
sigui el proceso?
Validacin: Determinacin de la correccin de los productos de software desarrollados con
respecto a las necesidades del usuario y los requerimientos. El sw cumple con lo solicitado por el
cliente?
Pruebas: Proceso de ejercicio software para verificar que se cumple con los requerimientos
especificados y para detectar errores.

La calidad del software est constituida por (ISO 9126):

 Atributos funcionales:
Funcionalidad significa: Correctitud (Atributos requeridos) y Completitud (requisitos
funcionales)
Funcionalidad Incluye: IPCIS
o Idoneidad /Adecuacin): Las funciones implementadas son adecuadas para su uso
esperado?
o Precisin: Las funciones presentan los resultados correctos (acordados)?
o Conformidad: El sistema cumple con normas y reglamentos aplicables?
o Interoperabilidad: Las interacciones con el entorno del sistema presentan algn
problema?
o Seguridad: Estn protegidos los datos/programas contra acceso no deseado o
prdida

Atributos No funcionales: FUEMP

o Fiabilidad (Confiabilidad): Madurez, tolerancia a defectos, recuperacin tras fallos
Calidad/Tiempo.
o Usabilidad: Fcil de usar, fcil de aprender, conforme a normas, intuitivo.
o Eficiencia: Comportamiento del sistema, funcionalidad y respuesta temporal.
o Mantenibilidad: Cualidad de ser analizado, modificable.
o Portabilidad: Capacidad de ser reemplazado, instalable.
NOTA: Los atributos de calidad se influyen mutuamente, debido a esta interdependencia y en
funcin del objeto de prueba, los atributos debern ser caracterizados por una prioridad a los
efectos de ser tenidos en cuenta.
Se realizarn distintos tipos de pruebas con el objeto de medir cada tipo de atributo.
Calidad total del sistema: Atributos de la calidad funcionales + Atributos de la calidad no
funcionales.

QA Analtico: Detectar y corregir defectos

Clase de equivalencia
Anlisis de Valores limite
CAJA NEGRA

Pruebas de Transicin de estados

Tablas de decisin
Algoritmo Pairwise (En parejas)
Tcnicas basadas en la experiencia
Cobertura de sentencia
CAJA BLANCA
DINAMICO

Cobertura de rama (Decisin)

Cobertura de condicin
Cobertura de camino
QA ANALTICO

Revisiones/Ensayos
Anlisis del flujo de control
ESTTICO

Anlisis del flujo de datos

Mtricas del compilador/Analizador
QA Constructivo: Prevencin de defectos
Guas

ORGANIZACIN
Estndares
Listas de Comprobacin
Reglas de proceso y normas
Requisitos legales
QA CONSTRUCTIVO

Mtodos
Herramientas
Lenguajes
TCNICO

Listas/Plantillas
Entorno de desarrollo integrado (IDE)

Principios del proceso de pruebas:

1. Principio 1: Las pruebas demuestran la presencia de defectos Las pruebas pueden
mostrar que hay defectos, pero no que no los hay
2. Principio 2: Las pruebas exhaustivas no existen Es imposible en la prueba cubrir
todas las combinaciones
3. Principio 3: Pruebas tempranas - Iniciar pruebas lo antes posible en el ciclo de vida del
sw
4. Principio 4: Agrupacin de defectos Donde encuentres un defecto, encontraras ms.
5. Principio 5: Paradoja del pesticida La ejecucin de los mismos escenarios evitan
encontrar nuevos errores
6. Principio 6: Las pruebas dependen del contexto Las pruebas son diferentes de
acuerdo al tipo de sistema.
7. Principio 7: Falacia de ausencia de errores No hay errores pero el sistema no cumple
con lo que pidi el cliente

Fases del Proceso de pruebas:

Planificacin: Abarca actividades como la definicin de la estrategia de pruebas para todos

las fases as como la planificacin de los recursos (tiempo, personal, mquinas).

Anlisis y diseo: Abarca el diseo de casos de prueba y sus resultados esperados.

Anlisis: Revisin de las bases de las pruebas (requisitos, arquitectura, diseo, interfaces),
Identificar condiciones de prueba especificas y los datos de prueba. Diseo: Crear casos de
prueba lgicos y establecer un orden de prioridad para los mismos. Crear tanto casos de
prueba positivos como negativos.

Implementacin y ejecucin: Abarca la definicin de datos de pruebas, la ejecucin de

pruebas y la comparacin de resultados. Incluye Creacin de guiones de automatizacin
de pruebas si fuera necesario. Configuracin del entorno de pruebas, Ejecucin de
pruebas de forma manual o automtica, Registro y anlisis de los resultados de pruebas,
Retest y pruebas de regresin.

Evaluacin del criterio de salida y generacin de informe: Abarca el anlisis de defectos y

la evaluacin del criterio de salida. Evaluacin de la ejecucin de las pruebas con respecto
 a objetivos definidos. Proporcionar informacin con el objeto de permitir decisin con
respecto a si tendr lugar pruebas adicionales.

Actividades de cierre: Recopilar datos de las actividades del proceso de pruebas

finalizadas con el objetivo de consolidar la experiencia, producto de las pruebas
(testware), hechos y resultados. Cierre de informes de incidencias o generacin de
solicitudes de cambio para cualquier punto que permaneciera abierto. Comprobar que
entregables planificados han sido entregados y probados. Documentar la aceptacin del
sistema. Finalizar y archivar los productos de las pruebas (testware). Lecciones aprendidas.

Control (Transversal): Actividad contina que influye en la planificacin de las pruebas. El

plan de pruebas puede ser modificado en funcin de la informacin adquirida a partir del
control de pruebas. El progreso, la cobertura y el cumplimiento del criterio de finalizacin
son objeto de seguimiento y son documentados.

NOTA: Las fases del proceso de pruebas se pueden superponer.

Incluye backtracking (vuelta atras).
Cada fase del proceso de pruebas tiene lugar de forma concurrente con las fases del proceso de
desarrollo software.

Objetivos de las pruebas:

Adquirir conocimiento sobre los defectos en un objeto de prueba.
Comprobar la funcionalidad.
Generar informacin.
Generar confianza.
Pruebas dirigidas por Objetivos:
Deteccin de defectos
Verificar la funcionalidad

Orculo De Pruebas: Fuente que permite determinar los resultados esperados en un software
sujeto a pruebas: comparativas benchmarks, manuales de usuario o conocimiento especializado.
No debe ser el cdigo.
Base de la prueba: Conjunto de documentos que definen los requisitos de un componente o
sistema utilizado como fundamento para el desarrollo de casos de prueba.

Criterio para la finalizacin:

No encontrar ms defectos es un criterio apropiado para finalizar las pruebas, sin embargo son
necesarias otras mtricas:
Pruebas basadas en riesgo
Pruebas basadas en plazos y presupuestos
Nota: Cada prueba debe contar con un criterio para la finalizacin de pruebas. Al alcanzar el
criterio de finalizacin de pruebas finalizan las actividades del proceso de pruebas.

PARA CADA NIVEL DEPRUEBAS SE DEBE DEFINIR:

Estrategia de pruebas: Descripcin a alto nivel de los niveles de prueba a llevar a cabo y
las pruebas asociadas a ellos.
 Se elige el mtodo de prueba, cmo y cuando las actividades asociadas a las pruebas
debern ser ejecutadas y cuando se debe detener el proceso de pruebas ->Criterio de
finalizacin.

Criterio de salida: Conjunto de condiciones genricas y especficas, acordadas con los

implicados para permitir que un proceso sea considerado formalmente finalizado. El
propsito de los criterios de salida es evitar que una tarea se considere finalizada
habiendo partes destacadas de la misma sin completar. Los criterios de salida son
utilizados como fuente para elaborar informes y planificar la suspensin de las pruebas.

Caso de prueba (IEEE610):

1. Precondiciones
2. Conjunto de valores de entrada
3. Conjunto de resultados esperados
4. Pasos (Forma en la cual se debe ejecutar el caso de prueba y verificar el resultado)
5. Pos condiciones esperadas

Capitulo 2:
El modelo V general es el modelo de desarrollo software ms utilizado.
Desarrollo y pruebas son dos ramas iguales.
Cada nivel de desarrollo tiene su correspondiente nivel de pruebas.
Las pruebas (rama derecha) se disean en paralelo al desarrollo software (rama izquierda).
Las actividades del proceso de pruebas tienen lugar a lo largo de todo el ciclo de vida software.

Rama: Desarrollo software

Definicin de requisitos: Documentos de especificacin.
Diseo funcional del sistema: Diseo del flujo funcional del sistema.
Diseo tcnico del sistema: Definicin de arquitectura Interfaces
Especificacin de los componentes: Estructura de los componentes.
Programacin: Creacin de cdigo ejecutable.
Rama: Pruebas software:
Pruebas de componente: Funcionalidad del componente.
Pruebas de integracin: Interfaces de componentes.
Pruebas de sistema: Sistema integrado especificaciones.
Pruebas de aceptacin: Pruebas formales de los requisitos del cliente.
Modelo V: Describe los niveles de desarrollo y niveles de prueba como dos ramas relacionadas.
Verificacin vs Validacin (ISO 9000):
Verificacin: Comprobacin de la conformidad con los requisitos establecidos Se ha
procedido correctamente en la construccin del sistema?
En el modelo en V, significa comprobar si los requisitos y definiciones de niveles previos
han sido implementados correctamente. Relacin con el nivel precedente. -> Rama
Desarrollo

Validacin: Comprobacin de la idoneidad para el uso esperado Hemos construido el

sistema software correcto?
En el modelo en V, significa comprobar lo adecuado de los resultados de un nivel de
desarrollo. Grado de ser correcto el producto dentro del nivel actual. - >Rama Pruebas.

Modelos de prueba iterativos:

Las actividades de definicin de requisitos, diseo, desarrollo y pruebas se segmentan en pasos
reducidos y se ejecutan de forma continua.
Se debe alcanzar el consentimiento con el cliente tras cada iteracin con el objeto de modificar el
rumbo del proyecto si fuera necesario.
Ejemplos:
Modelo prototipado.
Desarrollo rpido de aplicaciones (RAD): La interfaz de usuario se implementa utilizando una
funcionalidad hecha, simulando la funcionalidad que posteriormente ser desarrollada.
Proceso Unificado (RUP): Modelo orientado al objeto. Producto de la compaa IBM.
Principalmente aporta el lenguaje de modelado UML y soporte al proceso Unificado.
Programacin extrema: El desarrollo y las pruebas tienen lugar sin una especificacin de
requisitos formalizada.
Driver: Procesa la interfaz de un componente. Simulan datos de entrada, registran datos de salida
y aportan una armadura de pruebas. Utilizan herramientas de programacin.
Stub: Reemplaza o simula un componente que an no se encuentra disponible.

Niveles en el proceso de pruebas:

Pruebas de componentes: (Pruebas de mdulo, de clase, de unidad y de desarrollador)
Pruebas de cada componente tras su realizacin.
Solo se prueban componentes individuales.
Un componente es la unidad ms pequea especificada de un sistema.
Podrn comprobar caractersticas funcionales y no funcionales de un sistema.
Se utilizan herramientas de programacin como debbugers.
Los efectos cruzados entre componentes quedan fuera del alcance de estas pruebas.
La ejecucin de pruebas de componente requiere frecuentemente de drivers (procesa la interfaz
de un componente) y stubs (Reemplaza o simula un componente que an no se encuentra
disponible).
El conocimiento del cdigo fuente permitir la aplicacin de mtodos de caja blanca para pruebas
de componente.
Fuerte orientacin al desarrollo.
Pruebas de integracin: (Pruebas de interfaz)
Comprueba la integracin entre los elementos software (componentes) tras la integracin del
sistema.
Asume que los componentes ya han sido probados.
Son necesarios drivers de prueba. (Se pueden reutilizar los de los componentes)
Herramientas de control apoyan las actividades de este nivel de prueba.
Es la actividad en la cual se combinan componentes software individuales en subsistemas ms
amplios.
En condiciones reales factores adicionales del entorno pueden influir en el comportamiento del
componente. Por lo tanto las pruebas de integracin no pueden garantizar un comportamiento
correcto en el entorno real del sistema.
La estrategia de desarrollo influye en la estrategia de integracin.

Estrategias: (Determina la magnitud del esfuerzo requerido para las pruebas)

Estrategia ascendente (bottom - up): Un enfoque incremental de pruebas de integracin
donde los componentes de ms bajo nivel son probados en primer lugar, posteriormente
son utilizados para facilitar las pruebas de componentes de un nivel superior. Este proceso
se repite hasta que es probado el componente en el extremo superior de la jerarqua.
Estrategia descendente (top-down): Enfoque incremental de las pruebas de integracin
donde el componente en el nivel ms alto en la jerarqua es probado primero, con los
componentes del nivel inferior son simulados mediante stubs. Los componentes probados
son usados luego para probar a los componentes del nivel inferior. El proceso se repite
hasta que el nivel ms bajo haya sido probado.
Ad hoc: Inicio temprano de las actividades de prueba dando lugar a un proceso de
desarrollo software ms corto en trminos globales. Pruebas llevadas a cabo de manera
informal; no se realiza una preparacin formal de la prueba, no se utilizan tcnicas de
diseo reconocidas, no existen expectativas para con los resultados y la arbitrariedad gua
la actividad de ejecucin.
Big bang: Tipo de pruebas de integracin en el que los elementos software, elementos
hardware ambos son combinados en un componente o un sistema global en lugar de
hacerlo por fases.
NOTA: La estrategia de desarrollo influyen en la estrategia de integracin

Pruebas de sistema:
Pruebas del sistema software integrado con el objeto de comprobar la conformidad con los
requisitos especificados.
La calidad del software es observada desde el punto de vista del usuario.
Despliegue en el entorno real del sistema con datos reales.
No son necesarios stubs o drivers.
El entorno de pruebas debe coincidir con el futuro entorno real del sistema.
Se refieren a Requisitos funcionales y no funcionales.
Las pruebas de sistema funcionales confirman que los requisitos para un uso especfico previsto
han sido satisfechos (validacin).
Las pruebas de sistema no funcionales verifican los atributos de calidad no funcionales. Con
frecuencia estos atributos son una parte implcita de los requisitos, esto hace difcil validarlos.
Enfoques para probar requisitos funcionales:
Pruebas basadas en requisitos, en procesos de negocio y en casos de uso.
Pruebas de aceptacin:
Son pruebas formales llevadas a cabo con el objeto de verificar la conformidad del sistema con los
requisitos. El objetivo es aportar justificacin a la confianza en el sistema para que pueda ser
aceptado por el cliente.
Pruebas de aceptacin Aceptacin Contractual:
Con la aceptacin formal se cumplen hitos legales: Comienzo de fases de garanta, hitos de abono
(pago), acuerdos de mantenimiento.
Normalmente el cliente selecciona casos de prueba para las pruebas de aceptacin.
Pruebas de aceptacin Pruebas de aceptacin operativa:
Requiere que el software sea adecuado para su uso en un entorno operativo.
Integracin del software con la Tecnologa de informacin del cliente.
Con frecuencia son realizadas por el administrador de sistemas del cliente.
Son las pruebas de sistema por parte del cliente. El cliente conoce su negocio
Es una actividad de carcter contractual (satisface los requisitos del cliente?).
Requiere que el software sea adecuado para su uso en un entorno operativo.
Integracin del software en la estructura TI del cliente.

Pruebas de aceptacin Pruebas Alfa y Beta:

Pruebas Alfa: El cliente ejecuta las pruebas en las dependencias de la organizacin que
desarrolla.
Pruebas Beta (Pruebas de campo): El cliente ejecuta las pruebas en dependencias propias.
TIPOS DE PRUEBA:
Pruebas funcionales:
Objetivo: Probar la funcin.
Se pueden llevar a cabo en todos los niveles de prueba.
Se utilizan los mtodos de caja negra.
Se desarrollan teniendo en cuenta los requisitos funcionales.
Los resultados de la ejecucin de la prueba son comparados con los resultados esperados.

Pruebas no funcionales:
Objetivo: Probar las caractersticas del producto software.
Se pueden llevar a cabo en todos los niveles.
Las caractersticas de calidad no funcionales a menudo son incompletas, inexistentes por lo que
hace ms difcil las pruebas.
Ejemplo de pruebas no funcionales:
Pruebas de carga (ms usuarios, ms transacciones), de rendimiento (Rapidez-tarea), de volumen
(Procesamiento grandes cantidades de datos), de estrs (reaccin sobrecarga, recuperacin tras
fallos), de estabilidad (modo de operacin continuo), de robustez (entradas errneas, datos no
especificados, reaccin a fallos Hw, recuperacin ante desastres), de seguridad de datos
(proteccin contra accesos no autorizados), de compatibilidad (cumplimiento de normas y
reglamentos. Reaccin a diferentes entornos), de usabilidad.
NOTA: La conformidad con los requisitos no funcionales, se miden utilizando requisitos
funcionales.
Pruebas estructurales:
Objetivo: Probar la estructura/arquitectura software Cobertura.
Medir el grado en el cual la estructura del objeto de prueba ha sido cubierto por los casos de
prueba.
Enfoque: Caja blanca
Son posibles en todos los niveles.
Comprueban el flujo de control y datos midiendo la cobertura en el objeto de pruebas.
Se realizan de forma conjunta a las pruebas de componente y de integracin mediante el uso de
herramientas.
El diseo se realiza despus del diseo de las pruebas funcionales, para obtener un alto grado de
cobertura.

Pruebas de confirmacin/regresin (Pruebas relacionadas a cambios):

Objetivo: Probar despus de cambios
Se realizan despus de que un objeto de pruebas o en entorno de su sistema ha sido objeto de
modificacin.
Pruebas de regresin: Repetir una prueba de funcionalidad que ha sido verificada
previamente. Pruebas para descubrir nuevos defectos introducidos en una funcionalidad
previamente sin fallos.
Pruebas de confirmacin (retest): Pruebas despus de la correccin de defectos.
Pueden ser realizadas en todos los niveles.
Nota: Pruebas de mantenimiento: Probar los cambios en un sistema en operacin o el impacto de
un entorno modificado en un sistema en operacin.

Capitulo 3:
Tcnicas estticas:
Comprenden varios mtodos que no ejecutan el componente o sistema objeto de prueba.
Incluyen:
Revisiones (Actividad Manual). Se utilizan para verificar la correcta transicin de una fase a
la siguiente, segn est definido en el lado izquierdo del modelo en V.
Anlisis Esttico (Actividad basada en herramientas)

REVISIONES:
Complementan los mtodos dinmicos.
Detectan defectos en lugar de fallos, en una fase temprana antes de que sean implementadas en
el cdigo.
Objetivo: Mejorar la calidad del producto.
Moderador y participantes influyen directamente en la calidad de la revisin.
Las revisiones permiten detectar defectos en especificaciones, diseo/arquitectura, desviaciones
con respecto al estndar, mantenibilidad insuficiente.
Fases de una revisin:
Planificacin: Organizacin de la revisin, seleccin de miembros.
Preparacin de la organizacin e inicio kick-off: Distribucin objetivos de la revisin e
informacin adicional.
Preparacin individual: Inspeccin de los objetivos, se comentan los elementos en caso de
aclaraciones.
Reunin de revisin: Evaluadores presentan los resultados.
Seguimiento follow-up: Resultados ->Responsables, Recomendaciones.

Roles:
Director/Responsable/Jefe de proyecto.
Moderador.
Autor.
Evaluador/Inspector/Revisor.
Secretario.
Tipos de revisiones:
Inspeccin: Basado en reglas, uso de listas de comprobacin, Moderador capacitado e
independiente, proceso formal. Propsito: Deteccin de defectos utilizando un mtodo
estructurado. Roles claramente definidos, requiere preparacin.
Walkthrough: Dirigida por el autor, no es necesario moderador, posibilidad limitada de
control. Opcionalmente puede haber una preparacin de los evaluadores previa a la
reunin. El resultado queda abierto. Autor -> Influye en el resultado.
Revisin tcnica: Son necesarios expertos preferiblemente externos, la reunin puede
tener lugar sin la presencia del autor, se presenta las recomendaciones con carcter
unnime. Se requiere preparacin. Ejemplo: SQA.
Revisin informal (revisin por pares): Forma de revisin ms simple, frecuentemente
iniciada por el autor, solo estn incluidos los evaluadores, no es necesaria reunin. No hay
protocolo.
NOTA: Para la ejecucin apropiada de las revisiones es necesario un presupuesto suficiente 10-
15% del costo total del desarrollo.
Duracin: Mximo 2 Horas.

Anlisis Esttico:
Anlisis del objeto de prueba (cdigo fuente, guin/script, requisitos) llevado a cabo sin ejecutar el
producto software.
Se comprueba:
Reglas y estndares de programacin
Diseo de un programa (anlisis de flujo de control)
Uso de datos (anlisis de flujo de datos)
Complejidad de la estructura de un programa (Mtricas, ej: Nmero ciclomtico)
Todos los objetos de prueba deben tener una estructura formal.
El anlisis esttico de un programa mediante el uso de herramientas, se desarrolla con menor
esfuerzo que el de una inspeccin, por lo que con mucha frecuencia este se realiza antes de una
revisin.

Herramientas a utilizar:
Compiladores: Detecta errores sintcticos en el cdigo fuente de un programa, comprueba
la consistencia entre los tipos de variables. Detecta variables no declaradas o cdigo
inaccesible (cdigo muerto).
Analizadores: Trata aspectos como convenciones y estndares, mtricas de complejidad y
acoplamiento de objetos.
Anlisis de flujo de control:
Detectar defectos causados por un desarrollo anmalo del cdigo (ramas muertas, cdigo muerto,
retornos mltiples).
Visin del conjunto del cdigo de programa comprensible.
Mtodo: La estructura del cdigo se representa como un diagrama de control de flujo (grafo
dirigido).
Construccin mediante herramientas.
Anlisis de flujo de datos:
Deteccin de anomalas en el flujo de datos con la asistencia de los diagramas de control de flujo y
conjeturas racionales respecto de la secuencia de flujos de datos.
Se puede detectar fcilmente la localizacin exacta de los defectos.
Nmero ciclomtico:
Mtrica que mide la complejidad esttica de un programa basada en su grafo de flujo de control.
Aporta un ndice del nmero de casos de prueba necesarios para alcanzar cobertura de decisin.
Tambin puede ser calculado como el nmero de decisiones independientes + 1. (Puede dar
diferente valor debido a ramas superfluas o ramas faltantes).
Mide los caminos linealmente independientes como ndice de testeabilidad y mantenibilidad.
Frmula: V(G)=e-n+2p
e: Nmero de aristas
n: Nmero de nodos
p: Nmero de partes del programa independientes inspeccionadas (normalmente 1)
Valores hasta 10 son aceptables (Segn McCabe)
Aporta un ndice del nmero de casos de prueba necesarios para alcanzar cobertura de decisin.
NOTA: Ejemplo de otras mtricas LOC (Lneas de cdigo)

Capitulo 4:
Diseo de casos de prueba:
Los casos de prueba y los juegos de pruebas (test suites) son obtenidos a partir de los requisitos o
caractersticas de los objetos de pruebas.
El diseo de casos de prueba debe ser un proceso controlado.
Los casos de prueba pueden ser creados formal o informalmente dependiendo de las
caractersticas del proyecto y la madurez del proceso en uso.
Descripcin de un caso de prueba (IEEE829):
Valores de entrada
Precondiciones
Resultados esperados
Poscondiciones
Dependencias (orden de ejecucin)
Identificador distinguible
Requisitos

TCNICAS DE DISEO DE PRUEBAS:

Las pruebas dinmicas se dividen en dos categoras/grupos:
Tcnica caja Negra (Funcional/Orientada a la especificacin):
La estructura del objeto de prueba es irrelevante o desconocida.
Los casos de prueba se obtienen a partir del anlisis de la especificacin (funcional o no funcional)
de un componente o sistema.
Prueba del comportamiento entrada-salida.
La funcionalidad es el foco de atencin.
Las pruebas funcionales estn dirigidas a verificar que la funcin sea correcta y completa.
La cobertura de la especificacin puede ser medida. (Ej: El porcentaje de la especificacin cubierta
por los casos de prueba)
1. Particin equivalente o clase de equivalencia: Es lo que la mayora de los probadores
hacen de forma intuitiva: dividen los posibles valores en clases. Mediante lo cual
observan:
- Valores de entrada de un programa (uso habitual del mtodo CE)
- Valores de salida de un programa (uso poco habitual del mtodo CE)
Se evala un valor (tpico) de la clase de equivalencia.
El rango de valores definido se agrupa en clases de equivalencia, se aplican las siguientes
reglas:
- Todos los valores para los cuales se espera que el programa tenga un comportamiento
comn se agrupan en una clase de equivalencia CE.
- Las clases de equivalencia no se pueden superponer y no pueden presentar ningn
salto (discontinuidad)
- Las clases de equivalencia pueden consistir en un rango de valores o en un valor
aislado.
Las pruebas se ejecutan utilizando un nico representante de la clase equivalente. Para
otro valor perteneciente a la clase equivalente se espera el mismo comportamiento que
para el valor seleccionado.
La calidad de la prueba depende de la segmentacin precisa de variables o elementos en
clases de equivalencia.
Todas las variables de entrada del objeto de entrada son identificadas. Ejemplo: Campos
de una interfaz grfica de usuario o parmetros de una funcin.

La cobertura de clases de equivalencia puede ser utilizada como criterio de salida para
finalizar las actividades del proceso de pruebas.

Tratan entradas en condiciones aisladas.

Dado el posible enmascaramiento de errores, se debe evitar combinaciones de

representantes de CE invlidos con representantes de otras CE invlidas en un mismo caso
de prueba.

Cobertura CE: (Nmero de CE probados/Nmero de CE definidos)*100%

2. Anlisis de valores lmite: Amplia la tcnica de particin en clases de equivalencia

introduciendo una regla para seleccionar a los representantes.

Se evala los valores lmite (frontera) y su entorno.

Se detectan errores de programacin causado por un operador de comparacin errneo.

Tratan entradas en condiciones aisladas.

3. Tablas de decisin & grficos causa y efecto:

Tienen en cuenta el efecto de dependencias y combinaciones de entrada.

El diagrama causa y efecto utiliza un lenguaje formal.

Se genera traduciendo la especificacin (normalmente informal) de un objeto de prueba a

un lenguaje formal.

o Aseveracin (Afirmacin): Si causa A- entonces efecto E

A E

o Negacin: Si causa A - entonces no efecto

A ~ E

o O (Or): Si Causa A o B - entonces efecto E

A
E
B v

o Y (And): Si causa A y B -entonces efecto E

A
E
B

o Exclusivo: O causa A o causa B

A
Ex
B

o Inclusivo: Por lo menos una de las dos causas A o B

A
I
B
 o Una y solo una (Una y exactamente una de las dos causas A o B)

A
O
B

o Requerido: Si causa A entonces tambin causa B

A
R

Es difcil deducir valores lmite a partir del diagrama causa y efecto o de la tabla de
decisin, por esta razn es recomendable realizar una combinacin entre los dos.
El nmero de causas y efectos analizados determinarn la complejidad del diagrama causa
y efecto. (Para n precondiciones cuyos posibles valores puedan ser Verdadero o falso -> 2
casos de prueba.
Para sistemas de mayor tamao este mtodo solo es controlable con el apoyo de
herramientas.
4. Pruebas de transicin de estado:

A travs de diagramas de transicin de estado se modelan los distintos estados que puede
tomar un objeto de prueba.

El Anlisis de transicin de estado se utiliza para definir casos de prueba basados en la

transicin de estado.

rbol de transicin de estado: Sirve para determinar los casos de prueba utilizando un
diagrama de transicin de estado.

Para todos los estados, las posibles transiciones de un estado a otro se representan como
ramas.

El estado inicial es la raz del rbol.

Cada camino desde la raz hasta una hoja, representa un caso de prueba para las pruebas
de transicin de estado.

Buen mtodo de pruebas para aquellos objetos de prueba que pueden ser descritos como
una mquina de estado. Sirve para probar clases si se dispone del ciclo de vida del objeto.

El rbol de transicin de estado puede ser ampliado aplicando transiciones no vlidas

(casos de prueba negativos, pruebas de robustez).
 Con frecuencia los estados suelen ser complejos.

Criterios de salida de las pruebas:

Cada estado debe haber sido alcanzado al menos una vez.
Cada transicin debe haber sido ejecutada al menos una vez.

5. Pruebas de caso de uso: Los casos de prueba se obtienen directamente a partir de los
casos de uso del objeto de prueba.

El objeto de prueba es visto como un sistema reaccionando con actores.

Un caso de uso describe la interaccin de todos los actores involucrados conduciendo a un

resultado final por parte del sistema.

Todo caso de uso tiene precondiciones (deben ser cumplidas) y poscondiciones.

Describe un comportamiento, no una secuencia de acciones.

Muestra la reaccin del sistema desde el punto de vista del usuario.

Debido a que este mtodo no obtiene casos de prueba adicionales que vayan ms all de
la informacin aportada por el caso de uso, se debe utilizar solo en combinacin con otros
mtodos de diseo sistemtico de casos de prueba.

Pruebas apropiadas para pruebas de aceptacin y sistema.

Cada caso de uso describe un escenario.

Otras pruebas de caja negra:

6. Pruebas estadsticas: Una tcnica de diseo de pruebas en la que se usa un modelo de

distribucin estadstica de las entradas para construir casos de prueba representativos.
Vase tambin pruebas de perfil operativo.

7. Pruebas duales (Algoritmo pairwise)

8. Pruebas de humo: Subconjunto de todos los casos de prueba definidos/planeados que

cubren la funcionalidad principal de un componente o sistema, con el objeto de asegurar
que las funciones cruciales de un programa funcionan, pero sin preocuparse por los
detalles finos

Tcnica Caja blanca: (Prueba estructural o pruebas basadas en el flujo de control)

Se conoce la estructura interna del programa/cdigo
Ej: Jerarqua de los componentes, flujo de control, flujo de datos.
Los casos de prueba son seleccionados en basa a la estructura interna del programa/cdigo.
La estructura del programa es el foco de atencin.
Principalmente, los mtodos de caja blanca son utilizados en pruebas de bajo nivel como pruebas
de componente o pruebas de integracin.
Las tcnicas de caja blanca requieren el apoyo de herramientas para: La especificacin de caso de
prueba (generacin automtica del diagrama del flujo de control a partir del cdigo fuente del
programa) y Ejecucin de prueba (Herramientas para monitorizar y controlar el flujo del programa
dentro del objeto de prueba).
El soporte de herramientas asegura la calidad de las pruebas e incrementa su eficiencia (Debido a
la complejidad).
La medicin de la cobertura se realiza con el uso de herramientas diseadas de forma especifica
(Herramientas de Anlisis de Cobertura).
El cdigo faltante no puede ser detectado utilizando tcnicas de caja blanca.

Grado de cobertura de un programa: Se mide con el uso de herramientas:

o La instrumentacin del cdigo: Cuenta la ejecucin de caminos, es decir se insertan
contadores en el cdigo del programa del objeto de prueba. Estos contadores son
inicializados en cero, de esta manera cada ejecucin del camino especfico incrementar el
contador correspondiente. Los contadores que mantienen el valor en cero tras las pruebas
indican las partes del programa que an no han sido ejecutadas.
Tcnicas de diseo de caja blanca:
1. Cobertura de sentencia/Cobertura de cdigo: Porcentaje de sentencias ejecutables que
han sido practicadas por los casos de prueba.

Tambin puede ser aplicado a mdulos, clases, elementos de un men, etc.

El foco de atencin es la sentencia del cdigo de un programa.

La base de este anlisis es el diagrama del flujo de control. Se centra en los nodos.

Todas las instrucciones estn representadas por nodos y el flujo de control entre
instrucciones est representado por una arista (flecha).

Si hay cdigo muerto en el programa no se podr lograr una cobertura del 100%.

Cobertura de sentencia 0= 100%

2. Cobertura de Rama/Decisin: Porcentaje de resultados de decisin que han sido

practicados por los casos de prueba.

Se centra en el flujo de control de un segmento de programa (no los nodos sino las aristas
del diagrama de flujo de control)

El bucle no se cuenta como una decisin adicional.

Cobertura de decisin 1= 100%

Cobertura de rama 1= 100%

 Una cobertura de decisin del 100% siempre incluye una cobertura de sentencia del 100%.

Un solo camino a travs de un bucle es suficiente.

No se pude detectar sentencias faltantes.

No es suficiente para probar condiciones complejas.

No es suficiente para probar bucles de forma extensiva.

No se consideran las dependencias entre bucles.

3. Cobertura de condicin: Se tiene en cuenta la complejidad de una condicin que est

constituida por mltiples condiciones atmicas.
Una condicin atmica no puede ser dividida en sentencias condicionales ms pequeas.

Este mtodo tiene por objetivo detectar defectos que resulten de la implementacin de
condiciones mltiples (condiciones combinadas).

Las condiciones mltiples estn constituidas por condiciones atmicas que se combinan
con el uso de operadores lgicos como XOR AND, OR, etc.

Las condiciones atmicas no contienen operadores lgicos solo contienen operadores

relacionales y el operador NOT (<,>,=)

Hay 3 tipos de cobertura de condicin (De acuerdo al grado)

o Cobertura de condicin simple: Cada subcondicin atmica de una sentencia

condicional combinada tiene que tomar, al menos una vez, los valores lgicos
verdadero (true) as como falso (false).

o Cobertura de condicin mltiple: Todas las combinaciones que puedan ser creadas
utilizando permutaciones de las subcondiciones atmicas deben formar parte de
las pruebas, es decir se crean todas las combinaciones de valores verdadero y
falso. El nmero de casos de prueba se incrementa de forma exponencial.
n = Nmero de condiciones atmicas.
2 = nmero de casos de prueba.

Asegura cobertura de sentencia y de decisin.

Alto nmero de casos de prueba.

Xor
 OR

AND

o Cobertura de condicin mltiple mnima: Todas las combinaciones que puedan ser
creadas utilizando los resultados lgicos de cada sub-condicin deben ser parte de
las pruebas, slo si el cambio del resultado de una sub-condicin cambia el
resultado de la combinacin combinada.
El nmero de casos de prueba se puede reducir a un valor entre n+1 y 2n

Son cubiertas las coberturas de sentencia y decisin.

Tiene en cuenta la complejidad de las sentencias de decisin.

4. Cobertura de camino: Porcentaje de caminos de ejecucin que han sido practicados por
casos de prueba. Se centra en la ejecucin de todos los posibles caminos a travs de un
programa.

Un camino es una combinacin de segmentos de programa (en un diagrama de flujo de

control: una secuencia de alternante de nodos y aristas).
Para cobertura de decisin, un solo camino a travs de un bucle es suficiente. Para la
cobertura de camino hay casos de prueba adicionales. Esto puede conducir a un nmero
muy alto de casos de prueba.
El objetivo de esta prueba (criterio de salida) es alcanzar un porcentaje definido de
cobertura de camino.

Cobertura de camino = 100%

El 100% de cobertura de camino solo se puede lograr en programas muy simples,

Todo nmero de posible de ejecuciones de un bucle constituye un nuevo caso de prueba.

 Tericamente es posible un nmero indefinido de casos de prueba.

La cobertura de camino es ms exhaustiva que la cobertura de sentencia y decisin.

100% cobertura de camino, incluye 100% de cobertura de decisin, que a su vez incluye
100% cobertura de sentencia.

100% Camino

100% Decisin

100% Sentencia

Otras tcnicas:
5. LCSAJ: Secuencia lineal de cdigo y salto
6. Tcnicas basadas en el flujo de datos

Tcnicas basadas en la experiencia/Intuitivas

Practica para la creacin de casos de prueba sin un claro enfoque metodolgico, basada en la
intuicin y experiencia del probador.
Incluyen (Tcnicas de Diseo de casos de prueba):
- Prediccin de errores (error guessing): Pruebas orientadas a puntos dbiles.
- Pruebas exploratorias: Pruebas iterativas basadas en el conocimiento adquirido
respecto del sistema.
Complementan las tcnicas sistemticas para determinar casos de prueba.
No cumple los criterios de un proceso de prueba sistemtico.
Dependen en gran medida de la habilidad individual del probador.
Criterios para seleccionar el enfoque apropiado de diseo de casos de prueba:
- Fuente de pruebas (Fuente de la informacin respecto de los objetos de prueba)
- Objetivos del proceso de prueba (Que conclusiones de deben obtener a travs de las
pruebas)
- Aspectos asociados al riesgo.
- Estructura del proyecto/precondiciones (recursos, mtodos de desarrollo info clave
del proyecto).
- Requisitos contractuales/cliente.
-
Capitulo 5:
La gestin de pruebas como parte del proceso de pruebas.
La gestin de pruebas es la gestin del proyecto.
El proceso de pruebas es una actividad que cubre por completo el proceso de desarrollo de
software.
Actividad Producto Resultado de trabajo
Concepcin de pruebas Plan de pruebas (Esttico)
Planificacin de pruebas Plan de pruebas (Dinmico)
Control de pruebas Informe de estado, accin de control
Pruebas de aceptacin Versin del producto software

Roles asociados al proceso de pruebas:

Jefe de pruebas/Director de pruebas/Coordinador de Pruebas:
Planifica y realiza el seguimiento y control del proyecto de pruebas.
Competencias:
o Gestin de pruebas y calidad software
o Planificacin y control de pruebas
o Experiencia como jefe de proyecto
o Habilidades de gestor
Tareas:
o Organizacin del equipo de pruebas
o Planificacin de pruebas (de acuerdo con el plan de calidad corporativo)
o Planificacin de los ciclos de pruebas
o Estrategia de pruebas
o Ejecucin y control de pruebas
o Introduccin de un sistema de gestin de incidencias adecuado
o Introduccin de un sistema de gestin de la configuracin
o Informes de resultado y progreso para la direccin de la organizacin/compaa (El
cierre de las pruebas se confirma con el jefe de pruebas cuando todos los criterios de
salida (medidos utilizando mtricas) son cumplidos/alcanzados)
o Evala el informe de problemas (Luego de que el tester detecta los errores)
o Asigna prioridades a los errores detectados (de acuerdo con la direccin del proyecto,
cliente, etc.)
o Redacta el informe de estado en funcin del estado actual de las labores de
correccin.
o Planificacin del ciclo de pruebas.
Conclusin: Las tareas del jefe de pruebas son: Iniciacin, control, supervisin y ciclos de
pruebas.

Diseador de pruebas:
Disea los casos de prueba necesarios y establece el orden en el cual tendrn lugar la ejecucin de
los casos de prueba.

Competencias:
o Conocimiento de desarrollo y pruebas
o Conocimiento de ingeniera de software
o Conocimiento respecto a especificaciones tcnicas
o Conocimiento de requisitos funcionales
Ingeniero de automatizacin de pruebas:
Evala las posibilidades de la automatizacin de pruebas y las implementa.
Competencias:
 o Experiencia como tester
o Conocimiento tcnico Know How en el mbito de diseo y automatizacin de pruebas.
o Conocimientos de programacin
o Amplios conocimiento en el uso de las herramientas utilizadas.
Administrador del sistema de pruebas:
Prepara y opera el entorno de pruebas.
Competencias:
o Administracin de sistemas
o Conocimiento de herramientas de desarrollo y pruebas
o Sistemas de base de datos (si aplica)
o Redes (si aplica)
o Instalacin y operacin de software del sistema
Tester:
Ejecuta las pruebas de acuerdo con la especificacin de casos de prueba.
Competencias:
o Conocimiento bsico del software
o Conocimiento bsico de pruebas
o Operacin y uso de herramientas de pruebas
o Experiencia en la ejecucin de pruebas
o Conocimiento respecto de los objetos de prueba
Tareas:
o Asiste en la implementacin del plan de pruebas
o Ejecuta los casos de prueba y registra los resultados
o Introduce los errores en un repositorio
o Informa las pruebas
o Asiste en la implementacin de la automatizacin de pruebas
Experto tcnico:
Asiste al equipo de pruebas cuando es necesario.
Competencias:
o Administracin de bases de datos o diseo de bases de datos.
o Experto en interfaces de usuario.
o Experto en redes.
Consejo de control del cambio (CCC):
Decide respecto de los cambios de requisitos y sus prioridades.
Desarrollador:
Analiza los fallos, localiza la causa del error.
Corrige la causa de error de acuerdo con la prioridad asignada.
Ejecuta todos los cambios aprobados.

Actividades de cada fase del proceso de pruebas:

Planificacin de pruebas:
o La planificacin de pruebas es planificacin de proyectos.
o Es parte de la planificacin de la calidad en su conjunto.
o Todas las tareas deben ser planificadas con antelacin.
o Planificacin de recursos -> Para las distintas tareas se deben asignar recursos
(personal, presupuesto, herramientas, entornos de prueba, etc.). Estimar el esfuerzo
de los miembros del equipo, incluyendo sus necesidades en trminos de tiempo,
 herramientas, actividades de apoyo, etc. Estas estimaciones se convierten en parte del
plan de pruebas (dinmico).
o Realizar plan de prueba y concretarlo con el plan de proyecto.
o Estrategia de pruebas -> Definir el nivel de calidad: Describe los niveles de pruebas a
desarrollar y la intensidad de las pruebas en aquellos niveles. Establece los criterios de
entrada y salida para cada nivel incluyendo las mtricas para evaluar esos criterios.
o Se debe ajustar de acuerdo a la informacin proveniente de las actividades de
pruebas.
o Prioridad de las pruebas: Los casos de prueba ms importantes deben ser ejecutados
de forma temprana, de esta forma partes crticas de los programas son probados
incluso en el caso que las actividades de pruebas sean abortadas de forma prematura.
o Soporte de herramientas: Decidir respecto de que herramientas deben ser utilizadas
para probar, si las herramientas disponibles son suficientes o si hay necesidad de
herramientas adicionales.
Plan de pruebas esttico:
Cubre todas las fases del proceso de pruebas.
Se fijan reglas de acuerdo a los objetivos de las pruebas, recursos, actividades e hitos.
Este posteriormente es ampliado con el objeto de cubrir los resultados a partir de la fase
de planificacin de detalle.
El plan de pruebas cuenta con una extensin dinmica que ser ajustada durante el ciclo
de vida del proyecto si fuera necesario.

Plan de pruebas de acuerdo al estndar IEEE 829:

1. Introduccin
2. Supuestos
3. tems de prueba
4. Caractersticas sujetas a pruebas
5. Caractersticas no sujetas a pruebas
6. Enfoque
7. Criterios de xito/fracaso para un tem
8. Criterios de suspensin/reanudacin
9. Entregables de pruebas
10. Tareas de pruebas
11. Necesidades relativas al entorno
12. Responsabilidades
13. Dotacin de personal y formacin
14. Calendario
15. Riesgos y contingencias
16. Aprobacin
Criterios de salida de pruebas:
Los criterios de salida que indican la finalizacin de una fase de pruebas, deben ser
establecidos para cada nivel de pruebas. Son necesarias mtricas para controlar estos
criterios de salida. Ej: Cobertura de cdigo, Cobertura de riesgo.

Especificacin: Todas las pruebas documentadas en el plan de pruebas son especificadas, es

decir, se establece como se estructura y como debe ser ejecutado. Este proceso es iniciado por
el jefe de pruebas.
 Ejecucin y control: Ejecucin -> Comparacin de los resultados esperados y obtenidos en el
proyecto. Control -> Todas las desviaciones deben ser informadas y tenidas en cuenta.

Evaluacin: La gestin de pruebas proporciona transparencia a la evolucin del proceso de

pruebas y aporta indicadores a la direccin del proyecto. Los informes generados durante la
ejecucin de pruebas, el seguimiento de defectos e informes al cliente son una importante
fuente de informacin para el jefe del proyecto y la direccin de la compaa.

Estimacin de pruebas:
Factores:
o Caractersticas del producto
o Calidad de la base de pruebas
o Requisitos de fiabilidad y seguridad del producto
o Complejidad del proceso de desarrollo
o Estabilidad de la organizacin, madurez del proceso utilizado
o Personal involucrado, restricciones temporales.

Mtodos:

o Estimacin basada en tareas

o Estimacin basada en analogas
o Estimacin basada en porcentajes

Seguimiento y control de pruebas:

Seguimiento: Control de las actividades de pruebas con el objeto de detectar desviaciones

respecto al plan.

El seguimiento debe ser realizado en base a consideraciones medibles y esto debe ser
informado de forma regular.
o Mtricas en base a errores: Utilizando informacin del sistema de gestin de
incidentes.
o Mtricas en base a casos de prueba: Utilizando informacin del sistema de gestin de
pruebas.
o Mtricas en base a objetos de pruebas: gestin de la configuracin
o Mtricas en base a costes: Utilizando informacin del sistema de control de proyectos.

Control: Correccin del rumbo de las actividades de pruebas cuando sea necesario.

Es una tarea de gestin.

Se deben tomar medidas correctivas como respuesta a desviaciones respecto del plan.

Evaluacin del cierre de pruebas.

Medidas:

o Provisin de mayores recursos.

 o Reduccin del esfuerzo aplicado al trabajo

Informe de estado de pruebas segn IEEE 829:

o Objeto u objetos de prueba.

o Niveles de prueba, ciclos de prueba, perodo del informe.
o Estado de pruebas (mtricas)
o Recursos utilizados/presupuesto consumido
o Hitos alcanzados
o Informe de defectos
o Evaluacin del riesgo
o Pronstico
o Evaluacin general

Gestin de la configuracin:
Presenta un rol de apoyo dentro de un proyecto - todos los cambios deben ser registrados en
un recurso comn y comunicado haciendo uso de procesos definidos.

Se debe realizar un plan de gestin de la configuracin especfico dependiendo del alcance de

cada proyecto.

No es una actividad particular del proceso de pruebas, sino que es necesaria durante todas las
fases de un proyecto.

Sin el uso de herramientas solo es posible en proyectos muy pequeos.

Es necesaria para administrar los cambios sobre los objetos de prueba y sus respectivas
versiones.

La gestin de la configuracin se refiere a un conjunto de medidas que complementan al

desarrollo software:

o Gestin del cambio: Sigue todas las actividades.

o Gestin de la construccin: Describe todos los pasos para crear una versin de un
productos software con el objeto de ser suministrado como un todo o subsistemas
individuales.
o Gestin de entregas (Release): Permite la definicin de versiones aisladas para
cada artefacto componente de una versin completa de producto a ser probado,
entregado, etc. Determinar y administrar toda la informacin en las versiones
correspondientes que conforman un subsistema.
o Gestin de versiones: Registra toda la informacin de acceso para cada artefacto.

NOTA: La informacin de la construccin y entrega es conservada con el objeto de poder

reconstruir versiones antiguas.

Auditora de la Configuracin:
 Tiene como objeto comprobar la efectividad de las actividades de la gestin de la
configuracin.
Riesgo:
Es la probabilidad de un resultado negativo (matemtico) o la probabilidad de la ocurrencia de
un suceso negativo multiplicada por el monto del dao econmico.

El riesgo asociado al proyecto y al producto deben ser tenidos en cuenta durante la

planificacin y el diseo de casos de prueba, cuando se prioricen casos de prueba, cuando se
seleccionen mtodos y durante la ejecucin de pruebas.

Los riesgos asociados al proyecto afectan al xito del proyecto y deben ser gestionados.

Medidas:

- Evitar el riesgo
- Mitigar el riesgo (preparacin activa de medidas para reducir la probabilidad y/o dao
potencial)
- Control del riesgo (Preparar las medidas necesarias en el caso en el cual el riesgo se
convierte en un problema, contar con tiempos y fondos suficientes)
- Ignorancia del riesgo (rezar)
Riesgos asociados al proyecto (ms frecuentes):
- Riesgos asociados a la organizacin: Problemas personales entre equipos, falta de
cooperacin, conflictos de intereses entre departamentos, capacitacin y
disponibilidad de personal.
- Riesgos tecnolgicos: Requisitos defectuosos, incompletos, no realistas.
Herramientas, tecnologas, mtodos nuevos que presentan incertidumbre para el
desarrollo software. Dficit en la calidad de productos, Disponibilidad de un entorno
de pruebas complejo.
- Riesgos ambientales: Deficiencias por parte de externos en la provisin de
componentes, problemas contractuales con proveedores, acceso concurrente a
recursos externos, cambios en requisitos legales.
Riesgos asociados al producto:
- Funcionalidad insuficiente del producto suministrado.
- Atributos no funcionales insuficientes.
- El producto no es idneo para su uso previsto.
- El producto provoca daos a la propiedad.
- El producto provoca lesin o muerte accidentales.
NOTA: Las pruebas se ejecutan para reducir o evitar a los riesgos asociados al producto.

Gestin de riesgos asociados al producto utilizando pruebas basadas en riesgo:

1. Identificar, analizar y priorizar riesgos.
2. Influencia del riesgo tenido en cuenta durante la planificacin de pruebas. (Seleccionar los
mtodos de pruebas para mitigar riesgos. Asignar alcance de las pruebas de acuerdo al
nivel de riesgo. Priorizar los casos de prueba)
3. Actualiza la lista de evaluacin de riesgos de forma regular. (Los riesgos pueden
desaparecer, o aparecer nuevos o pueden cambiar)

Beneficios de las pruebas basadas en riesgo:

Los mtodos de pruebas son seleccionados de forma particular con el objeto de mitigar los riesgos
identificados.
El alcance de las pruebas se ocupa de los riesgos identificados.
El alcance del proceso de pruebas tiene en cuenta los riesgos identificados, de esta manera se
centra el esfuerzo de pruebas en abordar la reduccin del riesgo potencial.
Los fallos peligrosos son detectados de forma temprana (Ms econmica la correccin)
Se ejecutan los casos de prueba ms importantes (prioridad) an en el caso de que se haga un
aborto de pruebas.

Informe de incidencias (Informe de errores) segn IEEE 829:

El informe de incidencias describe el efecto de un error, no su causa.
1. Datos del error: #Id Error, denominacin del objeto de prueba-versin, Entorno de
pruebas, Nombre del autor del informe de incidencias, fecha de la primera ocurrencia.
2. Clasificacin de errores: Clase de error, estado (nuevo, reopen), Prioridad (urgencia).
3. Descripcin: Caso de prueba, resultado errneo (descripcin resultado obtenido y
resultado esperado), descripcin de la desviacin, severidad, referencias a informes
relacionados, comentarios, acciones correctivas tomadas.
Clase de error: La severidad. Pueden ser: Error crtico, error mayor, error medio, error menor.
Prioridad del error: Tiene en cuenta el efecto del error: Impacto sobre la funcionalidad del
programa, impacto sobre el proyecto, sobre el cliente, Posibilidad de aportar una solucin
(correccin) inmediata al problema o en la siguiente entrega. -> Rige la urgencia de la correccin.
Estado de un error: Aporta informacin relativa al progreso/evolucin del trabajo que ha sido
desarrollado para este error.
Solo un tester puede poner un error en estado finalizado.
El jefe de pruebas decide si un error debe ser corregido o rechazado.
El consejo de control del cambio puede decidir sobre la correccin de un error teniendo en cuenta
el coste de reparacin.
Todos los cambios (incluidos los comentarios) deben ser registrados en el sistema de gestin de
incidencias.
NOTA:
La gestin de incidencias es la gestin de desviaciones.
La gestin de incidencias es un proceso por s mismo con un flujo de trabajo (workflow) particular.
Las expresiones gestin de las desviaciones o gestin de los errores son utilizados con frecuencia
como sinnimos de la gestin de incidencias.

Capitulo 6:
Las herramientas de prueba pueden ser utilizadas para dar soporte a las actividades de pruebas.
La denominacin de las herramientas de pruebas se realiza segn el tipo de soporte que prestan.
Hay herramientas disponibles para cada nivel del proceso de pruebas.
Clasificacin de las herramientas de pruebas:
Herramientas unitarias (single tools): Dan soporte a una tarea particular, son diseadas para
una actividad de pruebas.

Paquetes de pruebas herramientas (test tool suites): Cubren varias tareas e integran varias
herramientas unitarias.

Herramientas de pruebas Intrusivas: Puede interferir en la ejecucin del objeto de prueba y

puede provocar que difiera respecto del objeto en el entorno real.
 - El depurador introduce puntos de corte y altera el tratamiento de interrupciones.
- Los Drivers de pruebas aportan al objeto de pruebas datos de entrada artificiales.
- La cobertura se determina a travs de contadores introducidos en el cdigo.

Herramientas que no alteran el objeto de prueba.

Herramientas de pruebas para implementaciones especificas: Dependen del tipo de

aplicacin. Ejemplos:
- Aplicaciones web
- Una plataforma de desarrollo especifica como Java
- Pruebas de seguridad

Herramientas de pruebas propietario (Fabricacin propia):

- Ejemplo: Hojas de clculo de Excel, guiones SQL, bases de datos para el tratamiento de
datos de pruebas, herramientas especficas de comparacin de resultados de pruebas.

Herramientas de gestin de pruebas:

- Recopilacin, categorizacin/clasificacin y administracin de casos de prueba.

- Evaluacin/Establecimiento de mtricas que describan los casos de prueba.
- Planificacin de recursos, tiempo y presupuesto.
- Documentacin del plan de pruebas
- Creacin de informes de desarrollo (progreso) de pruebas, evaluacin de pruebas,
documentacin de pruebas.
- Gestin de entregas y gestin de la configuracin.

Herramientas de gestin de requisitos:

- Acopio de los requisitos del sistema.

- Asignacin de prioridades a los requisitos.
- Establecer la referencia entre los requisitos y los casos de prueba.
- Comprobacin de la consistencia: Evaluaciones por ejemplo el grado de cobertura.

Herramientas de gestin de incidencias/Herramientas de gestin de defectos: Registro y

seguimiento de defectos. Asignacin de prioridades, categorizacin y agrupacin de defectos.

- Evaluaciones: Mtricas que presenten el grado de desarrollo/Progreso de las pruebas.

- Flujo de trabajo para el ciclo de vida de un defecto: Cambios de estado,
responsabilidad (asignacin).

Herramientas de gestin de la configuracin: Seguimiento de las diferentes versiones de

componentes: Requisitos cumplidos por una versin particular, entorno operativo, compilador
en uso, etc.

- Administracin del cdigo fuente y el cdigo objeto.

- Referencias a la gestin de pruebas/gestin de requisitos/gestin del cambio.
 Herramientas para pruebas estticas: Para poder realizar anlisis esttico las especificaciones
deben estar en un lenguaje formal.

Estas herramientas son muy utilizadas por los desarrolladores.

- Herramientas para pruebas estticas - > revisiones: Apoyo al proceso de revisin

(flujo de trabajo), documentacin de los resultados de revisin, Evaluacin de los
resultados de revisin, provisin de check list para revisiones y apoyar la ejecucin de
revisiones en lnea (on line review).

- Herramientas para pruebas estticas -> Anlisis Esttico:

Conformidad con estilos de codificacin/convenciones.
Anlisis de la estructura del cdigo: Anlisis del flujo de control, cdigo inalcanzable
(muerto), mtricas de complejidad de cdigo. Ej: Nmero ciclomtico.
Anlisis de pruebas basadas en modelos de datos / comprobacin de consistencia.
Anlisis de documentos de especificacin / modelos de diseo de objetos/diagramas
de estado.

Herramientas para la especificacin de pruebas: Los generadores de datos de prueba crean

datos para ser utilizados en pruebas. Las herramientas producen datos a partir de
descripciones formales o a partir de la definicin de una estructura. Las herramientas no
reemplazan el esfuerzo humano dada su carencias de creatividad e intuicin y conocimiento
del objeto de prueba.

Las herramientas se clasifican dependiendo de la fuente de los datos:

- Generadores de datos de prueba asociados a bases de datos:

Generan datos a partir de bases de datos o a partir de ficheros planos.
Obtienen datos a partir del reconocimiento de estructuras y contenidos.

- Generadores de datos de prueba basados en el cdigo: Generan datos a partir del

cdigo fuente, por esta razn no pueden identificar una funcionalidad ausente, ni
aportar los valores de resultados esperados, es decir solo pueden generar datos de
prueba en base al cdigo aportado.

- Generadores de datos de prueba asociados a la interfaz: Generan datos de acuerdo a

los parmetros de la interfaz. Obtienen clases de equivalencia y valores lmite
directamente para los rangos de los parmetros definidos. No pueden aportar valores
de resultados esperados pero pueden ser utilizados para pruebas de robustez.

- Generadores de datos de prueba basados en la especificacin: Generan datos

directamente de documentos de especificacin, estos requieren el uso de una
notacin formal estricta.

Herramientas para la ejecucin de pruebas:

Incluyen:

- Entrega de datos.
 - Recepcin de datos o escritura en el registro del comportamiento de la salida.
- Documentar la ejecucin de las pruebas.

Ejemplos:

Depurador: Herramienta para la deteccin de errores en el cdigo fuente. La

secuencia de la ejecucin de un programa puede ser interrumpida. Pueden ser
comprobadas sentencias unitarias y condiciones. Las variables pueden ser definidas de
forma individual y referenciadas.

Drivers de prueba: Permiten acceder al objeto de pruebas cuando las interfaces an

no han sido implementadas.
Regulan la entrada y salida de datos y registran el log el desarrollo de la prueba.
Registran los resultados reales (obtenidos).
Pueden ser productos estndar o programas desarrollados para un objeto de prueba
especfico.
Normalmente aportan su entorno de sistemas propio.

Stubs: Simulan la funcionalidad de un componente invocado.

Simuladores: Son una rplica del entorno de produccin (o parte del mismo) y son
necesarios cuando consideraciones de seguridad impiden el uso del entorno de
produccin objetivo (real). Principalmente son utilizados en el nivel de pruebas de
sistema y pruebas de integracin y posiblemente en pruebas de componente.
La emulacin del entorno de produccin debe ser tan prxima el mismo como sea
posible.

Robots de prueba: Pueden tratar la interfaz externa del objeto de prueba de forma
directa.
Pueden aceptar y/o suministrar datos, el desarrollo de la prueba se realiza de forma
automtica.
Con frecuencia aportan una funcin que compara el resultado real (obtenido) con el
resultado esperado.
Las herramientas de captura-repeticin son utilizadas con frecuencia, como robots de
pruebas. Estas herramientas registran los pasos de la ejecucin de la prueba a travs
de la interfaz de usuario y las guarda en un fichero en un formato de guin (script file).
Permiten la repeticin automtica de la secuencia de prueba haciendo uso de guin
(script) registrado/guardado.

Herramientas para el anlisis de pruebas y anlisis del objeto de prueba: Apoyan o

automatizan tareas de anlisis de pruebas. Su denominacin es acorde con su uso.

- Herramientas de comparacin: Comparan los resultados esperados y reales

(obtenidos) en base a ficheros o bases de datos de diferentes formatos. Los datos
relevantes a comparar con seleccionados haciendo uso de funcionalidades filtro.
- Herramientas de anlisis de cobertura: Se implementan contadores que registran
cada acceso. Tras completar las pruebas, los contadores sern utilizados para evaluar
la cobertura.
 - Herramientas de anlisis dinmico: Pueden soportar las pruebas dinmicas. Controlan
y registran el estado interno del objeto de prueba, por ejemplo: Uso de memoria.

Herramientas para pruebas no funcionales:

- Herramientas para pruebas de carga: Seguimiento del comportamiento en tiempo

real del objeto de prueba en distintas situaciones. Las herramientas generan, ejecutan
una repeticin de casos de prueba dirigidos por parmetros.
El despliegue en entornos complejos requiere un conocimiento experto con el objeto
de asegurar que los resultados son similares a las condiciones reales por ejemplo:
Interaccin de red.

- Supervisores de pruebas: Analizan, verifican y documentan de forma continua el uso

de recursos del sistema.
- Observan el comportamiento del objeto de prueba en el entorno del sistema y detecta
situaciones que pudieran ser susceptibles de problemas.

Ventajas de las herramientas de pruebas en general:

Reduccin de la necesidad de la totalidad de recursos humanos (Apoyan y aceleran las

tareas manuales).

Incremento de la calidad de la ejecucin de pruebas: Las evaluaciones automticas

aportan medidas objetivas.

Mayor potencial para el control de pruebas: la gestin de datos con herramientas de

pruebas hace posible una mayor variedad de evaluaciones.

Riesgos de las herramientas de prueba en general:

Desviaciones en la calidad de la herramienta desplegada: La funcionalidad y

usabilidad de la herramienta no cumple con las expectativas.
Estimacin errnea de los beneficios y costes.
Los guiones de prueba deben ser redactados/alterados/modificados.

Beneficios y riesgos de las herramientas de pruebas de rendimiento:

Generalmente son utilizadas en aplicaciones (sistemas) distribuidos y cuya

comunicacin se realiza a travs de redes.
En la mayora de los casos el entorno de pruebas no puede estar completamente
aislado y es objeto de la influencia de factores que no son conocidos en detalle a la
hora de preparar y ejecutar las pruebas.
La complejidad del entorno de puede hacer que sea imposible repetir pruebas
idnticas.
En muchos casos es necesario un conocimiento experto en detalle con el objeto de
analizar las salidas de la herramienta de forma correcta y extraer las conclusiones
correctas.
Beneficios y riesgos de las herramientas de pruebas de anlisis esttico:

Examinan el cdigo fuente con el objeto de comprobar la conformidad con

convenciones.
Con frecuencia es necesario preparar el cdigo para el anlisis esttico.
Un problema detectado con frecuencia: Una cantidad relativamente grande de
indicaciones, es difcil identificar su relevancia.

Beneficios y riesgos de las herramientas de gestin de pruebas:

La informacin debe ser mantenida abiertamente accesible.

Una hoja de clculo es la herramienta ms utilizada por los jefes de pruebas para
evaluaciones de informes.
Los informes y las evaluaciones de deben adaptar a la organizacin y no al revs!

La introduccin de una nueva herramienta en organizaciones es un proceso exigente que

necesita ser controlado/gestionado.

Pasos hacia la introduccin de una herramienta:

1. Anlisis de la necesidad: Cules son los puntos fuertes y dbiles del rea de pruebas?
Qu puede ser mejorado con el despliegue de la herramienta?
2. Definicin de requisitos: Las necesidades respecto de la herramienta deben ser
definidos de forma clara, deben ser establecidos criterios medibles.
3. Evaluacin: Examinar la conformidad de la herramienta con la funcionalidad solicitada
y los criterios de calidad adicionales. Solicitar el nmero de copias vendidas, servicio
de posventa y la posibilidad de colaboracin por parte del proveedor.
4. Lanzamiento: Apoyar la introduccin de la herramienta a travs de entrenamiento y
formacin para el uso de la herramienta. Lo ideal es establecer un proyecto piloto
para introducir la herramienta.