1.

Fundamentos de pruebas
1.1 Porque es necesario probar
Los defectos pueden resultar en fallas, pero no todos los defectos son
fallas. Las fallas pueden ser causadas por condiciones del medio,
como campos electromagnticos, tormentas, derrumbes, etc.
Un contexto de sistemas de Software
Causa de defectos del software
Rol de los probadores en desarrollo, mantenimiento y operacin
de software
Pruebas y calidad (Calidad de software ISO9126)
Cuantos probadores son necesarios

1.2 Que es un Tester

Es una persona que se encarga de encontrar fallas o defectos en un
software o sistema de manera que disminuyan los riesgos y por ende
los costos y tiempo empleados en el desarrollo del software

1.3 Principios generales del tester

1. Mostrar presencia de defectos: El testing muestra defectos

encontrados, ms no puede mostrar no defectos, adems no se
asegura que el software quede sin defectos.
2. Es imposible tener pruebas exhaustivas: No se pueden probar
todos los escenarios del software.
3. Pruebas tempranas: Las actividades de pruebas deben iniciar
tempranamente en el ciclo de vida del software.
4. Encontrar cluster de defectos: La mayor parte de los defectos
se encuentran en una pequea parte del software y deben ser
localizados y arreglados prontamente.
5. Paradoja Del Pesticida: Los casos de pruebas deben ser
revisados y de ser necesario replanteados en vista a algn defecto
encontrado al ser corregido ya que con los casos probados en el
momento de la falla se han de volver irreconocibles.
6. Las pruebas dependen del contexto: Las pruebas son diferentes
en diferentes contextos.
7. La falacia de la ausencia de errores: A pesar de realizar las
pruebas necesarias, no se puede determinar que el software o
sistema no tenga ningn error.

1.4 Proceso fundamental de pruebas

1.4.1 Planeacin y control:

1.4.1.1 Planeacin:
Alcance de la prueba
Actividades de la prueba
1.4.1.2 Control:
Progreso
Reportes
Estado
 monitoreo

1.4.2 Anlisis y desarrollo

Esta etapa es en la cual la prueba pasa a ser tangible y se dan los
casos de pruebas y condiciones. Se debe verificar:

Revisar bases de la prueba (Arquitectura, requerimientos,

desarrollo, interfaces)
Evaluar la prueba base y la prueba de objetos
Identificar y priorizar las condiciones de pruebas basadas en el
anlisis de tems de pruebas
Desarrollar y priorizar los casos de prueba.
Identificar los datos necesarios para soportar las pruebas
Desarrollar el ambiente de pruebas, identificar herramientas e
infraestructura.

1.4.3 Implementacin y ejecucin

Desarrollar, implementar y priorizar los casos de pruebas

Desarrollar y dar prioridad a los procesos de pruebas, creacin de
data, scripts necesarios.
Crear la suite de pruebas desde el proceso de pruebas para
eficiente ejecucin de pruebas.
Verificar que el ambiente de pruebas este correctamente cargado
Ejecutar cada proceso de pruebas ya sea manual o
automticamente de acuerdo a la secuencia planeada.
Guardar los logs de salida de las pruebas y grabar las diferentes
versiones de pruebas realizadas.
Comparar los actuales resultados con los resultados esperados.
Reportar las discrepancias como incidentes y analizarlos en pro de
establecer la causa.
Repetir las actividades de pruebas como resultado de la accin
tomada por cada discrepancia ocurrida

1.4.4 Evaluacin del criterio de salida y reportes

Verificar los logs de pruebas contra el criterio de salida

especificado en la planeacin.
Evaluar si es necesario realizar ms pruebas o s el criterio de
salida debera ser cambiado.
Escribir un reporte de pruebas para los ingenieros de soporte.
(stake holders)

1.4.5 Clausura de las actividades de pruebas

En esta etapa se debe colectar la data empleada, experiencia de

pruebas, actividades, factores y nmeros.
Verificar que lo planeado a entregar ha sido entregado, clausurar
reportes de incidentes y la documentacin de aceptacin del sistema
o software.
 Archivar y finalizar software de pruebas, el ambiente de pruebas,
y la infraestructura para despus ser usada.
Ceder el software de pruebas al mantenimiento de la
organizacin.
Analizar lecciones aprendidas para futuros releases o proyectos y
la madurez de la prueba.

1.5 La psicologa del tester

Un cierto gado de independencia del tester es a menudo
encontrando errores y fallas, sin embargo los desarrolladores tambin
pueden encontrar defectos y fallas en su propio cdigo.

Se pueden definir niveles de independencia:

Desarrollo de pruebas por la persona quien escribi el software

bajo pruebas (Bajo nivel de independencia)
Desarrollo de pruebas por cualquier otra persona involucrada
en el desarrollo
Desarrollo de pruebas por una persona diferente del grupo
desarrollador o especialistas de pruebas, dentro de la compaa
Desarrollo de pruebas por una persona externa a la compaa
(outsourcing) diferente al desarrollador.
El trabajo del tester suele ser visto como daino a la persona que
desarrolla y al desarrollo, pero en realidad genera menos riesgo en los
proyectos, por lo cual encontrar fallas en un sistema requiere
curiosidad, pesimismo profesional, un ojo crtico, atencin en los
detalles, buena comunicacin con el rea de desarrollo,

El tester debe dar a conocer los defectos y fallos del software al

desarrollador de manera constructiva y evitando tener
enfrentamientos personales.

2. Pruebas a travs del ciclo de vida

2.1 Modelos de desarrollo de software

2.1.1 V-Model (Modelo de desarrollo secuencial) (unitario, integral)

2.1.1.1 Pruebas unitarias
2.1.1.2 Pruebas de integracin
2.1.1.3 Pruebas de sistema
2.1.1.4 Pruebas de aceptacin

2.1.2 Modelos de desarrollo iterativo incremental (Regresin)

En este modelo el proceso es establecer requerimientos, desarrollo,
construccin y pruebas al sistema, como pequeos ciclos de
desarrollo.

2.1.3 Pruebas con un modelo de ciclo de vida

Para cada actividad de desarrollo debe existir su correspondiente
actividad de pruebas.
 Cada nivel de pruebas tiene su objetivo especifico al nivel
El anlisis y desarrollo de pruebas dada para un nivel de pruebas
debera comenzar durante la correspondiente actividad de
desarrollo.
Los tester deberan ser involucrados en la revisin de documentos
tan pronto como haya un esbozo del proyecto.

2.2 Niveles de prueba

2.2.1. Pruebas de componentes

En esta etapa se debe buscar por defectos en funciones, clases,
objetos que puedan ser probados independientemente (Divide y
vencers)

2.2.2 Pruebas de integracin

En esta etapa se debe probar interaccin entre componentes,

interaccin con diferentes partes del sistema as como con el sistema
operativo, interfaces de otros sistemas.
Idealmente los testers deberan entender la arquitectura.

2.2.3 Pruebas de sistema

Las pruebas de sistema pueden incluir pruebas basadas en riesgos,
especificaciones de requerimientos, reglas del negocio, procesos ,
sistemas operativos y recursos del sistema

2.2.4 Pruebas de Aceptacin

Suelen ser responsabilidad de los usuarios del software, y se debe
validar las partes no funcionales del sistema encontrando defectos no
encontrados por las pruebas realizadas.

2.3 Tipos de prueba

2.3.1 Pruebas de funcin (Pruebas funcionales)

Las funcionalidades del sistema describen Qu hace el sistema o
software? Se debe evaluar la capacidad del producto del software y la
interaccin con otros sistemas o componentes del sistema.

2.3.2 Pruebas de software basadas en caractersticas no funcionales

(Pruebas no funcionales)
Pruebas de caractersticas no funcionales incluye pruebas de
performance, seguridad, carga, estrs, usabilidad, mantenimiento,
portabilidad, muestra el Cmo trabaja el producto de software?

2.3.3 Pruebas de arquitectura/estructura de software (Prueba

estructural)
Las pruebas pueden ser realizadas en todos los niveles, para asegurar
el cubrimiento del 100 % de los requerimientos.
2.3.4 Pruebas relativas a cambios (Pruebas de confirmacin
(Reprueba) y pruebas de regresin)
Estas pruebas deben ser realizadas cuando se encontr un defecto y
fue reparado para probar que la falla fue superada y no afecto el
software en otro modulo, o cuando se realizan cambios debido a
cambios en los requerimientos.

2.4 Pruebas de mantenimiento

Las pruebas debern incluir pruebas operacionales de la nueva
plataforma o cambio realizado al nuevo ambiente, tambin nuevo
software requerido, vulnerabilidades, sistema operativo, bases de
datos involucradas en el software que ha sufrido el cambio.

3. Pruebas estticas
3.1 El proceso de pruebas y las tcnicas estticas
Cualquier producto de software puede ser revisado, incluyendo
revisiones de requerimientos, especificaciones de desarrollo, cdigo,
planes de pruebas, especificacin de pruebas, casos de pruebas. El
beneficio de la revisin incluye deteccin de errores y correccin
temprana, reduccin de costos y tiempo. La revisin encuentra
defectos como: desviacin de estndares, defectos de requerimiento,
defectos de desarrollo, insuficiente mantenibilidad e incorrectas
especificaciones de interfaces.

3.2 Procesos de revisin

La formalidad en el proceso de revisin es uno de los factores que
ayudan a la madurez de los procesos de desarrollo.

3.2.1 Fases de una revisin formal

Planear: Definir los roles, las personas involucradas, definir los
criterios de entrada y salida y definir que partes del documento
deben ser revisadas.
Empezar: Distribuir documentos, explicar los objetivos,
procesos y documentos de los participantes, y validar los
criterios de entrada.
Preparacin individual: Cada persona involucrada preparar
posibles preguntas, defectos potenciales.
Reunin de revisin: discusin acerca de la documentacin,
haciendo actas o minutas de lo expresado, hacer
recomendaciones sobre los defectos o tomar decisiones acerca
de los defectos.
Retrabajar: Arreglar defectos encontrados tpicamente dados
por el autor del requerimiento.
Seguimientos: Validar que los defectos fueron reparados o
redireccionados de acuerdo a un criterio de salida.

3.2.2 Roles y responsabilidades

Una revisin formal incluye:
Administrador: Cita la reunin de revisin, determina los objetivos de
la reunin.
Moderador: La persona que lidera la revisin del documento o
documentos, incluye planeacin de la reunin y la medicacin entre
variados puntos de vista con respecto a alguno de los temas de la
revisin.
Autor: La persona que escribi el documento o responsable del
requerimiento.
Revisores: Personas individuales con unas tcnicas especficas para
encontrar defectos o fallas en la revisin, tambin pueden ser
personas relacionadas con el negocio.
Escritor: persona que documenta la reunin con los puntos de vista
dados con respecto a la revisin.
Se deben buscar documentos con diferentes puntos de vista, del
usuario, del mantenimiento, del operador.

3.2.3 Tipos de revisin

Pueden variar desde la informal a la revisin tcnica.
3.2.3.1 Revisin informal:
Procesos no formales
Puede estar un desarrollador o un lder tcnico que revise el
cdigo
Opcionalmente puede ser documentado
Pueden variar en uso dependiendo del revisor
Propsito principal: Camino inesperado de obtener algn
beneficio

3.2.3.2 Ir a travs de:

Reunin liderada por el autor del documento
Escenarios, grupos pares, caminos equvocos
Abrir y cerrar la sesin
Opcionalmente realizacin de una pre-reunin para validar
documentacin
Puede variar de prctica e informal a muy formal
Propsito principal: Aprender, entender beneficios, encontrar
defectos

3.2.3.3 Revisin tcnica:

Documentacin definida por expertos tcnicos del sistema
Puede ser vista por un par de revisores tcnicos sin
administrador de la reunin.
Idealmente liderada por un moderador entrenado no por el
autor
Preparacin para la reunin
Opcionalmente revisin de listas de chequeo, reportes de
revisin, lista de defectos encontrados.
Puede variar de informal a formal
Propsito principal: discutir, tomar decisiones, evaluar
alternativas, encontrar defectos, resolver problemas tcnicos,
verificar estndares y especificaciones tcnicas.
3.2.3.4 Inspeccin
Liderada por un moderador entrenado no por el autor
 Usualmente examinar parejas de trabajo
Definir roles
Incluir mtricas
Proceso formal basado en reglas con criterios de entrada y
salida
Preparacin para la reunin
Inspeccin de reportes y lista de defectos encontrados
Formal seguimiento de procesos
Propsito principal: encontrar defectos

3.2.4 Factores sucedidos para revisin

Cada revisin tiene un objetivo claro predefinido.
Las personas involucradas para revisin de los objetivos est
implicada.
los Defectos encontrados son bienvenidos, y expresados
objetivamente.
Las preguntas personales y aspectos psicolgicos son
considerados
Las tcnicas de Revisin son aplicadas al tipo y el nivel de
productos de software y revisores.
Las listas de comprobacin es usada para aumentar la eficacia de
identificacin de defectos.
El entrenamiento es dado en tcnicas de revisin, sobre todo las
tcnicas ms formales, como la inspeccin.
La direccin apoya un proceso de revisin bueno
Hay un nfasis en la mejora de proceso y aprender

3.3 Anlisis estticos por Herramientas

El objetivo de las pruebas estticas es encontrar defectos en cdigo
fuente y modelos de software, las herramientas de anlisis de
pruebas estticas revisan cdigo y diagramas de flujo, no serviran
para anlisis dinmico.

El valor del anlisis esttico se refleja en:

Temprana deteccin de defectos
Temprana deteccin de errores de codificacin, calculo de
mtricas y alta medida de complejidad
Identificacin de defectos no encontrados fcilmente por el
anlisis dinmico
Deteccin de dependencias e inconsistencias en modelos de
software
Prevencin de defectos, si las lecciones son aprendidas en
desarrollo.

Tpicos defectos encontrados:

Referencia a una variable con valor indefinido
Inconsistencias de interfaces entre mdulos y componentes
Variables que no son usadas
Cdigo muerto
Violacin en los estndares de programacin
 Vulnerabilidades de seguridad
Violacin de sintaxis de cdigos o modelos de software

4. Tcnicas de desarrollo de pruebas

4.1 Proceso del desarrollo de pruebas
Durante la implementacin de los casos de prueba son
desarrolladas, implementadas, priorizadas y organizadas las
especificaciones de la prueba, el procedimiento de pruebas especifica
la secuencia de la accin de la ejecucin de las pruebas, la salida
esperada, el cronograma de pruebas.

4.2 Categoras de las tcnicas de desarrollo de pruebas

Se pueden admitir tcnicas como:
4.2.1 Basada en la especificacin basada en la experiencia,
conocidas como tcnica de caja negra:
Los modelos formales o informales son usados para la
especificacin del problema a resolver, el software o los
componentes.
Desde estos modelos los casos de pruebas pueden ser
derivados sistemticamente
El conocimiento de las personas involucradas es
aprovechado para generar los casos de prueba

4.2.2 Basada en la estructura o conocida como tcnica de Caja blanca

Se tiene informacin de cmo el software fue construido, es
usado para derivar los casos de pruebas
La extensin de cubrimiento del software puede ser medida
por la existencia de casos de prueba.

4.3 Tcnica basada en especificacin o caja negra

4.3.1 Particin equivalente

Se realizan particiones equivalentes en las que se espera un
comportamiento similar ante las mismas entradas o ante las salidas
esperadas, puede ser aplicada en todos los niveles de pruebas y se
estiman para entradas manuales, por interfaces o automticas.
4.3.2 Anlisis valor limite
El mximo y mnimo valor de una particin pueden dar el valor limite
y este valor correcto o incorrecto puede marcar el comportamiento en
el resto de la particin, se puede usar junto con la tcnica de particin
equivalente y tambin sirve para determinar valores necesarios para
los casos de prueba.
4.3.3 Pruebas de Tabla de decisin
Puede ser utilizada en sistemas que contienen decisiones lgicas y
que por su complejidad pueden determinar el camino a seguir, cada
columna puede significar una regla del negocio.
4.3.4 Prueba de estado de transicin
Los sistemas pueden estar sujetos a estados transitorios, y la prueba
debe ser diseada para cubrir las tpicas secuencias de estado, cubrir
cada estado y cada transicin o invalidas transiciones.
4.3.5 Pruebas de casos de uso
Esta prueba esta dirigida a los casos de uso o escenarios del negocio,
muestra la relacin entre los actores y la secuencia que debe seguir
para cumplir el siguiente caso, se describen los flujos del proceso.

4.4 Tcnica basada en la estructura o caja blanca

4.4.1 Prueba de cubrimiento y declaracin

Se debe asegurar la ejecutabilidad de un porcentaje del software, se
deriva de los casos de prueba.

4.4.2 Prueba de decisin y cubrimiento

El cubrimiento de una prueba permite la toma de decisiones acerca
de la salida, es una forma de controlar el flujo de pruebas a travs de
los puntos de decisin.

4.5 Tcnica basada en la experiencia

El conocimiento de un tester en un sistema en especfico, de su
comportamiento y de la arquitectura del mismo le permiten
desarrollar una intuicin que ve defectos que por las tcnicas
sistemticas no podran ser detectados, es un valor agregado frente a
la ejecucin de las pruebas.

4.6 Escoger la tcnica de pruebas

El escoger la tcnica de pruebas depende de mltiples factores

incluyendo el tipo de sistema, las regulaciones, estndares,
requerimientos del usuario, niveles de riesgo, objetivos de las
pruebas, documentacin, conocimiento del tester, algunas tcnicas
son ms aplicables en otros niveles y deben ser adaptadas de
acuerdo a la prueba generada.

5. Administracin de pruebas
5.1 Organizacin de pruebas
5.1.1 Organizacin e independencia de las pruebas
La efectividad para encontrar defectos en un software depende en
gran medida de la independencia del analista de desarrollo y del
analista de pruebas
Se debe validar:
Independencia del tester no debe probar su mismo cdigo
desarrollado.
El tester debe pertenecer a otro grupo y no al grupo de desarrollo
Grupos de pruebas independientes a la compaa

5.1.2 Tareas de los lideres de pruebas y testers

Algunas de las tareas del lder de pruebas incluyen:
Coordinar la estrategia de prueba
 Planear la prueba
Monitorear la prueba
Adaptar la planeacin basada en los resultados obtenidos y el
progreso
Decidir que puede ser automatizado, en que grado y como
Seleccionar las herramientas de pruebas
Algunas tareas del tester incluyen:
Revisar y contribuir con el plan de pruebas
Analizar, revisar y evaluar los requerimientos, modelos y
especificaciones de pruebas.
Crear las especificaciones de las pruebas
Preparar y adquirir los datos de prueba.

5.2 Planeacin y estimacin de pruebas

5.2.1 Planeacin de pruebas
La planeacin puede ser documentada para un proyecto o un plan
maestro de pruebas y diferentes planes de prueba para los diferentes
niveles. La planeacin est influenciada por las polticas de pruebas
de la organizacin.

5.2.2 Planeacin de actividades de pruebas

La planeacin de actividades de pruebas incluyen:
Determinar la escala y riesgo e identificar los objetivos de la
prueba
Definir la estrategia de pruebas incluyendo los niveles de prueba y
el criterio de salida.
Integrar y coordinar las actividades de pruebas dentro del ciclo de
vida del software
Tomar decisiones frente a quien ser el tester, los roles, las
actividades de pruebas, el calendario
Determinar el calendario de desarrollo de actividades y anlisis de
pruebas
Asignar recursos para las diferentes actividades de pruebas
Seleccionar las mtricas de medida y control

5.2.3 Criterio de salida

El propsito del criterio de salida es identificar cuando la prueba debe
parar, as como la terminacin del nivel o un objetivo especifico.
Los tpicos criterios de salida pueden ser:
Meticulosidad en la medicin, cubrimiento de cdigo,
funcionalidad y riesgo
Estimacin de la densidad de los defectos
Costos
Riesgos residuales con respecto a las reparaciones realizadas
Cronogramas basados en tiempo de comercializacin.

5.2.4 Estimacin de pruebas

Los esfuerzos en las pruebas dependen de mltiples factores, entre
los que se encuentran:
 Caractersticas del producto: La calidad de la especificacin, el
tamao de producto, la complejidad del problema, seguridad.
Caractersticas del desarrollo de los procesos: La estabilidad de la
organizacin, herramientas usadas, procesos de pruebas,
habilidades de las personas involucradas y premura de tiempo.
La salida de pruebas: el nmero de defectos y el monto requerido
por re-trabajo.

5.2.5 Estrategias de pruebas

Una forma de validar las estrategias de pruebas es basarse en el
punto de inicio del desarrollo del software.
Preventiva: Lo ms temprano posible, dentro del ciclo de vida del
desarrollo.
Reactivo: Cuando el desarrollo ya ha terminado.

Las tpicas estrategias incluyen:

Anlisis de los riesgos en reas que tengan un nivel mayor de
riesgos
Pruebas estocsticas basadas en informacin esttica
Metdicas basadas en experiencia, fallas registradas, listas de
chequeo

La seleccin de la estrategia debera contemplar:

Riesgo de falla del proyecto
Habilidades y experiencia de las personas involucradas en el
proyecto
El objetivo de la prueba y el grupo de pruebas
Regulacin de aspectos internos y externos que podran afectar
La naturaleza del producto y del negocio

5.3 Monitoreo del progreso y control de pruebas

5.31. Monitoreo del progreso de la prueba
El propsito del monitoreo es dar retroalimentacin acerca de los
resultados obtenidos, as como tener las mediciones y escalas de
comportamiento de las pruebas para ser aprovechadas en pruebas
futuras.

Las ms comunes mtricas de pruebas incluyen:

Porcentaje de trabajo empleado en la preparacin de los casos
de prueba
Porcentaje de trabajo empleado en la preparacin del ambiente
de prueba
Ejecucin de las pruebas
Informacin defectuosa
Costos de las pruebas
Subjetividad del tester en el producto

5.3.2 Reportes de pruebas

Estos reportes permiten tener informacin acerca las pruebas,
incluyen:
 Qu sucedi en un periodo determinado de la prueba como cuando
el criterio de salida fue encontrado.
Analizar las mtricas e informacin para tomar las decisiones
acerca de futuras pruebas

5.3.3 Control de pruebas

El control de pruebas incluyes las acciones a tomar de acuerdo a la
informacin obtenida, as como las mtricas establecidas, estas
acciones pueden afectar las pruebas y el ciclo de vida del software.

5.4 Administracin de la configuracin

El propsito de la administracin de la configuracin es establecer y
mantener la integridad de los productos de software, sistema o
proyecto a travs del ciclo de vida.

Puede envolver:
Todos los tems de testware son identificados, versiones
controladas, cambios.
Todos los tems de documentos y software no deben tener
ambigedad.

5.5 Pruebas y riesgos

El riesgo puede ser definido como la posibilidad de que un evento o
situacin ocurra y pueda generar consecuencias o un potenciales
problemas, el nivel de riesgo ser determinado por el dao causado
desde la iniciacin del evento

5.5.1 Riesgo del proyecto

Los riegos del proyecto son los que rodean la capacidad del proyecto
de cumplir los objetivos, estos pueden ser:

5.5.1.1 Factores organizacionales

Habilidades de las personas involucradas
Problemas de comunicacin entre el tester y el desarrollador

5.5.1.2 Cuestiones tcnicas

Problemas en la definicin correcta de los requerimientos
Extensos requerimientos que pueden existir
La calidad del desarrollo, cdigo y pruebas

5.5.2 Riesgo del producto

Son las potenciales fallas en reas del software y son un riesgo en la
calidad del producto, algunas son:
Falla en el software entregado
El dao potencial que el software podra causar a un individuo o
a la organizacin
Caractersticas pobres del software

Las pruebas son usadas para reducir riesgos, as mismo crean la

retroalimentacin para reparar fallas y evitar reprocesos.
5.6 Administracin de incidentes
Los incidentes deben ser rastreados desde el descubrimiento y
clasificacin hasta la correccin y confirmacin de la solucin.

Los reportes de incidentes deben contemplar:

Proveer a los desarrolladores de retroalimentacin del incidente
y la posible solucin dada.
Proveer al lder de pruebas de las herramientas para validar la
calidad del software frente al progreso de la prueba.
Proveer ideas para la creacin de procesos de pruebas

Los detalles contemplados para el reporte de incidentes deben incluir:

Fecha en que ocurri, organizacin y autor
Resultados esperados y resultados obtenidos
Software o ciclo en el cual el incidente fue observado
Severidad del impacto en el sistema
Conclusiones y recomendaciones

6. Herramientas de soporte para pruebas

Tipos de herramientas de pruebas
Clasificacin de las herramientas de prueba
Herramientas de soporte para administracin de pruebas y
probadores
Herramientas de soporte para pruebas estticas
Herramientas de soporte para pruebas de especificacin
Herramientas de soporte para pruebas de ejecucin e ingreso.
Herramientas de soporte para monitoreo y funcionalidad
Herramientas de soporte para reas de aplicacin especfica
Herramientas de soporte usando otras herramientas
Efectivo uso de herramientas: Potenciales beneficios y riesgos
Potenciales beneficios y riesgos las herramientas de soporte para
pruebas (Para todo tipo de herramientas)
Consideraciones especiales para algunos tipos de herramientas.
Introduccin de una herramienta en una organizacin