Probador Certificado

Programa de Estudio de Nivel Básico

Versión 2011
1.Fundamento de la prueba (K2) 155 minutos

Objetivos de aprendizaje para Fundamentos de Prueba

Los objetivos identifican lo que se podrá hacer tras la finalización de cada modulo

1.1 ¿Porque son las pruebas necesarias? (K2)

LO-1.1.1 Describir con ejemplos la manera en que un defecto puede causar
daños a la persona, al entorno o a la compañía (K2)
LO-1.1.2 Diferencia entre la causa principal de un defecto y sus consecuencias (K2)
LO-1.1.3 Por medio de ejemplos, explicar la razón de
porque son necesarias las pruebas (K2)
LO-1.1.4 Describir porque las pruebas son parte de la garantía de calidad y dar
ejemplos de cómo contribuyen las pruebas a una mayor calidad (K2)
LO-1.1.5 Por medio de ejemplos explicar y comparar los términos de errores, defectos,
fallos, mal funcionamiento y los términos de error correspondientes y virus
(K2)

1.2 ¿Que significan Pruebas? (K2)

LO-1.2.1 Tener en cuenta los objetivo comunes de pruebas (K1)
LO-1.2.2 Dar ejemplos para los objetivos de las pruebas en fases diferentes del ciclo
de vida del software (K2)
LO-1.2.3 Establecer la diferencia entre las pruebas y depuración (K2)

1.3 Siete Principios de Pruebas (K2)

LO-1-3.1 Explicado los siete principios en pruebas (K2)

1.4 Fundamento del Proceso de Prueba (K1)

LO-1.4.1 Tener en cuenta las cinco actividades fundamentales de la prueba y las
respectivas funciones desde la planeación de cierre (K1)

1.5 Psicología de las Pruebas (K2)

LO-1.5.1 Tener en cuenta los factores psicológicos que tienen influencia en el éxito
de la prueba (K1)
LO-1.5.2 Comparar la manera de pensar del probador y de un desarrollador (K2)

1.1 Porque son necesarias las pruebas (K2) 20 minutos

Términos
Virus, defectos, errores, fallas, desperfectos, errores, calidad, riesgo
1.1.1 Contexto del Sistema del Software (K1)

Los sistemas del software son parte integral de la vida, desde de aplicaciones comerciales
(por ejemplo banca) hasta productos de consumo (por ejemplo, carros). La mayoría de
gente que ha tenido experiencia con el software, no les ha funcionado como esperaban.
El software que no funciona correctamente, puede causar varios problemas, incluyendo
perdida de dinero, tiempo, reputación del negocio e incluso podría causar daño o muerte.

1.1.2 Causas de los Defectos del Software (K2)

Un ser humano puede cometer errores, que generan defectos (fallas, virus) en el código
del programa o en un documento. Sí se ejecuta un defecto en el código, pueden haber
fallas en el sistema al realizar lo que debe hacer (o lo que no debe hacer), generando
fallas. Los defectos en el software, sistemas o documentos pueden resultar en fallas, sin
embargo no sucede con todos los defectos.

Los defectos se dan debido a que la gente es falible y porque hay presión de tiempo,
códigos complejos, complejidad de infraestructura, cambios de tecnologías y / o varias
interacciones del sistema.

Las fallas se pueden dar por condiciones ambientales respectivamente. Por ejemplo,
radiación, magnetismo, campos electrónicos, y polución pueden causar desperfectos en
firmware o influencia en la ejecución del software cambiando las condiciones del hardware.

1.1.3 Función de las Pruebas en el Desarrollo, Mantenimiento y Operaciones del

Software (K2)

Las pruebas rigurosas de sistemas y documentación ayudan a reducir el riesgo de

problemas que ocurren durante la operación y contribuyen a la calidad del sistema del
software, si se corrigen los defectos encontrados antes de lanzar el sistema para uso
operativo.

También puede requerirse que el software cumpla los requisitos contractuales y legales o
estándares específicos industriales.

1.1.4 Pruebas y Calidad (K2)

Con la ayuda de las pruebas, es posible medir la calidad del software en términos de
defectos encontrados para los requisitos y características funcionales y no funcionales del
software (por ejemplo, confiabilidad, uso, eficiencia, mantenimiento y portabilidad).Para
mayor información sobre pruebas no funcionales, véase Capitulo 2; para mayor
información sobre características de Software, véase "Software Engineering-Sotfware
Product Quality" (ISO 9126).

Las pruebas dan confianza en la calidad del software si encuentran pocos o ningún defecto.
Una prueba designada adecuadamente que está aprobada, reduce todo el nivel de riesgo
 en un sistema. Cuando en la prueba se encuentran defectos, la calidad del sistema del
software aumenta cuando se corrigen dichos defectos.

Se deben aprender lecciones de proyectos anteriores. Al comprender la causa principal de

los defectos encontrados en otros proyectos, se pueden mejorar procesos que a su vez
deben prevenir que dichos defectos vuelvan a ocurrir y como consecuencia mejoren la
calidad de futuros sistemas. Lo anterior es una garantía de calidad.

Las pruebas deben integrarse como una de las actividades de garantía de calidad (Es decir,
junto con estándares de desarrollo, capacitación and análisis de defectos).

1.1.5 ¿Cuánto testing es necesario? (K2)

Cuando se toma la decisión de cuanto testing es suficiente, se debe considerar el nivel de

riesgo, incluyendo riesgos técnicos, de seguridad y comerciales y restricciones del proyecto
como tiempo y presupuesto. El riesgo se examina más detalladamente en el Capítulo 5.

Testing debe dar la suficiente información a accionistas parque tomen decisiones

fundamentadas respecto al lanzamiento del software o sistema que se está probando, para
la próxima fase de desarrollo o entrega a clientes.

1.2 ¿Que es Testing?(K2) 30 minutos

Terminos
Depuramiento, requisitos, revisión, caso de prueba, testing, objetivo de prueba

Antecedentes
Una percepción normal de testing es aquella que solo consiste en realizar pruebas, es
decir, ejecutar el software. Esto hace parte del testing pero no de todas las actividades
del mismo.

Las actividades de pruebas existen antes y después de la ejecución de pruebas. Estas

actividades incluyen la planeación, control, selección de condiciones de pruebas diseño y
ejecución de casos de prueba, revisión de resultados, evaluación de fin de pruebas,
reportes del proceso de testing y sistema conforme dicha prueba y finalización del cierre
de actividades después de haber terminado la fase de prueba. Testing también incluye la
revisión de documentos (incluyendo el código fuente) y dirección de análisis estáticos

Se puede utilizar el testing dinámico y estático como medio para lograr objetivos similares
y suministraran información que puede utilizarse para mejorar el sistema que se está
probando y los procesos de desarrollo y testing.
Testing puede tener los siguientes objetivos:
- Encontrar defectos
- Ganar confianza respecto al nivel de calidad
- suministrar información para la toma de decisiones.
- Prevenir defectos

El proceso pensado y actividades relacionadas en el diseño de pruebas en el ciclo de vida

(verificación de pruebas base por medio de diseños de pruebas) pueden ayudar a prevenir
que se introduzcan defectos en el código. La revisión de documentos (por ejemplo,
requisitos) y la identificación y resolución de asuntos ayudan también a prevenir defectos
que aparecen en el código.
En diferentes puntos de vista en testing, se toman en cuenta distintos objetivos. Por
ejemplo en el desarrollo del testing (por ejemplo, componentes, integración, y testing del
sistema), es posible que el principal objetivo sea identificar la mayor cantidad de fallas
posibles de manera que se puedan identificar defectos en el software y se solucionen. En
las pruebas de validación, el principal objetivo puede ser confirmar que el sistema funcione
como se había esperado, ganar confianza y cumplir los requisitos. En algunos casos el
principal objetivo de testing puede ser evaluar a la calidad del software (sin la intención
de arreglar defectos), informar a accionistas del riesgo que corren al lanzar el sistema en
un momento dado. El mantenimiento del testing generalmente incluye pruebas donde no
se han presentado defectos nuevos durante el desarrollo de los cambios. En el testing
operativo, el principal objetivo es evaluar las características del sistema como la
confiabilidad y disponibilidad.
Son diferentes la depuración y testing. El testing dinámico puede mostrar fallas causadas
por defectos. La depuración es la actividad de desarrollo que encuentra, analiza y remueve
la causa de la falla. El re-testing posterior hecho por un probador, garantiza que el arreglo
ciertamente resuelve la falla. La responsabilidad de estas actividades es que normalmente
los probadores y desarrolladores hagan el proceso de depuración.
El proceso de testing y actividades de testing se explican en la sección 1.4

1.3 Siete Principios de Testing (K2) 35 minutos

Términos
Testing Exhaustivo

Principios
Se han sugerido varios principios de testing los últimos 40 años así como se han ofrecido
pautas comunes para todo el proceso de testing.

Principio 1- Testing muestra la presencia de defectos

Testing puede mostrar que los defectos están presentes, pero no puede comprobar que no
haya defectos. Testing reduce las probabilidades de defectos no descubiertos que
permanecen en el software, pero incluso si no se encuentran defectos, no es prueba de
corrección.

Principio 2 -Testing exhaustivo es imposible

Hacer pruebas de todo (todas las combinaciones de entradas y prerrequisitos) no es viable
salvo casos triviales. En lugar de pruebas exhaustivas, se debe utilizar un análisis de riesgo
y prioridades que se enfocan en esfuerzo de testing (testing efforts).
Principio 3 - Testing anticipado
Para encontrar defectos por anticipado, las actividades deberán empezar lo más temprano
posible en el desarrollo del ciclo de vida del software o el sistema, y deberá enfocarse en
objetivos definidos

Principio 4 - Agrupación de defecto

Las pruebas se enfocaran proporcionalmente a la densidad del defecto de modulos
esperado y observado posteriormente. Pocos modulos generalmente contienen la mayoría
de defectos descubiertos durante el testing previo al lanzamiento, o son responsables de
la mayoría de fallas operativas.

Principio 5 Paradoja Pesticida (Pesticide paradox)

Si se repiten las mismas pruebas una y otra vez, los mismos casos de pruebas finalmente
ya no encontraran defectos nuevos. Para superar esta "paradoja pesticida", se necesitan
revisar y examinar regularmente los casos de prueba y además se deberán redactar
nuevas y diferentes pruebas que ejerciten distintas partes del software o sistema que
potencialmente encuentren más defectos

Principio 6 - Testing es un contexto dependiente

Testing se realiza de una manera diferente en diferentes contextos. Ejemplo, se prueba
el software crítico relacionado con seguridad de una manera diferente al portal e-
commerce

Principio 7 - Falta de errores

Encontrar y arreglar errores no ayuda si el sistema desarrollado no sirve o no cumple las
necesidades y expectativas del usuario.

1.4 Proceso fundamental de la Prueba (K1) 35 minutos

Terminos
La confirmación de testing, re-testing criterios de salida, incidentes, pruebas de regresión,
bases de pruebas, condiciones de pruebas, cubrimiento de pruebas, datos de pruebas,
ejecución de pruebas, log de pruebas, plan de pruebas procedimiento de pruebas, política
de pruebas, conjunto de pruebas, reporte de resumen de pruebas, testware

Antecedentes
La parte más visible de testing es la ejecución de pruebas. Sin embargo, para ser efectivo
y eficiente, los planes de prueba deben incluir el tiempo que se debe gastar en la
planeación de pruebas, diseño de casos de pruebas, preparación de la ejecución y
evaluación de resultados
 El proceso fundamental de pruebas consiste en las
siguientes actividades principales:
- Planeación de pruebas y control
- Análisis y diseño de pruebas
- Implementación evaluación de pruebas
- Evaluación de criterios de salida y reporte
- Actividades de cierre del testing

Siendo lógicamente secuencial, las actividades en el proceso pueden sobreponer u ocurrir

al mismo tiempo. Se requiere generalmente adaptar estas actividades en el contexto de
sistema y el proyecto.

1.4.1 Planeación y control de pruebas (K1)

La planeación de pruebas es la actividad que define los objetivos de testing y la
especificación de actividades de prueba con el fin de cumplir los objetivos misión.

El control de pruebas es la actividad continua de comparar el progreso real del plan, y el

reporte del estado, que incluyen desviaciones desde el plan. Este control incluye tomar las
acciones necesarias que cumplen la misión y objetivos del proyecto. Para controlar el
testing, estas actividades deben monitorearse a través del proyecto. La planeación de
pruebas considera la retroalimentación a partir del monitoreo y control de actividades.

Las funciones de planeación y control se definen en el Capitulo 5 de este programa

1.4.2 Análisis y Diseño de Pruebas (K1)

El análisis y diseño de pruebas es la actividad en la cual se transforman los

objetivos generales de testing en condiciones de prueba tangibles y en casos de
pruebas

El análisis y diseño de pruebas tiene las siguientes actividades principales:

- Revisar las bases de pruebas (como requisitos, integridad del software nivel 1 ( nivel
de riesgo), reporte de análisis de riesgo, arquitectura, diseño, interface,
especificaciones)
.
- Evaluación de comprobabilidad de la base de pruebas y objetos de
pruebas
- Identificación y prioridad de las condiciones de pruebas basadas en el
análisis del objeto de pruebas, la especificación, comportamiento y
estructura del software.
- Diseño y Prioridad de altos niveles de casos de pruebas
- Identificación de información de pruebas necesaria para apoyar las condiciones de
pruebas y casos de pruebas
- Diseño de la configuración del entorno de la prueba e identificación de
cualquier infraestructura requerida y herramientas.
- Creación de trazabilidad bidireccional entre las base de prueba y casos
de prueba
 1. el grado al cual el software cumple o debe cumplir con un conjunto de
características de software elegido por accionistas de un sistema basado en software
( por ejemplo, complejidad del software, evaluación de riesgo, nivel del seguridad,
desempeño deseado, confiabilidad o costo) que se definen para reflejar la importancia
del software a sus accionistas.

1.4.3 Implementación y ejecución de pruebas (K1)

La implementación y ejecución de pruebas es cuando los procedimientos de pruebas o

escritos se especifican combinando los casos de pruebas en un orden particular e incluyendo
cualquier otra información necesaria para ejecutar pruebas, se configura el entono y se
realizan pruebas.

La implementación y ejecución de pruebas tienen las siguientes tareas importantes:

- Finalizar, implementar y darle prioridad a los casos de pruebas ( incluyendo la

identificación de información pruebas)
- Desarrollar y darle prioridad a procedimientos de pruebas, crear información de
pruebas u opcionalmente preparar test.
Harnesses (herramienta de pruebas específicas que permite probar [...] un servicio
de manera aislada) y redactar scripts (escrito) de pruebas automatizadas.
- Crear grupos de pruebas a partir de procedimientos de pruebas para una eficiente
ejecución de pruebas
- Verificar que el entorno de pruebas se haya configurado correctamente.
- Verificar y actualizar la trazabilidad bidireccional entre las bases de pruebas y casos de
pruebas.
- Ejecutar procedimientos de pruebas manualmente o utilizando las
herramientas de ejecución de pruebas de acuerdo a la secuencia planeada
- Registrar los resultados de la ejecución de pruebas y registro de identidades
y versiones del software conforme la prueba, herramientas de pruebas y
testware
- Comparar resultados reales con los resultados esperados
- Reportar discrepancias como incidentes y analizarlos para establecer su causa
( por ejemplo, un defecto en el código, en datos específicos de pruebas
documentos pruebas o errores en la manera en que se ejecuto la prueba)
- Repetir las actividades de pruebas como resultado de las acciones tomadas de
cada discrepancia, por ejemplo, la re ejecución de una prueba que fallo
previamente con el fin de confirmar una solución ( confirmación de testing),
ejecución de una prueba corregida y / o ejecución de pruebas para asegurar
que los defectos no han sido ingresados en áreas inalteradas del software o
que la solución de defectos no descubrieron otros defectos ( Testing de
regresión)
1.4.4 Evaluación de criterios de salida y Reportes (K1)
La evaluación de criterios salida es la actividad donde se evalúa la ejecución de pruebas
con respecto a los objetivos definidos. Lo anterior debería realizarse para cada nivel de
prueba (ver sección 2.2)

La evaluación de los criterios de salida tienen las siguientes tareas importantes:

- Revisar registradores de pruebas respecto a criterios de salida especificados en la

planeación de pruebas
- Evaluar si se necesitan más pruebas o si los criterios de salida específicos deben
cambiarse
- Redactar un reporte de resumen de pruebas para accionistas

1.4.5 Actividades de Cierre de Pruebas (K1)

Las actividades de cierre recopilan información de actividades de pruebas finalizadas para

consolidar experiencia, testware hechos y cifras. Las actividades del cierre de pruebas se
dan en fases del proyecto cuando se lanza un sistema de software, finaliza un proyecto de
pruebas (o se cancela) se logra un hito o se completa una conformidad de mantenimiento.

Las actividades de cierre incluyen las siguientes tareas principales:

- Revisar que los resultados planeados se hayan entregado

- Cerrar los reportes de incidentes o levantar registros de cambios para
cualquiera de ellos que permanezcan abiertos.
- Documentar la aceptación del sistema
- Finalizar y archivar el testware, el entorno de pruebas e infraestructura de
pruebas para un futuro re uso o entrega de testware para la organización de
mantenimiento
- Analizar las lecciones aprendidas para determinar cambios necesarios
para futuras salidas y proyectos. - Uso de información recopilada que
mejoren el test maturity. (vencimiento de la prueba).

1.5 Psicología de testing (K2) 25 minutos

Terminos
Error guessing (calculo de errores), independencia

Antecedentes
La manera en que se analiza mientras el proceso de prueba y revisión es diferente a
aquella que se utiliza mientras se desarrolla el software .Con la correcta actitud los
desarrolladores pueden probar sus propios códigos, pero la división de esta
responsabilidad a un probador se realiza comúnmente para ayudar a enfocarse en
esfuerzos y suministra beneficios adicionales, como una perspectiva independiente por
recursos de testing capacitados y profesionales. Testing independiente puede llevarse
acabo en cualquier nivel del testing.

Un cierto grado de independencia (evitando la influencia del autor) generalmente hace

que el probador sea más eficiente para encontrar defectos y fallas. La independencia no
es, sin embargo, un reemplazo de familiaridad y desarrolladores pueden eficientemente
encontrar muchos defectos en sus propios códigos. Muchos niveles e independencia se
pueden definir tal como se muestra de bajo a alto:
- Las pruebas diseñadas por personas que han redactado el software conforme la
prueba (nivel bajo de independencia )
- Pruebas diseñadas por otras personas ( por ejemplo, el equipo de desarrollo)
- Pruebas diseñadas por personas de un grupo organizacional diferente ( por ejemplo,
equipo de prueba independiente) o especialistas de pruebas ( por ejemplo, uso o
desempeño de especialistas en pruebas)
- Pruebas diseñadas por personas de diferentes organizaciones o compañías ( es decir,
outsourcing o certificación por un organismo externo)

La gente y los proyectos se rigen por proyectos. La gente tiende a nivelar sus planes con
los objetivos planteados por el manejo y otros accionistas, por ejemplo encontrar defectos
o confirmar que el software cumple sus objetivos. Por lo tanto, es importante establecer
claramente los objetivos de testing.

Identificar fallas en el proceso de testing puede percibirse como una crítica del producto y
el autor. Como resultado, el testing se ve como una actividad destructiva a pesar de ser
muy constructiva en el manejo de riesgos del producto. La búsqueda de fallas en un
sistema requiere curiosidad, pesimismo profesional, ojo crítico, atención a detalles, buena
comunicación con desarrolladores, y experiencia donde basar error guessing.

SI hay errores, defectos o fallas se comunican de manera constructiva, se deben evitar

malos sentimientos entre los probadores y analistas, diseñadores y desarrolladores. Esto
aplica a los defectos encontrados en la revisión así como en el testing.

El probador y líder de pruebas necesitan habilidades interpersonales para dar información

objetiva respecto a defectos, progreso, y riesgos de manera constructiva. Para el autor del
software o documento, la información defectuosa puede ayudarles a mejorar sus
habilidades. Los defectos que se encuentra y se arreglan en el testing, ahorra tiempo y
dinero más adelante y reducen riesgos.

Es posible que haya problemas de comunicación, especialmente si los probadores se ven

solo como mensajeros de noticias no esperadas sobre defectos. Sin embargo, existen
varias maneras de mejorar la comunicación y relación entre probadores y otros:

- Comenzar con colaboración en lugar de disputas - recordarle a todos el objetivo común

de mejores sistemas de calidad.
- Comunicar resultados sobre el producto de una manera neutral y basada en hechos
sin criticar a quien creo el producto, redactar reportes de incidentes objetivos y reales
y revisar resultados.
- Tratar de comprender como se siente la otra persona y porque sus reacciones.
- Confirmar que la otra persona ha comprendido lo que se ha dicho y viceversa.

1.6 Código de Ética 10 minutos

La participación del testing software permite adquirir información confidencial y

privilegiada. Un código de ética es necesario, entre otras razones que garanticen que la
información no debe utilizarse inapropiadamente. Reconocer el ACM y IEEE código de ética
para ingenieros, el ISTQB dice el siguiente código de ética:

PUBLICO - Probador de software certificado actuara consistentemente con el interés

público

CLIENTE Y EMPLEADOR - Probador de software certificado actuara de una manera tal

que sea el mejor beneficio para el cliente y empleador, compatible con el interés público

PRODUCTO - Probador de software certificado garantizara que los entregables que

suministran (sobre los productos y sistemas que prueban) cumplen los estándares de más
alto nivel posible

DICTAMEN - Probador de software certificado mantendrá la integridad e independencia

en su dictamen profesional.

MANEJO - Probador de software certificado y lideres se suscribirá y promoverán un

enfoque ético al manejo del testing del software

PROFESION - Probador de software certificado fomentara la integridad y reputación de la

profesión compatible con el interés público

COLEGAS - Probador de software certificado será justo y apoyara a sus colegas y

promoverá cooperación con los desarrolladores de software.

SELF- Probador de software certificado participara en educación permanente respecto a

la práctica de su profesión y promoverá un enfoque ético a la práctica de la profesión

References
1.1.5 Black, 2001, Kaner, 2002
1.2 Beizer, 1990, Black, 2001, Myers, 1979
1.3 Beizer, 1990, Hetzel, 1988, Myers, 1979
1.4 Hetzel, 1988
 1.4.5 Black, 2001, Craig, 2002
1.5 Black, 2001, Hetzel, 1988

2. Testing a través del Ciclo de vida del Software (K2) 115 minutos

Objetivos de estudio para Testing a través del ciclo vida del Software
Estos objetivos identifican lo que se podrá hacer realizar siguiendo el proceso de
terminación de cada módulo.

2.1 Modelos de Desarrollo del Software (K2)

LO-2.1.1 Explicar la relación entre desarrollos, actividades de prueba, productos de
trabajo en el ciclo de vida del desarrollo dando ejemplos, utilizando
proyectos y tipos de productos (K2)
LO-2.1.2 Reconocer que se deben adaptar los modelos de desarrollo del software al
contexto del proyecto y características del producto (K1)
LO-2.1.3 Recordar las características de un buen proceso de testing que se aplican a
cualquier modelo de ciclo de vida (K1)

2.2 Niveles de Prueba (K2)

LO-2.2.1 Comparar los diferentes niveles de pruebas: objetivos principales, objetos
típicos de testing, objetivos típicos de testing (por ejemplo, funcionales o
estructurales) y productos de trabajo relacionado, personas que prueban,
tipos de defectos y fallas que debe identificarse (K2)

2.3 Tipos de Prueba (K2)

LO-2.3.1 Comparar por medio de ejemplos los cuatro tipos de pruebas del software
(funcional, no funcional, estructural y relacionado con cambios) (K2)
LO-2.3.2 Reconocer que las pruebas funcionales y estructurales ocurren en cualquier
nivel de prueba (K1).
LO-2.3.3 Identificar y describir tipos de prueba no funcional basados en requisitos no
funcionales (K2)
LO-2.3.4 Identificar y describir tipos de prueba basados en análisis de una estructura
o arquitectura del sistema del software (K2)
LO-2.3.5 Describir el propósito de testing de confirmación y testing de regresión (K2)

2.4 Testing de Mantenimiento (K2)

LO-2.4.1 Comparar el testing de mantenimiento (probando un sistema vigente) con
la prueba de una aplicación nueva respecto a los tipos de prueba, activadores
de pruebas y cantidad de pruebas (K2)
LO-2.4.2 Reconocer indicadores para testing de mantenimiento
(modificación, migración y retiros (K1)
LO-2.4.3 Describir la función del testing de regresión y análisis de impacto en
mantenimiento (K2)
 2.1 Modelos de Desarrollo del Software (K2) 20 minutos

Términos
Comerciales Off-The-Shelf (COTS), modelo de desarrollo iterativo-gradual, validación,
verificación, modelo V.

Antecedentes
Las pruebas no son hechos aislados; las actividades de pruebas se relacionan a las
actividades de desarrollo del software. Diferentes modelos de ciclo de vida de desarrollo
necesitan distintos enfoques al testing.

2.1.1 modelo -V (Modelo de Desarrollo Secuencial) (K2)

Aunque existen las variantes del modelo, un tipo común del modelo V utiliza cuatro niveles
de prueba, correspondientes a los cuatro niveles de desarrollo.

Los cuatro niveles utilizados en este programa son los siguientes:

- Componentes (unidad) de testing
- Testing de integración
- Testing del Sistema
- Testing de aceptación

En la práctica, un modelo - V puede tener más, menos o diferentes niveles de desarrollo y

pruebas dependiendo del proyecto y producto del software. Por ejemplo, puede existir un
testing de integración del componente después de un testing del componente, y testing
de integración del sistema después de testing en el sistema.

Productos de trabajo del software (como escenarios comerciales, casos de uso,

especificaciones de requisitos, documentos y códigos de diseño) que se producen durante
la fase de desarrollo son generalmente la base de pruebas en uno o más niveles de la
misma. Las referencias para productos de trabajo genérico incluyen la Capability Maturity
Model Integration (CMMI) (Integración de Modelos de Madurez de Capacidades) o
"procesos del ciclo de vida del software"(IEEE/IEC 12207). Se puede llevar a cabo la
verificación y validación (diseño de prueba inicial) durante la fase de desarrollo de los
productos de trabajo del software.

2.1.2 Modelos de Desarrollo Iterativo-progresivo (K2)

Un desarrollo iterativo-progresivo es el proceso que establece requisitos, diseños,
construcción y pruebas de un sistema en una serie de ciclos cortos de desarrollo, Por
ejemplo, prototipo, Rapid Application Development (RAD) (Desarrollo Rápido de
Aplicaciones) Rational Unified Process (RUP) (Proceso Unificado Racional), y modelos agiles
de desarrollo. Un sistema que se produce utilizando estos modelos se pueden probar en
varios niveles de prueba en cada iteración. Un incremento, junto a otros desarrollados
previamente, forma un creciente sistema parcial que también debe probarse .Las pruebas
de regresión son sumamente importantes en todas las iteraciones después de realizar la
primera. Se pueden llevar a cabo la verificación y validación en cada progreso.
2.1.3 Testing en un Modelo del Ciclo de Vida (K2)
En cualquier ciclo de vida, existen varas características de una buena prueba:
- En cada actividad de desarrollo, existe una actividad de prueba correspondiente
- Cada nivel de prueba tiene objetivos específicos de prueba a dicho nivel

- El análisis y diseños de pruebas en un nivel dado debe comenzar durante la

correspondiente actividad de desarrollo.
- Los probadores deben participar en la revisión de documentos tan pronto como estén
disponibles los bosquejos en el ciclo de vida del desarrollo.

Se pueden combinar o reorganizar niveles de prueba dependiendo de la naturaleza del

proyecto o arquitectura del sistema. Por ejemplo, en la integración a un sistema de un
producto de software comercial Off-The-Shelf (COTS), el comprador podrá realizar la
prueba de integración en el nivel del sistema (por ejemplo, la integración de infraestructura
y otros sistemas o despliegue del sistema) y pruebas de aceptación (funcional y / o no
funcional y el usuario y / o prueba operativa.

2.2 Niveles de Prueba (K2) 40 minutos

Términos
Pruebas Alpha, beta, de componentes, driver, de campo, requisito funcional, integración,
pruebas de integración, requisitos no funcionales, pruebas de resistencia, STUB, pruebas
del sistema, ambiente de pruebas nivel de prueba, desarrollo guiado por pruebas, pruebas
de aceptación del usuario.

Antecedentes
En cada nivel de prueba, se puede identificar lo siguiente: objetivos genéricos, producto
(s) de trabajo que se referencian en casos de prueba derivados (es decir, bases de
pruebas), objeto de prueba (es decir, lo que se está probando), defectos comunes y fallas
que deben encontrarse, requisitos de test harness (herramienta de pruebas específica que
permite probar un servicio de manera aislada) y soporte de herramientas y enfoques y
responsabilidades específicas.

Prueba de datos de configuración de un sistema se tendrá en cuanta en la planeación de

pruebas.

2.2.1 Pruebas del componente (K2)

Bases de Prueba
o Requisitos del componente
o Diseño detallado
o Código

Objetos de prueba comunes:

 o Componentes
o Programas
o Conversión de datos / programas de migración - Módulos de data base

Testing de componentes (también conocido como unidad, modulo o prueba de programa)

busca defectos y verifica el funcionamiento de los módulos, programas, objetos y clases
del software, etc. que se prueban por separado. Se puede realizar de forma aislada del
resto del sistema, dependiendo del contexto del ciclo de vida del desarrollo y del sistema.
Se pueden utilizar stubs, drivers, y simuladores.

Testing de componentes puede incluir pruebas de funcionalidad y características

específicas no funcionales, como comportamiento de recursos (por ejemplo, busca de
pérdidas de memoria) o pruebas de resistencia, así como pruebas estructurales (por
ejemplo, decisión de cobertura).Los casos de prueba se derivan de los productos de trabajo
como la especificación del componente, diseño del software o modelo de datos,

Normalmente, la prueba del componente ocurre con el acceso al código que se está
probando y con el apoyo de un entorno de desarrollo, como un marco de pruebas de
unidad o herramienta de depuramiento. En la práctica, las pruebas del componente
generalmente involucra al programador que redacto el código. Lo defectos normalmente
se solucionan cuando se encuentran sin manejar dichos defectos formalmente.

Un enfoque al testing del componente es preparar y automatizar los casos de prueba antes
de la codificación. Lo anterior se denomina como un enfoque de primeras pruebas, y
desarrollo guiado por pruebas. Este enfoque es altamente iterativo y se basa en ciclo de
casos de prueba desarrollados, luego en la construcción e integración de pequeñas piezas
de códigos y ejecución de pruebas de componentes corrigiendo cualquier inconveniente e
iteración hasta que pasen.

2.2.2 Pruebas de Integración (K2)

Bases de pruebas:
o Diseño del software y del sistema
o Arquitectura
o Flujos de trabajo
o Casos de uso

Objetos de prueba comunes:

o Subsistemas
o Implementación de base de datos
o Infraestructura
o Interfaces
o Configuración del sistema y datos de configuración

El testing de integración prueba interfaces entre componentes, interacciones con distintas

partes de un sistema, como el sistema operativo, sistema del archivo, y hardware e
interfaces entre sistemas.
Puede haber más de un nivel de testing de integración y puede llevarse a cabo en objetos
e prueba de diversos tamaños de la siguiente manera:
1. Las pruebas de integración de componentes prueban las interacciones entre los
componentes del software y se realiza después de las pruebas del componente.
2. las pruebas de integración del sistema prueban las interacciones entre distintos
sistemas o entre el hardware y software y puede realizarse después de probar el
sistema. En este caso, la organización de desarrollo podrá controlar únicamente un
lado de la interface. Esto podría considerarse un riesgo. Los procesos comerciales
que se implementan como workflows (flujo de trabajo) relacionaran una serie de
sistemas. Problemas con multiplataforma pueden ser relevantes
Entre mayor sea alcance de integración, más difícil es asilar defectos a un componente o
sistema específicos, lo que puede aumentar riesgos y gastar más tiempo para resolver el
problema.

Las estrategias de integración del sistema se pueden basar en la arquitectura del sistema
(como un planteamiento ascendente y un planteamiento descendente), tareas funcionales,
secuencias de trámites de transacciones, o algunos otros aspectos del sistema o
componentes. Con el fin de prontamente mitigar el aislamiento de fallas y detectar
defectos, la integración debe ser normalmente incremental en lugar de ser un "big bang"

Las pruebas de características no funcionales especificas (por ejemplo, desempeño) pueden

incluirse en las pruebas de integración así como pruebas funcionales.

En cada etapa de integración, los probadores se concentran únicamente en la integración

misma. Por ejemplo, si están integrando el modulo A con el modulo B, están interesados
en probar la comunicación que existe entre dichos módulos, no en la funcionalidad del
módulo tal como se realizó en las pruebas del componente. Se pueden utilizar los enfoques
funcionales y estructurales.

Es ideal que los probadores comprendan la planeación de integración de la arquitectura e

influencia. Si se planean las pruebas de integración antes de construir componentes o
sistemas, dichos componentes pueden construirse en el orden solicitado para una mayor
eficiencia en las pruebas.

2.2.3 Pruebas del sistema (K2)

Bases de Prueba:
o Especificación de requisitos del sistema y software
o Casos de uso
o Especificación funcional
o Reportes de análisis de riesgo

Objetos de prueba comunes:

o Manuales del sistema, usuario y operación
o Configuración del sistema y datos de configuración
Las pruebas del sistema se interesan por el comportamiento de todo el sistema/producto.
El alcance de las pruebas estará claramente abordado en el Plan de Pruebas Master y/ o
de Nivel para ese nivel de prueba.

En las pruebas del sistema, el entorno de la prueba corresponde al objetivo final o entorno
de producción tanto como sea posible con el fin de minimizar el riesgo de fallas de entorno
específicas que no se encuentran en las pruebas.

Pruebas del sistema pueden incluir pruebas basadas en riesgos y/o en especificaciones de
requisitos, procesos comerciales, casos de uso, u otras descripciones de texto de alto nivel
o modelos de comportamiento del sistema, interacciones con el sistema operativo y
recursos de sistemas.

Las pruebas del sistema deben investigar los requisitos no funcionales del sistema y
características de la calidad en los datos. También necesitan los probadores hacerse cargo
de requisitos incompletos o indocumentados las pruebas del sistema de requisitos
funcionales comienza con el uso de las más adecuadas técnicas basadas en especificaciones
(caja negra) para que se pruebe el aspecto del sistema. Por ejemplo, se puede crear una
tabla de decisiones para la combinación de efectos descritos en las normas comerciales.
Técnicas basadas en estructuras (caja blanca) se pueden usar para tener acceso a la
rigurosidad de la prueba respecto al elemento estructural, como la estructura del menú o
navegación de la página web (ver Capitulo 4)

Un equipo de prueba independiente generalmente lleva a cabo las pruebas del sistema.

2.2.4 Pruebas de aceptación (K2)

Bases de pruebas
o Requisitos del usuario
o Requisitos del sistema
o Casos de uso
o Procesos comerciales
o Reporte de análisis de riesgo

Objetos de prueba comunes

o Procesos comerciales en un sistema completamente
integrado
o Procesos operativos y de
mantenimiento
o Procedimientos del usuario
o Formas
o Reportes
o Datos de configuración
Frecuentemente es responsabilidad de los clientes o usuarios de un sistema, las pruebas de
aceptación; otros accionistas pueden participar respectivamente.

El objetivo en las pruebas de aceptación es establecer confianza en el sistema, partes del

sistema o características específicas no funcionales del sistema. Encontrar defectos no es
el enfoque principal en estas pruebas. Estas pruebas pueden evaluar la disponibilidad del
sistema para su despliegue y uso, aunque no es necesariamente el nivel final de la prueba.
Por ejemplo, una prueba de un sistema de integración a larga escala puede venir después
de una prueba de aceptación para un sistema.

Las pruebas de aceptación pueden darse en varios momentos del ciclo de vida, por ejemplo;
o Un producto software COTS puede ser prueba de aceptación cuando se instala o se
integra.
o Pruebas de aceptación del uso de un componente puede realizarse
durante la prueba del componente
o Pruebas de aceptación de una ampliación funcional pude venir antes de
probar el sistema.

Formas comunes de pruebas de aceptación incluyen el siguiente:

Pruebas de aceptación del usuario

Comúnmente verifica el ajuste para el uso del sistema por parte de usuarios comerciales.

Testing Operativo (de aceptación)

La aceptación del sistema por parte de los administradores del mismo, que incluyen:
o Testing de backup/restaurar
o Plan de recuperación de desastres
o Manejo de uso
o Tareas de mantenimiento
o Carga de datos y tareas de migración
o Revisiones periódicas de vulnerabilidades de seguridad

Testing de aceptación de contrato y norma

Las pruebas de aceptación de contrato se desarrollan respecto a los criterios de aceptación
de un contrato para producir un software adaptado a las medidas del cliente. Se deben
definir los criterios de aceptación cuando las partes acuerden el contrato. El testing de
aceptación de normas se desarrolla respecto a cualquier norma que deba adherirse a dicho
gobierno, normas jurídicas o de seguridad.

Testing de alpha y beta (o de campo)

El software de desarrolladores del mercado o COTS, frecuentemente desea recibir
retroalimentación de clientes potenciales o vigentes en su mercado antes de poner a la
venta el producto del software. Se desarrolla el testing alpha en los sitios de las
organizaciones de desarrollo pero no solamente por el equipo de desarrollo. El testing beta
o de campo, se desarrolló por parte de clientes o clientes potenciales en sus propias sedes.

Las organizaciones pueden utilizar otros términos respectivamente, como pruebas de

aceptación de fábrica y pruebas de aceptación de sitio para sistemas que se prueben antes
y después de llevarlos a las instalaciones del cliente.
 2.3 Tipos de prueba (K2) 40 minutos

Términos
El testing dl Black-box (caja negra, recuadro negro) cubrimiento del código, testing
funcional, testing de interoperabilidad, testing de carga, testing de mantenimiento, testing
de desempeño, testing de fiabilidad, testing de seguridad, testing de tensión, testing
estructural, testing de uso, testing de caja blanca

Antecedentes
Un grupo de actividades de prueba puede estar dirigido a la verificación del sistema del
software (o una parte del sistema) basado en razones especificas u objetivos de prueba

Un tipo de prueba se enfoca en un objetivo especial de prueba que puede ser lo siguiente:
o Una función que desarrolla el software.
o Una característica de calidad no funcional, como
confiabilidad o uso
o La estructura o arquitectura del software o
sistema.
o Cambios relacionados, es decir, confirmación de defectos que se han
solucionado (testing de confirmación) y búsqueda de cambios accidentales.

Se puede desarrollar y / o usar un modelo de software en un testing estructural (por

ejemplo, modelo de flujo de control o modelo de estructura del modelo), testing no
funcional (por ejemplo, modelo de desempeño, modelo de seguridad contra amenazas) y
testing funcional (por ejemplo, un modelo de procesos de flujo, un modelo de transición
de estado, o una especificación simple del idioma.

2.3.1 Testing de Función (Testing Funcional) (K2)

Las funciones donde se deben desarrollar un sistema, subsistema, o componentes pueden
describirse en productos de trabajo como especificación de requisitos, casos de uso o
especificación funcional, o pueden estar indocumentados. Las funciones son lo "Que" realiza
el sistema.

Las pruebas funcionales se basan en funciones y características (descritas en documentos

y comprendidas por los probadores) y su interoperabilidad con sistemas específicos y
podrán desarrollarse en todos los niveles de prueba (por ejemplo, pruebas para
componentes se pueden basar en una especificación de un componente).

Las técnicas basadas en especificación se pueden utilizar para derivar condiciones de

pruebas y casos de pruebas desde la funcionalidad del sistema o software (ver Capitulo 4).
EL testing funcional tiene en cuenta el comportamiento externo del software (testing de
caja negra).
Un tipo de testing funcional, seguridad, pruebas investiga las funciones (por ejemplo un
firewall) relacionado con la detección de amenazas como virus de factores externos
maliciosos. Otro tipo de testing funcional, testing de interoperabilidad, evalúa la capacidad
del producto del software que interactúa con uno o más componentes o sistemas más
específicos.

2.3.2 Testing de las características del software no funcionales (Testing no

funcional) (K2)
Testing no funcional incluye, pero no se limita a testing de desempeño testing descarga,
testing de tensión, testing de uso testing de mantenimiento, testing de confianza, testing
de portabilidad. Este testing se refiere a "como" funciona el sistema.

Testing no funcional puede desarrollarse en todos los niveles de prueba. Testing no

funcional describe las pruebas requeridas para medir las características de sistemas y
software que pueden cuantificarse en una escala variable. Estas pruebas pueden
referenciarse al modelo de calidad como el que se definió en Software Engineering –
Software Producto Quality’ (ISO 9126). Testing no funcional tiene en cuenta el
comportamiento externo del software y en la mayoría de casos utiliza técnicas de diseño
de pruebas de caja negra para cumplir dicha función.

2.3.3 Testing de la Estructura/Arquitectura del Software (Testing Estructural)

(K2)
Testing estructural (de caja blanca) se puede desarrollar en todos los niveles de prueba.
Técnicas estructurales son las que se utilizan de la mejor manera posterior a las técnicas
basadas en especificaciones, con el fin de ayudar medir l minuciosidad de la prueba por
medio de la evaluación de cobertura de un tipo de estructura.

El cubrimiento es la medida en que se ha ejercitado una estructura por parte de un conjunto

de pruebas, expresada como un porcentaje de las partidas que se cubren. Si el cubrimiento
no es del 100%, se pueden diseñar más pruebas para aquellas partidas que faltaron para
aumentar el cubrimiento. Las técnicas de cubrimiento se tratan el l Capitulo 4.

En todos los niveles de prueba, pero especialmente en el testing del componente y testing
de integración del componente, se pueden utilizar para medir el cubrimiento de códigos de
elementos como estados o decisiones. El testing estructural puede basarse en la
arquitectura del sistema, como una denominada jerarquía.

Los enfoques de testing estructurales pueden aplicarse también en el sistema, integración

del este, a o niveles de pruebas de aceptación (por ejemplo, a modelos comerciales o
estructuras del menú).

2.3.4 Testing Relacionado con Cambios: Re testing y Testing de Regresión (K2)

Después de detectar un defecto y solucionarlo, se debe probar nuevamente el software
para confirmar que el defecto original se ha removido exitosamente. Lo anterior se
denomina confirmación. La depuración (ubicación y solución de un defecto) es una
actividad de desarrollo, no una actividad de pruebas.
Las pruebas de regresión es el testing repetido de un programa que ya se ha probado,
después de una modificación, que descubre cualquier defecto introducido o descubierto
como resultad del cambio (s).Estos defectos pueden ser ya sea en el software que se está
probando o en otro componente del software relacionado o no relacionado. Se desarrolla
cuando el software o su entorno se cambian. El alcance de testing de regresión se basa el
riesgo de no encontrar defectos en el software que funcionaba anteriormente.
Se deben repetir las pruebas si se usan para el testing de confirmación y ayuda al testing
de regresión.
El testing de regresión puede desarrollarse en todos los niveles de prueba e incluye testing
estructural funcional y no funcional. Los conjuntos de pruebas de regresión se realizan
muchas veces y generalmente evolucionan lentamente, de manera que el testing de
regresión es un fuerte candidato para el proceso de automatización.

2.4 Testing de mantenimiento (K2) 15 minutos

Términos
Análisis de impacto, testing de mantenimiento

Antecedentes
Cuando se haya desplegado, un sistema del software esta frecuentemente en servicio
durante años o décadas. Durante este tiempo se corrigen, cambian o extienden el sistema,
sus datos de configuración, o su entorno. La planeación de salidas anticipadas es crucial
para pruebas de mantenimiento exitosas. Se debe hacer una distinción entre salidas
planeadas y "hot fixes" (arreglos).Se realiza el testing de mantenimiento en un sistema
operativo vigente, y se activa por modificaciones, migraciones o retiro de software o
sistema.

Las modificaciones incluyen cambios de mejora planeados (por ejemplo, basados en

salidas), cambios correctivos y de emergencia, y cambios de entorno como actualizaciones
planeadas del sistema operativo y de la base de datos, actualización planee del software
comercial Off-The-Shelf o remiendos que corrigen vulnerabilidades recientemente
expuestas o descubiertas del sistema operativo

El testing de mantenimiento para migración (por ejemplo, de una plataforma a otra) debe
incluir pruebas operativas del nuevo entorno así como el software que se ha cambiado. El
testing de migración (testing de conversión) también se necesita cuando los datos
provenientes de otra aplicación se van a migrar al sistema que se está manteniendo.

El testing de mantenimiento para retiro de un sistema puede incluir la prueba de migración

de datos o archivo si se requieren largos periodos de retención de datos.

Además de las pruebas lo que se ha cambiado, el testing de mantenimiento incluye testing

de regresión a partes de sistemas que no se han cambiado. El alcance del testing de
mantenimiento se relaciona con el riesgo de cambio, tamaño del sistema vigente y el
tamaño del cambio. Dependiendo de los cambios, el testing de mantenimiento puede
realizarse en cualquier o todos los niveles de prueba y para cualquier o todos tipos de
pruebas. Determinar como el sistema vigente puede afectarse por cambios se denomina
análisis de impacto y se utiliza para ayudar a decidir cuantas pruebas de regresión se
hacen. El análisis de impacto puede utilizarse para determinar la regresión del conjunto de
pruebas.

El testing de mantenimiento puede ser difícil si están obsoletos o faltan especificaciones o

no están disponibles probadores con conocimiento de dominio

Referencias
2.1.3 C M MI, Craig, 2 002, Hete l, 1988, IEE E 12207
2.2 Él t z el, 1 988
2.2.4 C o pelo un nd, 20 0 4, Myers, 1 9 79
2.3.1 B e iz e r, 1990, Falta B, 2001, Cop e la nd, 2 00 4
2.3.2 Bl cción, 2001, I S O 9126
2.3.3 B e iz e r, 1990, C opa ly, 2 0 04, Hetzel, 1988
2.3.4 H e tze l, 1988, me Eee S T D 8 febrero 9 a 19 9 8
2.4 B la c k, 2001, C r un ig, 2 0 02, H e tzel, 1988, I eee S T D 8 2 9-1998

3. Técnicas Estáticas (K2) 60 minutos

Objetivos de estudio para las técnicas estáticas

Estos objetivos identifican lo que se podrá hacer tras la finalización de cada módulo.

3.1 Técnicas estáticas y Proceso de Prueba (K2)

LO-3.1.1 Reconocer los productos software de trabajo que pueden examinar distintas
técnicas estáticas (K1)
LO-3.1.2 Describir la importancia y valor de las técnicas estáticas en la evaluación de
productos software de trabajo (K2)
LO-3.1.3 Explicar la diferencia entre técnicas estáticas y dinámicas, teniendo en cuenta
los objetivos, los tipos de defectos que deben identificarse y la función de
estas técnicas en el ciclo de vida del software

3.2 Proceso de Revisión (K2)

LO-3.2.1 Recordar las actividades, funciones y responsabilidades de una revisión
formal común (K1)
LO-3.2.2 Explicar las diferencias entre los tipos de revisiones: revisión informal,
revisión técnica, recorrido e inspección (K2)
LO-3.2.3 Explicar los factores para una revisión exitosa (K2)

3.3 Análisis Estático hecho por Herramientas (K2)

LO-3.3.1 Recordar los defectos y errores comunes que identifica el análisis estático y
compararlos con las revisión y pruebas dinámicas (k1)
LO-3.3.2 Describir con ejemplos los beneficios comunes del análisis estático (K2)
LO-3.3.3 Hacer una lista de defectos comunes de códigos y diseños que puedan
identificar las herramientas de análisis estático (K1)

3.1 Técnicas Estáticas y Proceso de Prueba 15 minutos

Términos
Pruebas dinámicas, pruebas estáticas

Antecedentes
A diferencia de las pruebas dinámicas, que requieren la ejecución del software, las técnicas
de pruebas dinámicas cuentan con la exanimación manual (revisiones) y un análisis
automatizado (análisis estático) del código u otra documentación del proyecto sin la
ejecución del código.

Las revisiones son una forma de probar los productos software de trabajo (incluyendo
códigos) y pueden desarrollarse correctamente antes de ejecutar la prueba dinámica. Los
defectos detectados durante las primeras revisiones en el ciclo de vida (por ejemplo,
defectos encontrados en los requisitos) son más económicos de remover que aquellos que
se detectan realizando pruebas en el código de ejecución.

Se podría realizar una revisión completa como un manual de actividades, pero también hay
soporte de herramientas. La principal actividad del manual es examinar un producto de
trabajo y hacer comentarios respecto a eso. Se puede revisar cualquier producto de software
de trabajo, incluyendo especificación de requisitos especificaciones de diseño, código,
planes de prueba, especificaciones de prueba, casos de prueba, comandos de prueba, guías
de usuario o páginas web.

Los beneficios de las revisiones incluyen una detección y corrección temprana de defectos,
mejoras en la productividad de desarrollo, calendarios de desarrollo reducidos, costos y
tiempos de pruebas reducidos, reducciones de costo de duración, menos defectos y mejor
comunicación. Las revisiones pueden encontrar omisiones, por ejemplo en requisitos que
probablemente no se encuentran en las pruebas dinámicas.

Las revisiones, análisis estáticos, y pruebas dinámicas tienen el mismo objetivo; identificar
defectos. Son complementarios; las distintas técnicas pueden encontrar diferentes tipos de
defectos de manera efectiva y eficiente. En comparación a las pruebas dinámicas, las
técnicas estáticas encuentras las causas de las fallas (defectos) en lugar de fallas como tal.

Los defectos comunes que son más fáciles de encontrar en las revisiones que en las pruebas
dinámicas incluyen lo siguiente: desviaciones de estándares, defectos de requisitos, defectos
de diseño, mantenimiento insuficiente y especificaciones de interfaces incorrectas.
3.2 Proceso de Revisión (K2) 25 minutos

Términos
Criterios de ingreso, revisión formal, inspección, métrica, moderador, revisión por expertos,
revisador, escritos, revisión técnica, recorridos.

Antecedentes
Los diferentes tipos de revisiones varían de instrucciones informales que se caracterizan por
no ser escritas para revisores a resultados sistemáticos documentados de la revisión,
procedimientos sistemáticos documentados para dirigir revisiones que se caracterizan por
la participación en equipo. La formalidad de un proceso de revisión se relaciona con factores
como la madurez del proceso de desarrollo, cualquier requisito legal o reglamentario o la
necesidad de un seguimiento de auditoria.

La manera en que se lleva a cabo una revisión depende de los objetivos de revisión
acordados (por ejemplo, encontrar defectos, comprender mejor, educar probadores y a
nuevos miembros en el equipo y decidir por consenso).

3.2.1 Actividades de una Revisión Formal (K1)

Una revisión formal común tiene las siguientes actividades principales:

1. Planeación
o Definición de criterios de revisión
o Selección de personal
o Asignación de funciones
o Definición de criterios de entrada y salida para tipos de revisión más formal
(inspecciones)
o Selección de cuales documentos se deben revisar
o Revisión de criterios de entrada ( para tipos de revisión más formal)
2. Kick-off
o Distribución de documentos
o Explicación de objetivos, procesos y documentos de los participantes
3. Preparación individual
o Preparación para reuniones de revisión por medio de la revisión de
documentos
o Observación de defectos, preguntas y comentarios potenciales
4. Exanimación / evaluación / registro de resultados (reunión de revisión)
o Discusión o registros con resultados o actas documentados ( para más tipos
de revisión formal)
o Observar defectos, recomendaciones respecto al manejo de defectos , toma
de decisiones respecto a los defectos
 o Exanimación / evaluación y registro de problemas en reuniones o monitoreo
de cualquier grupo de comunicaciones electrónico
5. Reelaboración
o Solución de defectos encontrados ( realizados comúnmente por el autor)
o Registro de estados actualizados de defectos ( en revisiones formales)
6. Seguimiento
o Revisión de que se han tratado defectos
o Recopilación de métricas
o Revisión de criterios de salida ( para tipos de revisión más formal)

3.2.2 Funciones y Responsabilidades (K1)

Una revisión formal común incluirá las siguientes funciones:
o Gerente: decide la ejecución de revisiones, distribuye tiempo en la programación
del proyecto y determina si se han cumplido los objetivos de revisión.
o Moderador: la persona que guía la revisión del documento o conjunto de
documentos, incluyendo la planeación de revisión, realizar reuniones, y seguimiento
posterior a reuniones. Si es necesario, el moderador podrá mediar entre varios
puntos de vista y generalmente es la persona responsable del éxito de la revisión.
o Autor: el escritor o persona con la responsabilidad principal de documento (s) a
revisarse.
o Revisores: personas con experiencia técnica o comerciales específicas (también
denominados correctores o inspectores) quienes después de la preparación
necesaria, identifiquen y describan resultados (por ejemplo, defectos) en el producto
conforme la revisión. deben escogerse los revisadores para representar diferentes
perspectivas y funciones en el proceso de revisión, y deben participar en las
reuniones de revisión.
o Notario - escriba ( o registrador): documenta todos los asuntos, problemas y
abiertamente señala que se identificaron en la reunión:

La observación de los productos software o productos de trabajo relacionados desde

distintas perspectivas y uso de listas, se pueden realizar revisiones más efectivas y
eficientes. Por ejemplo, una lista basada en varias perspectivas como el usuario,
mantenedor, probador u operaciones o una lista de problemas de requisitos comunes
pueden ayudar a descubrir problemas no detectados con anterioridad.

3.2.3 Tipos de Revisiones (K2)

Un solo producto software o producto de trabajo relacionado puede estar sujeto a varias
revisiones. Si se utiliza más de un tipo de revisión, puede variar el orden. Por ejemplo, se
puede llevar a cabo una revisión informal antes de una revisión técnica; o se puede realizar
una inspección sobre una especificación de requisitos antes de hacer el recorrido con los
clientes. Las siguientes son las principales características, opciones y propósitos de los tipos
de revisión comunes:
Revisión informal
o Proceso no formal
o Se realiza mediante una programación en pareja o liderazgo técnico que
revise diseños y códigos (La Programación en Pareja (o "Pair Programming"
en inglés) requiere que dos programadores participen en un esfuerzo
combinado de desarrollo en un sitio de trabajo)
o Se pueden documentar los resultados
o Variación de utilidad dependiendo de los revisores
o Propósito principal: forma de bajo costo para obtener beneficios

Recorrido
o Realizar una reunión por parte del autor
o Se realiza mediante escenarios, simulacros, participación de grupo
o Sesiones abiertas
 Preparación de pre-reuniones opcionales de revisores
 Preparación opcional de un reporte de revisión que incluya una lista de
resultados
o Notario - escribiente opcionales (que no sea el autor)
o Puede que varíe de muy informal a muy formal
o Propósito principal: Aprender, comprender, encontrar defectos

Revisión técnica
o Proceso documentado, de detección de defectos definido que incluya compañeros y
expertos técnicos con participación opcional de gerencia
o Se puede desarrollar como una revisión hecha por expertos sin la participación de
la gerencia
o Preferiblemente dirigido por un moderador capacitado (no el autor)
o Preparación de pre-reuniones por parte de revisores
o Uso opcional de listas
o Preparación de un reporte de revisión que incluya la lista de resultados, el veredicto
si el producto software cumple sus requisitos y cuando corresponda,
recomendaciones relacionadas con los resultados
o Puede variar en la práctica de demasiado informal a muy formal
o Propósitos principales: discusiones, toma de decisiones, evaluación de alternativas,
encontrar defectos, solución de problemas técnicos, y revisión de conformidad con
las especificaciones, planes, normas y estándares.

Inspección
o Guiada por un moderador capacitado (no el autor)
o Dirigida normalmente como una exanimación hecha por expertos
o Funciones definidas
o Incluye recopilación de métricas
 o Proceso formal basado en normas y listas
o Criterios de entrada y salida determinados para la aceptación del producto
software
o Preparación de pre-reuniones
o Reporte de inspección que incluya una lista de resultados
o Proceso formal de seguimiento ( con componentes opcionales de procesos
de perfeccionamiento)
o Lector opcional
o Propósito principal: encontrar defectos

Los recorridos, revisiones técnicas e inspecciones se pueden desarrollar en un grupo de

colegas, es decir, colegas del mismo nivel organizacional. Este tipo de revisión se denomina
“revisión entre colegas”.

3.2.4 Los factores de éxito para la revisión (K2)

Los factores de éxito para la revisión incluyen:
o Cada revisión tiene objetivos claramente predefinidos
o Participación de la gente apropiada para los objetivos de revisión
o Los probadores se consideran revisores que contribuyen a la revisión y además
aprenden del producto, lo que les permite preparar pruebas con anticipación
o Los defectos encontrados se presentados y expresados objetivamente
o se tratan los problemas del personal y aspectos psicológicos ( por ejemplo, hacer
que sea una experiencia positiva para el autor)
o la revisión se realiza en un ambiente de confianza, el resultado no se utilizara para
la evaluación de participantes
o Se aplican las técnicas de revisión que sean pertinentes para lograr los objetivos y
al tipo y nivel de productos software de trabajo y revisores
o Se utilizan listas o funciones si es apropiado para incrementar la efectividad en la
identificación de defectos
o Se da capacitación en las técnicas de revisión, especialmente en las técnicas más
formales como la inspección
o La gerencia apoya un buen proceso de revisión (por ejemplo, la incorporación de
tiempo adecuado para actividades de revisión en programas de proyecto)
o Existe un énfasis en el aprendizaje y proceso de perfeccionamiento

3.3 Análisis Estático con Herramientas (K2) 20 minutes

Términos
Compilador, complejidad, flujo de control, flujo de datos, análisis estático
Antecedentes
El objetivo del análisis estático es encontrar defectos en el código fuente de software y
modelos software. El análisis estático se desarrolla sin realmente ejecutar el software que
está examinando la herramienta; las pruebas dinámicas ejecutan el código del software. El
análisis estático puede localizar los defectos que son difíciles de encontrar en las pruebas
dinámicas. Al igual que en las revisiones, el análisis estático encuentra defectos en lugar de
fallas. Las herramientas del análisis estático analizan el código del programa (por ejemplo,
flujo de control y flujo de datos), así como mensajes generadas como HTML y XML.

El valor del análisis estático es:

o Detección temprana de defectos antes de ejecutar la prueba
o Advertencia temprana sobre aspectos sospechosos del código o diseño por
el cálculo de métricas, como una medida de alta complejidad
o Identificación de defectos que no se encuentran fácilmente en las pruebas
dinámicas
o Detectar dependencias e inconsistencias en los modelos software como
vínculos
o Mantenimiento perfeccionado del código y diseño
o Prevención de defectos, si se aprenden lecciones en la etapa de desarrollo

Los Defectos comunes que descubre el análisis estático incluyen lo siguiente:

o Referencia de una variable con un valor no definido
o Interfaces inconsistentes entre módulos y componentes
o Variables que no se utilizan o se declaran inapropiadamente
o Código faltante o erróneo ( circuitos potencialmente infinitos)
o Construcciones demasiado complicadas
o Violaciones de las normas de programación
o Vulnerabilidades de seguridad
o Errores de sintaxis del código y modelos software

Las herramientas del análisis estático se utilizan comúnmente por parte de desarrolladores
(revisión en contraste con normas predefinidas o estándares de programación) antes y
durante las pruebas del componente e integración o cuando se ingresa el código a las
herramientas de manejo del configuración y por parte de los diseñadores durante la
formación del software. Las herramientas del análisis estático pueden producir un gran
número de mensajes de advertencia que necesitan manejarse correctamente que permita
el uso más efectivo de la herramienta.

Los compiladores pueden ofrecer soporte en al análisis estático, incluyendo el cálculo de

métricas
Referencias
3.2 IEEE 1028
3.2.2 Gilb, 1993, van Veenendaal, 2004
3.2.4 Gilb, 1993, IEEE 1028
3.3 van Veenendaal, 2004
4. Técnicas de diseño de Prueba (K4) 285 Minutos

Objetivos de Estudio para técnicas de diseño de prueba

Los objetivos identifican lo que se podrá hacer tras la finalización de cada modulo

4.1 Proceso de desarrollo de testing (K3)

LO-4.1.1 Establecer la diferencia entre una especificación de diseño de prueba,
especificación de caso de prueba y especificación de procedimiento de
prueba (K2)
LO-4.1.2 Comparar los términos condiciones de prueba, caso de prueba y
procedimiento de prueba (K2)
LO-4.1.3 Evaluar la calidad de los casos de pruebas en términos de una clara
trazabilidad de requisitos y resultados esperados
LO-4.1.4 Transformar casos de pruebas en una especificación de procedimiento de
prueba bien estructurado a un nivel adecuado detalle pertinente al
conocimiento de los probadores (K3)

4.2 Categorías de las Técnicas de Diseño de Prueba (K2)

LO-4.2.1 Recordar las razones por las cuales las técnicas de diseño de testing basadas
en especificaciones (caja negra) y basadas en estructuras (caja blanca) son
útiles y nombrar las técnicas comunes para cada una (K1)
LO-4.2.2 Explicar las características, semejanzas y diferencias entre pruebas basadas
en especificaciones, pruebas basadas en estructuras y pruebas basadas en
experiencia (K2)

4.3 Técnicas basadas en especificaciones o Caja negra (K3)

LO-4.3.1 Redactar casos de pruebas a partir de los modelos del software
proporcionados utilizando una división equivalente, análisis de valor límite,
tablas de decisión y diagramas / tablas de transición de estado. (K3)
LO-4.3.2 Explicar el propósito principal de cada una de las cuatro técnicas de testing,
que nivel y tipo de prueba podría utilizar la técnica, y como se puede medir
la cobertura (K2)
LO-4.3.3 Explicar el concepto de pruebas de casos de uso y sus beneficios

4.4 Técnicas basadas en estructuras o Caja Blanca

LO-4.4.1 Describir el concepto y valor de la cobertura de código (K2)
LO-4.4.2 Explicar los conceptos de cobertura de estado y decisiones y dar razones por
las cuales estos conceptos también se pueden utilizar a niveles de prueba en
lugar de pruebas del componente (por ejemplo, sobre procedimientos
empresariales en el nivel del sistema (K2)
LO-4.4.3 Redactar casos de prueba a partir de flujos de control proporcionados
utilizando técnicas de diseño de pruebas de estado y decisión (K3)
LO-4.4.4 Cobertura de estado y decisión para totalidad respecto a los criterios de salida
definidos

4.5 Técnicas basadas en Experiencia (K2)

LO-4.5.1 Recordar los motivos para escribir los casos de pruebas basados en la
intuición, experiencia y conocimiento respecto a defectos comunes (K1)
LO-4.5.2 Comparar las técnicas basadas en experiencia con técnicas de pruebas
basadas en especificaciones
4.6 Selección de Técnicas de Prueba (K2)
LO-4.6.1 Clasificar las técnicas de diseño de acuerdo a sus capacidades en un contexto
determinado, para las bases de pruebas modelos y características de
software respectivos (K2)

4.1 El Proceso de Desarrollo de Prueba(K3) 15 minutos

Términos
Especificación de caso de pruebas, diseño de prueba, programación de ejecución de prueba,
especificación del procedimiento de prueba, script de prueba, trazabilidad.

Antecedentes
El Proceso de desarrollo de prueba descrito en esta sección se puede realizar de diferentes
maneras, a partir de una manera informal con poca o ningún tipo de documentación a muy
formal (tal como se describe más adelante). El nivel de formalidad depende del contexto de
la prueba, que incluye la madurez de la prueba y procesos de desarrollo, limitaciones de
tiempo, requisitos de seguridad o normativos y personas involucradas.

Durante los análisis de prueba, se analiza la documentación de bases de prueba para

determinar que se debe probar, es decir identificar las condiciones de prueba. Una condición
de prueba se define como un elemento o caso que se podría verificar por uno o más casos
de prueba (por ejemplo, una función, transacción, elemento de calidad de característica o
estructural).

El establecimiento de trazabilidad a partir de las condiciones de prueba nuevamente a las

especificaciones y requisitos permite un análisis de impacto efectivo cuando cambian los
requisitos y se determina la cobertura de requisitos en un conjunto de pruebas. En un
análisis de prueba se implementa un enfoque de prueba detallado con el fin de escoger las
técnicas de diseño de pruebas a utilizar, basadas, entre otras en consideraciones, riesgos
identificados (ver capítulo 5 para más información sobre análisis de riesgo).

En el diseño de prueba se crean y especifican los casos de prueba y datos de prueba. Un

caso de prueba consiste en un conjunto de valores de entrada, precondiciones de ejecución,
resultados esperados y post condiciones de ejecución, definida que cubra ciertos objetivos
de prueba o condiciones de pruebas. El Estándar para la Documentación de Prueba de
Software (Standard for Software Test Documentation’) (IEEE STD 829-1998) describe el
contenido de las especificaciones de diseño de prueba (que contienen condiciones de
prueba) y especificaciones de casos de prueba.

Los resultados esperados se deben producir como parte de la especificación de un caso de

prueba e incluir salidas, cambios a la información y estados, y otras consecuencias de la
prueba. Si no se han definido los resultados esperados, un resultado plausible, pero erróneo,
se puede interpretar como correcto. Los resultados deben definirse preferiblemente antes
de la ejecución de la prueba.
En la implementación de la prueba, se desarrollan, implementan, se da prioridad y se
organizan los casos de prueba en la especificación de procedimiento de prueba (IEEE STD
829-1998). El procedimiento de prueba específica la secuencia de acciones para la ejecución
de una prueba. Si una prueba se realiza con una herramienta de ejecución de prueba, se
especifica la secuencia de acciones en un script de prueba (que es un procedimiento de
prueba automatizado).

Varios de los procedimientos de prueba y script de prueba automatizados posteriormente

formados en un programa de ejecución de prueba que define el orden en el cual se ejecutan
varios procedimientos de prueba y posibles scripts de prueba automatizados. El programa
de ejecución de prueba tomara en cuenta dichos factores como pruebas de regresión,
prioridad y dependencias técnicas y lógicas.

4.2 Categorías de las Técnicas de Diseño de Pruebas 15 Minutos

(K2)

Términos
Técnica de diseño de prueba de caja negra, experiencia basada en técnicas de diseño de
pruebas, técnica de diseño o de prueba, técnica de diseño de prueba de caja blanca.

Antecedentes
El propósito de una técnica de diseño de prueba es identificar condiciones de prueba, casos
de prueba y datos de prueba.

Es una distinción clásica que señala técnicas de prueba como caja negra y caja blanca. Las
técnicas de diseño de prueba de caja negra (también denominada técnicas basadas en
especificación) son una forma de derivar y seleccionar condiciones de prueba, casos de
prueba o datos de prueba en un análisis de documentación de bases de prueba. Lo anterior
incluye pruebas funcionales y no funcionales. Las pruebas de caja negra (Black-box testing),
por definición, no utiliza ningún tipo de información respecto a la estructura interna del
componente o sistema que debe probarse. Las técnicas de diseño de prueba (también
denominadas técnicas estructurales o basadas en estructura) se basan en un análisis de la
estructura del componente o sistema. Las pruebas de caja negra y blanca (Black-box and
White-box testing) también pueden combinarse con técnicas basadas en experiencia para
así tomar ventaja de la experiencia de desarrolladores, probadores y usuarios para
determinar lo de se debe probar.

Algunas técnicas claramente caen en una sola categoría; otras tienen elementos de más de
una categoría.

Este programa se refiere a las técnicas de diseño de prueba basadas en especificaciones

como técnicas de caja negra y técnicas de diseño de prueba basadas en estructuras como
técnicas de caja blanca. Adicionalmente, se cubren las técnicas de diseño de pruebas
basadas en experiencia.
Las características comunes de las técnicas de diseño de pruebas basadas en la
especificación incluyen lo siguiente:
o Modelos formales o informales, se utilizan para la especificación del problema a
resolver, el software o sus componentes
o Se pueden derivar los casos de prueba sistemáticamente de estos modelos

Las características comunes de las técnicas de diseño de prueba basadas en la estructura

incluyen lo siguiente:
o La información de cómo se construye el software se utiliza para derivar los casos
de prueba (por ejemplo, el código e información detallada de diseño)
o El grado de cobertura del software se puede medir para los casos de prueba
vigentes y los casos de pruebas adicionales pueden derivarse sistemáticamente
para aumentar el cubrimiento

Las características comunes de las técnicas de diseño de prueba basadas en la experiencia

incluyen lo siguiente:
o El conocimiento y experiencia de la gente se utiliza para derivar los casos de
pruebas
o Es una fuente de información el conocimiento de probadores, desarrolladores
usuarios y otras partes interesadas respecto al software, su uso y entorno
o Otra fuente de información es conocer los probables defectos y su distribución

4.3 Técnicas basadas en la especificación o 150 minutos

Caja negra (K3)

Términos
Análisis de valor límite, testing de tablas de decisión, división de equivalencia, pruebas de
transición de estado pruebas de casos de uso.

4.3.1 División de Equivalencia (K3)

En la división de equivalencia, las entradas al software o sistema se dividen en grupos que
se espera muestren un comportamiento similar, así que se deben procesar de la misma
manera. Las divisiones de equivalencia (o clases) pueden encontrarse para información
valida, es decir, valores que deben aceptarse y datos inválidos, y los valores que deben
rechazarse. También se pueden identificar las divisiones para salidas, valores internos,
valores relacionados con el tiempo (por ejemplo, antes y después de un caso) y para los
parámetros de interface (por ejemplo, componentes integrados que se están probando
durante el testing de integración). Se pueden diseñar pruebas que cubran todas las
divisiones validas e invalidas. Las divisiones de equivalencia son pertinentes en todos los
niveles de pruebas.
La división de equivalencia se puede utilizar para lograr los objetivos de cobertura de entrada
y salida. Se puede aplicar al aporte humano, entrada por interfaces a un sistema o
parámetros de interface en pruebas de integración.

4.3.2 Análisis de Valor Limite (K3)

El comportamiento al límite de cada división de equivalencia es más probable que sea
incorrecta que el comportamiento dentro de la división de manera tal que los limites son
una área donde las pruebas probablemente produzcan defectos. Los valores máximos y
mínimos de una división son sus valores límite. Un valor límite para una división valida es
un valor límite valido; el límite de una división inválida es un valor límite inválido. Se pueden
diseñar las pruebas para cubrir valores límites validos e inválidos. Cuando se diseñan casos
de pruebas, se elige una prueba para cada valor límite.

El análisis de valor límite se puede aplicar en todos los niveles de prueba. Es relativamente
fácil de aplicar y su capacidad de encontrar defectos es alta. Las especificaciones detalladas
son útiles en la determinación de límites interesantes.

Frecuentemente se considera esta técnica como una extensión de división de equivalencia

u otras técnicas de diseño de prueba de caja negra. Se puede utilizar en clases de
equivalencia para el ingreso del usuario en la pantalla así como por ejemplo en periodos de
prueba (por ejemplo, tiempo de espera, requisitos de velocidad transaccional) o clasificación
de tablas (por ejemplo, tamaño de tablas es de 256*256)

4.3.3 Pruebas de Tablas de Decisión (K3)

Las tablas de decisión son una buena manera de capturar los requisitos del sistema que
contienen condiciones lógicas y documentar el diseño del sistema interno. Se pueden utilizar
para registrar normas empresariales complejas que debe implementar un sistema. Cuando
se crean tablas de decisión, se analiza la especificación y se identifican las condiciones y
acciones del sistema. Las condiciones y acciones de ingreso se indican comúnmente de
forman que sean verdaderas o falsas (Boolean). La tabla de decisión contiene las
condiciones de activación, frecuentemente combinaciones de falso y verdadero para todas
las condiciones de ingreso acciones resultantes en cada combinación de condiciones. Cada
columna de la tabla corresponde a una norma empresarial que define una combinación
única de condiciones y que resulta en la ejecución de acciones

asociadas con dicha norma. La cobertura estándar utilizada comúnmente con las pruebas
de tabla de decisión debe tener por lo menos una prueba por columna en la tabla que
normalmente involucra la cobertura de todas las combinaciones de las condiciones de
activación.

La fortaleza de las pruebas de tabla de decisión genera combinaciones de las condiciones

que de otra manera no podrían haberse ejercido durante la prueba. Se puede aplicar en
todas las situaciones cuando la acción del software depende de varias decisiones lógicas.

4.3.4 Pruebas de Transición de Estado

Un sistema puede presentar distintas respuestas dependiendo de las condiciones vigentes
o historia anterior (su estado). En este caso, el aspecto del sistema puede mostrarse con
un diagrama de transición de estado. Le permite al probador observar el sistema en términos
de sus estados, transiciones entre estados, ingresos o casos que activan los cambios de
estado (transiciones) y las acciones que puedan resultar de aquellas transiciones. Los
estados del sistema u objetos con forma la prueba se dan por separado, son identificables
y en números finitos.

Una tabla de estado muestra la relación entre los estados e ingresos y pueden resaltar las
posibles transiciones que sean inválidas.

Se pueden diseñar pruebas que cubran una secuencia normal de estados, todos los estados,
que ejerzan todas las transiciones, secuencias específicas de transiciones o que prueben
transiciones inválidas.

Se utilizan demasiado las pruebas de transición dentro de la industria del software integrado
y automatización técnica en general. Sin embargo, la técnica también es adecuada para la
formación de un objeto de negocio que tenga estados específicos o probar flujos de dialogo
de pantallas (por ejemplo, en aplicaciones de internet o escenarios empresariales).

4.3.5 Pruebas de Caso de Uso (K2)

Se pueden derivar las pruebas de los casos de uso. Caso de use describe las interacciones
entre los actores (usuarios o sistemas) que producen un resultado del valor al usuario del
sistema o el cliente. Se pueden describir los casos de uso a un nivel abstracto (caso de uso
empresarial, technology-free, nivel de proceso empresarial) o a nivel del sistema (caso de
uso del sistema en el nivel de funcionalidad del sistema). Cada caso de uso tiene requisitos
que necesitan cumplirse para que el caso de uso funcione exitosamente. Cada caso de uso
termina con post condiciones que son los resultados visibles y estado final del sistema
después de haberse completado el caso de uso. Un caso de uso generalmente tiene una
escenario principal (es decir, muy probable) y escenarios alternativos.

Los casos de uso describen los “flujos de procesos” por medio de un sistema basado en su
posible uso real, de manera que los casos de prueba derivados de los casos de uso, son
más útiles en descubrir defectos en los flujos de proceso durante el uso del sistema en el
mundo real. Los casos de uso son muy útiles para el diseño de pruebas de aceptación con
la participación del cliente / usuario. También ayudan a descubrir defectos de integración
causados por la interacción e interferencia de distintos componentes, que no podría ver una
prueba del componente.
El diseño de casos de prueba a partir de casos de uso se puede combinar con otras técnicas
de prueba basadas en la especificación.
4.4 Técnicas basadas en la estructura o de 60 minutos
Caja blanca (K4)

Términos
Cubrimiento de código, cubrimiento de decisión, cubrimiento de instrucciones, pruebas
basadas en la estructura

Antecedentes
Las pruebas basadas en la estructura o de Caja blanca se basan en una estructura identificas
del software o del sistema, tal como se observa en los siguientes ejemplos:
o Nivel del componente: la estructura de un componente software, es decir,
instrucciones, decisiones, sedes o incluso distintos modelos
o Nivel de integración: la estructura puede ser un call tree ( un diagrama en los
cuales los módulos se comunican con otros módulos )
o Nivel del sistema: la estructura puede ser una estructura del menú, proceso
comercial o estructura de página web

En esta sección se discuten tres técnicas de diseño de prueba de relacionado con el código
para en cubrimiento de código, basadas en instrucciones sedes y decisiones. Para las
pruebas de decisión, se puede utilizar un diagrama de flujo de control para visualizar las
alternativas de cada decisión.

4.4.1 Pruebas y cobertura de instrucciones (K4)

En las pruebas del componente, la cobertura de instrucción es la evaluación del porcentaje
de las instrucciones ejecutables que un conjunto de casos de prueba han ejercido. La técnica
de pruebas de instrucción deriva casos de prueba que ejecuten instrucciones específicas,
normalmente que aumenten el cubrimiento de instrucción

Se determina el cubrimiento de instrucción por el número de instrucciones ejecutables que

cubren (diseñan o ejecutan) los casos de prueba divididas por el número de instrucciones
ejecutables en el código conforme la prueba.

4.4.2 Pruebas de Decisión y Cobertura (K4)

EL cubrimiento de decisión relacionado con las pruebas branch (sede), es la evaluación del
porcentaje de resultados de decisión (por ejemplo, opciones de Falso y Verdadero de una
evaluación IF) que un conjunto de pruebas han ejercido. La técnica de pruebas de decisión
deriva casos de prueba que ejecutan resultados de decisión específica. Branches se origina
de los puntos de decisión en código y muestran la transferencia de control a diferentes
ubicaciones en el código.

La cobertura de decisión se determina por el número de todos los resultados de decisión

cubiertos (diseñados o ejecutados) por los casos de prueba que se dividen por el número
de todos los resultados de decisión posibles en el código conforme la prueba.
Las pruebas de decisión son una forma de prueba de flujo de control ya que sigue un flujo
de control por medio de los puntos de decisión. El cubrimiento de decisión es más fuerte
que el cubrimiento de instrucción; el 100% de cubrimiento de decisión garantiza un 100%
de cubrimiento de instrucción, pero no viceversa.

4.4.3 Otras Técnicas basadas en la Estructura (K1)

Existen mayores niveles de cobertura estructural que van más allá de la cobertura de
decisión, por ejemplo, cobertura de condición y múltiple cobertura de condición.

También se puede aplicar el concepto de cobertura en otros niveles de prueba. Por ejemplo,
a nivel de integración, el porcentaje de modulos, components o clases que se han ejercido
por un conjunto de caso de pruebas se podría expresar como modulo, componente o
cobertura de clase.

La herramienta de soporte es útil para las pruebas estructurales del código.

4.5 Técnicas Basadas en la experiencia (K2) 30 Minutos

Términos
Testing exploratorio, (falla) ataque

Antecedentes
En las pruebas basadas en la experiencia se derivan pruebas de la capacidad e intuición del
probador así como su experiencia con aplicaciones y tecnologías similares. Cuando se
aumentaban las técnicas sistemáticas, dichas técnicas pueden ser útiles en la identificación
de pruebas especiales que no se capturan fácilmente por parte de las técnicas formales,
especialmente cuando se aplican después de enfoques más formales. Sin embargo, esta
técnica puede ceder ampliamente variando los grados de efectividad, dependiendo de la
experiencia del probador.

Una técnica basada en la experiencia normalmente utilizada, es un error guessing (método

de prueba en el cual se utilizan casos de prueba para encontrar virus en programas
establecidos basados en la experiencia en pruebas anteriores). Generalmente los
probadores anticipan defectos basándose en la experiencia. Un enfoque estructurado a la
técnica de error guessing es enumerar una lista de posibles defectos y diseñar pruebas que
ataquen estos defectos. Este enfoque sistemático se denomina fault attack. Estas listas de
defectos y fallas se pueden construir basadas en la experiencia, información disponible sobre
defectos y fallas y de conocimiento común de las razones por las que falla el software.

Las pruebas exploratorias son un diseño de prueba concurrente, ejecución de prueba, test
logging, y aprendizaje, basado en un test charter que contenga objetivos de prueba y se
llevan a cabo en espacios de tiempo. Es un enfoque que es útil donde haya especificaciones
pocas o inadecuadas y fuerte presión de tiempo o con el fin de aumentar o complementar
otras pruebas más formales. Pueden servir estas pruebas para controlar el proceso de
prueba que ayude a garantizar que se encuentren los defectos más graves.
4.6 Selección de Técnicas de Prueba (K2) 15 minutos

Términos
No hay términos específicos

Antecedentes
La elección de cuales técnicas de prueba se deben utilizar, depende de un numero de
factores que incluyen el tipo de sistema, estándares normativos, requisitos del cliente o
contractuales, nivel de riesgo, tipo de riesgo, objetivo de prueba, documentación disponible,
conocimiento de los probadores, tiempo y presupuesto, ciclo de vida del desarrollo, modelos
de caso de uso y experiencia previa con tipos de defectos encontrados.

Algunas técnicas son más aplicables en algunas situaciones y niveles de prueba; otras son
aplicables a todos los niveles de prueba.

Cuando se crean casos de prueba, los probadores generalmente utilizan una combinación
de técnicas de prueba incluyendo técnicas de proceso, normas y basadas en datos que
garanticen un cubrimiento adecuado del objeto conforme la prueba.

Referencias
4.1 Craig, 2002, Hetzel, 1988, IEEE STD 829-1998 4.2 Beizer, 1990, Copeland, 2004
4.3.1 Copeland, 2004, Myers, 1979
4.3.2 Copeland, 2004, Myers, 1979
4.3.3 Beizer, 1990, Copeland, 2004
4.3.4 Beizer, 1990, Copeland, 2004
4.3.5 Copeland, 2004
4.4.3 Beizer, 1990, Copeland, 2004 4.5 Kaner,
2002
4.6 Beizer, 1990, Copeland, 2004

5. Manejo de Prueba (K3) 170 minutos

Objetivos de Estudio para el Manejo de Prueba

5.1 Organización de Prueba (K2)

LO-5.1.1 Reconocer la importancia de pruebas independientes (K1)
LO-5.1.2 Explicar los beneficios e inconvenientes de pruebas independientes en una
organización (K2)
LO-5.1.3 Reconocer los distintos miembros del equipo para tenerlos en cuenta en la
creación de un equipo de prueba (K1)
LO-5.1.4 Recordar las tareas de un líder y probador común (K1)

5.2 Planeación y Cálculo de Prueba (K3)

LO-5.2.1 Reconocer los distintos niveles y objetivos de la planeación de prueba (k1)
LO-5.2.2 Resumir el propósito y contenido del plan de prueba, especificación de diseño
 de prueba y documentos de procedimiento de prueba de acuerdo al Estándar
para Documentación de Software de Prueba (IEEE Std 829-1998) (K2)
LO-5.2.3 Establecer la diferencia entre los enfoques de prueba conceptualmente
diferentes como lo es el analítico, basado en modelos, metódico,
proceso/estándar, dinámico/ heurístico, consultivo y contrario a regresión
(K2)
LO-5.2.4 Establecer la diferencia entre el objeto de la planeación de prueba en un
sistema y ejecución de programación de pruebas (K2)
LO-5.2.5 Redactar un programa de ejecución e prueba para un conjunto de casos de
pruebas, teniendo en cuenta la prioridad y dependencias técnicas y lógicas
(K3)
LO-5.2.6 Hacer una lista de preparación de pruebas y actividades de ejecución que
deben tenerse en cuenta durante la planeación de pruebas (K1)
LO-5.2.7 Recordar factores comunes que tienen influencia en el esfuerzo relacionado
con pruebas (K1)
LO-5.2.8 Establecer la diferencia entre dos enfoques de cálculos conceptualmente
diferentes: el enfoque basado en métricas y el enfoque basado en expertos
(K2)
LO-5.2.9 Reconocer / justificar criterios adecuados de entrada y salida en niveles
específicos de prueba y grupos de casos de prueba (por ejemplo, en pruebas
de integración, pruebas de aceptación o casos de prueba en pruebas de uso)
(K2)
5.3 Seguimiento y Control del Progreso de Prueba (2)
LO-5.3.1 Recordar las métricas comunes utilizadas para hacer seguimiento de la
preparación y ejecución de pruebas (K1)
LO-5.3.2 Explicar y comparar métricas de prueba para reportar pruebas y control
pruebas (por ejemplo, defectos encontrados y solucionados, pruebas
aprobadas y perdidas) relacionado al propósito y uso (K2)
LO-5.3.3 Resumir el propósito y contenido del documento resumen del reporte de
prueba de acuerdo al “Standard for Software Test Documentation’ (IEEE Std
829-1998) (K2)
5.4 Manejo de configuración (K2)
LO-5.4.1 Resumir como el manejo de configuración respalda las pruebas (K2)

5.5 Riesgo y Pruebas (K2)

LO-5.5.1 Describir un riesgo como un posible problema que podría amenazar el logro
de uno o más objetivos del proyecto de la partes interesadas (K2)
LO-5.5.2 Recordar que el nivel de riesgo se determina por probabilidad (que pueda
suceder) e impacto (daños que resulten en caso de suceder) (K1)
LO-5.5.3 Establecer la diferencia entre los riesgos del proyecto y producto (K1)
LO-5.5.4 Reconocer los riesgos comunes del producto y proyecto (K2)
LO-5.5.5 Describir con ejemplos como se puede utilizar el análisis de riesgo y manejo
de riesgo en la planeación de pruebas.
5.6 Manejo de Incidentes (K3)
LO-5.6.1 Reconocer el contenido de un reporte de incidentes de acuerdo al Standard
for Software Test Documentation’ (IEEE Std 829-1998) (K1)
LO-5.6.2 Redactar un reporte de incidentes que cubran la observación de una falla
durante la prueba (K3)
5.1 Organización de Pruebas (K2) 30 minutos

Términos
Probador, líder de pruebas, gerente de pruebas

5.1.1 Organización e independencia de Prueba (K2)

La efectividad en encontrar defectos por medio de pruebas y revisiones se puede mejorar
con el uso de probadores independientes. Las opciones de independencia incluyen lo
siguiente:
o No hay probadores independientes, desarrolladores prueban su propio código
o Probadores independientes en equipos de desarrollo
o Un equipo de prueba independiente o un grupo en la organización que le reporte a
la gerencia del proyecto o gerencia ejecutiva.
o Probadores independientes a partir de la organización empresarial o comunidad del
usuario
o Especialistas de prueba independiente en tipos específicos de pruebas como
probadores de uso, probadores de seguridad o probadores de certificación (quienes
certifican un producto software en relación a los estándares y normas)
o Probadores independientes contratados o externos a la organización

En proyectos grandes, complejos o críticos para la seguridad, es mucho mejor tener niveles
múltiples de pruebas con algunos o todos los niveles que realizaron probadores
independientes. El personal de desarrollo podrá participar en las pruebas, especialmente en
niveles inferiores, pero la falta de objetividad frecuentemente limita su efectividad. Los
probadores independientes tendrán la autoridad de solicitar definir procesos de prueba y
normas, pero deben asumir funciones relacionadas con el proceso únicamente en la
presencia de un claro mandado de gerencia.

Los beneficios de independencia incluyen lo siguiente:

o Los probadores independientes ven otros y distintos defectos que son imparciales
o Un probador independiente puede verificar suposiciones que han hecho personas
durante la especificación e implementación del sistema

Las desventajas incluyen lo siguiente:

o Aislamiento del equipo de desarrollo ( si se trata como independencia total)
o Los desarrolladores podrían perder el sentido de responsabilidad en cuanto
a la calidad
o Los probadores independientes pueden verse como obstáculos o ser
culpables por retrasos en el lanzamiento.

Las tareas de prueba se pueden realizar por personas con una función de prueba específica,
u otra persona que desempeñe otra función como un gerente de proyecto, gerente de
calidad, desarrollador, un experto en negocios y en el sector, infraestructura u operaciones
IT.

5.1.2 Tareas de un Lider de Pruebas y Probador (K1)

En este programa se cubren dos puestos de prueba, líder de pruebas y probador. Las
actividades y tareas que realizan personal en estas dos funciones dependen del contexto
del proyecto y producto, el personal en distintas funciones y la organización.

Algunas veces se le denomina a un líder de prueba un gerente de prueba o coordinador de

prueba. La función del líder de pruebas puede desarrollarse por un gerente de proyectos,
gerente de desarrollo, gerente de garantía de calidad o el gerente de un grupo de prueba.
En grupos más grandes, pueden haber dos puestos de trabajo: líder de pruebas y gerente
de pruebas. Comúnmente el líder planea, monitorea y controla las actividades de pruebas y
tareas como se define en la sección 1.4.

Las tareas comunes de un líder de prueba son las siguientes:

o Coordinar la estrategia de pruebas y realizar planeación con gerentes de proyectos
y otras personas
o Redactar o revisar una estrategia de pruebas en el proyecto así como una política
de pruebas en la organización.
o Contribuir la perspectiva de pruebas a otras actividades del proyecto como la
planeación de integración
o Planear pruebas teniendo en cuenta el contexto y comprendiendo los objetivos de
las pruebas y riesgos que incluyen la selección de enfoques de prueba, calculando
el tiempo, esfuerzo y costo de las pruebas, adquiriendo recursos, definiendo niveles
y ciclos de prueba y planeación en la gestión de incidentes
o Iniciar la especificación, preparación, implementación y ejecución de pruebas,
monitorear los resultados de las prueba y revisar los criterios de salida
o Adaptar la planeación basada en los resultados de las pruebas y su progreso (que
algunas veces se documentan en los reportes de estados) y tomar las medidas
necesarias para compensar problemas causados.
o Configurar un manejo de configuración adecuado de testware para trazabilidad
o Presentar métricas apropiadas para la medición del progreso de las pruebas y
evaluación de calidad de las pruebas y el producto
o Decidir lo que se debe automatizar, a que grado y como
o Seleccionar herramientas que respalden las pruebas y organizar capacitaciones en
el uso de herramientas para probadores
o Decidir la implementación del entorno de las pruebas
o Redactar reportes resumido de pruebas basados en la información recopilada en el
proceso de pruebas

Las tareas más comunes de un probador son las siguientes:

o Revisar y contribuir planes de prueba
 o Analizar, revisar y evaluar requisitos, especificaciones y modelos para testabilidad-
comprobabilidad
o Crear especificaciones de prueba
o Configurar el ambiente de prueba (frecuentemente coordinar la administración del
sistema y manejo de la red)
o Preparar y adquirir datos de prueba
o Implementar pruebas en todos los niveles, ejecutar y registrar pruebas, evaluar los
resultados y documentar desviaciones de los resultados esperados
o Utilizar administración de pruebas o herramientas de gestión y se requiere un
monitoreo de pruebas
o Automatizar pruebas (pueden respaldarse por un desarrollador o un experto en
automatización de pruebas)
o Medir el desempeño de los componentes y el sistema (si corresponde)
o Revisar pruebas desarrolladas por otras

La gente que trabaja en análisis de pruebas, diseño de pruebas, tipos de pruebas específicos
o automatización de pruebas, pueden ser especialistas en estas funciones. Dependiendo del
nivel de prueba y los riesgos relacionados con el producto y el proyecto, distintas personas
pueden asumir la función de probadores, manteniendo el grado de independencia.
Comúnmente, los probadores en niveles del componente e integración seria desarrolladores,
probadores en el nivel de aceptación seria experto en negocios y usuarios y probador para
pruebas de aceptación operativa serian operadores

5.2 Planeación de Pruebas y Calculo (K3) 40 minutos

Términos
Enfoque de pruebas, estrategia de pruebas

5.2.1 Planeación de Pruebas (K2)

Esta sección cubre el propósito de planeación de pruebas dentro de proyectos de
desarrollo e implementación y actividades de mantenimiento. Se puede
documentar la planeación en un plan de prueba maestro y en planes de prueba
por separado en niveles de prueba como pruebas del sistema y de aceptación. El
resumen de un documento de planeación de prueba se cubre por parte del
‘Standard for Software Test Documentation’ (IEEE Std 829-1998).

La planeación está bajo la influencia de la política de prueba de la organización, el

alcance de pruebas, objetivos, riesgos, limitaciones, criticidad, comprobabilidad y
disponibilidad de recursos. A medida que progresan el proyecto y planeación de
prueba, hay más información disponible y más detalles que se pueden incluir en el
plan.
Esta planeación es una actividad continua y se desarrolla en los procesos del ciclo
de vida y actividades. Se utiliza la retroalimentación de actividades de prueba para
reconocer evolución de riesgos de manera que se pueda ajustar la planeación.

5.2.2 Actividades planeación de pruebas (K3)

En todo un sistema o parte de un sistema se puede incluir en estas actividades:
o Determinación del alcance y riesgos e identificación de los objetivos de pruebas
o Definición de todo el enfoque de pruebas, que incluye la definición de niveles de
prueba y criterios de entrada y salida
o Integración y coordinación de las actividades de prueba en las actividades del ciclo
de vida del software (adquisición, suministro, desarrollo, operación y
mantenimiento)
o Toma de decisiones de lo que se debe probar, que funciones desarrollaran las
actividades de prueba, como se deben desarrollar las actividades y como se
evaluaran los resultados de la prueba
o Programación de los análisis de prueba y actividades de diseño
o Programación de implementación, ejecución y evaluación de la prueba
o Asignación de recursos en distintas actividades ya definidas
o Definición de la cantidad, nivel de detalle, estructura y plantillas para la
documentación de la prueba
o Selección de métricas en el monitoreo y control de la preparación y ejecución de la
prueba, solución de defectos y situaciones de riesgo
o Configuración del nivel de detalles de procedimientos de la prueba con el fin de
suministrar suficiente información que respalde la preparación y ejecución
reproducible de prueba

5.2.3 Criterios de entrada (K2)

Definen cuando iniciar las pruebas al principio de un nivel de prueba o cuando está listo un
conjunto de pruebas
Comúnmente estos criterios podrán cubrir lo siguiente:
o Disponibilidad y preparación del entorno de la prueba
o Preparación de herramienta de prueba en el entorno de la misma
o Disponibilidad del código que se puede probar
o Disponibilidad de datos de prueba

5.2.4 Criterios de salida (K2)

Definen cuando detener las pruebas al final de un nivel de prueba cuando han logrado un
objetivo específico un conjunto de pruebas

Comúnmente estos criterios podrán cubrir lo siguiente:

o Medidas rigurosas, como el cubrimiento del código, funcionalidad o riesgo
o Calculo de la densidad de defectos o medidas de confiabilidad
o Costos
o Riesgos residuales, como defectos sin solucionar o falta de cubrimiento de
la prueba en algunas áreas
o Programaciones como las que se basan en mercado en tiempo real
5.2.5 Calculo de la Prueba (K2)
Los siguientes son dos enfoques en el cálculo de una prueba:
o El enfoque basado en métricas: cálculo de esfuerzo de pruebas basado en
métricas de proyectos antiguos o similares o valores comunes
o Enfoque basado en recomendaciones expertas: cálculo de tareas basándose
en caculos hechos por parte del propietario de tareas o expertos

Una vez se calcule el esfuerzo de la prueba, se pueden identificar los recursos y elaborar
una programación

Este esfuerzo podrá depender de un número de factores que incluyen lo siguiente:

o Características del producto: la calidad de la especificación y otra información
utilizada en los modelos de la prueba (bases de la prueba), el tamaño del producto,
la complejidad del dominio del problema, los requisitos de confiabilidad y seguridad
y los requisito para documentación
o Características del proceso de desarrollo: la estabilidad de la organización,
herramientas utilizadas, proceso de la prueba, destrezas de la gente involucrada y
presión de tiempo
o El resultado de la prueba: el número de defectos y la cantidad de revisión requerida

5.2.6 Estrategia de la Prueba, Enfoque de la Prueba (K2)

El enfoque de la prueba es la implementación de la estrategia de la prueba en un proyecto
específico. El enfoque de la prueba se define y mejora en los planes de la prueba y diseño
de la misma. Comúnmente incluye las decisiones tomadas basándose en el objetivo del
proyecto (la prueba) y evaluación de riesgos. Es el punto de inicio para la planeación del
proceso de la prueba, la selección de las técnicas de diseño de la prueba y tipos de la prueba
que se deben aplicar y la definición de criterios de entrada y salida

El enfoque seleccionado depende del contexto y podrá tener en cuenta riesgos, peligros y
seguridad, recursos y destrezas disponibles, tecnología, origen del sistema (por ejemplo, a
medida vs COTS) objetivos de la prueba y normas

Los enfoques comunes incluyen lo siguiente:

o Enfoques analíticos como pruebas basadas en riesgo cuando se dirigen las pruebas
a áreas de mayor riesgo
o Enfoques basados en modelos, como pruebas estocásticas que utilizan información
estadística respecto a tasa de fallos (como modelos de crecimiento de confiabilidad)
o uso ( perfiles operativos)
o Enfoques metódicos, como los basados en fallas (error guessing y ataques de falla),
basados en la experiencia, basados en listas de verificación y basados en
características de calidad
o Enfoques de proceso o de cumplimiento de normas como las que se especifican en
las normas específicas de industria o varias metodologías flexibles
o Enfoques dinámicos y heurísticos como pruebas exploratorias cuando las pruebas
son más reactivos a casos que planeados previamente y cuando la ejecución y
evaluación son tareas concurrentes
o Enfoques de consultoría como aquellos en los cuales se dirige el cubrimiento de la
 prueba principalmente por la asesoría y orientación de tecnología y /o expertos en
dominio empresarial fuera del equipo de prueba
o Enfoques de regresión – aversos como aquellos que incluyen el reusó de material de
prueba vigente, automatización extensiva de pruebas funcionales de regresión y
conjunto estándar de prueba

Se podrán combinar distintos enfoques; por ejemplo, un enfoque dinámico basado en

riesgos.

5.3 Monitoreo y Control en el Proceso de la Prueba 20 minutos

(K2)

Términos
Densidad del defecto, porcentaje de fallas, control de la prueba, monitoreo de la prueba,
informe de resumen de la prueba
5.3.1 Monitoreo Progreso de la Prueba (K1)
El propósito de este monitoreo es dar retroalimentación y visibilidad respecto a las
actividades de la prueba. La información que se debe monitorear podrá recopilarse manual
o automáticamente y se podrá utilizar para medir los criterios de salida, como la cobertura.
También se podrán utilizar las métricas para evaluar el progreso respecto a la programación
y presupuesto planeado. Las métricas comunes de la prueba incluyen:
o Porcentaje de trabajo realizado en la preparación de caso de la prueba (o el
porcentaje de casos de la prueba planeados que se han preparado
o Porcentaje del trabajo realizado en la preparación del entorno de la prueba
o Ejecución caso de la prueba (número de casos de la prueba funcionando / sin
funcionar y casos de prueba aprobados / fallidos)
o Detectar información ( densidad del defecto, defectos encontrados y solucionados,
porcentaje de fallas y resultados de pruebas hechas nuevamente)
o Cobertura de la prueba de requisitos, riesgos o código
o Confianza subjetiva de probadores en el producto
o Fechas de objetivos de la prueba
o Costos de pruebas que incluyen el costo comparado con el beneficio de encontrar
el próximo defecto o dirigir la próxima prueba

5.3.2 Informe de la Prueba (K2)

Se ocupa de resumir información respecto al esfuerzo hecho en pruebas incluyendo lo
siguiente:
o Lo que sucedió en un periodo de pruebas, como fechas, cuando se cumplieron los
criterios de salida
o Información y métricas analizadas que respalden recomendaciones y decisiones
respecto a acciones futuras como una evaluación de defectos restantes, el beneficio
económico de pruebas continuas, riesgos pendientes y el nivel de confianza en el
software probado.
El esbozo de un resumen del informe de la prueba se suministra en Standard for
Software Test Documentation’ (IEEE Std 829 1998).
Se deben recopilar las métricas durante y al final del nivel de la prueba con el fin de evaluar:
 o La adecuación de los objetivos de la prueba en ese nivel de prueba
o La adecuación de los enfoques de la prueba tomada
o La efectividad de las pruebas respecto a los objetivos

5.3.3 Control de la Prueba (K2)

Describe todas las acciones de orientación y correctivas tomadas como resultado de la
información y métricas recopiladas y reportadas. Las acciones podrán cubrir cualquier
actividad de la prueba y podrá afectar cualquier actividad o tarea del ciclo de vida del
software.
Los ejemplos de acciones de control de la prueba incluyen lo siguiente
o Tomar decisiones basándose en información tomada del monitoreo de la prueba
o Darle prioridad nuevamente a las pruebas cuando ocurren un riesgo identificado (
un software entregado tarde)
o Cambios en la programación de la prueba debido a la disponibilidad o no
disponibilidad de un entorno de la prueba
o La configuración de un criterio de entrada que requiere soluciones que se han
probado nuevamente ( confirmación probada) por parte de un desarrollador antes
de aceptarlos en una construcción

5.4 Gestión de Configuración (K2) 10 minutos

Términos
Gestión de configuración, control de versión

Antecedentes
El propósito de la gestión es establecer y mantener la integridad de los productos
(componentes, datos y documentación) del software o sistema por medio del ciclo de vida
proyecto y producto

Para las pruebas, la gestión de configuración podrá involucrarse garantizando lo siguiente:

o Se identifican todas las partidas del testware, versión controlada, monitoreadas para
cambios, relacionados entre sí y con las partidas de desarrollo (objetos de prueba)
de manera que se pueda mantener la trazabilidad a través del proceso
o Se hacen referencia inequívocamente a todos los documentos identificados y
partidas del software en la documentación de la prueba

Para el probador, la gestión de configuración ayuda a identificar únicamente (y a reproducir)

la partida probada, documentos de la prueba, pruebas y harness de la prueba.

En la planificación de la prueba los procedimientos e infraestructura (herramientas) de la

gestión de configuración deben escogerse, documentarse e implementarse
5.5 Riesgo y pruebas (K2) 30 minutos

Términos
Riesgo del Producto, riesgo del proyecto, risk, pruebas basadas en riesgo

Antecedentes
Se puede definir el riesgo como la chance de haber un caso, peligro, amenaza o situación
que ocurre o resulta en consecuencias no deseables o problema potencial. El nivel de riesgo
se determinara por la probabilidad de un caso adverso que ocurra y el impacto (el daño que
resulte de dicho caso).

5.5.1 Riesgos del Proyecto (K2)

Son los riesgos que rodean la capacidad del Proyecto para entregar sus objetivos, como lo
son:
o Factores organizacionales:
Destreza, capacitación y escasez de personal
Asuntos del personal
Asuntos de políticas como:
Problemas con los probadores al comunicar sus necesidades y resultados
de prueba
Fallas hechas por el equipo al hacer seguimiento de
información encontrada en las pruebas y revisiones (por
ejemplo, que no haya perfeccionamiento de desarrollo y
prácticas de pruebas)
Mal comportamiento respecto a las expectativas de las pruebas (por
ejemplo no apreciar el valor de encontrar defectos en las pruebas)
o Asuntos Técnicos
 Problemas en la definición de requisitos correctos
 En la medida en que los requisitos no se puedan cumplir dadas las restricciones vigentes
 Entorno de la prueba que no esté listo a tiempo
 Conversión tardía de datos, planificación de migración y conversión / herramientas de
migración de datos de desarrollo y pruebas
 Baja calidad del diseño, código, datos de configuración datos de prueba y pruebas
o Proveedor:
 Falla de terceros
 Asuntos contractuales

Cuando de analiza, gestiona y mitigan estos riesgos, el gerente de la prueba sigue los
principios bien establecidos de gestión del Proyecto. El resumen del Standard for
Software Test Documentation’ (IEEE Std 829-1998) en planes de la prueba, exige
que se indiquen riesgos y contingencias

5.5.2 Riesgos de Productos (K2)

Las áreas de fallas potenciales (futuros eventos o peligros adversos) en el software o sistema
 se conocen como riesgos de productos ya que son un riesgo para la calidad del producto.
Incluyen lo siguiente

 Software entregado que este propenso a fallas

 El potencial que el software/hardware pueda causar daño a una persona o a la
compañía
 Malas características del software (por ejemplo, funcionalidad, confiabilidad, uso y
desempeño)
 Mal integridad y calidad de datos (por ejemplo, asuntos de migración de datos,
problemas en la

Conversión de datos, problemas en la transferencia de datos, violación de reglas de

datos)
 El software que no desarrolle sus funciones previstas

Los riesgos se utilizan para decidir donde iniciar la prueba y donde se deben hacer más
pruebas; se utilizan las pruebas para reducir el riesgo de un efecto adverso o reducir el impacto
de un efecto adverso.

Estos riesgos son un tipo especial de riesgo para el éxito de un proyecto. Las pruebas como
una actividad de control de riesgo suministran retroalimentación respecto riesgos residuales
midiendo la efectividad en remover defectos críticos y de planes de contingencia.

Un enfoque de pruebas basado en riesgos suministra oportunidades proactivas de reducir los

niveles de riesgo en el producto, comenzando en las fases iniciales de un proyecto. Involucra
la identificación de riesgos del producto y su uso en la guía de planificación de la prueba y
control, especificación, preparación y ejecución de pruebas. Los riesgos identificados en un
enfoque basado en riesgos se pueden utilizar para lo siguiente:

o Determinar las técnicas de prueba que deben utilizarse

o Determinar el grado de prueba que debe llevarse a cabo
o Darle prioridad a las pruebas en un intento por encontrar defectos críticos lo más
pronto posible
o Determinar si cualquier actividad que no requiere pruebas se pueda utilizar para
reducir el riesgo (por ejemplo, dar capacitación el diseñadores sin
experiencia)

Los sorteos de pruebas basadas en riesgos en conocimiento colectivo y perspectivas de los

participantes del proyecto para determinar los riesgos y los niveles de pruebas requeridos
para reconocer dichos riesgos.

Para garantizar la probabilidad de falla en un producto se minimice, las actividades de

gestión de riesgo suministra un enfoque disciplinado para:
o Evaluar ( y reevaluar regularmente) lo que puede salir mal (riesgos)
o Determinar los riesgos que deben tratarse
o Implementar acciones para tratar con dichos riesgos
Adicionalmente, las pruebas podrán respaldar la identificación de nuevos riesgos y también
podrá ayudar a determinar que riesgos se deben reducir y disminuir la incertidumbre sobre
riesgos.

5.6 Gestión de Incidentes (K3) 40 minutos

Términos
Registro de incidentes, gestión de incidentes, informe de incidentes

Antecedentes
Puesto que uno de los objetivos de las pruebas es encontrar defectos, las
discrepancias entre los resultados reales y esperados deben registrarse como
incidentes. Se debe investigar un incidente que pueda resultar en un defecto. Las
acciones pertinentes para eliminar incidentes y defectos deben definirse. Se deben
monitorear los incidentes y defectos a partir del descubrimiento y clasificación para
corrección y confirmación de la solución. Con el fin de manejar todos los incidentes
y finalizarlos, una organización debe establecer un proceso de gestión de incidentes
y normas de clasificación.

Pueden surgir incidentes durante la fase de desarrollo, revisión, pruebas o uso de

un producto software. Podrán surgir por asuntos ocurridos en el código o el sistema
en funcionamiento o cualquier tipo de documentación incluyendo requisitos,
documentos de desarrollo, documentos de la prueba e información del usuario como
“Ayuda “o guías de instalación.

Los informes de incidentes tienen los siguientes objetivos:

o Darles retroalimentación a los desarrolladores y otras partes retroalimentación
respecto al problema que permita la identificación, asilamiento y corrección que sea
necesaria
o Darles a los líderes de la prueba los medios de monitorear la calidad del sistema
conforme la prueba y el progreso de las pruebas
o Dar ideas para el perfeccionamiento de los proceso de pruebas

Los detalles del informe del incidente podrán incluir:

o Fecha de emisión, organización que emite y autor
o Resultados esperados y reales
o Identificación de la partida de prueba (partida de configuración) y entorno
o Proceso del ciclo de vida del software o sistema donde se observó el incidente
o Descripción del incidente que permita la reproducción y resolución, incluyendo
registros, memorias de base de datos y captura de pantallas
o Alcance o grado de impacto en los intereses de los participantes
o Severidad del impacto en el sistema
o Urgencia / prioridad a solucionar
 o Estado del incidente ( por ejemplo, abierto, diferido, duplicado, en espera a ser
solucionado, pruebas hechas nuevamente ya solucionadas en espera, cerrado)
o Conclusiones, recomendaciones y aprobaciones
o Asuntos a nivel global, como otras áreas que puedan resultar afectadas por los
cambios que resulten de incidentes
o Cambio de historial, como la secuencia de las acciones tomadas por parte de los
miembros del equipo respecto al incidente que se debe aislar y confirmarse como
solucionado
o Referencias, incluyendo la identidad del caso de la especificación del caso de la
prueba que revelo el problema

La estructura de un informe de incidentes también se cubre en

Standard for Software Test Documentation (IEEE std 829-1998).

References
5.1.1 Black, 2001, Hetzel, 1988
5.1.2 Black, 2001, Hetzel, 1988
5.2.5 Black, 2001, Craig, 2002, IEEE Std 829-1998, Kaner 2002
5.3.3 Black, 2001, Craig, 2002, Hetzel, 1988, IEEE Std 829-
1998
5.4 Craig, 2002
5.5.2 Black, 2001 , IEEE Std 829-1998
5.6 Black, 2001, IEEE Std 829-1998

6. Herramientas de Soporte para Pruebas (K2) 80 minutos

Objetivos de estudio en herramientas de soporte para pruebas

Los objetivos identifican lo que se podrá hacer tras la finalización de cada modulo

6.1 Tipos de Herramientas de Prueba (K2)

LO-6.1.1 Clasificar los diferentes tipos de herramientas de prueba de acuerdo a sus
propósitos y actividades del proceso fundamental de la prueba y el ciclo de
vida del software (K2)
LO-6.1.3 Explicar el termino herramienta de prueba y el propósito de las herramientas
de soporte en pruebas (K2)

6.2 Uso Efectivo de Herramientas: Beneficios y Riesgos Potenciales (K2)

LO-6.2.1 Hacer un resumen de los beneficios y riesgos potenciales de automatización
de la prueba y herramientas de soporte en pruebas K2)
LO-6.2.2 Tener en cuenta consideraciones especiales en las herramientas de ejecución
de la prueba, análisis estático y herramientas de gestión de la prueba (K1)
6.3 Presentación de la Herramienta en una Organización (K1)
LO-6.3.1 Mencionar los principios fundamentales en la introducción de la herramienta
en una organización (K1)
LO-6.3.2 Mencionar los objetivos de una prueba de concepto para la evaluación de la
herramienta y una fase experimental para implementación de la herramienta
(K1)
LO-6.3.3 Reconocer que son requeridos los factores para herramientas de soporte
apropiadas en lugar de simplemente adquirir una herramienta (K1)

6.1 Tipos de Herramientas de Prueba (K2) 45 minutos

Términos
Herramienta de gestión de configuración, herramienta de cobertura, herramienta de
depuración, herramienta de análisis dinámico, herramienta gestión de incidentes,
herramienta pruebas de carga, herramienta de modelos, herramienta de monitoreo,
herramienta desempeño de la prueba, efecto de sondeo, herramienta gestión de requisitos,
herramienta de revisión, herramienta de análisis estático. Herramienta prueba de tensión,
comparador de la prueba, preparación datos de la prueba, herramienta diseño de la prueba,
harness de la prueba, herramienta ejecución de la prueba, herramienta gestión de la prueba,
herramienta marco de pruebas unitarias.

6.1.1 Herramientas de soporte en Pruebas (K2)

Las herramientas de prueba se pueden utilizan para realizar una o más actividades que
respaldan las pruebas. Incluyen lo siguiente:
1. Herramientas que se utilizan directamente en pruebas como las herramientas de
ejecución de la prueba, herramientas de generación de datos de prueba y
herramientas de comparación de resultados
2. Herramientas que ayuden en la gestión de procesos de pruebas como aquellos que
se utilizan para gestionar pruebas, resultados de pruebas, requisitos, incidentes,
defectos, etc., y que además ayuden en los reportes y seguimiento de ejecución de
prueba.
3. Herramientas que se utilicen en el reconocimiento o en términos simples: exploración
(por ejemplo, herramientas que monitorean la actividad del archivo en una
aplicación)
4. Cualquier herramienta que ayude en las pruebas ( una hoja de cálculo también una
herramienta de prueba en este significado)

La herramienta de apoyo en pruebas puede tener uno o más de los siguientes propósitos
dependiendo del contexto:
o Mejorar la eficiencia de las actividades de prueba por medio de la automatización
repetitiva de tareas o por medio del apoyo en las actividades del manual de prueba
como la planificación de prueba, diseño de prueba, reporte y seguimiento de prueba.
o Automatizar actividades que requieran recursos importantes cuando se realicen
manualmente ( por ejemplo, pruebas estáticas)
 o Automatizar actividades que no se puedan ejecutar manualmente ( por ejemplo,
pruebas de desempeño de gran escala de las aplicaciones servidor-cliente)
o Aumentar la confiabilidad de las pruebas ( por ejemplo, por medio de la
automatización de grandes comparaciones de datos o por medio de la simulación de
comportamiento

El término “marco de referencia de prueba” se utiliza frecuentemente en la industria, como

mínimo de las tres siguientes maneras:
o Bibliotecas de pruebas reusables y extensibles que se puedan utilizar para construir
herramientas de prueba ( denominadas harnesses de prueba respectivamente )
o Un tipo de diseño de automatización de prueba ( por ejemplo, orientado a los datos
y basabas en palabras clave)
o Todo el proceso de ejecución de pruebas

Para efectos de este programa, el término “marco de referencia de prueba” se utiliza en sus
dos primeros significados, tal como se describe en la Sección 6.1.6

6.1.2 Clasificación de la Herramienta de Prueba (K2)

Existe un número de herramientas que soportan distintos aspectos de pruebas. Se pueden

clasificar las herramientas basándose en varios criterios como propósitos / shareware /
comercial/ gratis / de fuente abierta, tecnología utilizada entre otras. Se clasifican las
herramientas en este programa de acuerdo a las actividades de pruebas que soportan.

Algunas herramientas claramente soportan un actividad; otras soportan más de una

actividad, pero se clasifican conforme la actividad con la cual se asocian más
estrechamente. Las herramienta provenientes de un solo proveedor, particularmente
aquellas que se han designado para trabajar juntas, podrán combinarse en un solo paquete.

Algunos tipos de herramientas de prueba pueden ser intrusivos, lo que significa que pueden
afectar el resultado real de la prueba. Por ejemplo, el momento real puede ser diferente
debido a las instrucciones extras que ejecuta la herramienta, o puede que se obtenga una
medida diferente de la cobertura del código. La consecuencia de la herramienta intrusiva
se denomina el efecto de sondeo.

Algunas herramientas ofrecen un apoyo más apropiado para desarrolladores (por ejemplo,
herramientas que se utilizan durante las pruebas del componente e integración del
componente). Dichas herramientas se marcan con “(D)” en la siguiente lista.

6.1.3 Herramienta de Soporte en la Gestión de Pruebas (K1)

Las herramientas de gestión se aplican a todas las actividades de prueba en todo el ciclo
de vida del software.
 Herramientas de Gestión de Prueba
Estas herramientas suministran interfaces para la ejecución de pruebas, seguimiento de
defectos y gestión de requisitos, junto con el soporte para análisis cuantitativo y reporte de
objetos de prueba. También soportan el rastreo de objetos de prueba a las especificaciones
del requisito y podrían tener una capacidad independiente de control de versión
independiente o una interface a una externa.

Requisitos Herramientas de Gestión

Estas herramientas almacenan enunciación de requisitos, características para requisitos
(que incluyen prioridades), suministra identificadores únicos y soportan el seguimiento de
los requisitos en pruebas individuales. Estas herramientas podrán también ayudar a
identificar requisitos inconsistentes o que hagan falta.

Herramientas Gestión de Incidentes (Herramientas Monitoreo de Defectos)

Estas herramientas almacenan y manejan informes de incidentes, es decir, defectos, fallas,
solicitudes de cambio o problemas y anomalías percibidas y ayudan en la gestión del ciclo
de vida de incidentes, opcionalmente con el soporte en análisis estadístico.

Herramientas Gestión de Configuración

Aunque no sean estrictamente herramientas de prueba, son necesarias para la gestión de
almacenamiento y versión del testware y software relacionado especialmente cuando se
configura más de un entorno de hardware/software en términos de versiones de sistemas
operativos, compiladores, navegadores, etc.

6.1.4 Herramientas de Soport en Pruebas Estáticas (K1)

Las pruebas estáticas suministran una manera rentable de encontrar más defectos con
anticipación en el proceso de desarrollo.

Herramientas de Revisión
Estas herramientas ayudan con la revisión de procesos, listas de control, pautas de revisión
y se utilizan para almacenar y hacer comentarios de revisión sobre defectos y esfuerzos.
Pueden ser una ayuda adicional al suministrar apoyo en las revisiones en línea en equipos
grandes o dispersos geográficamente.

Herramientas Análisis Estático (D)

Estas herramientas le ayudan a los desarrolladores y probadores a encontrar defectos antes
de las pruebas dinámicas suministrando soporte para reforzar los estándares de codificación
(incluyendo la codificación segura), análisis de estructuras y dependencias. También pueden
ayudar a planear o analizar riesgos suministrando métricas en el código (por ejemplo,
complejidad)

Herramientas de Modelación (K1)

Estas herramientas se utilizan para validar los modelos del software (por ejemplo, modelo
de datos físicos (MDF) en una base de datos relacional), enumerando inconsistencias y
encontrando defectos. Estas herramientas normalmente ayudan a generar algunos casos de
prueba basados en el modelo

6.1.5 Herramientas de Soporte en la Especificación de la Prueba (K1)

Herramientas Diseño de Prueba
Estas herramientas se utilizan para generar entradas de prueba o pruebas ejecutables y / o
oráculos de prueba a partir de requisitos, interfaces graficas de usuarios, modelos de diseño
(estado, datos, u objeto) o códigos.

Herramientas Preparación Datos de Prueba

Manipulan las bases de datos archivos o transmisiones de datos para configurar datos de
prueba que se utilizan durante la ejecución de pruebas que garantizan la seguridad por
medio de la confidencialidad de datos.

6.1.6 Herramientas de Soporte Para Ejecución de Pruebas y Registro (K1)

Herramientas Ejecución de Prueba
Estas herramientas permiten que las pruebas se ejecuten automáticamente, o semi
automáticamente, utilizando entradas o salidas esperadas, por medio del uso de lenguaje
scripting y generalmente suministran un log de prueba en cada ejecución de prueba.
También pueden utilizarse para registrar pruebas y soportar los lenguajes scripting o
configuración basada en GUI para la parametrización de datos y otra configuración en las
pruebas.

Herramientas Marco de prueba Harness/ Unidad de Pruebas (D)

Una unidad de prueba harness o marco facilita las pruebas del componente o partes de un
sistema por medio de la simulación del entorno en el cual el objeto de la prueba funcionara
a través del suministro de objetos simulados como stubs o drivers.

Comparadores de Prueba
Determinan las diferencias entre archivos, bases de datos o resultados de pruebas. Las
herramientas de ejecución de prueba incluyen comúnmente comparadores dinámicos, pero
se pueden realizar comparaciones posteriores a la ejecución por parte de una herramienta
de comparación separada. Un comparador de prueba puede utilizar un oráculo de prueba,
particularmente si esta automatizado.

Herramientas Medidas de Cobertura (D)

Estas herramientas que por a través de medios intrusivos o no intrusivos, mide el porcentaje
de tipos específicos de estructuras de códigos que se han ejercitado (por ejemplo, estados,
sedes o decisiones y llamados de modulo o funciones) por parte de un conjunto de pruebas.

Herramientas de Prueba de Seguridad

Se utilizan para evaluar las características de seguridad del software. Lo anterior incluye la
evaluación de la habilidad del software para proteger la confidencialidad de datos,
integración, autenticación, autorización, disponibilidad y no repudio. Las herramientas de
seguridad se enfocan generalmente en una tecnología, plataforma y propósito en particular.
6.1.7 Herramienta de Apoyo para Desempeño y Seguimiento (K1)
Herramientas de Análisis Dinámico (D)
Encuentran defectos solo cuando se está ejecutando el software, como en dependencias de
tiempo o pérdida de memoria. Se utilizan comúnmente en el componente y las pruebas de
integración del componente y cuando se prueba el middleware.

Herramientas Prueba de desempeño /Prueba de Carga / Pruebas de Tensión

Las herramientas de prueba de desempeño monitorean cómo se comporta el sistema
conforme una variedad de uso simulado en términos de un número de usuarios simultáneos,
su modelo de incremento, frecuencia y porcentaje relativo de transacciones. La simulación
de carga se logra por medio de la creación de un usuario virtual que lleva a cabo un conjunto
seleccionado de transacciones, extendidos a varias máquinas de prueba comúnmente
conocidas como generadores de carga.

Herramientas de Seguimiento
Continuamente analizan, verifican e informan el uso de recursos específicos del sistema y
advierten de posibles problemas en el servicio

6.1.8 Herramienta de Soporte para Necesidades Especificas de Prueba (K1)

Evaluación calidad de datos
Data se encuentra en el centro de algunos proyectos como proyectos de conversión /
migración de datos y aplicaciones como data warehouses y sus atributos pueden variar en
términos de criticidad y volumen. En dichos contextos, se necesitan emplear las
herramientas en la evaluación de calidad de dtapsy verificar las normas de conversión y
migración de datos para garantizar que los datos procesados son los correctos, completos y
cumplen con los estándar del contexto especifico pre definido.

Existen otras herramientas de prueba para prueba de usabilidad.

6.2 Uso Efectivo de Herramientas: Beneficios 20 minutos

y Riesgos Potenciales (K2)

Términos
Pruebas dirigidas a datos, pruebas dirigidas a palabras claves, script (En informática un
"script", archivo de órdenes, archivo de procesamiento por lotes o guion es un programa
usualmente simple, que por lo regular se almacena en un archivo de texto plano)

6.2.1 Beneficios y Riesgos Potenciales de Herramientas de soporte en

Pruebas (Todas las Herramientas) (K2)
Con el simple hecho de comprar o alquilar una herramienta no se garantiza el éxito
de dicha herramienta. Todo tipo de herramienta requiere un esfuerzo adicional en
el que se logren beneficios reales y duraderos. Existen beneficios y oportunidades
potenciales en las pruebas utilizando herramientas; pero también hay riesgos.
 Los beneficios potenciales de uso de herramientas incluyen:
o Se reduce el trabajo repetitivo ( por ejemplo, funcionamiento pruebas de
regresión, re ingreso de los mismos datos de prueba y revisión de los
estándares de codificación)
o Mayor consistencia y respetabilidad (por ejemplo, pruebas que ejecuta
una herramienta en el mismo orden con la misma frecuencia y pruebas
derivadas de requisitos)
o Evaluación objetiva, ( por ejemplo, medidas estáticas, cobertura)
o Fácil acceso a información de prueba o proceso de pruebas ( por ejemplo,
estadísticas y graficas del progreso de pruebas, tasas de incidentes y
desempeño)

Los riesgos de usos de herramientas incluyen

o Expectativas poco realistas en la herramienta (que incluyen funcionalidad y
facilidad de uso)
o Subestimar el tiempo, costos y esfuerzo necesario para lograr beneficios
significativos y continuos con la herramienta ( que incluye capacitación y
conocimiento externo)
o Subestimar el esfuerzo requerido para mantener los activos de las pruebas
generadas por la herramienta
o Confiar en la herramienta excesivamente (reemplazar el diseño de prueba o
uso de pruebas automatizadas cuando las pruebas manuales serían más
apropiadas)
o Descuidar el control de versiones de activos de la prueba dentro de la
herramienta
o Descuido de asuntos de relaciones e interoperabilidad entre herramientas
críticas, como requisitos herramientas de gestión, herramientas control de
versiones, herramientas gestión de incidentes, herramientas seguimiento de
defectos y herramientas de varios vendedores
o Riesgo de que el fabricante de la herramienta salga del negocio, retire la
herramienta o venda dicha herramienta a otro fabricante
o Poca respuesta por parte del fabricante en cuanto a soporte, actualizaciones
y solución de defectos
o Riesgo de suspensión de proyecto de fuentes abiertas / libre de
herramientas
o Imprevistos como la incapacidad de soporte de una nueva plataforma

6.2.2 Consideraciones especiales para algunos Tipos de Prueba (K1)

Herramientas de Ejecución de Prueba
Ejecutan los objetos de la prueba por medio de scripts de prueba automatizados. Este tipo
de herramienta generalmente requiere esfuerzos significativos con el fin de lograr
beneficios significativos.

Al capturar pruebas por medio del registro de acciones de un probador manual puede
resultar atractivo, pero este enfoque no logra grandes cifras de scripts de prueba
 automatizados. Un script capturado es una representación lineal con datos específicos y
acciones como parte de cada script. Es posible que este tipo de script sea inestable al
ocurrir casos inesperados.
Un enfoque de prueba dirigida a datos generalmente divide en una hoja de cálculo las
entradas de prueba (los datos) y utiliza un script de prueba más genérico que pueda leer
los datos de entrada y ejecutar el mismo script de prueba con datos diferentes. Los
probadores que no conozcan el script, pueden crear los datos de prueba en estos scripts
predefinidos.
Existen otras técnicas utilizadas en las técnicas basadas en datos donde en lugar de haber
combinaciones de datos codificados ubicados en una hoja de cálculo, se generan los datos
por medio de algoritmos basados en parámetros configurables al momento de la ejecución
y se suministran a la aplicación. Por ejemplo, es posible que una herramienta utilice un
algoritmo que genere una identificación aleatoria de un usuario y se utiliza una semilla para
repetitividad en el modelo para controlar aleatoriedad.

En un enfoque de pruebas basados en palabras claves, la hoja de cálculo contiene palabras

claves que describen las acciones que deben tomarse (también denominadas palabras de
acción) y datos de prueba. Los probadores (incluso si no conocen el lenguaje del script)
pueden definir pruebas por medio de las palabras claves que pueden diseñarse de acuerdo
a la aplicación que se está probando.
Los conocimientos técnicos en el script son necesarios en todos los enfoques (ya sea por
parte de los probadores o especialistas en la automatización de la prueba)
Independientemente de la técnica del script utilizada, los resultados esperados en cada
prueba necesitan almacenarse en una futura comparación.

Herramientas de Análisis Estático

Estas herramientas aplicadas al código fuente pueden hacer cumplir los estándares de
codificación, pero si se aplican a un código vigente, pueden generar una gran cantidad de
mensajes. Los mensajes de advertencia no detienen el código de traducirse en un programa
ejecutable, pero debe idealmente estar dirigido de manera que el mantenimiento del código
sea más fácil en un futuro. Es un enfoque efectivo una implementación manual de la
herramienta de análisis con filtros iniciales para excluir algunos mensajes.

Herramientas Gestión de Prueba

Necesitan una interrelación con otras herramientas u hojas de cálculo con el fin de producir
información útil en un formato que se ajuste a las necesidades de la organización.

6.3 Presentación de una Herramienta a una

Organización (K1) 15 minutos

Términos
No hay términos específicos

Antecedentes
Las consideraciones principales en la selección de una herramienta en una organización
incluyen:
 o Evaluación de una madurez organizacional, fortalezas y debilidades e identificación
de oportunidades en un proceso de prueba perfeccionado que soportan las
herramientas
o Evaluación de requisitos claros y criterios objetivos
o Una prueba de concepto utilizando una herramienta de prueba durante la fase de
evaluación para establecer si dicha herramienta funciona efectivamente con el
software conforme la prueba y dentro de la infraestructura o para identificar los
cambios necesarios a dicha infraestructura para utilizar la herramienta efectivamente
o Evaluación del fabricante ( que incluye capacitación, soporte y aspectos comerciales)
o proveedores de soporte de servicio en caso de herramientas no comerciales
o Identificación de requisitos internos para capacitación y asesoramiento en el uso de
la herramienta.
o Evaluación de las necesidades de capacitación teniendo en cuenta las destrezas de
automatización de prueba del equipo
o Calculo de la relación costo beneficio basándose en un caso de negocio concreto

La presentación de la herramienta seleccionada en una organización comienza con un

proyecto piloto que tiene los siguientes objetivos:
o Aprender más detalladamente sobre la herramienta
o Evaluar como la herramienta se ajusta a los procesos y practicas vigentes y
determinar que se debería cambiar
o Decidir en cuanto a las maneras estándares de utilizar, gestionar, almacenar y
mantener la herramienta y activos de la prueba (por ejemplo, decidir la convenciones
para fijar nombres en archivos y pruebas, creación de bibliotecas y definición de la
modularidad de los conjuntos de pruebas)
o Evaluar si los beneficios se van a lograr con un costo razonable

Los factores de éxito para el despliegue de la herramienta dentro de una organización

incluyen:
o Extensión gradual de la herramienta al resto de la organización
o Adaptación y perfeccionamiento de procesos que se ajusten al uso de la herramienta
o Suministro de formación y capacitación / tutoría a nuevos usuarios
o Definición del uso de directrices
o Implementación de una forma de reunir información de uso desde el uso real
o Monitoreo de la herramienta de uso y beneficios
o Suministro de soporte al equipo de prueba en una herramienta dada
o Reunión de lecciones aprendidas de todos los equipos

Referencias
6.2.2 Buwalda, 2001, Fewster, 1999
6.3 Fewster, 1999