MTP ISTQB 28032018 - v2.0 MTP PDF

Principios de las Pruebas de Software
Formación para el “Certified Tester – Foundation Level”, Versión 2.0

2
Capítulo 0 – Introducción
• 0/01 Contenidos de la presentación.
• 0/02 Contenido.
• 0/03 Programa.
• 0/04 Documentación.
• 0/05 Evaluación.
• 0/06 Niveles de Conocimiento.
3
0 – General
01 – Contenidos de la Presentación
Seminario “Principios de las pruebas de Software”

• Proporciona al participante conocimientos básicos en el campo de las
Pruebas de Software.
• Constituye la base de evaluación para el “Probador Certificado – Nivel
Básico”.
Los objetivos de la formación para el Probador Certificado son,

entre otros:
• Proporcionar conocimientos acerca de las pruebas de software sobre una
base fundamentada (marco estándar)
• Poder concebir las pruebas de software específicamente para un proyecto
• Poder elegir de forma adecuada las técnicas para las pruebas y sus
objetivos
• Poder escoger y utilizar de manera adecuada las herramientas de apoyo
para las pruebas.
4
0 – General
02 – Contenido
El seminario está dividido en siete capítulos de acuerdo con el plan

de formación del ISTQB:
• Capítulo I Introducción.
• Capítulo II Principios de las pruebas de software.
• Capítulo III Pruebas durante el ciclo de vida del software.
• Capítulo IV Técnicas estáticas.
• Capítulo V Técnicas de prueba (dinámicas).
• Capítulo VI Gestión de las pruebas.
• Capítulo VII Herramientas de Pruebas.
5
0 – General
03 – Programa
El seminario de tres días con posible evaluación final por parte del
ISTQB incluye :
• Preparación teórica del material de estudio y una serie de ejemplos

para determinados comportamientos técnicos.
• Aclaración de dudas.
• Ejercicios en profundidad acerca del material de estudio.
• Discusión sobre los temas aprendidos.
6
0 – General
04 – Documentación
• El material de apoyo se compone de:
• Un manual completo.
• Un conjunto de preguntas de tipo test para preparar el examen.
• Listas de bibliografía, estándares, etc.
• Referencias:
• Certified Tester Foundation Level Syllabus Maintenance Release
(Marzo de 2010)
• ISTQB Glossary of terms used in Software Testing Version 2.1
7
0 – General
05 – Evaluación
El manual se basa en los contenidos del Certified Tester Foundation

Level Syllabus Maintenance Release (Marzo de 2010):
• Tras la finalización del seminario se podrá llevar a cabo la evaluación

para el Nivel básico para el probador certificado (que no caduca).
• La aceptación se llevará a cabo por un examinador independiente.
• El examen que estará dividido en diferentes áreas, de acuerdo a los
capítulos de este seminario, se compone de preguntas de elección
múltiple. El examen será en español con una duración de 60 minutos.
Es necesario obtener un 65% (26 de 40)
8
0 – General
06 – Niveles de Conocimiento
En cada sección del Syllabus se indican los objetivos de aprendizaje

correspondientes, y se clasifican según lo siguiente (consultar el
Apéndice B del Syllabus):
• K1: recordar, reconocer, memorizar.

• K2: entender, explicar, razonar, comparar, clasificar, categorizar,
poner ejemplos, resumir.
• K3: aplicar, usar (ejercicios prácticos).
• K4: saber analizar y proponer acciones apropiadas para solucionar un
problema o abordar una tarea.
NOTA: cada tema se examinará según sus objetivos de aprendizaje (K).
9
10
Capítulo I – Introducción
• I/01 Destinatarios.
• I/02 ISTQB / Organizaciones Internacionales.
• I/03 Probador certificado.
11
I – Introducción
01 – Destinatarios
Queremos dirigirnos a probadores de software en empresas

de software y empresas industriales que quieran asentar sus
conocimientos sobre unas bases fundamentadas.
¡El aprendizaje durante toda la vida

es imprescindible,
especialmente en el sector de las TI!
12
I – Introducción
02 – ISTQB / Organizaciones Internacionales
Programa de cualificación del ISTQB
• En 1998 se definió en Gran Bretaña un programa de cualificación

multi-etapa.
• En el Nivel Básico se presentan las bases de las Pruebas de Software.
• Desde el año 2004 se ofrece, asimismo, la posibilidad de certificarse en
el Nivel Avanzado (Gestor de Pruebas, Probador Técnico, Probador
Funcional).
• Existen comités de pruebas específicos para cada país que forman
conjuntamente el ISTQB - International Software Testing
Qualification Board. En España existe el Spanish Software Testing
Qualification Board.
• Los comités de pruebas específicos de cada país son responsables
de la acreditación de los proveedores de formación y de la
realización de exámenes en los respectivos países.
www.istqb.org
13
I – Introducción
03 – Probador certificado
Programa de cualificación del iSTQB
• Como instancia independiente, el comité verifica los cursos ofrecidos

en base a los criterios definidos y otorga la acreditación al proveedor
de formación.
• A pesar de que la comprobación y las pruebas de software tienen en la
práctica una gran importancia debido a la irrupción de las tecnologías
de la información en prácticamente todos los ámbitos de la vida,
existen pocos cursos de aprendizaje y seminarios que se ocupen de
manera intensiva de esta problemática.
• Esto ha llevado al ISTQB a reavivar las ya mencionadas medidas de
cualificación en diferentes etapas.
14
15
Capítulo II – Fundamentos de las
pruebas de Software
• II/01 Conceptos y definiciones.
• II/02 ¿Por qué es necesario probar?.
• II/03 ¿Qué son las pruebas (Testing)?
• II/04 Problemática de la comprobación y las pruebas.
• II/05 Siete Principios de las Pruebas.
• II/06 Proceso de pruebas fundamental.
• II/07 Psicología de las pruebas.
• II/08 Código de buenas prácticas.
• II/09 Resumen.
16
II - Fundamentos de las pruebas de software
01 – Conceptos y definiciones
Fallos, defectos, errores…

• Error:
Desviación entre el comportamiento real y el comportamiento esperado, no
cumplimiento de un requisito establecido.
• Defecto (defect, fault):
Anomalía en un componente o sistema que puede dar lugar a que no se lleve a
cabo correctamente una función determinada. El término “bug” se aplica
históricamente a los defectos en informática.
• Fallo (failure). Efecto del error
Manifestación de un defecto.
• Equivocación (mistake):
Acción humana que da lugar a un resultado incorrecto.
El software es elaborado por seres humanos

que pueden cometer errores que dan lugar a defectos.
Estos defectos pueden generar un fallo.
17
Prueba y Caso de Prueba
• Enmascaramiento del error:

Varios estados de error se compensan mutuamente – no aparece el efecto
del error.
• Depuración:
Localización y corrección de errores internos.
• Prueba:
Búsqueda dirigida y sistemática de los efectos del error, para demostrar
defectos.
• Prueba de Software:
Cada ejecución de un objeto de prueba que sirva para su comprobación.
18
Prueba y Caso de Prueba

• Caso de Prueba:
Unión de una prueba y unas condiciones de entorno establecidas – p. ej.
requisitos de ejecución, datos de entrada fijos en relación con los datos
esperados o con un comportamiento esperado del objeto de prueba.
• Explosión de casos de prueba:

Debido a las numerosas posibilidades de combinación, p.ej. de datos de
entrada, el número de los posibles casos de prueba crece tanto que puede
llevar a un conjunto de cientos o miles de casos de prueba.
19
Calidad de Software
• Según ISO / IEC 9126:

La calidad de software es la totalidad de propiedades y características de un
producto de software referidas a su aptitud para satisfacer necesidades
explícitas o implícitas.
• Según IEEE Std 610:

El grado en el que un componente, sistema o proceso alcanza los requisitos
especificados y/o las necesidades y expectativas del usuario o cliente.
20
Calidad de Software
• La Calidad de Software según la norma ISO / IEC 9126 abarca:
• Funcionalidad.
• Fiabilidad.
• Usabilidad.
• Eficiencia.
• Mantenibilidad.
• Portabilidad.
• El aseguramiento de la calidad (QS/QA) diferencia entre:
• Medidas constructivas para evitar errores (p.ej. mediante métodos
adecuados de ingeniería de software).
• Métodos analíticos para la detección de errores (p. ej. mediante
pruebas, ya que el descubrimiento de errores sirve para corregir
defectos y elevar de esta manera la calidad del software).
21
Medidas constructivas para el aseguramiento de la calidad (QA)
Medidas QA
constructivas
Medidas Medidas
Técnicas Organizativas
Listas de Requisitos
Métodos Herramientas Directrices Estándares
Chequeo legales
Plantillas
• Motivación principal:
Los errores que no se cometen no necesitan ser corregidos.
22
Medidas analíticas para el aseguramiento de la calidad (QA)
Medidas QA
analíticas
Medidas Medidas
estáticas dinámicas
Análisis de flujos Técnicas basadas

Revisiones / Caja negra Caja blanca
de control y de en la experiencia
Walkthroughs
datos
Análisis de
código. • Partición de equivalencia
Compiladores • Análisis de valores límite • Cobertura de sentencias
• Transición de estados • Cobertura de decisiones o
• Tablas de decisión ramas
• Cobertura de condiciones
23
II – Fundamentos de las pruebas de software
02.1 – ¿Por qué es necesario probar?
El software como factor económico

• El software contribuye de manera definitiva al funcionamiento de aparatos e
instalaciones de uso cotidiano (automoción, banca...). De hecho, existen
sistemas que serían inviables sin un software que los apoyara.
Calidad del Software

• La calidad del software es un factor decisivo para el éxito de determinados
productos o de las propias empresas. Desgraciadamente todos tenemos
experiencias negativas...
• Movimientos incorrectos en la cuenta del banco, en la factura del teléfono,
etc.
• Problemas con la “centralita” del automóvil.
• No disponibilidad de páginas Web.
• No poder sacar dinero de la cuenta.
• No poder realizar una gestión administrativa.
• No poder devolver o recoger un libro, etc.
24
Que la calidad del software sea un factor

decisivo de éxito es difícil de ver, pero que la
falta de calidad es un factor decisivo de
fracaso, es un tema bastante claro.
25
Ejemplo: Fallo en la unidad de coma flotante del Pentium

• En 1994 se descubrió que algunas operaciones de división devolvían siempre
un valor erróneo por exceso.
• Estas comprobaciones crearon una gran polémica. Intel negó inicialmente la

existencia del problema, después lo minimizó negándose a una sustitución
sistemática. Si bien evaluaciones independientes mostraron la poca
importancia del error llegó a haber demandas (incluyendo entre los
demandantes empresas como IBM). Por último, Intel se vio forzada a aceptar
sustituir todos los microprocesadores defectuosos, lo que le representó un
coste enorme.
26
Ejemplo: Phobos 1
• La Phobos 1 despegó y tuvo un funcionamiento correcto hasta que dos meses

después de su lanzamiento se perdió la señal. La fuente del problema fue una
orden errónea (concretamente se transmitió un "+" en vez de un "-"). Incapaz
de controlar su orientación, la Phobos 1 dejó de orientar sus paneles solares
hacia nuestra estrella. Sin energía, no pudo restablecerse contacto con ella.
• Al margen del error, parecería lógico haber “asegurado” una orden tan crítica
como demostró ser la que se envió. Estaba previsto, pero la versión definitiva
del código que la contenía no se implantó a causa de las prisas en la
finalización de los trabajos.
27
Otros errores software famosos
• Apolo 11 (fallo de aterrizaje).
• Mariner 1 (faltaba una coma).
• Ariadne 5 (basado en una versión anterior de sw, el equipo físico no pudo

responder a la mayor aceleración). Importancia de las condiciones de entorno.
• Therac-25 (Dosis masivas de radiación. Generó, al menos, 5 muertes).

Importancia del control de los sistemas software .
28
Causas de los defectos
• El software es elaborado por seres humanos que pueden cometer errores

que dan lugar a defectos. Estos defectos pueden generar un fallo.
• Las causas de los errores (al margen de la falibilidad del ser humano)
pueden ser: presión en los tiempos, complejidad de la aplicación o la
arquitectura, tecnologías cambiantes, existencia de un gran número de
interfaces, etc.
• Al margen de por la existencia de un defecto pueden producirse fallos por

condiciones ambientales (radiación, magnetismo, campos eléctricos, etc.).
29
Las Pruebas como medio de mejora de la calidad
• Un medio para conseguir la mejora de la calidad tanto de los sistemas de

software como del propio proceso de desarrollo son la comprobación y prueba
sistemática del software desarrollado.
• Los errores que se detecten antes del uso del software pueden ser corregidos
antes de que generen fallos.
• Puede exigirse por contrato un nivel mínimo de prueba.
• Las pruebas pueden requerirse también para satisfacer requisitos

contractuales o legales, o estándares específicos de la industria.
30
Calidad de Software
• Una Funcionalidad de buena calidad implica

• Circunscribirse a las características funcionales requeridas (corrección).
• Cubrir todos los requisitos funcionales definidos (completitud).
• Características que debe cumplir una funcionalidad (ISO/IEC 9126):
• Idoneidad (suitability).
¿Son adecuadas las funciones disponibles para la utilización prevista?
• Precisión (accuracy).
¿Se ejecutan las funciones correctamente (como estaba acordado)?
• Conformidad (compliance).
¿Se cumplieron las normas y preceptos?
• Interoperabilidad.
¿Se proporciona una interrelación libre de errores con el entorno del sistema?
• Seguridad.
¿Están protegidos los datos / programas frente a accesos / pérdidas?
31
Calidad de software. Atributos no funcionales
• Fiabilidad
• Capacidad de un software / un sistema de mantener un rendimiento /
funcionalidad bajo condiciones predeterminas durante un periodo de
tiempo definido.
• Da una idea del comportamiento de la calidad a lo largo del tiempo.
• Factores asociados: tolerancia a fallos, capacidad de recuperación
ante fallos.
• Usabilidad*
• Un software es usable si es:
• Fácil de entender (uso intuitivo).
• Fácil de aprender.
• Existe normativa específica.
* ver ISO / IEC 9241.
32
Calidad de software. Atributos no funcionales

• Eficiencia
• Utilización de recursos lo más reducida posible (p.ej. tiempo de CPU)
para la consecución de una tarea.
• Mantenibilidad
• Esfuerzo necesario para realizar una serie de modificaciones
definidas de antemano.
• Factores asociados: estabilidad, facilidad de cambio.
• Portabilidad
• Posibilidad de trasladar un software a otro entorno (hardware,
software u organizativo).
• Factores asociados: facilidad de sustitución, facilidad de instalación,
cumplimiento de estándares.
33
Calidad de Software. Atributos de la calidad
• Algunas características de la calidad de software influyen entre si. Puede

ser necesario según el caso asignar unas prioridades a las características.
• Ejemplos:
• Una descripción puede dejar de ser concisa en aras de la claridad.
• Un software puede ser redundante (y con ello más difícil de mantener)
para aumentar su fiabilidad.
• Una base de datos lo puede ser para mejorar los tiempos de acceso.
• A lo largo del seminario quedará claro que para las diferentes

características deben ejecutarse diferentes tipos de pruebas.
34
¿Cuánto esfuerzo en pruebas es suficiente?
• Como todos los demás productos, tampoco el software está “siempre”

libre de fallos:
• Las pruebas no pueden garantizar nunca la ausencia de fallos en un

programa, sin embargo pueden encontrar y solucionar errores.
• En la práctica unas pruebas exhaustivas son rara vez posibles, sin

embargo tampoco se puede garantizar para las partes probadas la
ausencia total de errores.
35
• Según el ámbito de aplicación y el tipo de error pueden ocasionarse

daños graves.
• Por eso deben ser probadas “todas” las funcionalidades de un software
de manera sistemática.
• Un proceso de pruebas puede considerarse en cierto sentido como
destructivo y debe estar siempre encaminado a encontrar nuevos fallos.
• La resolución de errores durante el desarrollo.

• Mejora el producto.
• Reduce el coste de una eliminación posterior de los errores.
36
• Criterios de finalización
• No localizar defectos durante un tiempo determinado.
Es una métrica simple pero no es suficiente. La posibilidad de que exista un
error crítico podría forzar la continuación de las pruebas.
• Fin del tiempo o de los recursos

disponibles para las pruebas.
• Desgraciadamente, suele ser un criterio
aplicado frecuentemente.
• Curvas de crecimiento de fiabilidad.
• Proporcionan un método de estimación
objetiva para establecer el punto óptimo de
finalización pero requieren un control
preciso del esfuerzo de prueba y un
conocimiento histórico de las
características del sistema.
37
La pendiente de la curva
representa el número total
de fallos encontrados, es
muy pronunciada hasta
casi el final de los 18
intervalos de pruebas, a
partir de este punto el
crecimiento de fallos irá
decreciendo hasta hacerse
nulo, momento en el que
ya se habrán encontrado
todos los fallos esperados.
38
Las técnicas de crecimiento de fiabilidad del software, se utilizan para estimar
la tasa de fallos y la fiabilidad de un sistema de software durante la fase de
pruebas de su desarrollo. Además, se podrá predecir el número de fallos que
tendrá un sistema en la fase de producción, de forma que el gestor del
proyecto dispondrá de una útil herramienta de decisión para:
1. Establecer si el conjunto de pruebas al que ha sido sometido el sistema
ha resultado suficiente de forma que se pueda autorizar su paso a
producción.
2. Reducir la posibilidad de que ocurra una incidencia grave en producción.
3. Estimar el momento, durante la fase de pruebas, en que se alcanzan los
objetivos de fiabilidad del sistema.
39
03 – ¿Qué son las pruebas (Testing)?
• Las pruebas no son sólo ejecutar test cases:

• Esto es parte de las pruebas, pero existen más actividades de pruebas
• Existen actividades de prueba antes y después de la ejecución (planificación y control;
diseño y ejecución de test cases; comprobación de resultados; evaluación de los criterios de
salida; informar sobre el proceso de prueba y el sistema bajo prueba; y finalizar las actividades de
cierre)
• Las pruebas también incluyen la revisión de la documentación (incluyendo el código)
y la realización de análisis estático.
• Ambas, pruebas estáticas y dinámicas persiguen los mismos objetivos y
proporcionan información valiosa para la mejora, tanto del sistema, como de los
procesos de desarrollo y de pruebas.
• Objetivos de las pruebas:
• Encontrar defectos
• Ganar confianza acerca del nivel de calidad
• Proporcionar información para la toma de decisiones
• Evitar o Prevenir defectos
40
03 – ¿Qué son las pruebas (Testing)?
• Depurar y probar son diferentes:

• Las pruebas dinámicas muestran fallos causados por defectos.
• La depuración, sin embargo, es la actividad de desarrollo que localiza, analiza y
elimina las causas de los fallos.
• Normalmente, la responsabilidad de las pruebas la tienen los probadores, mientras
que los desarrolladores suelen tener la de la depuración (debugging)
41
04 – Problemática de la comprobación y las pruebas
Problemas generales de las pruebas
• Ámbito de las pruebas

• ¡Ningún software complejo puede ser probado completamente ! – Incluso
si se definieran todos los casos de prueba posibles su ejecución
consumiría enormes recursos.
• En la práctica no sería posible la definición de todos los casos de prueba
necesarios para unas pruebas exhaustivas, ya que habría que tener en
cuenta todas las diferentes condiciones de entorno posibles.
• Además prácticamente en ningún caso se podrá decir con seguridad que
se han definido todos los casos de prueba posibles.
42
• Alcance
• El alcance de las pruebas debe ser, por consiguiente, reducido - esto
sucede en función de la relación entre Prioridades y Riesgo establecida
utilizando formas de proceder sistemáticas.
• Un alto esfuerzo de pruebas para la eliminación de fallos “menores” no está
justificado.
• Implementar un programa sin comprobar los errores en sus características
esenciales no tiene mucho sentido.
• En la práctica se prueba mediante casos puntuales.
• En todo caso, esta prueba puntual se determina en la práctica de
manera analítica.
43
• Costes
• Las pruebas originan altos costes dentro del desarrollo de software
• Sobre todo en grandes proyectos de IT el esfuerzo para realizar las
pruebas puede ser el mayor de todos respecto del esfuerzo total
empleado.
• Las pruebas tempranas contribuyen a la mejora del proceso de
desarrollo y reducen de esta manera los costes (entre otras causas
por la reducción de errores descubiertos en fases posteriores del
desarrollo de software, ya que ahí el descubrimiento de fallos y su
resolución conlleva un esfuerzo claramente mayor).
44
• Costes
• Los errores que no se encuentran en las pruebas también producen
costes (Coste de Errores):
• Pérdidas de imagen, esfuerzos para las correcciones y
compensación de daños amenazan al productor.
• Errores o pérdidas de datos y tiempos de inactividad son las
consecuencias para los clientes.
• En muchas situaciones es aplicable que:

• Los costes de las pruebas deberían ser menores que los posibles costes
de los errores.
45
05 – Siete Principios de las Pruebas
Principio 1: Las pruebas muestran la presencia de defectos
• Las pruebas pueden mostrar la presencia de defectos.

• Las desviaciones respecto a los resultados previstos que se descubren
durante las pruebas permiten localizar defectos existentes en el software
• Las pruebas no pueden probar la ausencia de defectos.

• Las pruebas reducen la probabilidad de que queden defectos sin descubrir.
La ausencia de fallos no prueba que el software sea correcto
• El propio procedimiento de prueba puede contener errores
• Las condiciones de pruebas pueden no estar bien preparadas para encontrar
errores
46
Principio 2: Las pruebas exhaustivas no son posibles

• Pruebas exhaustivas. Es una estrategia de pruebas en la que se abarcan
todas las posibles combinaciones de valores de entrada y precondiciones.
• Explosión de casos de prueba. Define el aumento exponencial de esfuerzo

y coste que aparece cuando se hacen pruebas exhaustivas.
• Muestreo en las pruebas

• Las pruebas deben incluir sólo un subconjunto de todos los valores de entrada
posibles. Las entradas seleccionadas pueden escogerse de forma sistemática o
aleatoria.
• En condiciones reales, se suele emplear el muestreo. Las pruebas de todas las
combinaciones de entradas y precondiciones es viable desde el punto de vista
económico sólo en casos triviales.
• En lugar de llevar a cabo pruebas exhaustivas, se debería utilizar el análisis de
riesgo y el uso de priorizaciones para enfocar los esfuerzos de las pruebas.
47
Principio 3: Pruebas tempranas
Las actividades de prueba deberían iniciarse tan pronto como sea posible
en el ciclo de vida de desarrollo y deberían tener objetivos concretos.
• Cuanto antes se descubra un defecto, menos costosa será su corrección.

• La máxima efectividad se alcanza cuando los errores se corrigen antes de ser
implementados.
• Pueden probarse los documentos de requisitos conceptuales y las
especificaciones.
• Los defectos que se descubren en la fase de concepción del proyecto se
corrigen con mínimos esfuerzos y costes.
• La preparación de una prueba consume tiempo. La prueba no es sólo la

ejecución.
• Pueden realizarse actividades de prueba (Diseño) antes de que se complete el
desarrollo del software.
• Las actividades de prueba (considerando como tales las revisiones) deberían
llevarse a cabo en paralelo a la especificación y el diseño del software.
48
Principio 4: Bloques de defectos
Unos pocos módulos contienen la mayor parte de los defectos descubiertos

durante la fase de pruebas o son responsables de la mayoría de los fallos en
producción.
• Encuentre un defecto y encontrará más en los alrededores

• Los defectos aparecen frecuentemente en grupos como las setas.
• Es una buena idea repasar el módulo en el que se ha encontrado un defecto.
• Los probadores deben ser flexibles

• Una vez detectado un defecto, es una buena idea reconsiderar la dirección de las
siguientes pruebas.
• La localización de un defecto debe ser revisada con un mayor nivel de detalle, ya
sea incorporando nuevas pruebas o modificando las existentes.
49
Principio 5: La paradoja del pesticida (Bezier)
Si se repiten una y otra vez los casos de prueba, se llegará a que el mismo
conjunto de casos de prueba no sirva para localizar nuevos defectos. Para
superar esta “paradoja del pesticida”, los casos de prueba necesitan ser
revisados de manera regular y se necesita escribir casos nuevos (y
diferentes) para ejercitar diferentes partes del software o sistema para
localizar más defectos.
• Cualquier método que se use para prevenir o encontrar bugs deja un

residuo o bugs más sutiles, contra los que ese método no es efectivo.
• Repetir las pruebas bajo las mismas condiciones no es efectivo.
• Si se repiten una y otra vez las mismas pruebas no se encontrarán nuevos
errores.
• Las pruebas deben ser revisadas regularmente.
• Es necesario repetir una prueba después de que se hagan cambios en el código.
• Las pruebas automatizadas pueden ser una ventaja si se usa regularmente un
grupo de casos de prueba.
50
Principio 6: Las pruebas dependen del contexto
Las pruebas se llevan a cabo de manera diferente en contextos diferentes. Por

ejemplo, el software crítico desde el punto de vista de la seguridad de las
personas (safety) se prueba de forma distinta que la seguridad de un portal de
comercio electrónico (security).
• Las pruebas pueden tener distintos resultados en distintos contextos.

• Diferentes objetos de prueba se prueban de forma distinta.
• El controlador del motor de un coche requiere distintas pruebas que las de una
aplicación de comercio electrónico.
• Pruebas en el entorno de prueba vs pruebas en el entorno de producción.

• Las pruebas deben llevarse a cabo en un entorno separado al de producción. El
entorno de prueba debe ser muy similar al de producción.
• Siempre habrá desviaciones entre ambos entornos.
51
Principio 7: La falacia de la ausencia de errores
Localizar y corregir defectos no sirve de nada si el sistema construido no cubre

las necesidades y expectativas de los usuarios.
• Unas pruebas adecuadas localizan los fallos más serios.

• En la mayoría de los casos, las pruebas no encontrarán todos los defectos del
sistema (ver principio 2) pero sí los más serios.
• Con esto solamente, no se prueba la calidad del software.

• La funcionalidad del software puede no cumplir las necesidades y expectativas de
los usuarios.
• No se puede probar la calidad de un producto solo con las pruebas, debe
construirse desde el principio con la calidad requerida.
52
06 – Proceso de pruebas fundamental
El proceso de desarrollo de software
• Un desarrollo de software estructurado sigue pasos claramente definidos

• Diferentes modelos de procedimiento muestran el desarrollo estructurado
• Modelo en cascada según Royce (1970):

• Proceso de desarrollo en 7 etapas.
• Cada etapa sólo tiene una conexión
hacia atrás con la etapa anterior.
• Las pruebas sólo representan una
etapa en el proceso .
• Se corresponde con la aceptación
final de producto.
53
06 – Proceso de pruebas fundamental
Las pruebas dentro del proceso de desarrollo de software

• Independientemente del modelo de procedimiento, las pruebas se llevan a
cabo en diferentes momentos del proceso de desarrollo de software.
• Las pruebas en sí deben ser entendidas también como un proceso.
• El proceso de pruebas incluye las siguientes fases:
• Planificación y control.
• Análisis y diseño.
• Implementación y ejecución.
• Evaluación y documentación.
• Cierre de las pruebas.
• Estas fases no tienen por qué ocurrir siempre de forma secuencial,
podrían solaparse o suceder concurrentemente.
54
06.1 – Proceso de pruebas fundamental
Planificación de las pruebas
• Comienza con el inicio del proceso de desarrollo
• Principales tareas:
Inicio
• Determinar el alcance y los riesgos.
• Identificar los objetivos de las pruebas y los Planificación y
criterios de finalización. control
• Seleccionar y priorizar las pruebas (p.ej. según el
riesgo). Análisis y diseño
• Determinar las técnicas, cobertura, herramientas,
entorno y equipos de prueba.
Implementación y
• Determinar los métodos y estrategia. Ejecución
• Planificar las actividades.
Evaluación y
• Adquirir/planificar los recursos.
Documentación
• Personal.
• Entorno y medios de apoyo.
Cierre
• Coste.
• La planificación debe tomar en consideración la
información que le proporcionen las actividades Fin
de control y monitorización.
55
Control de las pruebas

• Comparar el progreso real con el planificado. Incluye
tomar las acciones necesarias para llevar a cabo la mision
Inicio
y alcanzar los objetivos del proyecto.
• Para ello, el proyecto de pruebas ha de ser monitorizado a Planificación y
lo largo de toda su vida. Ejemplos de métricas: control
• % del trabajo realizado en la preparar casos de prueba.
• % de trabajo hecho en la preparación del entorno. Análisis y diseño
• % Ejecución de casos.
• Información de defectos. Implementación y
• Cobertura de requisitos, riesgos o código. Ejecución
• Confianza subjetiva de los probadores en el producto.
• Fechas de los hitos de prueba. Evaluación y
• Costes de las pruebas. Documentación
• Principales tareas:
• Tomar decisiones basadas en la información que le proporciona la Cierre
monitorización de las pruebas.
• Repriorizar las pruebas cuando aparece un riesgo identificado (por Fin
ejemplo, retraso en la entrega del sw).
• Cambiar la planificación según la disponibilidad del entorno.
56
Análisis y diseño de las pruebas

• Analizar la documentación en base a la cual se van a Inicio
generar los casos de prueba.
• Evaluar la capacidad de los objetos de ser probados. Planificación y
control
• Diseñar y priorizar casos de prueba lógicos (alto nivel).
• En base a los métodos establecidos en la estrategia de Análisis y diseño
pruebas.
• Identificar los datos de prueba. Implementación y
Ejecución
• A menudo son necesarios datos “anónimos”.
• Establecer las condiciones marco. Evaluación y
Documentación
• Diseñar/adaptar el entorno de pruebas. Identificar
infraestructuras necesarias.
Cierre
• Definir la operación del entorno de prueba, incluyendo la
administración de los usuarios. Fin
• Crear trazabilidad bidireccional entre la documentación
base y los casos de prueba.
57
Implementación de las pruebas
• Desarrollo, implementación y priorización de casos Inicio

de prueba.
Planificación y
• En su caso, escribir scripts de pruebas control
automatizadas.
• Crear secuencias de prueba para mejorar la Análisis y diseño
eficiencia de la ejecución.
Implementación y
• Implementar controladores de pruebas. Ejecución
• Implementar/configurar/verificar el entorno de
Evaluación y
pruebas. Documentación
• Instalar herramientas.
• Integrar los datos de prueba. Cierre
• Verificar y actualizar la trazabilidad bidireccional

Fin
entre la documentación base y los casos de prueba.
58
Ejecución de las pruebas

• Ejecutar los casos/secuencias de prueba. Inicio
• Registrar y analizar resultados. Registro de:
Planificación y
• Objeto de la prueba. control
• Probador.
• Datos de prueba. Análisis y diseño
• Resultado.
Implementación y
• Comparar los resultados obtenidos con los Ejecución
resultados esperados e informar acerca de las
discrepancias, analizándolas establecer su origen Evaluación y
Documentación
(error en código, en los datos de prueba, en el caso
de prueba, en la forma de ejecutar la prueba...).
Cierre
• Repetir las actividades de prueba según la acción
que se lleve a cabo para cada discrepancia. Fin
59
Evaluación y documentación de las pruebas

• La evaluación de los criterios de finalización (o de Inicio
salida) es la actividad en la que se valora la
ejecución de la prueba respecto de los objetivos Planificación y
control
definidos. Debería llevarse a cabo en cada nivel
de prueba e implica:
Análisis y diseño
• Analizar los logs de la prueba (resumen de
actividades de prueba realizadas, resultado de la
prueba, etc). Implementación y
Ejecución
• Comprobación de los criterios de finalización de
las pruebas. Evaluación y
Documentación
• Comparar los resultados obtenidos con los
objetivos esperados.
Cierre
• Si se cumplen todos los criterios, las pruebas
finalizan.
Fin
60
Evaluación y documentación de las pruebas

• Si no se cumplen los criterios, Inicio
• Habrá que comprobar, en determinados casos, si
realmente es posible cumplirlos Planificación y
control
• Habrá que comprobar si la planificación de las
pruebas necesita ser adaptada
Análisis y diseño
• En su caso, los errores encontrados llevan a un
nuevo ciclo de pruebas – empezando por la Implementación y
especificación de los casos de prueba. Ejecución
• Se ha de proporcionar información suficiente para Evaluación y

ayudar a la decisión de si se ha de continuar o no Documentación
con las pruebas.
• Se ha de generar un informe final de pruebas Cierre
dirigido a las áreas afectadas.
Fin
61
Criterios de finalización de las pruebas

• Ratio de localización de errores
• El número de errores encontrados por hora de esfuerzo de pruebas desciende de
un valor establecido.
• Si se encuentra, p.ej., menos de un error nuevo por hora de esfuerzo de pruebas,
las pruebas finalizarán.
• Aquí se tiene en cuenta la rentabilidad de las pruebas que no se da a partir de un
determinado ratio.
• Finalización de las pruebas por motivos de coste o tiempo
• P.ej. a causa de una planificación escasa de recursos .
• Origina, por norma general, costes adicionales por la aparición posterior de
errores.
• Cobertura de código
• x % de código del programa ha debido ser ejecutado.
• Cobertura de riesgos
• Los casos de prueba de una clase de riesgo definida (p.ej. de la máxima
prioridad) se han debido ejecutar sin errores.
62
Actividades de cierre
• Recoger datos de las actividades de prueba
Inicio
completadas para consolidar experiencia.
• Cierre de los informes de incidencias o apertura de Planificación y
control
solicitudes de cambio para todos los puntos que
sigan abiertos.
• Comprobación de que entregables han sido Análisis y diseño
efectivamente entregados y aprobados.

Implementación y
• Documentación de la aceptación del sistema. Ejecución
• Archivado de las pruebas, el entorno de pruebas y
la infraestructura de pruebas para posterior Evaluación y
Documentación
reutilización.
• Análisis de las lecciones aprendidas para futuros
Cierre
proyectos.
• Usar la información recopilada para mejorar la
Fin
madurez de las pruebas.
63
07 – Psicología de las pruebas
Diferencias entre diseñar, desarrollar y probar

• Las pruebas requieren una forma diferente de pensar de las de aquellos que
diseñan o desarrollan sistemas:
• La misión del diseñador es ayudar al cliente suministrándole los requisitos correctos.
• La misión del desarrollador es convertir los requisitos en funciones.
• La misión del probador es examinar la correcta implementación de los requisitos del
usuario.
• Objetivo común: proporcionar buen software.
• En principio, una persona puede asumir los tres roles:
• Es difícil pero es posible.
• Se deben tener en cuenta las diferencias en los objetivos asociados a cada rol.
• Otras soluciones (como tener un equipo de pruebas independiente) suelen ser más
fáciles y producir mejores resultados.
64
Las personas y los proyectos se conducen en base a

objetivos. Las personas tienden a alinear sus planes con los
objetivos establecidos por los gestores u otros responsables,
por ejemplo: encontrar defectos o confirmar que funciona el
software.
Por eso es importante establecer de una forma clara los

objetivos de las pruebas.
65
La mentalidad a utilizar durante las pruebas y revisiones es

distinta a la que hay que tener durante el desarrollo.
El desarrollador. El probador.
• Transforma los requisitos. • Planifica sus pruebas.
• Desarrolla estructuras. • Especifica casos de prueba.
• Programa el software. • Sólo quiere encontrar errores.
• Consigue un producto. • Los errores del programador son
su éxito.
⇒ ¡El desarrollador es constructivo!. ⇒ ¡El probador es destructivo!.
¡Falso!
¡También las pruebas son constructivas, ya que su objetivo es
un producto libre de errores!
66
Las dificultades
• El probador experimentado mantiene una distancia suficiente respecto del
objeto de la prueba.
• Cuanto más alejado esté el probador del desarrollo más
independientemente y más objetivamente podrá llevar a cabo su trabajo.
• Una distancia demasiado grande respecto del objeto de prueba puede,
sin embargo, provocar que se necesite más tiempo para las pruebas.
67
Posibles formas de llevar a cabo las pruebas

• Pruebas del desarrollador:
• El desarrollador nunca se mantiene neutral respecto de su “creación”.
• En definitiva conoce el objeto de prueba mejor que nadie.
• No se producen costes adicionales por tener que ponerse al corriente
respecto del objeto de prueba.
• El hombre tiende a ser ciego respecto a sus errores.
• Por eso existe el peligro para el desarrollador de no ver fallos evidentes.
• Los errores como consecuencia de una mala interpretación de los
requisitos quedan sin descubrir.
• Estos errores se pueden evitar, o al menos reducir, mediante la formación
de equipos de desarrollo en los que los desarrolladores comprueban
mutuamente sus productos.
68

• Pruebas diseñadas por otras personas del equipo de desarrollo.
• La formación de equipos de pruebas con miembros de diferentes áreas
del proyecto mejora la calidad de las pruebas.
• Es importante que estos equipos puedan trabajar lo más
independientemente posible.
• Pruebas diseñadas por personas de un grupo distinto perteneciente a la

organización (como un equipo de prueba independiente) o especialistas
en pruebas (como los especialistas en pruebas de usabilidad o
prestaciones).
69

• Pruebas diseñadas por personas de otras organizaciones (como
Outsourcing de pruebas o certificación realizada por un ente externo).
• Una separación completa de las pruebas consigue la mayor distancia
posible entre el objeto de prueba y el probador.
• En todo caso se dispone de poco conocimiento sobre el objeto de prueba
y el proyecto.
• Se requiere un gran esfuerzo de puesta al corriente.
• Los expertos externos deberían ser por ello involucrados desde las fases
tempranas del proyecto.
• Los expertos externos tienen en todo caso un Know-how muy
desarrollado acerca de las pruebas.
• La definición optima de los casos de prueba queda así garantizada.
• Como otra ventaja, la utilización óptima de métodos y herramientas, además
de una ejecución de las pruebas acorde.
70
Personalidad de un buen probador
• Curioso, atento a los detalles.

• Para comprender los escenarios prácticos en los que se mueve el cliente.
• Para ser capaz de analizar la estructura de la prueba.
• Para descubrir detalles que pueden identificar fallos.
• Escepticismo y ojo crítico.
• Los objetos de prueba contienen defectos. Se trata de encontrarlos.
• No se debe ver limitado por el hecho de que un error grave pueda afectar a (por
ejemplo) las fechas del proyecto.
71
Personalidad de un buen probador

• Buenas capacidades de comunicación.
• Para dar malas noticias a los desarrolladores.
• Para no perder la perspectiva ante situaciones frustrantes.
• Para establecer rápidamente una relación de trabajo con los desarrolladores.
• La comunicación positiva puede ayudar a evitar o facilitar situaciones
complicadas.
• Experiencia.
• Los factores personales influyen en la ocurrencia de errores.
• La experiencia ayuda a identificar donde se pueden acumular los errores.
72
Problemas de comunicación
• Especialmente en fases del proyecto estresantes la notificación de los
errores puede generar problemas, sobre todo si los probadores son vistos
como portadores de malas noticias.
• La manera de notificar el error y la descripción del mismo son decisivos.
• No criticar a las personas sino mostrar el error de forma objetiva.
• Facilitar la solución del error al desarrollador mediante la notificación.
• El objetivo común debe estar siempre en primer plano.
• Una comunicación insuficiente o la ausencia de ésta entre probadores y
desarrolladores puede impedir el buen trabajo en equipo.
• En ocasiones, no hay entendimiento entre el equipo de pruebas y el de
desarrollo.
• Los desarrolladores deberían tener nociones básicas de pruebas.
• Los probadores deberían conocer las características esenciales del desarrollo de
software.
73
Problemas de comunicación
• Hay, sin embargo, varias formas de mejorar la comunicación y las relaciones

entre los probadores y el resto:
• Empezar a colaborar, en vez de entrar en refriegas - recordar a todos que el objetivo
común es obtener sistemas de mejor calidad.
• Comunicar lo que se ha encontrado en el producto de forma neutra, enfocada a los
hechos, sin criticar a la persona que lo ha creado, por ejemplo, redactando informes
de incidencias y revisiones de forma objetiva y ateniéndose a los hechos.
• Intentar comprender como se siente la otra persona y por qué reacciona como lo
hace.
• Confirmar que la otra persona ha entendido lo que has dicho y viceversa.
74
08 – Código de buenas prácticas
Necesario porque:
• Debido a su participación en las pruebas del software el probador podría
acceder a cierta información privilegiada y confidencial.
• Es necesario, entre otras razones, asegurar que dicha información no es
objeto de un uso inapropiado.
El ISTQB establece el siguiente código de buenas prácticas:
• PUBLICO: Los probadores de software certificados actuarán conforme al interés
público.
• CLIENTE Y PROVEEDOR: Los probadores de software certificados actuarán de la
mejor manera posible para el interés de sus clientes y proveedores a los que
pertenecen, de conformidad con el interés público.
• PRODUCTO: Los probadores de software certificados asegurarán que los entregables
que proporcionen cumplan con los más altos estándares profesionales posibles.
• JUICIO: Los probadores de software certificados mantendrán integridad e
independencia en sus juicios profesionales.
75
08 – Código de buenas prácticas
El ISTQB establece el siguiente código de buenas prácticas (cont.):

• GESTIÓN: Los jefes y gestores de pruebas de software certificados promoverán y
contribuirán con un enfoque ético de la gestión de las pruebas del software.
• PROFESIÓN: Los probadores de software certificados potenciarán la integridad y
reputación de la profesión de conformidad con el interés público.
• COMPAÑEROS: Los probadores de software certificados serán justos y de apoyo a
sus compañeros y promoverán la cooperación con los desarrolladores de software.
• UNO MISMO: Los probadores de software certificados participarán en el aprendizaje
permanente en lo que respecta a la práctica de su profesión y promoverán un enfoque
ético en la práctica de su profesión.
76
09 – Resumen
Afirmaciones importantes del capítulo:

• Las pruebas son el instrumento principal para el aseguramiento de la calidad
durante el desarrollo de software.
• La Norma ISO 9126 establece el término de calidad de software.
• Las pruebas completas de programas son prácticamente imposibles.
• El software no está casi nunca libre de errores.
• La ausencia de errores no puede ser constatada en la práctica mediante
pruebas.
• Los costes de las pruebas se contrastan siempre con los costes de los errores.
• Las pruebas son un proceso en sí dentro del proceso de desarrollo.
• Para cada caso de prueba son necesarios datos de entrada y valores
esperados, así como condiciones previas y posteriores.
77
09 – Resumen

• Para mantener un número manejable de los casos de prueba hay que
priorizar.
• Nadie trabaja sin errores – en todos los desarrollos ocurren errores.
• Sin embargo, la naturaleza del hombre hace difícil reconocer los propios
errores – ceguera frente a errores.
• Chocan “dos mundos”.
• Desarrollar es constructivo – ¡se crea algo!.
• Probar es “destructivo” – ¡se deben y se tienen que demostrar los errores!.
• Sin embargo, en conjunto ambas actividades son constructivas, siendo su
objetivo común construir programas con el menor número de defectos
posible.
• Según la estrategia de pruebas, prueban los desarrolladores, los equipos
de pruebas o expertos externos.
• Para asegurar que la información accedida por el profesional de pruebas
no es objeto de un uso inapropiado, el ISTQB establece un código de
buenas prácticas (8)
78
79
Capítulo III – Las pruebas en el ciclo
de vida del software
• III/01 Modelos de desarrollo de software.
• III/02 Niveles de prueba.
• Pruebas de componentes.
• Pruebas de integración.
• Pruebas del sistema.
• Pruebas de aceptación.
• III/03 Tipos de prueba.
• III/04 Pruebas de mantenimiento.
• III/05 Resumen.
80
III – Las pruebas en el ciclo de vida del software
01 – Modelos de desarrollo de software
Modelos de procedimiento
• Los modelos de procedimiento relacionan métodos de desarrollo de software
con fases de proyecto para permitir un desarrollo del proyecto estandarizado.
• Las pruebas encajan en el modelo, estando asociadas a actividades de
desarrollo.
• Ejemplos de modelos de procedimiento:
• Modelo en cascada.
• Modelo genérico en V.
• Modelo en V 97 (Modelo de procedimiento de la federación).
• Modelo en V XT (nuevo modelo de procedimiento de la federación [2004]).
• Extreme Programming (XP).
81
01.1 – Modelos de desarrollo de software
Las pruebas en el modelo genérico en V

• El modelo genérico en V es un modelo de procedimiento para el proceso de
desarrollo de software (secuencial).
• El desarrollo y las pruebas se representan mediante dos ramas de la misma
consideración.
• Cada fase del desarrollo se contrapone
a una fase diferente de las pruebas.
Especificación Pruebas de
de requisitos aceptación • La preparación de las pruebas se lleva
Diseño Pruebas del a cabo de manera paralela al desarrollo
funcional sistema
de software, de hecho, en cada etapa .
Diseño
técnico
Pruebas de
integración
• Se prueba durante el ciclo de vida
completo del software.
Especificación de Pruebas de
componentes componentes • Puede haber más o menos fases:
pruebas de integracion de
Codificación
componentes y de integración de
sistemas.
82

• Fases del desarrollo (Rama izquierda)
• Definición de requisitos.
• Definición de las características
Especificación
del software. de requisitos
• Diseño funcional. Diseño

funcional
• Conversión de los requisitos en
funciones y procesos. Diseño
técnico
• Diseño técnico. Especificación de
componentes
• Definición del entorno del sistema.
• Diseño de interfases etc. Codificación
• Diseño de la arquitectura del sistema.
83

• Fases del desarrollo (rama izquierda).
Especificación
• Especificación de componentes. de requisitos
• Elaboración de los componentes. Diseño

funcional
• Unión de los componentes.
Diseño
técnico
• Codificación.
Especificación de
• Transformación de los componentes en componentes
código ejecutable.
Codificación
84

• Fases de pruebas (rama derecha).
• Pruebas de componentes. Pruebas de
aceptación
• Se prueba la funcionalidad de cada
componente individual. Pruebas del
sistema
Pruebas de
integración
• Pruebas de integración.
Pruebas de
• Probar si los componentes individuales componentes
trabajan en conjunto tal y como se
esperaba. Codificación
• Se prueban funciones que abarquen

varios componentes.
85

• Fases de pruebas (rama derecha).
• Pruebas del sistema. Pruebas de
aceptación
• Prueba de los requisitos que debe
cumplir el sistema completo. Pruebas del
sistema
Pruebas de
integración
• Pruebas de aceptación.
Pruebas de
• Pruebas del cliente para comprobar el componentes
cumplimiento de los requisitos
especificados. Codificación
86

• Cada una de las fases del desarrollo se
verifica respecto de su fase anterior. Especificación Pruebas de
de requisitos aceptación
• verificar: demostrar, comprobar.
Diseño Pruebas del
funcional sistema
• La verificación se refiere aquí a la
comprobación acerca de si los supuestos Diseño técnico
Pruebas de
integración
trasladados de la fase anterior han sido
correctamente implementados. Especificación de
componentes
Pruebas de
componentes
Codificación
Desarrollo
e integración
Verificación
87
• Mediante las fases de prueba se validan las fases de desarrollo.

• validar: reforzar, reconocer como válido
Diseño Pruebas del

funcional sistema
Desarrollo
Diseño Pruebas de e integración
técnico integración
Especificación de Pruebas de Verificación

componentes componentes
Validación
Codificación
88

• Ambas partes del modelo han de ser consideradas de igual valor.
• Algunas actividades se pueden desarrollar en paralelo, de esta forma se
pueden concluir con anticipación la especificación de casos de prueba / la
planificación de las pruebas. Otras actividades deben ser postergadas.
Diseño Pruebas del

funcional sistema
Desarrollo
Diseño Pruebas de e integración
técnico integración
Especificación de Pruebas de Verificación

componentes componentes
Validación
Codificación
89

• El modelo en W puede verse como una ampliación del modelo genérico en V
• En el modelo de W queda claro que ciertas actividades de pruebas pueden
establecerse como procesos paralelos al propio desarrollo de software.
Especificación de Planificación Ejecución pruebas de Debugging y

requisitos actividades test aceptación corrección de errores
Planificación pruebas Ejecución pruebas Debugging y

Diseño funcional
de sistema del sistema corrección de errores
Planificación pruebas Ejecución pruebas de Debugging y

Diseño técnico
de integración integración corrección de errores
Especificación de Planificación pruebas Ejecución pruebas Debugging y

componentes de componentes de componentes corrección de errores
Codificación
90
Modelos de desarrollo iterativos-incrementales
• Desarrollo de software iterativo
• Las actividades: definición de requisitos, diseño, desarrollo y pruebas se dividen en
etapas pequeñas y se lanzan continuamente.
• Para poder reorientar el proyecto si es necesario debe alcanzarse un consenso con
el usuario tras cada iteración.
• Ejemplos de modelos iterativos
• Prototipado: construcción rápida de una representación utilizable del sistema,
seguida de modificaciones sucesivas hasta que el sistema esté preparado.
• Rapid Application Development (RAD): la interfaz del usuario se implementa
mediante funcionalidad comercial, ignorando la funcionalidad que será desarrollada
con posterioridad.
• Rational Unified Process (RUP): modelo orientado a objeto, producto de Rational /
IBM. Proporciona sobre todo el lenguaje UML y soporte para el proceso unificado.
• Modelos de desarrollo ágiles, como Extreme Programming (XP): el desarrollo y las
pruebas se llevan a cabo sin que exista una especificación de requisitos
formalizada.
91
Las pruebas dentro del modelo de ciclo de vida
• Hay varias características asociadas a unas buenas pruebas que aplican a
todos los modelos de ciclo de vida:
• Para cada actividad de desarrollo hay una actividad de prueba asociada
• Cada nivel de prueba tiene objetivos específicos al nivel.
• Debería iniciarse el análisis y diseño de las pruebas de cada nivel durante la
actividad de desarrollo asociada
• Los probadores debieran involucrarse en la revisión de documentación tan pronto
como estén disponibles los borradores
• Se pueden combinar o reorganizar los niveles de prueba en función de la
naturaleza del proyecto o de la arquitectura del sistema. Por ejemplo, para la
integración de un software comercial (COTS) en un sistema, el comprador
podría llevar a cabo pruebas de integración a nivel de sistema (esto es:
integración con la infraestructura y con otros sistemas, o despliegue del
sistema) y pruebas de aceptación (pruebas funcionales y/o no funcionales; y
operacionales y/o de usuario).
92
02.1 – Niveles de prueba. Pruebas de componentes
Definiciones y conceptos
• Pruebas de componentes (Definición):
Pruebas de cada uno de los componentes básicos del software (componentes)
respecto de su programación.
Debido a las diferentes definiciones de componentes básicos de software en
los distintos lenguajes de programación existen diferentes definiciones para
las pruebas de componentes:
• Pruebas de módulo (denominadas así, p.ej., en C).
• Pruebas de clases (denominadas así, p.ej., en Java o C++ ).
• Pruebas de unidad (denominadas así, p.ej., en Pascal).
• Los componentes comprobados serán, respectivamente, módulos, clases o
unidades.
93
¿Qué se prueba?
• Pruebas completas de los componentes individuales.
• Un componente puede estar formado por varios elementos más simples.
• Cada componente se prueba de manera separada y aislada.

• Se deben buscar errores internos.
• Los efectos hacia otros componentes del programa quedan fuera de
consideración.
• Comentario.:
A nivel de pruebas de componentes puede tener sentido la ejecución de
pruebas de carga.
94
¿Dónde y como se prueba?
• Los objetos de prueba son componentes individuales programados

• Estos objetos de prueba son , por lo general, partes del programa que se puedan
ejecutar aisladamente
• El probador dispone del código de programa de los componentes
• Si Probador=Desarrollador (habitual):
se puede probar de forma muy cercana al desarrollo
• El conocimiento acerca de funciones, estructuras y variables pueden ser utilizados
para la generación de casos de prueba (caja blanca)
• A menudo se utilizan pruebas funcionales.
• Mediante herramientas (depuradores) se posibilita la observación y actuación
sobre las variables del programa.
• El conocimiento de código fuente posibilita, en general, la utilización de
procedimientos de caja blanca para las pruebas de componentes.
95
Generalidades
• Fuentes de casos:
• Especificación del componente.
• Diseño de SW.
• Modelo de datos.
• Objetos de prueba típicos:
• Componentes.
• Programas.
• Conversión de datos / migración de programas.
• Módulos de base de datos.
• Los defectos suelen corregirse según se prueba.
• No se suelen documentar los errores.
• Una posible aproximación es preparar y automatizar las pruebas antes de
codificar (“test first approach” o “test driven development”). Son modelos
iterativos válidos para cuando las modificaciones suelen ser pequeñas.
96
• Para la ejecución de los casos de prueba se utilizan, por regla general, stubs
(maquetas) y, según el caso, controladores de pruebas
• El controlador de pruebas constituye o utiliza la interfase abierta del objeto de
prueba (componente)
• Los controladores de pruebas posibilitan la ejecución de los componentes en el
entorno del software
• Los controladores de pruebas simulan entradas, p.ej., del usuario
• Los controladores de pruebas recogen valores de salida
• Los controladores de pruebas proporcionan normalmente entornos de ejecución
de software
• Opcionalmente un controlador de pruebas también permite el registro de
diferentes valores.
97
• Los controladores de pruebas pueden ser programados por uno mismo si:
• Se tiene conocimientos de programación.
• El código de programa está disponible.
• Se dispone de herramientas de programación.
• Los stubs se necesitan cuando los componentes a probar requieren por su

parte entradas o deben manipular salidas. Reemplazan o simulan
componentes que aún no están disponibles.
• Los stubs no contienen a diferencia de los controladores ninguna o una
muy pequeña lógica de programación.
• Los stubs proporcionan en ocasiones datos de pruebas (Dummies).
98
Relación entre:
• Componentes,
• Controladores de pruebas,y
• Stubs.
Controlador Datos
Componente
de pruebas de prueba
Stub
99
¿Porqué se prueba?
• Pruebas funcionales
• Las pruebas de componentes deben asegurar su funcionalidad:
• ¿Se cumplen todas las especificaciones?.
• ¿Se ejecutan correctamente todas las funciones?.
• Cada una de las funciones de un componente se comprueba, al menos,
con un caso de prueba.
• Los errores frecuentes que se pueden encontrar con estas pruebas son:
• Errores en la elaboración.
• Ausencia de funciones.
100
• Pruebas de robustez
• Se prueba cómo de robusto es un componente.
• La robustez describe la capacidad de respuesta de un software frente a
entradas incorrectas, etc.
• La robustez se prueba mediante casos de prueba negativos.
• Los casos de prueba negativos son casos que contienen datos de entrada
incorrectos o no permitidos.
• Si el componente dispone de un tratamiento de excepciones para cada
posible entrada de datos errónea, se considera robusto.
• Sin el correspondiente tratamiento de excepción los datos erróneos se
introducen en el proceso y pueden ocasionar errores.
• Las posibles consecuencias son caídas y mal funcionamiento de los
componentes
101
• Otras pruebas posibles
• Según los requisitos también deben ser cumplidas otras características
de la calidad de software.
• Junto a la funcionalidad y la robustez también podrían jugar un papel

dentro de las pruebas de componentes otros aspectos como la eficiencia
y la capacidad de modificación.
102
02.2 – Niveles de prueba. Pruebas de integración
• Prueba de integración (Definición):
Pruebas de la interrelación de los elementos del software (componentes) tras
su integración
• La integración es el proceso por el cual los elementos básicos del software

(componentes) son agrupados en elementos mayores.
• Si estos elementos se unen a su vez entre sí, esto también pertenece a la
integración.
• Aún cuando los componentes básicos pasen sin error las pruebas de
componentes debe comprobarse su funcionalidad externa.
• Ello implica pruebas de interoperabilidad entre diferentes componentes de un
software
103
¿Qué se prueba?
• En las pruebas de integración se comprueba la interoperabilidad entre

elementos básicos (grupos de elementos) del software.
• Funcionalidad de las interfases.
Cada elemento básico debería haber sido comprobado antes de que

comience la integración.
• Comentario (sobre la psicología de las pruebas):

En las pruebas de integración debería tenerse en cuenta que existe la
posibilidad de tener que reunir los resultados de diferentes desarrolladores y/o
equipos de pruebas.
104
¿Qué se prueba?
• En las pruebas de integración se comprueban también las interfases con el
entorno del sistema.
• En la mayoría de los casos sólo se comprueba el comportamiento de salida de

los elementos agrupados frente al comportamiento de entrada simulado del
entorno.
• Bajo condiciones reales puede haber factores adicionales que afecten al

funcionamiento del componente.
Las pruebas de integración no pueden por ello garantizar una funcionalidad sin
defectos en el entorno real del sistema.
105
¿Donde y cómo se prueba?

• Se comprueba un sistema (parte de un sistema) que se compone de
componentes individuales.
• Cada uno de los componentes tiene una interfase externa o que lleva a
otro componente del sistema (sistema parcial).
• Se necesitan de nuevo controladores de pruebas (que proporcionan el entorno
de ejecución del sistema / subsistema) que:
• Produzcan/posibiliten entradas y salidas para el sistema / sub-sistema.
• Registren datos.
Aquí pueden ser reutilizados los controladores de casos de pruebas utilizados
en las pruebas de componentes.
106
¿Donde y cómo se prueba?
• En este punto se pueden introducir con sentido monitores que permitan un

control de las pruebas mediante la captura de datos.
• Los stubs sustituyen a los componentes que faltan:

• Los datos/funciones de un componente que no hayan sido integrados se
introducen mediante stubs especialmente programados.
• Los stubs asumen las tareas elementales de los componentes que
falten.
107
¿Por qué se prueba?
• Las pruebas de integración persiguen encontrar errores de interfases, se

comprueba el correcto funcionamiento conjunto de los componentes (entre
otras cosas también con vistas al rendimiento o a la seguridad).
• Se efectúan pruebas de integración, entre otros motivos, por motivos de
migración (pruebas de conformidad, pruebas de compatibilidad).
• Para esto son necesarios otros procedimientos de pruebas.
108
¿Por qué se prueba?
• Los errores de interfase no aparecen hasta después de la integración de los
elementos básicos:
• Si se cambian los controladores de pruebas y los stubs por interfases de
componentes “reales” pueden aparecer circunstancialmente errores.
• P. ej. se pueden perder ciertos datos, no transmitirse o transmitirse de manera
errónea, etc.
• Las pruebas de integración deberían asentarse sobre las pruebas de
componentes:
• Todos los errores de las pruebas de componentes podrían ser encontrados, en
principio, en las pruebas de integración pero sería muy complicado localizarlos.
• Probar los componentes en el nivel de integración es confuso.
• No todos los casos de prueba pueden siquiera “lanzarse”.
109
Pruebas e integración
• Existen diferentes alternativas para las estrategias de integración.
• Generalmente las estrategias serán establecidas por el gestor/responsable de
pruebas.
• El modo de proceder incremental es común a todas las estrategias (excepción:
Big Bang).
• La elección de la estrategia deberá tener en cuenta la eficiencia de las
pruebas
• La estrategia de integración decide acerca del esfuerzo de las pruebas (p.ej.
utilización de herramientas, programación de controladores de pruebas, stubs
etc.)
• La terminación de los componentes fija para cada estrategia de integración el
marco temporal.
• Sin unos componentes probados no es eficaz una estrategia de integración
encaminada a ahorrar esfuerzos.
110
• En función del proyecto se deberá sopesar entre el ahorro de tiempo y el
esfuerzo para las pruebas:
• Probar lo que está terminado – eventualmente mayor esfuerzo, por el
contrario, no existen periodos de inactividad.
• Seguir una estrategia establecida – menor esfuerzo pero, por el
contrario, eventualmente, periodos de inactividad.
111
• Estrategias de integración
• Estrategia Bottom-Up:
• Se lleva a cabo una integración de abajo a arriba.
• Se empieza por aquellos componentes que no llaman a otras partes del
programa.
• Siguen paso a paso los componentes que sólo llaman a la parte ya
integrada.
• Se aplica en desarrollos nuevos, pruebas de equipos grandes y
distribuidos.
112
• Características de la estrategia Bottom-Up:
• No existen huecos que deban ser completados por stubs.
• Los componentes superiores deben ser simulados mediante controladores
de pruebas.
• Implantación de la estrategia Bottom-Up:
• La implantación de la estrategia sólo es posible para software construido
jerárquicamente de manera constante – por ello en su forma pura no tiene
apenas relevancia práctica.
113
• Estrategia Top-Down:
• La integración se lleva a cabo sistemáticamente de arriba a abajo.
• Se empieza por los componentes que no son llamadas desde otros
componentes del software.
• Paso a paso se integran aquellos componentes que únicamente son
llamados desde la parte ya integrada.
• Se aplica cuando se utiliza software ajeno o Frameworks.
114
• Características de la estrategia Top-Down:
• Debido a la forma de proceder no son necesarios controladores de
pruebas.
• Todos los componentes subordinados deben ser sustituidos por stubs.
• Implantación de la estrategia Top-Down:

• La implantación de la estrategia sólo es posible para software construido
jerárquicamente de manera continuada – por ello en su forma pura no tiene
apenas relevancia práctica.
115
• Integración orientada al proceso de negocio:
• La integración se lleva a cabo por procesos de negocio.
• En cada caso se integran los componentes necesarios por parte de un
proceso de negocio.
• También se denominan como pruebas End-to-End.
• Características de la integración orientada al proceso de negocio:
• Los controladores de pruebas sustituyen los componentes de rango
superior.
• Todos los componentes subordinados de deben sustituir por stubs.
116
• Integración orientada a funciones:
• La integración se orienta a una función del sistema escogida.
• Se integra cada uno de los componentes necesitados por la función
correspondiente del sistema.
• Características de la integración orientada a funciones:

• Los controladores de pruebas sustituyen a los componentes de rango
superior.
• Todos los componentes subordinados deben ser sustituidos mediante
stubs.
117
• Integración Ad-Hoc:
• Los componentes ya probados son integrados – en tanto sea posible-
inmediatamente después de su programación y comprobación exitosa.
• Características de la integración Ad-Hoc:
• No existen retrasos en las pruebas, por lo que ocasionalmente se puede
lograr un acortamiento del proceso completo de desarrollo del software.
• Dependiendo del tipo de componente terminado pueden ser necesarios
stubs y controladores de pruebas.
• Implantación de la estrategia Ad-Hoc:
• La integración Ad-Hoc puede ser empleada en cualquier situación – en la
práctica suele ser combinada con otras estrategias.
118
• Integración no incremental (big bang):
• Se integra en el momento en que se dispone de todos los componentes.
• Esta estrategia se aplica, p. ej., en proyectos de mantenimiento o
ampliación, así como en el marco de migraciones.
• Características de la integración no incremental:
• El área de las pruebas tiene mucho “tiempo muerto” – no se puede probar
durante largo tiempo.
• Las pruebas se hacen más complicadas y más amplias - los efectos de los
errores aparecen con frecuencia y son difíciles de rastrear.
119
• ¿Como se pueden coordinar la integración y las pruebas?
La integración debe llevarse a cabo de acuerdo Las pruebas deben ser eficientes, es decir,
con la arquitectura del sistema y la preparación encontrar el mayor número de errores graves
de los componentes. sin utilizar para ello demasiados recursos.
Se dispone de una estrategia de integración

que sirve también de base para el proceso de En la planificación de las pruebas se
pruebas. determinan el tiempo y el resto de recursos
Determina también el esfuerzo de las pruebas para las pruebas – ¡si no se puede probar
pero depende de la disponibilidad de los según el plan aparecen costes adicionales!
componentes.
En principio el orden de la preparación determina la

integración - y de esta manera también el curso de las
pruebas .
Se debe componer una estrategia que se adapte
individualmente.
120
Generalidades
• Diferentes niveles de Pruebas de integración:
A parte de las pruebas de integración de componentes, puede haber más
niveles de pruebas de integración y, éstas, se pueden llevar a cabo en objetos
de prueba de diversos tamaños. Un ejemplo sería:
• Pruebas de integración de sistemas: se prueban las interacciones entre
diferentes sistemas o entre hardware y software y podría llevarse a cabo después
de las pruebas de sistema. En este caso, puede que la organización
desarrolladora controle sólo un lado de la interfaz. Esto podría considerarse como
un riesgo.
• Diseño de software y del sistema
• Arquitectura
• Workflows
• Casos de uso
121
Generalidades
• Implementación de bases de datos de subsistemas
• Infraestructura
• Interfaces
• Configuración del sistema
• Configuración de datos
122
02.3 – Niveles de prueba. Pruebas de sistema
• Pruebas del sistema (Definición):

• Comprobación del sistema integrado completo respecto del cumplimiento de
los requisitos específicos.
• Desde el punto de vista técnico ya se han probado todos los componentes y

su interrelación – faltan las pruebas del sistema completo en condiciones de
funcionamiento y desde el punto de vista del usuario:
• entorno
• funciones
• carga
• …
123
¿Qué se prueba?
• Pruebas del sistema integrado desde el punto de vista del usuario
• Implantación completa y correcta de los requisitos.
• Implantación en el entorno real del sistema y con datos cercanos a la práctica.
• El entorno de pruebas debería corresponderse con el entorno de producción
• Se omiten los controladores de pruebas y los stubs.
• Todas las interfaces externas del sistema se probarán bajo condiciones de
producción.
• Recreación lo más exacta posible del entorno posterior de producción.
• Pero: ninguna prueba en el entorno de producción

• Los errores surgidos pueden dañar el sistema productivo.
• El entorno del sistema está en movimiento - las pruebas no son reproducibles.
124
¿Por qué y como se prueba?
• Las pruebas del sistema deben validar el cumplimiento de los requisitos

establecidos.
• En principio se prueba la calidad del software para el usuario.
• De acuerdo con la calidad de software según (ISO 9126) las pruebas del
sistema diferencian entre requisitos:
• Funcionales
• Funcionalidad
• No funcionales
• Fiabilidad
• Usabilidad
• Eficiencia
• Mantenibilidad
• Portabilidad
125
Requisitos funcionales
• Cuestión: ¿Las características requeridas quedan implementadas por las
funciones disponibles?
• El sistema debe ser probado en los siguientes puntos:
• Idoneidad
• ¿Son adecuadas las funciones disponibles para la utilización prevista?
• Precisión
• ¿Se ejecutan las funciones correctamente (como estaba acordado)?
• interoperabilidad
• ¿Se proporciona una interrelación libre de errores con el entorno del
sistema?
• Conformidad
• ¿Se cumplieron las normas y preceptos?
• Seguridad
• ¿Están protegidos los datos /programas frente a accesos/pérdidas?
126
Requisitos funcionales
• Las pruebas de los requisitos funcionales pueden incluir:

• Pruebas basadas en riesgos y/o especificaciones de requisitos:
• Los casos de prueba se deducen a partir de la definición de requisitos.
• El número de casos de prueba varía en función de los requisitos.
• Pruebas basadas en procesos de negocio:
• Los procesos de negocio individuales sirven como base para la
creación de los casos de prueba.
• Se puede trasladar la importancia de los procesos a la priorización de
casos de prueba.
• Pruebas basadas en casos de uso:
• Los casos de prueba se deducen a partir de los casos de uso –
procesos habituales del usuario.
• Aquellos casos de uso más frecuentes tendrán mayor prioridad en las
pruebas.
• Cualquier otra descripción de alto nivel del comportamiento del
sistema.
127
Requisitos no funcionales
(Eficiencia, fiabilidad, usabilidad, mantenibilidad, portabilidad)
• Los requisitos no funcionales vienen especificados, entre otras, en la norma

ISO 9126.
• Junto a aspectos como rendimiento o seguridad, la ergonomía (usabilidad)

representa un importante requisito no funcional.
• Los requisitos de ergonomía vienen descritos en la norma ISO 9241, sobre

todo en el capítulo 10, p.ej., tolerancia a fallos, facilidad de aprendizaje y
adecuación a las tareas.
128
• El cumplimiento de estos requisitos es igual de importante pero a menudo

difícil de probar y por ello están sometidos a un mayor riesgo.
• En la definición de requisitos no esta siempre claro “como de bien” debe

funcionar algo:
• A menudo definiciones vagas (manejar sin problemas, pantallas claras,
etc.).
• Los requisitos no funcionales se dan a menudo de manera implícita y por
este motivo no se definen.
129
• La prueba de un requisito no funcional se da como superada si se consigue un

determinado valor en una métrica establecida:
• P.ej., métrica para la fiabilidad del software:
• MTBF – Mean Time Between Failure/Tiempo medio entre fallos
• MTTR – Mean Time To Repair/Tiempo medio de reparación
• De todos modos suele ser difícil una cuantificación de los requisitos no

funcionales.
130
• Pruebas de carga.
• ¿Cómo se comporta el sistema bajo condiciones de carga nominales (número
creciente de usuarios/acciones)?
• Pruebas de rendimiento.
• ¿Cómo de rápido es el sistema en determinadas funciones/casos de uso?
• Pruebas de volumen / Pruebas masivas.

• ¿Como se comporta el sistema al procesar grandes cantidades de conjuntos de
datos/archivos?
• Pruebas de estrés
• ¿Como reacciona el sistema con sobrecarga?
• ¿Como reacciona el sistema al regresar al modo de funcionamiento normal?
131
• Pruebas de seguridad (- de datos).

• ¿Está protegido el sistema frente a accesos no autorizados?.
• ¿Están protegidos los datos frente a accesos no autorizados o pérdidas?.
• Pruebas de estabilidad.
• ¿Con qué frecuencia se cae el sistema por unidad de tiempo determinada?.
• Comportamiento del sistema en funcionamiento prolongado.
• Pruebas de robustez.
• ¿Cómo reacciona el sistema frente a una utilización incorrecta o frente a errores
de entrada (manejo de excepciones)?.
• Comportamiento de sistema frente a defectos de hardware y el regreso al
funcionamiento normal.
132
• Pruebas de compatibilidad (Conversión de datos)

• ¿Cómo trabaja el sistema junto con otros programas?
• ¿Qué interfases existen hacia otros programas?
• ¿Cómo reacciona el sistema en diferentes entornos (Hardware, S.S.O.O., etc.)?
• Pruebas de idoneidad de uso (usabilidad)

• ¿Cómo de visible y comprensible es el sistema?
• ¿Con qué facilidad puede aprender su manejo el usuario típico?
133
• Comprobación de la documentación
• ¿Concuerda la documentación del programa con el sistema real?
• ¿La documentación se ha escrito de manera clara y comprensible?
• Comprobación de la mantenibilidad
• ¿Se dispone de documentos adecuados acerca del desarrollo del sistema?
• ¿Se han cumplido los estándares de código preestablecidos?
• ¿Tiene el sistema una arquitectura estructurada (modular)?
134
Generalidades
• Especificación de requisitos del software y del sistema
• Casos de uso
• Especificación funcional
• Informes de análisis de riesgos

• Manuales de usuario, del sistema y de operación
• Configuración del sistema
135
02.4 – Niveles de prueba. Pruebas de aceptación
• Pruebas de aceptación (Definición):
Las pruebas de aceptación comprueban el producto desde el punto de vista del usuario
o del cliente antes de su paso a producción – ¿Se cumplen las expectativas del
usuario/cliente?
• El usuario/cliente está involucrado, dependiendo del grado, en la personalización del

software
• El software personalizado suele ser probado a menudo directamente por el
solicitante/cliente
• Para productos “de masas” se involucra a una selección representativa de
usuarios en las pruebas
136
Posibles formas de las pruebas de aceptación
• Pruebas de aceptación contratada

• La aceptación en sí del producto por parte del cliente – el cliente
comprueba si el producto cumple con los requisitos contratados
• Primeras pruebas en las que el cliente debe estar involucrado

activamente (en todo caso es aconsejable involucrar al cliente en las
pruebas ya durante la fase de desarrollo de prototipos).
• Se rige por criterios de aceptación acordados por contrato
• Suelen estar cubiertas por el fabricante ya con las pruebas del sistema
137
• Pruebas de aceptación contratada

• El cliente determina los casos de prueba para las pruebas de aceptación.
• Posibles mal interpretaciones de los requisitos pueden ser eliminadas –
“solo el cliente sabe lo que realmente quiere”.
• Las pruebas se hacen en el entorno del cliente.

• En ocasiones son posibles efectos de errores debido al entorno del cliente
– eventualmente ha podido ser modificado desde el comienzo del proyecto.
138
• Pruebas de aceptación del usuario

• ¿Se acepta el software por parte de los usuarios últimos?
• Se comprueba si es posible ya durante el desarrollo (p.ej., mediante
prototipos)
• Se comprueba si el software
• Cumple las expectativas de diferentes usuarios
• Deja una impresión positiva en el usuario
• Muestra errores graves, que reducen la aceptación por parte del usuario
139

• Pruebas de aceptación del usuario
• Las pruebas de aceptación deben realizarse en función de la
personalización del software.
• En la personalización de software específica para un cliente deben ser
cumplidos obligatoriamente los requisitos de los grupos de usuarios
especiales.
• Para el software estándar suele ser normalmente difícil conseguir una
aceptación general debido al gran número de grupos de usuarios
140

• Pruebas de aceptación operacional
• Aceptación del sistema por parte de los Administradores. Incluyen:
• Pruebas de backup/restore
• Recuperación de desastres
• Gestión de usuarios
• Tareas de mantenimiento
• Tareas de carga y migración de datos
• Comprobación periódica de vulnerabilidades de seguridad
141
• Pruebas de campo (alfa y beta)

• Distribución anticipada de versiones estables del software (versiones
beta) a una selección representativa del círculo de clientes
• Los clientes prueban en sus respectivos entornos de producción y
documentan los efectos de los errores, etc.
• Pruebas en escenarios predeterminados o implantación de versiones beta
en el entorno normal del usuario
• Alternativamente primero pruebas a nivel alfa de una versión previa
(versión alfa)
• Usuarios representativos del entorno del productor llevan a cabo estas
pruebas.
142
• Pruebas de campo (alfa y beta)

• Las pruebas de campo deben asegurar más allá de las pruebas del
sistema, que el software se puede ejecutar en un gran número de
entornos diferentes.
• La utilización de pruebas de campo

• Reduce el esfuerzo de las pruebas del sistema y
• Posibilita pruebas de mayor alcance (posibilidad de pruebas en entornos
diferentes, etc.).
143
Generalidades
• Requisitos de usuario
• Requisitos de sistema
• Casos de uso
• Procesos de negocio
• Informes de análisis de riesgos
• Procesos de negocio en el sistema integrado completo
• Procesos operacionales y de mantenimiento
• Procedimientos de usuario
• Formularios
• Informes
144
03 – Tipos de prueba
Tipos de prueba
• Puede haber grupos de actividades de prueba encaminados a la verificación

del software de un sistema (o de parte de un sistema) que estén basadas en
una razón u objetivo de prueba determinados.
• Cada tipo de prueba se centra en un objetivo de prueba en particular, como la
prueba de una función que tiene que realizar el software, una característica de
calidad no funcional como fiabilidad o usabilidad, la estructura o arquitectura
del software o del sistema; o relacionado con cambios, esto es, confirmar que
se han corregido los defectos (pruebas de confirmación) y buscar cambios no
intencionados (pruebas de regresión).
• Se puede elaborar un modelo de software y/o utilizarlo en las pruebas
estructurales (ej.: un modelo de flujo de control o un modelo de estructura de
menús); en las pruebas no funcionales (ej.: modelo de usabilidad); y, en las
pruebas funcionales (ej.: un modelo de flujo de procesos, un modelo de
transición de estados o una especificación en lenguaje sencillo)
145
03.1 – Tipos de prueba
Pruebas funcionales
• Las funciones que tiene que realizar un sistema, subsistema o componente
pueden ser descritas en productos de trabajo, como una especificación de
requisitos, casos de uso, o una especificación funcional, o bien pueden
quedar indocumentados. Las funciones son “qué” hace el sistema.
• Las pruebas funcionales se basan en funciones y rasgos (descritos en
documentos o sobreentendidos por los probadores) y en su
interoperabilidad con sistemas específicos, y pueden llevarse a cabo en
todos los niveles de prueba (por ejemplo, las pruebas de componentes
pueden basarse en la especificación del componente).
• Pueden usarse técnicas basadas en especificaciones para obtener casos
de prueba a partir de la funcionalidad del software o del sistema (véase
Capítulo 5). Las pruebas funcionales toman en consideración el
comportamiento externo del software (pruebas de caja negra).
• Existe un tipo de prueba funcional, la prueba de seguridad que investiga las
funciones (por ejemplo, un cortafuegos) relativas a la detección de
amenazas, como virus, de intrusos maliciosos. Otro tipo de prueba
funcional, la prueba de interoperabilidad, evalúa la capacidad del producto
software para interactuar con uno o varios componentes o sistemas
específicos.
146
Pruebas no funcionales
• Las pruebas no funcionales incluyen, pero no están limitadas a, pruebas de

prestaciones, de carga, de estrés, de usabilidad, de mantenibilidad, de
fiabilidad y de portabilidad. Son las pruebas de “cómo” trabaja el sistema.
• Pueden realizarse pruebas no funcionales en todos los niveles de prueba. El
término prueba no funcional describe las pruebas necesarias para medir
características de sistemas y de software que pueden cuantificarse según una
escala variable, como pueden ser los tiempos de respuesta en las pruebas de
prestaciones. Estas pruebas pueden hacer referencia a un modelo de calidad
como el definido en ‘Software Engineering – Software Product Quality’ (ISO
9126).
147
Pruebas de la Estructura/Arquitectura del software (estructurales)

• Las pruebas estructurales (de caja blanca) pueden llevarse a cabo en todos
los niveles de prueba. Es mejor usarlas después de las técnicas basadas
en especificación, ayuda a medir con rigurosidad las pruebas, mediante la
evaluación de la cobertura de un tipo de estructura.
• La cobertura mide el grado con el que una suite de pruebas ha utilizado
una estructura. Si la cobertura no es del 100%, pueden diseñarse más
pruebas, para comprobar los elementos que se han pasado por alto y, por
consiguiente, incrementar la cobertura. Las técnicas de cobertura se tratan
posteriormente.
• En todos los niveles de prueba, pero especialmente en las pruebas de
componentes y en las de integración de componentes, se pueden utilizar
herramientas para medir la cobertura de código de elementos como
sentencias o decisiones. Las pruebas estructurales pueden basarse en la
arquitectura del sistema, como la jerarquía de llamadas.
• Los enfoques de prueba estructural pueden aplicarse también en los
niveles de prueba de sistema, integración de sistemas o aceptación (por
ejemplo, para los modelos de negocio o las estructuras de menús).
148
Pruebas después de la aceptación
• El cliente ha aceptado el producto y lo ha llevado a producción
• Las fases propias del desarrollo y las pruebas relacionadas han
finalizado.
• El software mismo está sin embargo al comienzo de su vida
• A menudo se implanta para muchos años y se sigue desarrollando.
• Seguro que sigue conteniendo errores y por ello se sigue trabajando
sobre él.
• Debe ser adaptado a nuevas condiciones o integrado en un nuevo
entorno.
• ¡Cada nueva versión del producto, cada nueva actualización y cualquier
otro tipo de cambio debe ser probado de nuevo!
149
Pruebas relativas a los cambios (Confirmación o re-prueba y regresión)

• Después de que se haya detectado y corregido un defecto, se debería volver a probar
el software par confirmar que el defecto original se ha eliminado con éxito. A esto se
le llama confirmación. La depuración (eliminación de defectos) es una actividad
de desarrollo, no de pruebas.
• Las pruebas de regresión consisten en la prueba repetida de un programa ya
probado, tras su modificación, para descubrir cualquier defecto introducido o
descubierto como resultado de uno o varios cambios. Estos defectos pueden estar,
bien en el software que se está probando o en otro componente software relacionado
o no relacionado. Se lleva a cabo cuando se cambia el software o su entorno. La
extensión de las pruebas de regresión viene dada por el riesgo de no encontrar
defectos en el software que estaba funcionando.
• Las pruebas deberían ser repetibles si van a utilizarse como pruebas de confirmación
y para ayudar a las pruebas de regresión
• Las pruebas de regresión pueden hacerse en todos los niveles de prueba y se aplican
tanto a pruebas funcionales como a no funcionales y estructurales. Los paquetes de
pruebas de regresión se lanzan muchas veces y suelen evolucionar lentamente, por
lo que son fuertes candidatos a la automatización.
150
04 – Pruebas de mantenimiento

• Mantenimiento de software (Correctivo y adaptativo)
• El mantenimiento de software distingue dos tipos de actividades
• El propio mantenimiento: eliminación de errores que ya existen desde
el desarrollo del software
• Cuidado del software: adaptación del software a condiciones de
implantación modificadas
• Pruebas de las modificaciones y eventualmente errores debido a las
mismas
• Continuación del desarrollo del software (Evolutivo)
• La continuación del desarrollo abarca medidas que se salen del
mantenimiento (continuación planificada del desarrollo)
• Ampliación de las interfases
• Ampliación de funciones
• Aquí se vuelve a recorrer otra vez el modelo de desarrollo
151
• ¿Cómo se prueban las modificaciones en el software?
• Pruebas de regresión
Pruebas de un sistema que ya ha sido comprobado por si, debido a las
modificaciones, surgen nuevos errores (p.ej., después de la corrección
de errores).
• Comentario:
Las pruebas de regresión son necesarias y se aplican ya antes de la
aceptación del producto.
152
• En función del alcance de las pruebas de regresión se distingue entre:
• Repetición de la prueba del error (también llamado Retest)
• Repetir la ejecución de los casos de prueba que han descubierto errores
para comprobar que fueron eliminados.
• Las repeticiones de las pruebas son, de esta manera, una parte de las
pruebas de regresión
• Pruebas de la funcionalidad modificada

• Pruebas de todas las partes del software que han sido modificadas
• Pruebas de nuevas funcionalidades

• Pruebas completas de las nuevas partes del programa
• Estas han sido previamente comprobados como componentes etc.
• Pruebas de regresión completas

• Las pruebas del sistema se ejecutan/repiten de nuevo
153
• El software reacciona a menudo frente a los cambios en lugares en los que no

se realizo ninguna modificación.
• Alcance de las pruebas de regresión:
• La repetición de las pruebas de la parte que generó el error no son suficientes por
si mismas para comprobar una modificación.
• Tampoco las pruebas exclusivamente de funciones nuevas o modificadas serían
apropiadas en este contexto.
• Unas pruebas completas de regresión serían una posible solución pero en la
práctica necesitan mucho tiempo y generan muchos costes.
• Una combinación de pruebas de las partes modificadas (repetición de pruebas

de error) y una selección de las pruebas del sistema (p.ej., en función de la
priorización de las funciones a comprobar) es lo que mejor se adapta a los
requisitos.
154
05 – Resumen
Afirmaciones importantes del capítulo
• Fases de pruebas establecidas según el “modelo genérico en V”

• Diferenciación entre validación y verificación
• La unidad de prueba mas pequeña para los elementos constituyentes del
software es la prueba de componentes
• Las pruebas de integración comprueban la interrelación entre estos elementos
• Diferentes estrategias para la integración
• El sistema completo se prueba mediante pruebas funcionales y no funcionales
• Prueba de regresión = prueba de un software ya comprobado
• Las pruebas de mantenimiento se llevan a cabo en programas pasados a
producción
155
156
Capítulo IV – Técnicas estáticas
• IV/01 Las técnicas estáticas y el proceso de prueba
• IV/02 Proceso de revisión
• IV/03 Análisis estático (Mediante herramientas)
• IV/04 Resumen
157
IV – Técnicas estáticas
01 – Las técnicas estáticas y el proceso de prueba
Conceptos generales
• El término “técnicas estáticas”, “pruebas estáticas” o –frecuentemente
también- “análisis estático” engloba procedimientos que adoptan
• Análisis manual del objeto de prueba (leer, etc.) o
• Análisis del objeto de prueba respaldado por herramientas sin ejecutar el objeto
de prueba
• Se prescinde de los datos de prueba (necesarios en las pruebas dinámicas).
• Los errores pueden ser descubiertos directamente con las pruebas estáticas
(no únicamente en base a sus efectos)
• El objetivo de las pruebas estáticas es encontrar errores / incidencias en las
especificaciones mismas antes de que se implementen (totalmente).
• Corregir especificaciones o supuestos y evitar errores en el software
• Descubrir y eliminar los puntos débiles del proceso
158
01 – Las técnicas estáticas y el proceso de prueba
Conceptos generales
• Beneficios:
• Detección y corrección temprana de defectos
• Mejora de la productividad del desarrollo
• Tiempos de desarrollo reducidos
• Mejores costes y tiempos de prueba
• Reducciones en el coste durante su tiempo de vida
• Menos defectos
• Mejora en las comunicaciones.
• Las revisiones pueden encontrar omisiones, por ejemplo, en los requisitos,
algo que no se puede encontrar durante las pruebas dinámicas.
• Tanto las revisiones como el análisis estático y las pruebas dinámicas
tienen el mismo objetivo - identificar defectos. Son complementarias:
diferentes técnicas pueden encontrar distintos tipos de defectos de forma
efectiva y eficiente.
• Entre los defectos típicos que son más fáciles de encontrar en las
revisiones que en las pruebas dinámicas, se encuentran: desviaciones de
los estándares, defectos en los requisitos o en el diseño, mantenibilidad
insuficiente y especificaciones de interfaz incorrectas.
159
02 – Proceso de revisión
Conceptos y definiciones
• Pruebas en grupo estructuradas (definición) :

Las pruebas en grupo estructuradas son aquellos procedimientos de prueba
en los que, sin apoyarse en una herramienta, sólo se aplican las cualidades
humanas de “pensar” y “analizar”.
• Se buscan errores en la documentación / objetos de prueba (en ocasiones con

un enfoque determinado, p.ej., estilo de código) mediante un trabajo intensivo
(leer, deducir, investigar)
• Los procedimientos se agrupan bajo el termino revisión (también inspección).
• La revisión y la inspección son a la vez tipos concretos de pruebas en grupo

estructuradas
El siguiente apartado se orienta según los conceptos del plan de

formación ASQF/ISTQB V2.2 y según IEEE1028
160
Objetivos de una revisión
• Las revisiones deben mejorar el proceso de desarrollo y asegurar la calidad
del producto
• Las verificaciones en la rama izquierda del modelo en V – es decir, la
correcta implementación de los requisitos de una etapa a otra – se
llevan a cabo, p.ej., mediante revisiones.
• Una calidad alta en la documentación (en toda la documentación) mejora
obligatoriamente la calidad del producto
• Si no hay errores en las especificaciones/requisitos no se pueden
implementar errores.
• Se pueden ahorrar costes

• Si se corrigen errores de manera temprana se ahorrarán costes en el
proceso de desarrollo posterior.
161
Ventajas e inconvenientes de la revisión
• Ventajas
• Documentación limpia
• Bajos costes en comparación al alto potencial de ahorro
• Desarrollo mejorado del producto mediante una documentación sin
errores
• Menos esfuerzo de pruebas durante el ciclo de vida del software
• Aumento de la comunicación como consecuencia de las revisiones
• Intercambio de ideas / intercambio de Know-how
162
Ventajas e inconvenientes de la revisión
• Inconvenientes
• Se pueden originar tensiones en el caso de que el autor sea tratado o
atacado personalmente.
• Expertos en la materia deben formarse como supervisores.
• Se necesita tiempo libre para esta actividad.
• Una mala preparación disminuye el éxito.
• La calidad del moderador y de los participantes en la revisión determina
en gran medida el resultado.
• Si el moderador no consigue mantener la revisión en un plano técnico se
reduce el éxito.
163
02.1 – Proceso de revisión
Fases de una revisión
• Todos los tipos de revisiones se basan en una división común en fases
• Planificación
• Organización de la revisión (p.ej., por el moderador)
• Planificación de plazos (p.ej., por el moderador) y de recursos (por regla
general por el gestor)
• Elección de los participantes y asignación de roles (por regla general por el
gestor)
• Selección de los objetos de prueba
• Definición de los criterios de entrada y salida para revisiones más formales
(ej.: inspecciones)
• Preparación organizativa
• En su caso se citan todos los participantes para una reunión previa
(Reunión de Kick off)
• Distribución de los objetos de prueba
• Distribución de toda la documentación relevante para la evaluación
• Acuerdo de los criterios de prueba (ej: checklists), reparto de tareas,
objetivos, procesos
• Comprobación de los criterios de entrada (para revisiones más formales)
164

• Preparación individual
• Preparación de los participantes para la reunión de revisión (revisando
la documentación)
• Los supervisores deben ocuparse intensivamente con la
documentación/ objetos de prueba
• Se determinan las carencias del objeto de revisión a comprobar
• Se anotan los posibles defectos, preguntas y comentarios.
• Reunión de revisión
• Encuentro de los participantes para la revisión (¡por regla general, sin el
gestor!) Bajo la dirección del moderador, cada supervisor expone sus
resultados.
• Exposición objetiva y técnica de los aspectos a comprobar
• Se anotan los defectos, tomando decisiones sobre los mismos
• No se ataca al autor, ni éste debe pretender defender su trabajo
• Los errores de ponderan y se consideran para una modificación
posterior. La ausencia de errores se menciona también expresamente
165

• Retrabajo
• La corrección de los defectos encontrados suele quedar en manos del
autor
• Seguimiento (Follow-up)
• El gestor recibe el protocolo de la reunión con los siguientes contenidos
• Objeto de prueba y documentos de comparación
• Participantes y asignación de roles
• Resultados para el objeto de prueba
• Afirmaciones/Recomendaciones de los supervisores
• Decisión del gestor sobre la aceptación del documento

• Seguir (o no) las recomendaciones. Se deberá hacer un
seguimiento posterior para asegurarse (en su caso) de que se
han seguido las recomendaciones
• Eventualmente sigue una “reunión “posterior“ – 2ª. Revisión
166

• Seguimiento (follow up)
• Se generarán métricas y se comprobará (en el caso de las revisiones
más formales) si se han cumplido los criterios de finalización.
• Se pueden extraer de los errores encontrados referencias sobre déficits
generales en el proceso de desarrollo
• Los resultados de la reunión no deberán ser empleados para adoptar
medidas disciplinarias. Los resultados no se deben hacer por ello
públicos con demasiado detalle.
167
Roles y responsabilidades
• A los participantes en una revisión se les asignan diferentes roles y tareas o
bien, se deben cubrir diferentes roles:
• Gestor
• Inicia la revisión y planifica en su caso su desarrollo, define participantes y distribuye
recursos
• Moderador
• Es neutral respecto del objeto de prueba y dirige la revisión
• Dirige la discusión (enfocado a los objetivos)
• Modera entre los diferentes puntos de vista
¡De la calidad del moderador depende principalmente el

éxito de la revisión!
168
Roles y responsabilidades
• Autor
• Elaborador o representante del elaborador del objeto de prueba
• Si se establece una crítica, es al objeto de prueba – ¡no debe ser criticado
personalmente!
• Asume finalmente las modificaciones requeridas
• Documentador
• Documenta la revisión
• Prepara una lista de todas las consideraciones realizadas y de todos los errores
reconocidos
• Supervisor (también revisor o inspector)
• Expertos en la materia que participan en una revisión – por regla general pueden
participar hasta cinco supervisores en la revisión
• Reciben previamente el objeto de prueba y trabajan sobre él
• Descubren errores, plantean problemas, etc.
• Tienen, idealmente, el enfoque de un supervisor acerca de aspectos especiales
• Indican qué partes del objeto de prueba deben ser corregidas y cuales pueden
mantenerse sin modificaciones
169
Tipos de revisión (IEEE 1028)
• El proceso fundamental de la revisión –tal y como se ha descrito aquí– se
puede dividir a su vez en diferentes modalidades de revisiones
• Algunas de estas modalidades se diferencian en algunos aspectos del
procedimiento general descrito
• La diferenciación general de la revisión viene determinada por la clase de
objeto de prueba a tratar
• El proceso de desarrollo de software o el curso del proyecto se analiza y
se hace un dictamen
• Esto también se refiere a revisiones de gestión (estas revisiones no influyen
directamente en el proceso de pruebas y no se tratan más dentro de este
seminario)
• La documentación / los productos del proceso de desarrollo se analizan
y se someten a dictamen
• Revisión en el sentido de este apartado
170
• Inspección: Desarrollo
• Modo de proceder altamente formal con un reparto claro de roles.

• Preparación previa a la reunión.
• Previamente se establece la capacidad de que el objeto de prueba
pueda ser revisado. El objetivo es encontrar defectos.
• Los supervisores comprueban el objeto de prueba siguiendo criterios
establecidos (reglas, listas de chequeo). Es frecuente que sea una
revisión entre iguales (peer review).
• Se necesita un moderador independiente (no el autor) para la reunión.
• Las entradas y salidas están establecidas. Se genera un informe de
inspección y una lista de hallazgos.
• Proceso de seguimiento formal.
• Incluye métricas.
171

• Inspección: ventajas e inconvenientes
• Reunión que se desarrolla con una buena organización

• Gran esfuerzo para la preparación y la elaboración posterior
• Se precisa de un moderador y un encargado de documentar la reunión
• Es posible una búsqueda de errores estructurada
172
• Walkthrough: desarrollo
• En este tipo de revisiones se distribuye previamente a lo sumo la
documentación. Puede haber una preparación previa a la reunión de
revisión.
• El propio autor presenta el objeto de prueba en una reunión y suele
liderarla. Suele haber un documentador distinto del autor. Informe de
revisión y lista de hallazgos
• Durante la presentación del objeto de prueba por parte del autor, los
supervisores intentan descubrir errores o problemas. Es frecuente
que sea una revisión entre iguales (peer review)
• Puede variar desde bastante informal a muy formal
• Sesiones abiertas / de duración indefinida (open-ended)
• Propósitos: aprender, ganar conocimiento y encontrar defectos
• Ejemplos para la utilización de Walkthroughs
• Walkthrough de documentación
• Walkthrough de propuestas para GUI
• Walkthrough de procesos de negocio
173
• Walkthrough: Ventajas e inconvenientes
• Menor esfuerzo en la preparación – por contra en ocasiones reuniones

más larga
• La reunión se puede iniciar a corto plazo
• El autor tiene mucha influencia (precisamente como director de la
reunión) – se corre el peligro de no discutir suficientemente acerca de
puntos críticos.
• No hay control, ya que el autor es el encargado de la elaboración
posterior
174
• Revisión técnica: desarrollo
• Comprobación de los aspectos técnicos del objeto de prueba
• Suelen participar expertos en la materia, si es posible expertos externos
al proyecto. Pueden participar también iguales o ser enteramente una
reunión entre iguales (peer review)
• La reunión se desarrolla sin el autor. Suele haber moderador
• Comprobación sólo en base a los requisitos y al patrón de pruebas
• Se hace un dictamen unánime de la valoración global. Opcionalmente,
uso de listas de comprobación, informe de revisión, lista de hallazgos,
participación de los gestores
• Preparación previa a la reunión
• Puede variar desde bastante informal a muy formal
• Propósito: discutir, tomar decisiones, evaluar alternativas, encontrar
defectos, resolver problemas y comprobar conformidad (con
especificaciones, planes, normas y estándares)
175

• Revisión técnica: ventajas e inconvenientes
• Aumento de la comunicación
• Muy eficiente si el personal es adecuado (y los procedimientos correctos)
• Se requiere disponer de personal experto (con tiempo disponible, lo que
no siempre es fácil)
• Gran esfuerzo para la preparación y la elaboración posterior
• Se precisa de un moderador y un encargado de documentar la reunión
• Es posible una búsqueda de errores estructurada
176
• Revisión informal: desarrollo
• La variante más simple de las revisiones
• A menudo iniciada por el autor
• Solo es necesaria la elección de los supervisores
• No se requiere una reunión de revisión
• Los resultados suelen transmitirse en forma de lista. Puede (o no)
documentarse
• Su utilidad depende mucho del revisor
• A menudo en forma de lectura mutua de los objetos de prueba de entre
colegas
• Objetivo: Forma barata de obtener (algún) beneficio
177
• Revisión informal: Ventajas e inconvenientes
• Se organizan y desarrollan rápidamente

• Coste bajo
• No suele haber documentación
178
Factores de éxito en las revisiones

• Es necesario que haya un líder a nivel de proyecto o de organización. Su
autoridad debe ser reconocida por el resto de participantes (soporte de la
Dirección)
• Hay que tener claras las ideas:
• Cada revisión tiene un objetivo predefinido claro
• Se involucra a la gente correcta desde el punto de vista de los objetivos de la
revisión
• Se han de identificar los documentos más importantes para el proyecto. Tiene que
haber un ROI claro. NO se debe revisar todo (las revisiones son costosas)
• Se aplican técnicas de revisión apropiadas al tipo y nivel de los productos software y
de los revisores
• Hay que planificar y hacer seguimiento de las actividades asociadas a la
revisión (por ejemplo, reservar en los calendarios de proyecto un tiempo
adecuado para las actividades de revisión).
• Puede ser necesario formar a los participantes en técnicas de revisión,
especialmente en las más formales, como es la inspección
179
02.4 – Proceso de revisión.
Factores de éxito en las revisiones

• Los probadores son revisores valorados, que contribuyen a la revisión y
aprenden sobre el producto para poder preparar las pruebas más pronto.
• Hay que considerar los aspectos personales de las revisiones
• Los defectos encontrados son bienvenidos y se expresan de forma objetiva
• Se consideran los aspectos psicológicos y personales (por ejemplo, hacer que sean
experiencias positivas para el autor)
• Estos aspectos han de ser considerados cuando se está dando la formación previa
a la revisión
• Facilitar el trabajo:
• Ser formal cuando sea necesario. No entrar a niveles de detalle demasiado altos o
demasiado teóricos si no es necesario
• Utilizar listas de comprobación (checklists) o incorporar roles cuando ayude a
incrementar la efectividad o la identificación de defectos
• Cuidar la presentación de los resultados. Debe ser clara, concisa, objetiva y no
herir susceptibilidades si no es necesario
• Hacer hincapié en la mejora continua del proceso, los participantes y las
herramientas
• La revisión se realiza en un ambiente de confianza; el resultado no será
utilizado para evaluar a los participantes
180
03 – Análisis estático
Conceptos y definiciones
• Análisis, por lo general apoyado en herramientas, para la comprobación de los

errores en un objeto de prueba, como documentos o código de programa sin
llegar a ejecutarlo.
• Los aspectos que pueden / suelen comprobarse con esta técnica son:
• Directrices de programación y estándares
• Construcción del programa (análisis del flujo de control)
• Utilización de datos (análisis del flujo de datos)
• Complejidad de la estructura del programa (Métricas – p.ej., complejidad
ciclomática)
181
Generalidades
• Todos los objetos de prueba deben tener una estructura formal.

• Inevitable debido al empleo de herramientas
• En el caso de documentos no se da con frecuencia
• Las análisis estáticos se pueden desarrollar con poco esfuerzo en

comparación con las revisiones, gracias a la implantación de herramientas.
• Por eso se lleva a cabo frecuentemente un análisis estático antes de
llevar a cabo la revisión.
182
Generalidades
• Como herramientas se utilizan compiladores o analizadores
• Compilador
• Descubren errores de sintaxis en el lenguaje de programación
• Proporcionan comprobantes del uso de las partes del programa (listas de
referencias cruzadas)
• Comprueban la utilización correcta de los tipos de variables
• Encuentran variables no declaradas y código inaccesible (p.ej., el
compilador de Java)
• Los analizadores se refieren más a aspectos como
• Convenciones y
• Estándares.
183
Análisis del flujo de control
• Objetivo
• Encontrar errores dentro de la construcción del programa
(ramas muertas / código muerto etc.)
• Procedimiento
• Representación del código en forma de
• gráfico de flujo de control
• Gráfico orientado
?
• Sentencias del programa / secuencias como nodos
• Decisiones / Bucles como aristas
• Se crean generalmente mediante una herramienta
184
Análisis del flujo de control
• Resultado
• Representación visible del código del programa
• Las anomalías se encuentran con facilidad
y se pueden comprobar sus fallos
• Salidas/saltos de bucles
• Ramas muertas
?
185
Análisis del flujo de datos

• Objetivo:
Descubrir anomalías en el flujo de datos con ayuda del análisis de las rutas del
programa y comprobar si las secuencias de flujo de datos son correctas
186
• Procedimiento :
• Una variable x puede ser accedida a lo largo de una ruta del programa
de las siguientes maneras:
• x se define (d) – asignar un valor (p.ej., x = 1)
• x está indefinida (i) – La variable no tiene al principio ningún valor
• x se referencia (r) – ¡el valor de x no se modifica! (p.ej., z = x + 5 o if(x > 0)
)
• x no se utiliza (e) – x no se utiliza en la sentencia
• El flujo se datos de una variable puede ser de esta manera representado
por una secuencia de d, i, r y e
• En el caso de que una de estas secuencias tenga una secuencia parcial
sin sentido existe una anomalía de flujo de datos
187
• Ventajas:
• Descubrimiento seguro de determinados tipos de errores
• Localización directa del error
• Buen complemento a otros procedimientos de pruebas
• Inconvenientes:
• Limitado a escasos tipos de errores
188
• Anomalías de flujo de datos

• Ejemplo IV/03-1
En el ejemplo se intercambian El análisis de flujo de datos muestra la El ejemplo se puede corregir

los valores para Min y Max siguiente anomalía: fácilmente:
utilizando una variable auxiliar - La variable Aux se referencia estando
en caso de que no estén indefinida (anomalía ri)
ordenadas por valor:
- La variable Max se define dos veces
seguidas (anomalía dd)
void MinMax (int Min, int Max) void MinMax (int Min, int Max)
{
- El valor definido para Aux queda {
int Aux; int Aux;
indefinido sin haber sido referenciado
if (Min>Max) if (Min>Max)
(anomalía di)
{ {
Max = Aux;
Aux = Min;
Max = Min;
Min = Max;
Aux = Min;
Max = Aux;
} }
End MinMax; End MinMax;
189
Métricas y su determinación
• Mediante las métricas se pueden medir y expresar aspectos individuales de la

calidad
• La unidad de medida debe referirse siempre al aspecto valorado
• Se mide la complejidad estática del programa
• Existen actualmente aprox. 100 métricas diferentes
• Las diferentes métricas se orientan a diferentes características
• Tamaño del programa (p.ej., líneas de código/Lines of Code – LOC)
• Estructuras de control del programa (p.ej., número ciclomático)
• Estructuras de control de datos (z. B. Medida-Halstead)
• ¡Por regla general las métricas con un objetivo idéntico tampoco se pueden
comparar!
190
• Número ciclomático
• Medida de la complejidad estructural del código en base a los gráficos de flujo de control
• Determinación de las rutas de programa independientes
• Puntos de referencia para la evaluación de la prueba y el mantenimiento
• El número ciclomático v(G) se calcula a partir de

• El número de aristas e
• El número de nodos n
• El número de las conexiones externas p
(generalmente si p = 2 significa
entrada simple/ single entry –salida simple/single exit)
• Los valores hasta 10 son aceptables según McCabe,

por encima se debería reelaborar el código
(Valores por experiencia)
v(G) = e − n + p
191
• Ejemplo IV/03-2
(Número ciclomático) v(G) = e − n + p
• El ejemplo de la derecha tiene
1
• 2 conexiones externas: 1
• p= 2 2
2 3
• 14 nodos: n = 14
3 4
• 19 aristas: e = 19 4 6
5 7
1 5 6 7 8
9 11 12
8 13
9 10 10 16 11
• Si v (G ) = e − n + p 14
15
19 12
se obtiene con ello un valor para el 17
18 13
número ciclomático de v (G ) = 7
14
192
• Número ciclomático (s. McCabe) – motivo de utilización
• Puede así servir como directriz de comprobación en pruebas de grupo
estructuradas
• Una desviación entre el número de decisiones y el valor del número
ciclomático reducido en una unidad apunta a errores:
• Una rama innecesaria
• La falta de una rama
• El número ciclomático puede utilizarse como una medida adicional para
la cobertura de las pruebas, ya que v(G) está relacionado con el número
de rutas del programa
• El número ciclomático es un mejor indicador para la propensión a errores
de un segmento del programa que su tamaño (medido en LOC – Lines
Of Code)
193
04 – Resumen
• Con el análisis manual – muchos ojos, muchos puntos de vista, muchas

opiniones- se encuentran errores
• Revisiones para el control y aumento de la calidad
• Tareas y roles en las revisiones:

• Gestor
• Moderador
• Autor
• Supervisor
• Documentador
194
04 – Resumen
• El proceso de revisión elemental se compone de:

• Planificación
• Preparación organizativa
• Preparación individual
• Reunión de revisión
• Re-trabajo
• Seguimiento (Follow-up)
• Tipos de revisiones según IEEE1028

• Inspección
• Walkthrough
• Revisión técnica
• Revisión informal
195
04 – Resumen
• Junto a las revisiones existen dictámenes sobre documentos apoyados por

herramientas, también denominado análisis estático
• Los gráficos de flujo de control representan el desarrollo del programa
• Los análisis de flujos de control muestran “ramas muertas”, etc.
• Las anomalías en el flujo de datos se encuentran con la ayuda de los análisis
de flujos de datos
• Diversas métricas permiten hacer afirmaciones acerca de la construcción
estructural y del esfuerzo de las pruebas
• Antes de la revisión del código debería realizarse un análisis estático
196
197
Capítulo V – Técnicas de diseño de
prueba
• V/01 El proceso de desarrollo de las pruebas
• V/02 Categorización de las técnicas de diseño de
prueba
• V/03 Técnicas de caja negra (basadas en
especificación)
• V/04 Técnicas de caja blanca (basadas en la
estructura)
• V/05 Técnicas basadas en la experiencia
• V/06 Selección de técnicas de prueba
• V/07 Resumen
198
V – Técnicas de diseño de prueba
01 – El proceso de desarrollo de las pruebas
• En las pruebas dinámicas se compara el resultado esperado y el resultado
obtenido, donde los resultados obtenidos se obtienen mediante la ejecución
de los casos de prueba sobre el objeto de prueba.
• Las pruebas dinámicas son complementarias a las pruebas estáticas, donde

los objetos de prueba son analizados sin ejecutarse
• Las pruebas se ejecutan en un entorno de pruebas separado – según la fase
de pruebas en (una representación del) el entorno de implantación o en un
marco de pruebas sintético(p.ej., en las pruebas de componentes).
• Los datos de prueba se ejecutan en el objeto de prueba
• El comportamiento de salida / los resultados se documentan
199
Análisis de las pruebas

• Distintos niveles de formalidad a la hora de describir el proceso,
dependiendo de:
• Contexto de pruebas
• Organización
• Madurez de los procesos de desarrollo y pruebas
• Restricciones de recursos y tiempo
• Durante el análisis de pruebas se analiza la documentación base de
pruebas para determinar lo que hay que probar, es decir, las condiciones
de prueba (ej.: una función, transacción, elemento estructural,
característica de calidad).
• Estableciendo trazabilidad desde las condiciones de prueba hacia las
especificaciones y los requisitos permite:
• Análisis de impacto (cuando cambian los requerimientos), y
• Cobertura de requerimientos (para un conjunto de pruebas)
200
Diseño de las pruebas
• Durante el diseño de las pruebas los casos de prueba y datos de prueba se
crean y especifican.
• Un caso de prueba consiste en:
• Conjunto de valores de entrada
• Precondiciones de ejecución
• Resultados esperados y poscondiciones de ejecución
desarrolladas para cubrir ciertas condiciones de prueba
• En el ‘Standard for Software Test Documentation’ (IEEE 829) se describe el
contenido de:
• Especificaciones de diseño de pruebas
• Especificaciones de casos de prueba
201

• Los resultados esperados deberían formar parte de la especificación de los
casos de prueba e incluir salidas, cambios de datos y estados, y cualquier
consecuencia de la prueba
• Los resultados esperados deberían ser definidos antes de la ejecución de
las pruebas
• Durante la implementación de las
pruebas los casos de prueba son
desarrollados, priorizados y
organizados en una especificación de
casos de prueba (o en una
especificación de casos +
especificación de procedimientos)
• En un procedimiento de prueba se
especifica la secuencia de acciones
para la ejecución de la prueba
202
• Los procedimientos de pruebas y scripts automatizados son incorporados en
una planificación de ejecución de pruebas que define el orden en que se
ejecutarán, cuando y por quien.
• Tendrá en cuenta factores como:

• Pruebas de regresión
• Priorización
• Dependencias lógicas y técnicas
203
02 – Categorización de las técnicas de diseño de prueba
Generalidades
• Los procesos de prueba dinámicos se dividen en dos categorías básicas

• La división se orienta a los fundamentos respectivos para la
especificación de casos de prueba
Caja negra Whiteblanca

Caja Box
• Cada una de las categorías engloba diferentes procedimientos para la

especificación de los casos de prueba para las pruebas dinámicas
204
Procedimiento de actuación. Técnicas de caja negra
• El probador considera al objeto de prueba como una caja negra
• La estructura del programa es irrelevante o desconocida
• Los casos de prueba se deducen en su totalidad de las especificaciones /

requisitos disponibles
• Pruebas de comportamiento de entrada y salida
• ¡La funcionalidad es el punto central a considerar!

• Se habla por ello de procedimiento de pruebas funcional
Especificación de casos de prueba Objeto de prueba
Deducción de los casos de prueba

de las especificaciones
La estructura de programa
es irrelevante!
Pruebas de todas las posibles combina-

ciones o combinaciones seleccionadas de
valores de entrada y salida
205
Procedimiento de actuación. Técnicas de caja blanca
• El probador conoce la estructura del programa y su código

• esto es, jerarquía de componentes, flujo de control , flujo de datos etc..
• Los casos de prueba se especifican en base a la estructura del programa /

código del programa
• Los accesos al objeto de pruebas durante la ejecución son posibles
• Se prueba la estructura del programa

• Se habla por ello de procedimiento de pruebas estructural
Objeto de prueba
Especificación de los casos de prueba
Elaboración los casos de prueba en
base a la estructura del programa
Posibilidad de dirigir la prueba desde el

exterior mediante accesos externos
Análisis de los procesos en el objeto de

prueba durante la ejecución de las pruebas
206
Clasificación de técnicas de pruebas
Aseguramiento dinámico de la calidad vs. Aseguramiento estático de la calidad

• Análisis del software mediante • Análisis del software sin ejecución
ejecución con datos de prueba
Caja negra vs. Caja blanca

• Implementación desconocida durante • Implementación conocida durante la
la especificación de casos de prueba especificación de casos de prueba
Procedimiento de pruebas funcional vs. Procedimiento de pruebas estructurado

• La especificación es el punto de • Generación de casos de prueba
partida para la definición de casos de mediante el análisis de la
prueba implementación
207
03 – Técnicas de caja negra
Generalidades
• Las siguientes técnicas de caja negra son las que se tratan de manera más
profunda:
• Formación de clases de equivalencia
• Análisis de valores límite
• Pruebas referidas a estados
Se trata de las técnicas más importantes y más utilizadas
• Otras técnicas de caja negra son, p.ej. :
• Pruebas aleatorias
• Análisis de gráficos de causa y efecto
• Pairwise Testing
208
03 – Técnicas de caja negra
Generalidades
• El objetivo de las pruebas funcionales es la comprobación de la integridad y
funcionamiento correcto de las funciones
• El sistema se comprueba respecto de sus especificaciones
• ¿Están contenidas correctamente todas las funciones solicitadas?
• La ejecución de las pruebas debería ser lo menos redundante posible y sin

embargo amplia
• ¡No probar más de lo necesario!
209
03.1 – Técnicas de caja negra
Formación de clases de equivalencia
• Se prueba cada vez con un representante de la clase de equivalencia

• Para todas las pruebas con otro valor de la clase de equivalencia se espera un
resultado idéntico
• Las clases de equivalencia se crean para datos de entrada válidos y no

válidos
• Si se define un valor x como “x > 0”, aparecen en principio dos clases de
equivalencia – una todas las entradas “> 0” y otra las entradas “<= 0”
• Pueden identificarse tipos de datos no numéricos – esto representa otra posible
clase de equivalencia
210
Formación de clases de equivalencia – procedimiento de actuación
• Todas las variables de entrada (elementos) del objeto de prueba son

identificadas
• Campos de la máscara de una GUI
• Parámetros de una función
• Para cada una de las variables de entrada se define el rango de definición

• Las clases de equivalencia válidas (Cev) de las variables (del elemento) se
corresponden con este rango de definición
• Las clases de equivalencia inválidas se producen a partir de los valores fuera del
rango de definición(Cei)
211
• Ejemplo V/03-1:
• Un programa precisa la entrada de un peso en “Kg.” (una función
integrada redondea siempre sin decimales – valores menores que “0,5”
se redondean a “0”)
• Se permiten aquí valores ≥ 0 y no permitidos serían todos los números
negativos y los valores de entrada no numéricos (p.ej., “Hugo”)
• Clase de equivalencia válida: x≥0
• 1. Clase de equivalencia no válida: x<0
• 2. Clase de equivalencia no válida : x = no numérico
212
• Ejemplo V/03-1:
• Junto a las clases de equivalencia no válidas enunciadas anteriormente
existen más clases de equivalencia no válidas que no se tienen en
cuenta en este ejemplo:
• x > 0, pero mayor que el mayor número que puede representar el

ordenador
• x > 0, pero más pequeño que el número positivo más pequeño que se
puede representar en el ordenador
213

• Durante la formación de clases de equivalencia se consideran los rangos de
definición de los valores
• Valores de entrada y salida respectivamente del programa
• Los valores definidos se dividen en clases de equivalencia

• Esto es, aquellos para los que se espera un comportamiento idéntico del sistema
son agrupados en una clase de equivalencia (CE)
214
• Las clases de equivalencia de cada variable (de cada elemento) deben ser
subdivididas
• CE válida: dentro del rango de definición se agrupan todos los valores
que se procesan de forma idéntica por el objeto de prueba
• En ejemplo V/03-1 son todas las entradas numéricas positivas
• CE no válidas : fuera del rango de definición se distinguen dos casos:

• Valores con formato correcto pero que están fuera del rango de definición
se agrupan en una o más clases de equivalencia
• Valores con formato incorrecto forman generalmente otra clase de
equivalencia
• En el ejemplo V/03-1 se forman, p.ej., dos clases de equivalencia no
válidas: x < 0 y x no es un valor numérico
215
• Finalmente se elige un representante para cada CE y se define el resultado

esperado
• Para el ejemplo V/03-1 :
Variable Clase de equivalencia Representante

Peso CE1: x ≥ 0 +1,00
CE2: x < 0 -1,00
CE3: x no numérico Hugo
216
• Ejemplo V/03-2:
• Un programa calcula el precio de un producto en función de su valor, un
descuento en % y gastos de envío establecidos de (6,- , 9,- o 12,-€
según envío)
Variable Clases de equivalencia Estado Representante Existen las siguientes

Valor del CE11: x >= 0 Válido 1000,00 excepciones:
producto
CE12: x < 0 No válido -1000,00 • Valor del producto
CE13: x no numérico No válido Hugo numérico positivo con
Descuento CE21: 0% ≤ x ≤ 100% Válido 10%
dos decimales
CE22: x < 0% No válido -1% • Descuento numérico
en formato de % sin
CE23: x > 100% No válido 101%
comas, entre 0% y
CE24: x no numérico No válido Hugo
100%
Gastos de CE31: x = 6 Válido 6
envío
• Para los gastos de
CE32: x = 9 Válido 9 envío se proporcionan
CE33: x = 12 Válido 12 valores fijos que
CE34: x ≠ {6, 9, 12} No válido 5 pueden ser 6, 9, o 12
217
• Ejemplo V/03-2:
• Las clases de equivalencia válidas permiten formar las siguientes combinaciones
o casos de prueba (CP01, CP02 y CP03) :
Variable Calse de equivalencia Estado Representante CP01 CP02 CP03
Valor del CE11: x >= 0 Válido 1000,00

producto
CE12: x < 0 No válido -1000,00
Descuento CE21: 0% < x < 100% Válido 10%
CE22: x < 0% No válido -1%
CE23: x > 100% No válido 101%

envío
CE32: x = 9 Válido 9
CE34: x ≠ {6, 9, 12} No válido 5
218

• Ejemplo V/03-2:
• De las CE no válidas se deducen directamente los siguientes casos de prueba:
cada una en combinación con CE válidas de los otros elementos
Variable Calse de equivalencia Estado Represen- CP0 CP0 CP0 CP0 CP0 CP0 CP1
tante 4 5 6 7 8 9 0
Valor del CE11: x >= 0 Válido 1000,00
producto
CE12: x < 0 No válido -1000,00
Descuento CE21: 0% < x < 100% Válido 10%
CE22: x < 0% No válido -1%
CE23: x > 100% No válido 101%


envío
CE34: x ≠ {6, 9, 12} No válido 5

219

• Ejemplo V/03-2:
• Se deducen en total 10 casos de prueba
3 casos válidos y 7 casos no válidos:
Variable Clase de Estado CP01 CP02 CP03 CP04 CP05 CP06 CP07 CP08 CP09 CP10
equivalencia
Valor del Válido 1000,00
producto
No válido -1000,00
No válido Hugo
Descuento Válido 10%
No válido -1%
No válido 101%
No válido Hugo
Gastos de Válido 6
envío
Válido 9
Válido 12
No válido 5
No válido Hugo
220

• Formación de clases de equivalencia en base a los valores de salida
• El procedimiento se puede aplicar de forma análoga para la división de
todos los valores de salida definidos
• La variable (el elemento) será entonces un valor de salida (p.ej., un
campo de salida de una GUI)
• De los posibles valores de salida definidos se formarán otra vez las
respectivas clases de equivalencia
• Una CE engloba a aquellos valores a los que se subordina un mismo
comportamiento de salida
• Por cada clase de equivalencia se elige un representante
• Se decide finalmente mediante qué valores de entrada se pueden
conseguir los representantes
• Requiere un gran esfuerzo al tener que buscar datos de entrada para los
diferentes comportamientos de salida definidos
221
Formación de clases de equivalencia – Generalidades
• Descomposición
• El éxito o el fracaso de la calidad de las pruebas depende de la precisión
con que se descompongan las variables individuales
• De la precisión a la hora de descomponer las variables / elementos
individuales depende la calidad de las pruebas
• Las CE no reconocidas implican el riesgo de pasar posibles efectos de
error por alto, ya que sus representantes pueden provocar resultados
diferentes
222
• Elección de representantes
• Cada valor de una CE puede ser elegido como representante para la
prueba – lo lógico es sin embargo elegir “valores típicos”.
• Los representantes de las CE no válidas deben ser siempre unidos con
representantes idénticos de la misma CE válida en casos de prueba
(combinaciones estándar).
• Con el fin de no enmascarar errores no se deben elegir representantes
de CE no válidas junto a representantes de otras CE no válidas.
223
• El criterio de finalización de las pruebas puede ser aquí un determinado grado

de cobertura
• ¿Cuantas de las posibles CE han sido probadas en relación a todas las
CE definidas?
Cobertura de CE = Nº de CE probadas * 100 %

Nº total de CE
224
• Paso de definiciones / requisitos a clases de equivalencia

• A menudo una tarea difícil ya que los documentos disponibles no son
precisos o son incompletos
• Límites de rangos de valores imprecisos o, eventualmente falta de datos
acerca de la definición exacta dificultan la transformación
• ¡A menudo suele ser necesario volver a consultar con el cliente!
225
• Ventajas del procedimiento

• Determinación sistemática de casos de prueba, es decir, con un número
mínimo de casos de prueba se maximiza la cobertura de pruebas
• La descomposición en clases de equivalencia en base a las definiciones
/ especificaciones abarca de muy buena manera los requisitos
funcionales.
• La priorización de las clases de equivalencia puede servir para priorizar
los casos de prueba (los datos de entrada que no se utilizan nunca son
los últimos a probar)
• La pruebas de las condiciones de excepción definidas quedan
aseguradas por los casos de prueba negativos
226
Análisis de valores límite

• El análisis de valores límite amplia la formación de clases de equivalencia
• Las regiones límite de las clases de equivalencia se prueban de forma
más intensiva
• ¿Por qué probar más intensivamente las regiones límite ?

• A menudo hay una definición insuficiente en las especificaciones acerca
de la los límites de los rangos de valores
• Comprobación acerca de si los límites se han implementado
correctamente en la programación
¡La experiencia muestra que los errores son más frecuentes en las
regiones límite!
227
• La utilización del análisis de valores límite presupone que

• La clase de equivalencia abarca un rango de valores y
• Que se pueden identificar los límites para ese rango de valores
• La diferencia / la ampliación respecto de la formación de clases de
equivalencia reside en la elección de los representantes
• Formación de clases de equivalencia:
• considera un valor cualquiera (típico) de la clase
• Análisis de valores límite:
• Considera los límites de la clase y sus valores vecinos
• Si las clases de equivalencia de una variable vienen representadas en forma
de un grupo de valores no se podrá, en general, formar valores límite
• P.ej. Soltero, casado, separado, viudo
228
• Ejemplo V/03-3:
• Rango de valores para el descuento en %: 0,00 ≤ x ≤ 100,00
• Formación de CE
3 Clases (< 0, Rango de definición, > 100)
p.ej., con los representantes: -50,00; 50,00; 150,00
• Análisis de valores límite
amplía los representantes a :
1. (-50,00): -0,01
2. (50,00): 0,00; 100,00
3. (150,00): 100,01
229
Tablas de decisión
• Es un buen sistema para representar la lógica de los requisitos de usuario,
sobre todo las reglas de negocio complejas.
• Las tablas de decisión están compuestas por cuatro secciones:
REGLAS DE DECISIÓN
IDENTIFICACIÓN DE CONDICIONES VALORES DE CONDICIONES
IDENTIFICACIÓN DE ACCIONES VALORES DE ACCIONES
• Una vez confeccionada la tabla, quedarán determinadas las reglas de

decisión. Estas son proposiciones que se leerán verticalmente, partiendo
desde la sección Valores de Condiciones y descendiendo por la sección
Valores de Acciones. Se las enuncia así: “SI.......(condición1, condición2,
etc.)... ENTONCES ... (acción1, acción2, etc.)....”.
230
Tablas de decisión
• Ejemplo:
REGLAS DE DECISIÓN
CONDICIONES 1 2 3 4
¿Pago contado? S S N N
¿Compra > 50.000€? S N S N
ACCIONES
Calcular descuento del 5%
X X
sobre el importe de la compra
Calcular descuento del 7%
X X
sobre el importe de la compra
Calcular importe neto de la
X X X X
factura
231
Pruebas referidas al estado
Los dos procedimientos conocidos hasta el momento solo tienen en cuenta los
comportamientos de entrada/salida según las especificaciones
• Los diferentes estados que puede adoptar un objeto de prueba durante su
ejecución no son contemplados
• ¿Tienen consecuencias los procesos que ya han tenido éxito sobre el
desarrollo posterior?
• Los diferentes estados que puede adoptar un objeto de prueba durante su
ejecución se representan mediante un modelo de estados
• Una prueba referida al estado debería ejecutar para cada estado todas las
funciones definidas para el mismo al menos una vez
232
Pruebas de transición de estados
• Para aquellos sistemas que se ajusten a un modelo de transición de
estados, el objetivo de las pruebas sobre este tipo de sistemas sería
demostrar la conformidad de los requisitos especificados en forma de
diagrama de transición de estados o tablas de transición de estados.
EVENTOS
ESTADOS
Evento_1 Evento_n
Estado_2
Ignorar
Estado_1 Acción_ 1
(1) (n)
Ignorar Ignorar
Estado_m
(n*(m-1)+1) (n*m)
Se diseñarán casos de prueba que cubran todas las transiciones

de estados representadas en la tabla.
233
Pruebas de transición de estados
• Ejemplo de una tabla de transición de estados para una máquina junto con
el correspondiente diagrama de estados.
• Todas las entradas posibles a la máquina están enumeradas a través de las columnas de la
tabla. Todos los estados posibles están enumerados a través de las filas. Desde la tabla de
transición de estados anterior, es fácil ver que si la máquina está en S1 (la primera fila), y la
siguiente entrada es el carácter 1, la máquina permanecerá en S1. Si llega un carácter 0, la
máquina realizará la transición a S2 como puede verse desde la segunda columna. En el
diagrama esto es denotado por la flecha desde S1 a S2 etiquetada con un 0.
234
Pruebas referidas al estado
• Criterios de finalización de pruebas
• Cada estado se debe alcanzar al menos una vez
• Cada transición de estados se debe alcanzar al menos una vez
• Ventajas e inconvenientes del procedimiento
• Es una buena posibilidad de probar objetos de prueba dependientes del
estado
• Método apropiado para las pruebas de clases en caso de disponer del
ciclo de vida del objeto
• Los estado son a menudo muy complejos en su estructura, esto es, son
determinados por un gran número de parámetros diferentes
• Tanto la definición de casos de prueba como la valoración de las pruebas
son muy trabajosos en estos casos
• La cobertura de todas las transiciones de estado no garantiza unas
pruebas completas
235
Pruebas de escenarios de uso o casos de uso
• Estas pruebas consisten en validar un sistema siguiendo la lógica de los
casos de uso (también llamados escenarios de uso).
• Los casos de uso describen los flujos de un sistema teniendo en cuenta
situaciones reales a las que se enfrenta el usuario.
Los casos de prueba basados en

casos de uso son muy útiles, ya
que permiten descubrir defectos
probando situaciones reales que
sin duda se darán durante la
explotación regular del sistema.
236
Pruebas de escenarios de uso o casos de uso
• Los casos de uso son muy interesantes para diseñar las pruebas de
aceptación de usuario.
• Además ayudan a descubrir defectos que no se encuentran durante las
pruebas de componentes, pero si en las pruebas de integración de
componentes, cuando esos mismos componentes interactúan unos con
otros.
Proceso dirigido por los Casos de Uso
«trace» «trace»
Caso de Uso Realización de Análisis Realización de Diseño
«trace»
«trace»
Pruebas
Unitarias
Pruebas Funcionales X
Caso de Prueba
[The Unified Software Development Process. I. Jacobson, G. Booch and J. Rumbaugh. Addison-Wesley, 1999]
237
Generalidades
• Comprobación de la funcionalidad como objetivo de las técnicas de caja negra
• El resultado de las pruebas depende de la calidad de la especificación
de requisitos (p.ej., especificación con errores o incompleta)
• Si existen errores en la especificación también se probará con errores – se
prueba la funcionalidad descrita (anteriormente debería ser asegurada la
calidad del código del programa mediante un análisis estático)
• Si el objeto de prueba contiene funciones que no han sido especificadas
éstas permanecerán sin descubrir
• Estas características no requeridas pueden ser problemáticas p.ej., cuando
llevan a problemas de estabilidad o seguridad o cuando no se cumplen las
expectativas del cliente
238
Generalidades
• A pesar de estas carencias las pruebas funcionales son las de mayor peso
dentro de las pruebas
• Por ello, los procedimientos de caja negra son siempre utilizados
• Los problemas/puntos débiles mencionados pueden ser compensados al

menos parcialmente por otros métodos de prueba (p.ej., procedimientos
de caja blanca)
239
04 – Técnicas de caja blanca
Procedimiento para el “análisis basado en código”
• Se va a profundizar ahora en las siguientes técnicas dinámicas de caja blanca
• Cobertura de sentencias
• Cobertura de ramas
• Cobertura de condiciones
• Cobertura de rutas
• Estas técnicas son las más importantes y utilizadas. Otras técnicas de caja
blanca son p.ej., :
• LCSAJ (Linear Code Sequence And Jump)
• Procedimiento basado en el flujo de datos
240
Herramientas
• En las técnicas de caja blanca se trata de ejecutar partes del programa

• En teoría deberían ser probadas todas las partes del programa al menos
una vez durante las pruebas
• La ejecución es seguida mediante herramientas (p.ej., mediante analizadores

de cobertura):
• Se realiza una instrumentación, esto es, se instalan contadores en
determinadas posiciones del objeto de prueba
• Estos contadores están al principio de la prueba a cero y son
aumentados escalonadamente con cada ejecución de la parte del
programa
• Si al final de la prueba quedan contadores a cero significa que la parte
del programa no se ha ejecutado
241
Herramientas
• Las técnicas de caja blanca necesitan en muchos casos el apoyo de
herramientas - p.ej., durante la
• especificación de casos de prueba
• P.ej., deducción de gráficos de flujo de control a partir del código del
programa
• ejecución de los casos de prueba
• Herramientas para el seguimiento y control de los procesos dentro del
objeto de pruebas
• La utilización de herramientas en este punto asegura y aumenta la calidad de
las pruebas
• Debido a la complejidad de los procesos, la ejecución manual:
• Consume tiempo y recursos
• Es propensa a errores y difícil de llevar a cabo
242
Generalidades acerca de las técnicas de caja blanca

• ¡Siempre se prueba sólo lo que existe!
• Casos de prueba basados en el código disponible
• ¡La falta de funciones no se descubre!
• Utilización de las técnicas más potentes en las fases de desarrollo mas
tempranas
• Pruebas cercanas al desarrollo con las técnicas de caja blanca
• P.ej., pruebas de componentes y de integración
• Los procedimientos se diferencian en la intensidad de pruebas
• En función del procedimiento y la estructura del programa varía el número de
casos de prueba
243
04.1 – Técnicas de caja blanca
Cobertura de sentencias
• Cada sentencia de un programa y su ejecución respectiva constituyen el
centro de la observación
• ¿Qué casos de prueba son necesarios para ejecutar todas las sentencias
disponibles o bien una cuota determinada de las mismas?
• La base de esta investigación es el gráfico de flujo de control
• cada sentencia se representa mediante un nodo y el flujo de datos entre
sentencias mediante una arista
• las secuencias de sentencias son de nuevo agrupadas en un nodo (se ejecuta
una directamente a continuación de la otra)
• El objetivo de las pruebas (criterio de finalización de las pruebas) consiste
en ejecutar un número predeterminado de sentencias (Medida de cobertura
o Medida-C0)
Nº de sentencias cubiertas por casos

Medida-C0 (Cobertura de sentencias) = (diseñadas o ejecutadas) * 100%
Nº total de sentencias
244
• Ejemplo V/04-1
• Se da el siguiente segmento de programa representado a la derecha
como gráfico de flujo de control :
if (i > 0) {
j = f(i);
if (j > 10) {
for (k=i; k > 10; k --) {
...
}
}
}
245
• Ejemplo V/04-1
• El gráfico de flujo de control representado en la parte
derecha
• contiene dos sentencias IF y un bucle (dentro de la
segunda sentencia IF)
• Hay tres “caminos” que llevan por este segmento de

programa
• de la primera sentencia IF salen dos caminos
• la rama derecha de la primera sentencia IF se reparte otra
vez en dos caminos mediante la segunda sentencia IF (el
recorrido del bucle no se contempla aquí como un camino)
• Todas las sentencias de este ejemplo se pueden alcanzar

por el camino de la derecha
• un único caso de prueba conseguiría un 100% de
cobertura de sentencia
246
• Ejemplo V/04-2
• El segundo ejemplo representa el gráfico de un
segmento de programa algo más complicado
• Se compone de tres sentencias IF y un bucle (dentro
de una sentencia IF)
• Cuatro caminos diferentes recorren la parte del
programa
• para ambas ramas de la primera sentencia IF se dan
respectivamente otras dos posibilidades de recorrido
debido a las siguientes sentencias IF
• el recorrido del bucle no se contempla aquí como un
camino
• Por uno de los caminos se alcanzan sólo siete de las
doce sentencias (C0=58,33%)
• para una cobertura del 100% de las sentencias se
necesitan aquí cuatro casos de prueba
247
Cobertura de sentencias – Generalidades
• La medida de cobertura se realiza mediante herramientas
• Se habla de los llamados analizadores de cobertura
• Ventajas/Inconvenientes del procedimiento
• Las sentencias muertas, esto es, las sentencias que no pueden ser
alcanzadas se encuentran en el caso de una solicitud de cobertura total.
• Si existen sentencias muertas en el programa no es posible alcanzar una
cobertura del 100%
• Las sentencias no existentes – sentencias que serían necesarias para la
función – se quedan fuera
• Lo que se prueba es si todas las sentencias contenidas son ejecutables /
accesibles
• ¡Si en una parte del programa falta una sentencia, esto no podrá ser
determinado mediante la cobertura de sentencias!
248
Cobertura de decisiones o ramas

• En lugar de las sentencias, es el flujo de control el que está en el centro de la
valoración (no sólo los nodos si no también las aristas)
• Todas las aristas del gráfico de flujo de control deben ser recorridas al menos una
vez.
• ¿Qué casos de pruebas son necesarios para recorrer todas las posibles flechas?
• El objetivo de las pruebas (criterio de finalización de las pruebas) consiste en
conseguir una cobertura de ramas previamente determinada (cobertura de
ramas o Medida-C1)
Nº de ramas cubiertas por casos

Medida- C1 (Cobertura de ramas) = (diseñadas o recorridas)
* 100%
Nº total de ramas
249

• Ejemplo V/04-3
• Se da el segmento de programa representado por el gráfico
de flujo de control de la ilustración de la derecha
• Tres diferentes caminos recorren este segmento de
programa
• Una rama de la primera sentencia IF se reparte de nuevo en
dos caminos mediante la segunda sentencia IF – el bucle se
encuentra en la rama derecha de la sentencia
• Todas las aristas sólo pueden ser alcanzadas mediante la
combinación de los tres caminos diferentes
• Tres casos de prueba llevarán a una cobertura del 100% de
las ramas
• Por los dos caminos de la derecha se pueden aún cubrir
nueve de las diez aristas (Medida-C1=90%)
250

• Ejemplo V/04-4:
• Aquí se representa el gráfico de un segmento de programa
algo más complicado
• Cuatro posibles caminos recorren el segmento del
programa
• para ambas ramas de la primera sentencia IF se dan
respectivamente otras dos posibilidades de recorrido
debido a las siguientes sentencias IF
• recorriendo tres caminos sólo se recorren un máximo
de trece de las quince aristas (C1=86,66%)
• Para una cobertura 100% de los nodos/aristas se
necesitan cuatro casos de prueba
• Los casos de prueba para la cobertura de ramas pueden
servir aquí también para la cobertura de sentencias!
251
• Este método lleva, por lo general, a mayor número de casos de prueba que la
cobertura de sentencias
• ¡La cobertura del 100% de las sentencias está contenida en una
cobertura del 100% de las ramas!
• No se puede evitar tener que recorrer varias veces algunas aristas
• Inconvenientes
• Las sentencias que falten no son localizadas
• Inapropiado para la comprobación de condiciones complejas
• Insuficiente para la comprobación de bucles
• No se tienen en cuenta las dependencias entre bucles
252
Cobertura de sentencias y de ramas
• Ambos procedimientos se refieren al recorrido de gráficos de flujo de control
• La diferencia se debe al diferente número de casos de prueba
• En el gráfico de flujo de control sólo se recoge el resultado de las sentencias

(p.ej., IF (x > y) puede ser cierto o falso)
• Esto es , qué camino se toma después de una sentencia
• Quedan sin considerar aquí los errores dentro de la sentencia, es decir,
errores dentro de sus condiciones múltiples
253
Otras técnicas basadas en estructura. Cobertura de condiciones
• Este procedimiento examina los procesos dentro de las sentencias de un
segmento de programa
• ¿En qué condiciones se basa el valor verdadero que devuelve una
sentencia?
• El objetivo es localizar errores que se encuentren en condiciones (condiciones
múltiples)
• Las condiciones múltiples se forman mediante la unión con operadores
(OR, AND, etc.) de condiciones elementales (p.ej., a > 2 OR b < 6)
• Las condiciones elementales (como parte de una condición también
condiciones elementales parciales) no contienen operadores lógicos
(p.ej., a > 2) – se permiten los símbolos relacionales (=, > , <, etc.)
• Se distinguen tres variantes de la cobertura de condiciones
• Cobertura de condiciones simple, múltiple y múltiple mínima
254

simple
• Cada condición parcial elemental dentro de una condición múltiple debe
tomar en la prueba tanto el valor verdadero como el valor falso
• El ejemplo de la izquierda explica la cobertura
de condiciones simple
• Se da una condición múltiple sencilla
Ejemplo V/04-6:
Se da la siguiente condición: • Con sólo dos casos de prueba se consigue la
cobertura simple
a > 2 OR b < 6
• Cada condición parcial ha adoptado
Los casos de prueba para la cobertura de ambos estado (verdadero y falso)
condiciones simple serían p.ej. :
• El resultado de la condición completa es, sin
a =6 (verd.) b=9 (falso) a>2 OR b<6 (verd.)
embargo, en ambos casos de prueba el
a=1 (falso) b=2 (verd.) a>2 OR b<6 (verd.) mismo
• verdadero OR falso = verdadero
• Los diferentes valores verdaderos de la
condición completa no son tenidos en cuenta
255
múltiple
• Todas las combinaciones que se puedan formar a partir de los estados de las
condiciones básicas contenidas deben estar contenidas en la prueba
• El ejemplo de la izquierda explica la cobertura de

Ejemplo V/04-6: condiciones múltiple
Se da la siguiente condición: • Se da una condición múltiple sencilla
a > 2 OR b < 6
• Con cuatro casos de prueba se consigue la
cobertura múltiple
Los casos de prueba para la cobertura de
condiciones múltiple serían p.ej. : • Se han formado todas las posibles
combinaciones de estados (verdadero & falso)
a=6 (verd.) b=9 (falso) a>2 OR b<6 (verd.) • Se han alcanzado todas las posibles salidas de
a=6 (verd.) b=2 (verd.) a>2 OR b<6 (verd.) la condición múltiple
a=1 (falso) b=2 (verd.) a>2 OR b<6 (verd.)
a=1 (falso) b=9 (falso) a>2 OR b<6 (falso) • El número de casos de prueba crece
exponencialmente:
• n = Nº de condiciones elementales
• 2n = Numero de casos de prueba
256
Otras técnicas basadas en estructura. Cobertura mínima de

condiciones múltiple
• Todas las combinaciones que se puedan formar a partir de los estados de
las condiciones parciales contenidas deben estar incluidas en la prueba, si
la variación del valor verdadero de una condición parcial puede influir en el
resultado de la condición completa
• El ejemplo de la izquierda explica la cobertura mínima de
condiciones múltiple
Ejemplo V/04-6:
Se da la siguiente condición: • Se da de nuevo una condición múltiple sencilla
a>2 OR b<6
• En tres de los cuatro casos de prueba una modificación de uno
Los casos de prueba para la cobertura de de los valores verdaderos lleva a la modificación del resultado
condiciones múltiple serían p.ej. completo
• ¡Sólo en el 2º caso (verdadero OR verdadero) la
a=6 (verd.) b=9 (falso) a>2 OR b<6 (verd.) modificación de uno de los valores verdaderos no infuye
a=6 (verd.) b=2 (verd.) a>2 OR b<6 (verd.) en la condición completa – se puede prescindir del
segundo caso de prueba!
a=1 (falso) b=2 (verd.) a>2 OR b<6 (verd.)
a=1 (falso) b=9 (falso) a>2 OR b<6 (falso)
• El número de casos de prueba se reduce y queda entre n+1 y
2n
257

• La cobertura de condiciones simple es un instrumento débil para comprobar
condiciones múltiples
• La cobertura de condiciones múltiple es un procedimiento sólido
• Cumplimiento de la cobertura de ramas y sentencias
• Por contra muchos casos de prueba (cantidad: 2n)
• Eventualmente no se pueden representar las combinaciones
• P.ej., para “5< x AND x < 10” no pueden ser nunca ambas condiciones
parciales falsas
• La cobertura mínima de condiciones múltiples ofrece ventajas
• Reduce el número de casos de prueba (de n+1 a 2n)
• La cobertura de ramas y sentencias también quedan cubiertas
• Tiene en cuenta la complejidad de las condiciones
Si existen condiciones complejas deberán ser comprobadas. La
cobertura mínima de condiciones múltiples es un procedimiento
adecuado
258
Otras técnicas basadas en estructura. Cobertura de rutas
• En el centro de estudio se sitúa la cobertura de todas las rutas del programa

• Ruta: caminos que pueden tomas los datos dentro del programa
• En la cobertura de ramas es suficiente, p.ej. para un bucle, un caso de
prueba que lo recorra
• La cobertura de rutas necesita de casos de prueba adicionales:
• uno que no recorra el bucle y
• respectivamente uno para cada posible recorrido adicional del bucle
259
• La base del análisis es de nuevo el gráfico de flujo de control
• Las sentencias son los nodos
• El flujo de datos se representa mediante aristas
• Una ruta es el recorrido de nodos y aristas de principio al fin del gráfico
de flujo de control
• El objetivo de las pruebas (criterio de finalización de las pruebas) es un valor
predefinido de cobertura de rutas:
Número de rutas recorridas* 100%

Medida de cobertura de rutas =
Número total de rutas
260
Otras técnicas basadas en estructura.

Cobertura de rutas
• Ejemplo V/04-7:
• Se da el segmento de programa representado por el
gráfico de flujo de control de la ilustración de la
derecha
• Compuesto de tres sentencias IF
• Tres diferentes “caminos” recorren este segmento de

programa
• Se pueden recorrer cinco rutas diferentes

• Son necesarios cinco casos de prueba para una
cobertura de rutas del 100%
• (Sólo dos para un 100% de la medida C0 y tres para
C1)
261
Otras técnicas basadas en estructura.

Cobertura de rutas
• Ejemplo V/04-7:
• Se da el segmento de programa representado
por el gráfico de control de flujo de la ilustración
de la derecha
• Compuesto por dos sentencias IF y un bucle
(dentro de la segunda sentencia IF)
• Tres diferentes “caminos” recorren este

segmento de programa
• Se pueden recorrer cuatro rutas diferentes

teniendo en cuenta el doble recorrido del bucle
• Cada recorrido adicional del bucle supone un

caso de prueba adicional
262
• La cobertura de rutas del 100% sólo se puede lograr con los segmentos de
programa más sencillos
• Un bucle lleva p.ej., a una explosión de los casos de prueba, ya que cada posible
recorrido del bucle debe ser considerado como una ruta propia
• La cobertura de rutas tiene mayor alcance que la cobertura de sentencias o de

ramas
• Se recorre cada posible ruta dentro del segmento de programa a analizar
263
05 – Técnicas basadas en la experiencia
Especificación intuitiva de casos de prueba

• Definición
Procedimiento en el que los casos de prueba son elaborados sin un modo de
proceder claramente metódico en base a la intuición y la experiencia del
probador.
• Los casos de prueba se basan en la intuición y experiencia

• ¿Donde han aparecido ya errores frecuentemente en el pasado?
• ¿Donde podría aparecer todavía un error?
• La especificación intuitiva de casos de prueba se denomina también como

pruebas orientadas a puntos débiles o error guessing
264

• En la práctica sólo se utiliza para completar un conjunto de casos de prueba
disponibles
• No es suficiente para procedimientos de prueba sistemáticos
• Sin embargo, a menudo obtiene casos de prueba que no es posible especificar
mediante otros procedimientos
• Ejemplos:
• En la introducción de una fecha utilizar 30.02.2005
• Conjuntos vacios en datos de entrada
• Como método es aplicable mas bién en las etapas posteriores de las pruebas
265
• El probador debe tener experiencia o conocimientos que pueda transformar en
casos de prueba
• Intuición – ¿Dónde pueden estar los errores?
• La intuición caracteriza a un buen probador
• Experiencia – ¿Dónde hubo errores en el pasado?
• Los probadores experimentados tienen este conocimiento
• Alternativamente se pueden recuperar listas con efectos de error recurrentes
• Saber / conocimiento – ¿Dónde se pueden esperar aquí los errores?
• Entran los detalles especiales del proyecto
• ¿Dónde se pueden esperar más errores en función de la complejidad o la escasez de
tiempo?
266
Casos de prueba intuitivos – Posibles fuentes
• Resultados de pruebas y experiencias práctica con sistemas similares
• Eventualmente un antecesor del software o un sistema con funcionalidad similar
• Experiencias de usuarios
• Intercambio de experiencias relativas al software en círculos de usuarios
• Puntos críticos de la implantación

• ¿Que áreas del software se utilizarán principalmente?
• Dificultades del desarrollo

• ¿Es previsible un mayor número de errores en áreas determinadas?
267
• La especificación intuitiva de casos de prueba es un buen complemento para
los procedimientos sistemáticos
• Debe permanecer, sin embargo, como un complemento
• No hay criterios para comprobar su integridad – el número de casos de prueba
intuitivos puede variar mucho
• La ejecución de las pruebas se corresponde con el de los casos de prueba

especificados sistemáticamente
• Sólo se diferencia en la forma en la que el caso de prueba es especificado /
determinado
• Mediante las pruebas intuitivas se pueden encontrar errores adicionales que

no se hubieran detectado mediante las pruebas sistemáticas
268
Pruebas exploratorias
• Consiste en la realización concurrente de diseño, ejecución, y registro de
pruebas, y aprendizaje basado en unos objetivos de prueba dentro de una
planificación de pruebas.
• En las pruebas orientadas a scripts manuales, la ejecución de las pruebas, sin
embargo, se lleva a cabo, siguiendo una secuencia de pruebas previamente
documentada.
• Técnica informal en la que el probador controla de manera activa el diseño de
las pruebas así como de aquellas pruebas que se han ejecutado, y utiliza la
información obtenida durante las pruebas para diseñar nuevas y mejores
pruebas.
• Buena aproximación cuando:
• Las especificaciones son escasas o inadecuadas,
• Hay presiones de tiempo, y
• Como complemento a otras técnicas mas formales
269
Pruebas exploratorias. Comparativa de aproximaciones
En pruebas tradicionales (scripted), las pruebas son diseñadas y registradas. Luego

pueden ser ejecutadas posteriormente, incluso por otro probador
Basadas en términos:
- Cuantitativos, y
- Decisión
Vs
En las pruebas exploratorias, las pruebas son diseñadas y ejecutadas al mismo tiempo,
y a menudo no son registradas
Basadas en términos de:

- Adaptación y
- Aprendizaje
270
06 – Selección de técnicas de prueba
¿Qué técnica seleccionar?
• La selección de qué técnicas utilizar depende de múltiples factores, entre los

que se incluyen el tipo de sistema, estándares regulatorios, requisitos del
cliente o contractuales, nivel de riesgo, tipo de riesgo, objetivo de las pruebas,
documentación disponible, conocimiento de los probadores, tiempo y
presupuesto, ciclo de vida de desarrollo, modelos de caso de uso y experiencia
previa en cuanto al tipo de defectos encontrados.
• Algunas técnicas son más aplicables a ciertas situaciones y niveles de prueba;

otras son aplicables a todos los niveles de prueba.
• Los probadores normalmente, cuando crean los casos de prueba, usan una
combinación de técnicas de prueba que incluye procesos, normas y técnicas
“data-driven”, para asegurar una adecuada cobertura del objeto bajo prueba.
271
07 – Resumen
• Existen muchos procedimientos de prueba diferentes con objetivos distintos
• Algunas pruebas requieren controladores de pruebas y stubs adicionales
• Diferencia entre técnicas de caja negra y caja blanca
• ¡El objetivo debería ser especificar con el mínimo esfuerzo los casos de
prueba más relevantes!
• La formación de clases de equivalencia en combinación con el análisis de
valores límite debería aplicarse a cada objeto de prueba
• Las pruebas referidas al estado tienen en cuenta los diferentes estados que
puede adoptar un objeto de prueba durante su ejecución
• En general los procedimientos de caja negra no pueden descubrir funciones
desarrolladas adicionalmente a las funciones especificadas
272
07 – Resumen
• La ejecución del segmento del programa está en primer plano en la ejecución

de las pruebas de caja negra y las pruebas de caja blanca
• Las pruebas de caja blanca se utilizan en la fase más temprana de las
pruebas
• Las pruebas de caja negra se ponen en práctica en las fases más tardías con
los métodos adecuados
• Como complemento a los métodos mencionados anteriormente nunca debería
prescindirse de la especificación intuitiva de casos de prueba
• Las pruebas engloban diferentes métodos y procedimientos que pueden ser
combinados con sentido
273
274
Capítulo VI – Gestión del proceso de
pruebas
• VI/01 Consideraciones previas generales
• VI/02 Organización del equipo de pruebas
• VI/03 Estimación y planificación de las pruebas
• VI/04 Monitorización y control de las pruebas
• VI/05 Gestión de la configuración
• VI/06 Riesgo y pruebas
• VI/07 Gestión de incidencias
• VI/08 Resumen
275
VI – Gestión del proceso de pruebas
01 – Consideraciones previas generales
Consideraciones previas.
• Las pruebas sistemáticas de software y la gestión de la calidad disminuyen a

largo plazo los costes de desarrollo y mantenimiento.
• La utilización temprana de la gestión de pruebas minimiza los riesgos en la
implantación y permite acortar los tiempos del desarrollo del proyecto.
• La gestión de pruebas proporciona transparencia y es, al mismo tiempo, un
indicativo valioso para el estado global del proyecto.
• Dentro del ciclo de vida de un producto deben llevarse a cabo diferentes
tareas de pruebas.
• La gestión de pruebas temprana y profesional asegura a largo plazo las
inversiones.
276
02 – Organización del equipo de pruebas
Generalidades.
• Las pruebas son una actividad que se distribuye durante el proceso de
desarrollo completo.
• Desde el primer componente hasta la aceptación.
• Las pruebas comienzan ya con la elaboración de los primeros documentos
(en forma de revisiones).
• En cada fase del desarrollo se dispone de diferentes objetos de prueba
para los que a su vez se deben implantar diferentes procedimientos de
pruebas.
• Pruebas de componentes, pruebas de integración, pruebas de
sistema, etc.
• Para cada una de estas fases de pruebas deben formarse probadores o
equipos de pruebas.
• Hay que equilibrar los costes y el aprovechamiento.
• Escoger al equipo de pruebas en base a las áreas.
277
02.1 – Organización del equipo de pruebas
Posibles formas de organización.

1. No hay probadores independientes. Los desarrolladores de software son
responsables de las pruebas de su propio código.
2. Hay probadores independientes dentro del equipo de desarrollo.
3. Hay un equipo de pruebas independiente en la organización. Este grupo
informa al gestor de proyecto.
4. Existen probadores independientes que forman parte del área de negocio o
del área usuaria.
5. Existen equipos especializados en pruebas dentro del proyecto que asumen
las actividades de pruebas, principalmente para objetivos específicos: usabilidad,
seguridad o certificación de la funcionalidad.
6. Hay probadores independientes, externalizados o externos a la organización.
Junto al enfoque de pruebas de aplicaciones mostrado aquí se debe tener en

cuenta durante la organización de los equipos de pruebas, que también se
requiere una organización de pruebas adecuada para las revisiones.
278
Beneficios y desventajas de la independencia.
• Entre los beneficios de la independencia se incluyen:

• Los probadores independientes ven diferentes defectos y son imparciales.
• Un probador independiente puede verificar suposiciones que ha hecho la gente
durante la especificación e implementación del sistema.
• Entre las desventajas se incluyen:

• Aislamiento del equipo de desarrollo (si la independencia es total).
• Los probadores de pruebas pueden ser el cuello de botella en tanto en cuanto
son el último punto de control.
• Los desarrolladores pueden perder sensación de responsabilidad respecto de la
calidad.
279
Perfiles.
• Para proyectos grandes, complejos o críticos desde el punto de vista de la
seguridad de las personas, suele ser mejor tener múltiples niveles de prueba,
siendo realizados algunos o todos ellos por probadores independientes. El
personal de desarrollo puede participar en las pruebas, especialmente en los
niveles más bajos, pero su falta de objetividad suele limitar su efectividad. Los
probadores independientes pueden tener autoridad para requerir y definir
procesos y reglas de pruebas pero los probadores sólo deberían asumir esos
roles relacionados con el proceso sólo cuando hay un claro mandato al
respecto.
• Dependiendo de la fase o nivel de prueba y los riesgos relacionados con el

producto y el proyecto, diferentes personas pueden asumir el papel de
probador manteniendo un cierto grado de independencia. Los probadores
típicos a nivel de componente y de integración de componentes serían los
desarrolladores, en las pruebas de aceptación, expertos en negocio y usuarios
y en la aceptación operativa los operadores. Las pruebas de sistema e
integración de sistemas suelen ser llevadas a cabo por equipos independientes
de prueba.
280
Perfiles.
• En el marco de las pruebas se necesitan muchos colaboradores

diferentes. Para diferentes tareas se requieren diferentes cualificaciones.
• Se distinguen en este curso dos perfiles básicos:

• Responsable de pruebas (test leader).
• Probador (tester).
• Las actividades y tareas ejecutadas por estos dos roles dependen del
proyecto y de la organización.
• A veces al responsable de pruebas se le llama también gestor de pruebas
o coordinador de pruebas.
• El rol de responsable de pruebas puede ser realizado por un jefe de
proyecto, gestor de desarrollo, gestor de aseguramiento de calidad o el
jefe de un grupo de pruebas.
• En proyectos más grandes pueden existir dos posiciones diferenciadas:
responsable de pruebas y gestor de pruebas.
281
Perfiles.
• Respecto a los probadores, en función del grado de especialización se

puede hablar de:
• Analista de pruebas.
• Diseñador de pruebas.
• Automatizador de pruebas.
• Administrador del sistema de pruebas.
• Ejecutor de pruebas.
• Se pueden diferenciar otros roles.
282
Perfil del responsable de pruebas.
• Entre las tareas típicas de un responsable de las pruebas se pueden incluir:

• Coordinar la estrategia y el plan de pruebas con los jefes de proyecto y otros
responsables.
• Escribir o revisar una estrategia de pruebas para el proyecto, así como una política
de pruebas para la organización.
• Contribuir con la perspectiva de prueba en otras actividades del proyecto, como la
integración de la planificación.
• Planificar las pruebas – considerando el contexto y comprendiendo los objetivos y
riesgos de las pruebas – incluyendo la selección de enfoques de prueba, la
estimación del tiempo, esfuerzo y coste de las pruebas, adquisición de recursos,
definición de los niveles y ciclos de prueba y planificación de la gestión de
incidencias.
• Iniciar la especificación, preparación, implementación y ejecución de las pruebas,
monitorizar sus resultados y comprobar los criterios de finalización.
283
• Adaptar la planificación en base a los resultados y progresos de las pruebas

(documentado en ocasiones en informes de estado) y tomar cualquier acción
necesaria para compensar los problemas.
• Establecer una gestión de configuración del software relacionado con las pruebas,
para asegurar la trazabilidad.
• Introducir métricas adecuadas para la medición del progreso de pruebas y evaluar la
calidad de las pruebas y del producto.
• Decidir qué debería automatizarse, hasta donde y cómo.
• Seleccionar herramientas para dar soporte a las pruebas y organizar la formación de
los probadores en su uso.
• Decidir sobre el levantamiento del entorno de pruebas.
• Escribir informes resumen de las pruebas basadas en la información recopilada
durante éstas.
284
• Se necesitan experiencias especiales en las áreas de:

• Pruebas de SW y gestión de la calidad.
• Planificación y dirección de pruebas.
• Experiencia en dirección de proyectos.
• Capacidad para dirigir.
285
Tareas del probador.

• Entre las tareas típicas de un probador se pueden incluir:
• Revisar y contribuir en los planes de prueba.
• Analizar, revisar y evaluar los requisitos de usuario, las especificaciones y los
modelos, para valorar qué tanto pueden ser probados.
• Crear especificaciones de pruebas
• Montar el entorno de prueba (frecuentemente coordinándose con los
administradores de sistemas y administradores de red).
• Preparar y adquirir datos de prueba.
• Implementar pruebas a todos los niveles, ejecutar y registrar los resultados de
las pruebas, evaluar los resultados y documentar las desviaciones respecto de
los resultados esperados.
• Usar herramientas de administración o gestión de las pruebas y probar
herramientas de monitorización según se necesite.
• Automatizar pruebas (puede ser soportado por un desarrollador o por un experto
en automatización de las pruebas).
• Medir las prestaciones de componentes y sistemas (si aplica).
• Revisar las pruebas desarrolladas por otros.
286
02.3 – Organización del equipo de pruebas. Perfiles
Perfiles.
• Analista y diseñador de pruebas.

• Estudia la documentación de entrada con el fin de analizar, revisar y evaluar
los requisitos de usuario, las especificaciones y los modelos, para valorar qué
tanto pueden ser probados.
• Propone las pruebas necesarias y establece el orden de su ejecución.
• Conocimientos:
• Conocimiento (Know-how) de desarrollo y pruebas.
• Conocimientos de ingeniería de SW.
• Conocimientos sobre métodos de análisis y de especificación.
• Automatizador de pruebas.
• Comprueba las posibilidades de automatización y las lleva a cabo.
• Conocimientos:
• Experiencia como probador.
• Conocimientos (Know-how) en diseño de pruebas y automatización.
• Experiencia en programación.
• Muy buenos conocimientos de las herramientas implantadas.
287
Perfiles.
• Administrador del sistema de pruebas.

• Implanta el entorno de las pruebas y lo gestiona.
• Conocimientos:
• Administración de sistemas (o acceso a un administrador de sistemas).
• Herramientas de desarrollo y pruebas.
• Sistemas de bases de datos, Redes en caso de ser necesario.
• Instalación y gestión del entorno del sistema.
• Ejecutor de las pruebas de software.

• Ejecuta las pruebas en función de los supuestos / especificaciones.
• Conocimientos:
• Conocimientos generales de IT y básicos de pruebas.
• Manejo / parametrización de la herramienta implantada.
• Experiencia en la ejecución de pruebas.
• Conocimientos acerca del objeto de prueba.
288
Perfiles.
• Experto técnico.
• Completa el equipo de pruebas en caso de necesidad.
• Pueden ser:
• Administradores o diseñadores de bases de datos.
• Expertos en interfases de usuario.
• Especialistas en redes.
• Otros perfiles.
• Según el planteamiento del problema, el entorno de pruebas, etc. pueden
incorporarse otros especialistas al equipo de pruebas.
• Aquí se necesitan conocimientos especiales en materias que no tengan relación
con las pruebas, p.ej., expertos en usabilidad o psicólogos.
289
Perfiles.
• Perfiles Soft
• A las cualificaciones técnicas referidas se añaden factores como:
• Capacidad de trabajo en equipo, habilidad política o diplomática.
• Disponibilidad para consultar acerca de hechos evidentes.
• Capacidad para imponerse, apariencia de seguridad.
• Exactitud y creatividad.
• Manejar con seguridad situaciones complejas.
• Comentario:
Sin estas características añadidas un probador sólo tendrá un éxito condicional
aunque sea muy competente en la materia.
290
03.1 – Estimación y planificación de las pruebas
Planificación.
• En esta sección se cubre el propósito de la planificación de las pruebas,
tanto en proyectos de desarrollo e implementación como en actividades de
mantenimiento. La planificación puede documentarse en un plan de
proyecto o en un plan maestro de pruebas y en planes de pruebas
separados para cada nivel de prueba (como en las pruebas de sistema y de
aceptación). El ‘Standard for Software Test Documentation’ (IEEE 829)
bosqueja los documentos de planificación de las pruebas.
• La planificación está influida por la política de pruebas de la organización,
el alcance de las pruebas, objetivos, riesgos, restricciones, criticidad,
capacidad de ser probado y disponibilidad de los recursos. Cuanto más
progrese el proyecto y la planificación de las pruebas, más información se
encontrará disponible y más detalle podrá incluirse en el plan.
• La planificación de las pruebas es una actividad continua y se lleva a cabo
a lo largo de todas las actividades y procesos del ciclo de vida.
• El uso de la realimentación que proporcionan las actividades de pruebas,
permite reconocer riesgos de cambio, de forma que se pueda ajustar la
planificación.
291
Actividades de planificación de las pruebas.
• Entre las actividades de planificación de las pruebas se puede incluir:
• Determinar el alcance y los riesgos, e identificar los objetivos de las pruebas.
• Determinar el enfoque general a aplicar durante las pruebas (la estrategia de
prueba), incluyendo la definición de los niveles de prueba y los criterios de
finalización.
• Integrar y coordinar las actividades de prueba dentro de las actividades del ciclo
de vida del software: adquisición, suministro, desarrollo, operación y
mantenimiento.
• Tomar decisiones acerca de qué probar, que roles llevarán a cabo las
actividades de prueba, como deberán hacerse las actividades de prueba y como
se evaluarán los resultados de las pruebas.
• Planificar las actividades de análisis y diseño de las pruebas.
• Planificar la implementación, ejecución y evaluación de las pruebas.
• Asignar recursos a las diferentes actividades definidas.
• Definir la cantidad, nivel de detalle, estructura y plantillas para la documentación
de prueba.
• Seleccionar métricas para la monitorización y controlar la preparación y
ejecución de las pruebas, la resolución de defectos y los factores de riesgo.
• Establecer el nivel de detalle de los procedimientos de prueba con vistas a
proporcionar suficiente información para soportar una preparación y ejecución
de las pruebas reproducible.
292
Plan de pruebas.
• Es el documento en el que se presenta el alcance, enfoque, recursos y

planificación de las actividades de prueba. Asimismo, se identifica los
elementos a probar, las características a probar, las tareas, el personal
encargado de cada tarea y los riesgos asociados.
• El plan de pruebas, es adaptado y modificado a lo largo del proyecto.
• En el ‘Standard for Software Test Documentation’ (IEEE 829) se proporciona
una recomendación de estructura para el plan de pruebas.
293
Plan de pruebas según IEEE 829.
1. Identificador del Plan de pruebas 9. Entregables de pruebas

2. Introducción 10. Tareas de pruebas
3. Objetos de prueba 11. Necesidades de entorno
4. Características que deben ser (Infraestructura de pruebas)
probadas 12. Responsabilidades, obligaciones
5. Características que no deben ser 13. Personal y necesidades de formación
probadas
14. Planificación
6. Estrategia de pruebas
15. Riesgos de la planificación e
7. Criterios de aceptación y rechazo imprevistos
8. Criterios para la interrupción y el 16. Aprobación y Autorización
reinicio de las pruebas
294
Criterios de entrada
• Los criterios de entrada definen cuándo comenzar a probar, como por ejemplo,
al principio de un nivel de pruebas o cuando se tiene un conjunto de pruebas
preparado para su ejecución.
• Típicamente, los criterios de entrada pueden consistir en:
• Disponibilidad y preparación del entorno de pruebas.
• Preparación de las herramientas de pruebas en el entorno de pruebas.
• Disponibilidad de código que se puede probar.
• Disponibilidad de datos de prueba.
295
Criterios de finalización (salida).
• El propósito de los criterios de finalización es definir cuando dejar de probar,

como al final de un nivel de prueba o cuando un conjunto de pruebas tienen un
objetivo específico.
• Típicamente, los criterios de finalización pueden consistir en:
• Medidas del grado de rigurosidad, como cobertura de código, funcionalidad o riesgo.
• Estimación de la densidad de defectos o medidas de fiabilidad.
• Coste.
• Riesgos residuales, como pueden ser el número de defectos no corregidos o la falta
de cobertura de pruebas en ciertas áreas.
• Planificaciones, como las que se basan en el time to market.
296
Estimación de las pruebas.

• En este curso están cubiertas dos aproximaciones en la estimación del
esfuerzo en pruebas:
• La aproximación basada en métricas: estimar el esfuerzo en pruebas basándose
en métricas de proyectos previos o similares o en valores típicos.
• La aproximación basada en la experiencia: la estimación queda a cargo del
propietario (encargado) de las tareas o de expertos.
• Una vez estimado el esfuerzo en pruebas, pueden identificarse recursos y
prepararse una planificación.
• El esfuerzo en pruebas puede depender de múltiples factores, entre los que
se incluyen:
• Características del producto: la calidad de la especificación y de otra información
utilizada en los modelos de prueba (esto es, las bases de prueba), el tamaño del
producto, la complejidad del dominio del problema, los requisitos de fiabilidad y
seguridad y los requisitos de documentación.
• Características del proceso de desarrollo: la estabilidad de la organización,
herramientas usadas, proceso de pruebas, capacidades de las personas
involucradas y presión de tiempo.
• Los resultados de las pruebas: el número de defectos y la cantidad de re-trabajo
requerida.
297
Estrategia de Pruebas, Aproximación de pruebas
• La Aproximación o Enfoque de las pruebas es la implementación de la
Estrategia de pruebas para un proyecto específico
• Típicamente incluye decisiones tomadas basándose en los objetivos de las
pruebas y la evaluación de riesgos.
• Es el punto de partida para:
• La planificación del proceso de pruebas.
• La selección de las técnicas y tipos de pruebas a llevar a cabo.
• La definición de los criterios de entrada y de salida.
• La selección del enfoque de las pruebas debería considerar el contexto,
incluyendo:
• Riesgo de fallo en el proyecto, peligros que pueden afectar al producto y riesgos
de fallo del producto que pueden afectar a las personas, al entorno y a la
compañía.
• Capacidades y experiencia de las personas en las técnicas de prueba, las
herramientas y los métodos.
• El objetivo de esfuerzo de las pruebas y la misión del equipo de pruebas
• Aspectos reguladores, como las regulaciones internas y externas que aplican al
equipo de desarrollo.
• La naturaleza del producto y del negocio.
298
• Una forma de clasificar las aproximaciones o enfoques de prueba se basa
en el momento en el que se inicia el diseño de las pruebas:
• Enfoques preventivos, en los que las pruebas se diseñan tan pronto como se
puede.
• Enfoques reactivos, en los que el diseño se realiza después de que se ha
producido el software o el sistema.
• Entre los enfoques o estrategias típicos se incluyen:
• Enfoques analíticos, como las pruebas basadas en riesgos, en las que la prueba
se orienta a las áreas de mayor riesgo.
• Enfoques basados en modelos, como las pruebas estocásticas, en los que se
utiliza información estadística acerca de los ratios de fallo (como los modelos de
crecimiento de fiabilidad) o uso (como los perfiles operacionales).
• Enfoques metódicos como los basados en fallos (incluyendo error guessing y
fault-attacks), los basados en la experiencia, los basados en listas de
comprobación y los que se basan en características de calidad.
• Enfoques que cumplen procesos o estándares, como los especificados por
estándares industriales o las metodologías “agiles”.
• Enfoques dinámicos y heurísticos como las pruebas exploratorias en las que las
pruebas reaccionan a los eventos más que lo que se haya podido planear por
anticipado, y en las que la ejecución y la evaluación son tareas concurrentes.
299
• Enfoques de consulta, como aquellos en los que la cobertura de pruebas está

dirigida principalmente por el asesoramiento y guía de expertos en el dominio
tecnológico y/o de negocio, fuera del equipo de pruebas.
• Enfoques centrados en la regresión, como aquellos que incluyen la reutilización
de material de pruebas existente, automatización exhaustiva de pruebas de
regresión y suites de prueba estándar.
• Pueden combinarse diferentes enfoques, por ejemplo, un enfoque dinámico
basado en riesgo.
300
04.1 – Monitorización y control del proceso de prueba
Monitorización.
• El propósito de la monitorización de las pruebas es proporcionar
realimentación y visibilidad de las actividades de prueba. La información a
monitorizar puede ser recogida de forma manual o automática y puede
utilizarse para medir criterios de salida, como la cobertura. Pueden
utilizarse también métricas para valorar el progreso respecto del calendario
y presupuesto planificados. Entre las métricas de prueba comunes se
incluyen:
• Porcentaje de trabajo realizado en la preparación de casos de prueba (o
porcentaje de casos de prueba preparados).
• Porcentaje de trabajo realizado en la preparación del entorno de pruebas.
• Ejecución de casos de prueba (por ejemplo: número de casos de prueba que se
han lanzado / que no se han lanzado y casos de prueba que han pasado / que
han fallado.
• Información de defectos (por ejemplo, densidad de defectos, defectos
encontrados y corregidos, ratio de fallos y resultados de las re-pruebas).
• Cobertura de pruebas respecto a requisitos, riesgos o código.
• Confianza subjetiva de los probadores en el producto.
• Fechas de hitos de prueba.
• Costes de las pruebas, incluyendo el coste comparado con los beneficios de
encontrar el siguiente defecto o de lanzar la siguiente prueba.
301
Informes de pruebas
• Se trata de resumir información relativa al esfuerzo en pruebas, incluyendo:

• Qué ha ocurrido y cuando ha ocurrido, como, por ejemplo, las fechas en las que
se han alcanzado los criterios de finalización.
• Información y métricas analizadas para dar soporte a las recomendaciones y
decisiones que haya que tomar, como, por ejemplo, una evaluación de los
defectos que no han sido corregidos, el coste / beneficio económico de seguir
probando, los riesgos más destacados y una valoración (una estimación del
nivel de confianza) del software probado.
• Deberían recogerse métricas durante y al final de cada nivel de prueba, con
vistas a valorar:
• La adecuación a este nivel de los objetivos de prueba.
• La adecuación del enfoque de pruebas elegido.
• La efectividad de las pruebas respecto de sus objetivos.
302
Informes de pruebas
• En el ‘Standard for Software Test Documentation’ (IEEE 829) se recomienda
una estructura para el informe resumen de las pruebas:
• Identificador del documento
• Resumen
• Variaciones
• Evaluación comprensible
• Resumen de resultados
• Evaluación
• Resumen de actividades
• Aprobación.
303
Control de las pruebas

• Dentro del control de las pruebas se considera cualquier guía o acción
correctiva tomada como resultado de información y métricas recogidas e
informadas. Las acciones pueden cubrir cualquier actividad de prueba y
pueden afectar a cualquier otra actividad o tarea del ciclo de vida del software.
• Ejemplos de acciones de control de las pruebas son:
• Toma de decisiones basadas en la información de monitorización de las pruebas.
• Repriorización de las pruebas cuando ocurre un riesgo identificado (por ejemplo,
software suministrado tarde).
• Cambios en el calendario de pruebas debido a la no disponibilidad de un entorno de
pruebas.
• Establecimiento de un criterio de entrada que requiera que las correcciones hayan
de ser vueltas a probar (prueba de confirmación) por un desarrollador antes de
aceptarlas en un “build”.
304
05 – Gestión de la configuración
Generalidades.
• En el transcurso del desarrollo de software se producen una gran cantidad de
datos / informaciones/ resultados.
• Comenzando con los requisitos.
• Las especificaciones y el diseño del sistema.
• Componentes individuales y elementos integrados.
• Versiones completas del sistema.
• Dentro del proyecto existe un gran número de diferentes colaboradores que
deben trabajar juntos en los objetos mencionados anteriormente.
• Las partes individuales pasan por diferentes manos y son modificadas en
diferentes lugares.
305
Generalidades.
• Para mantener la perspectiva, cada documento, cada dato, cada versión del
programa debe ser descrito y catalogado claramente.
• Se asignan sucesivas versiones numeradas del software, etc.
• Las autorizaciones para su elaboración posterior son anotadas, etc.
• Las modificaciones se posponen para un control posterior.
306
Generalidades.
• Todas las tareas mencionadas anteriormente se engloban bajo el término de
gestión de la configuración
• El objetivo de la gestión de la configuración es establecer y mantener la
integridad de los productos (Componentes, datos y documentación) del
software o del sistema durante el proyecto y el ciclo de vida del producto
• Se trata en este caso de una función transversal dentro del proyecto – todas
las modificaciones deben ser recogidas de forma centralizada y poder ser
dadas a conocer según un esquema claramente definido
• Según el tipo y el alcance del proyecto pueden variar en gran medida los
requerimientos para la gestión de la configuración – se debe definir un plan de
gestión de la configuración individualizado
• En la IEEE 828 se dispone de un estándar para la gestión de la configuración y

sus planes correspondientes
307
Problemas típicos.
• Si se desatiende la gestión de la configuración surgirán casi irremediablemente
p.ej., los siguientes problemas:
• “Confusión de versiones” – confusión acerca de que versiones de los
ficheros van juntas, qué versiones son actuales – ¡se programa en base a
especificaciones “antiguas”!
• ¿Dónde y cuando se modificó algo? ¿Quién lo hizo? – Una modificación
paralela de los datos es posible... Las modificaciones pueden ser en
ocasiones sobrescritas.
• ¿Qué versión de los ficheros se probó? – ¡Sin indicaciones claras acerca
de las versiones se dificultan las pruebas y su valoración!
308
Requisitos de la gestión de configuración.

• Desde el punto de vista de un probador la gestión de la configuración
permite que todos los elementos de testware se puedan identificar,
versionar y controlar. Que se pueda hacer un seguimiento de los cambios y
tener trazabilidad con los componentes desarrollados y probados:
• Gestión de versiones.
• Catalogar, almacenar y recuperar las diferentes versiones de un objeto
(V1.0, V1.1 etc.)
• Registro de comentarios y motivos de modificación.
• Administración de configuraciones.
• Determinación y administración de todos los datos de la versión
correspondiente que pueden juntarse en un sistema parcial.
• Seguimiento del estado.
• El seguimiento de errores y modificaciones, el registro de reportes de
problemas y la posibilidad de poder hacer el seguimiento de su
conversión.
309
Comprobación de la configuración.
• Una comprobación de la configuración se implanta para verificar la efectividad
de la gestión de la configuración.
• Dentro de la comprobación de la configuración de comprueba entre otras

cosas:
• Si todos los componentes han sido recogidos en la gestión de la
configuración.
• Si las configuraciones pueden ser siquiera identificadas.
310
06 – Riesgo y pruebas
Definición de riesgo.
• Un riesgo es la posibilidad de que ocurra un evento con consecuencias no

deseadas, un problema potencial. El nivel de riesgo vendrá determinado por la
probabilidad de que ocurra el evento adverso y por el impacto (el daño
resultante).
311
06.1 – Riesgo y pruebas
Riesgos del proyecto.
• Los riesgos asociados a proyecto que puedan influir en el éxito de éste deben
ser gestionados.
• Se ha de estimar la probabilidad de que ocurra y el daño potencial.
• Implementar medidas para tratar los riesgos identificados.
• Evitar riesgos
• Mitigar riesgos (preparar de forma activa medidas para reducir la probabilidad y/o el
daño potencial).
• Controlar riesgos (preparar medidas necesarias si el riesgo se transforma en un
problema, reservar tiempo y dinero).
• Ignorar el riesgo (esperar que los riesgos no acaben generando un problema, rezar,
cruzar los dedos, etc).
• Las tres primeras opciones cuestan dinero, la cuarta puede costar mucho
dinero.
312
Riesgos típicos en un proyecto.
• Factores organizativos.
• Falta de recursos o de capacidad.
• Problemas personales entre equipos o entre miembros del mismo equipo.
• Insuficiente cooperación entre departamentos.
• Estimaciones no realistas.
• Factores técnicos.
• Requisitos incorrectos, incompletos o no realistas.
• No se pueden satisfacer los requisitos debido a la existencia de ciertas restricciones
• Tecnologías, métodos o herramientas nuevos.
• Baja calidad del diseño, del código o de las pruebas.
• No disponibilidad del entorno de pruebas a tiempo.
• Conversión de datos tardía, planificación y desarrollo de la migración y herramientas
de migración/conversión de datos de prueba.
• Riesgos asociados al proveedor.
• Cambios debidos a requisitos legales.
• Problemas contractuales con el suministrador.
• Mala calidad de los productos proporcionados por suministradores nuevos.
313
Riesgos asociados al producto.

• Se entiende como riesgos asociados a producto aquellas áreas de fallo
potencial en el software o en el sistema que son un riesgo para la calidad
del producto. Ejemplos:
• La funcionalidad del producto suministrado es insuficiente.
• Atributos no funcionales insuficientes.
• Integridad y Calidad de los datos pobre.
• El producto no se ajusta al uso para el que estaba previsto, por lo que no puede
implantarse en producción.
• El producto puede causar daños a la propiedad.
• El producto puede causar accidentalmente heridas o muerte.
• El nivel de riesgo identificado sirve para decidir donde empezar a probar y
donde se debe probar más. Se prueba para reducir la probabilidad de que
ocurra el efecto negativo o para reducir el impacto.
• Los riesgos de producto son un tipo especial de riesgo que afectan al éxito
de un proyecto. Las pruebas son una actividad de control de riesgos que
proporciona información acerca del riesgo residual, mediante la medición
de la efectividad de la eliminación de defectos críticos y planes de
contingencia o evitar los riesgos asociados al producto.
314
Gestión de los riesgos del producto.
• Gestionar los riesgos del producto mediante las pruebas basadas en riesgo.
• Se han de identificar, analizar y priorizar los riesgos.
• Los riesgos deben tenerse en cuenta desde la fase de planificación de las
pruebas:
• Seleccionando métodos de prueba para mitigar los riesgos.
• Asignando un nivel de profundidad en las pruebas acorde al nivel de riesgos.
• Adaptando el orden de la ejecución de los casos de prueba (primero los casos que
puedan localizar errores críticos, de forma que se puedan encontrar lo antes posible).
• Actualizar la hoja de evaluación de riesgos regularmente. Los riesgos pueden
desaparecer o cambiar y pueden aparecer nuevos riesgos (nuevas funciones
solicitadas).
• Beneficios de las pruebas basadas en riesgo.
• Se escogen métodos de prueba para mitigar los riesgos identificados.
• El alcance de las pruebas toma en consideración los riesgos identificados. De
esta forma, los esfuerzos en pruebas se centran en la reducción del riesgo.
• Los errores que generan mayor nivel de riesgo se encuentran antes, por lo que
es más económico corregirlos.
• Aún en el caso de que haya que parar las pruebas, se asegura que los casos de
prueba más importantes han sido ejecutados (priorización de las pruebas basada
en riesgos).
315
07 – Gestión de incidencias
Localización de errores durante el trabajo de pruebas.
• Los probadores ejecutan las pruebas especificadas y documentan los
resultados.
• A continuación sigue la investigación acerca de las desviaciones entre los

resultados esperados y obtenidos.
• Los efectos de los errores se hacen públicos.
• En este punto el probador ha cumplido hasta el momento con su tarea.

• Ahora espera a someter a una repetición de las pruebas a la versión
corregida.
• La gestión y supervisión posterior de la eliminación de errores es asumida a

partir de este punto por la gestión de incidencias.
316
Tareas de la gestión de incidencias.
• En la gestión de incidencias se recogen todos las incidencias / errores
encontrados en el proyecto.
• Además de su recogida y administración se establecen informaciones
adicionales para los errores individuales.
• Se determina la gravedad del error.
• Estado del error- p.ej., abierto, en proceso de trabajo, solucionado…
• Todas las informaciones se almacenan en una base de datos central.
• Aquí es posible un tratamiento sin redundancias.
• Se proporciona una visión óptima acerca de los errores encontrados y su
tratamiento.
317
Tareas de la gestión de incidencias.
• Sin un proceso de gestión de incidencias en funcionamiento no se puede tener
un tratamiento ordenado de las mismas.
• La gestión de incidencias debe construirse al principio del proyecto.
• Algunos puntos que deben ser considerados para una gestión correcta de
incidencias son:
• Proporcionar notificaciones / formularios de notificación comunes.
• Todos las incidencias / errores / problemas deben ser recogidos,
independientemente de parte de qué persona involucrada en el proceso
provengan y de dónde hayan aparecido.
• Se debe definir una manera de proceder determinada para el tratamiento
de las incidencias (definir el proceso).
• Debe de existir en la organización unas normas establecidas para
clasificar las incidencias.
318
Reparto de tareas.
• Probador.
• Ejecuta las pruebas para detectar errores.
• Documenta los resultados (Documentación de pruebas).
• Registra los errores en la base de datos (Notificación de errores y desviaciones).
• Gestor de pruebas.
• Evalúa las notificaciones de errores.
• Otorga prioridades (de acuerdo con el director de proyecto, el cliente, ...)
• Supervisa el tratamiento.
319
Reparto de tareas.
• Gestión de las modificaciones o Change Control Board (CCB)
• Toma decisiones sobre las modificaciones y su priorización.
• Desarrollador.
• Corrige los errores de acuerdo con sus prioridades.
• Lleva a cabo todas las modificaciones acordadas.
• Las tareas se resuelven en un proceso iterativo:

• Probador
• Gestor de pruebas
• Gestión de las modificaciones (o CCB)
• Desarrollador
320
Notificación de incidencia (informe de incidencias)
• Objetivos.
- Proporcionar a los desarrolladores y otros roles de la organización,
información sobre los problemas detectados para permitir su identificación
y corrección en caso necesario.
- Proporcionar a los responsables de pruebas un medio de seguimiento de la
calidad del sistema bajo prueba y del progreso de las pruebas.
- Proporcionar ideas para la mejora del proceso de pruebas.
321
Contenido de una notificación de incidencia (informe de incidencias).
• La notificación del error / incidencia debería contener al menos los siguientes
puntos:
• Datos de la incidencia.
• Número único (p.ej., asignación secuencial).
• Datos acerca del objeto de prueba (nombre, versión).
• Entorno de pruebas.
• Nombre del notificador.
• Fecha de la primera aparición.
• Clasificación de la incidencia.
• Clase de la incidencia.
• Estado de la incidencia (nueva, repetición de las pruebas, etc.).
• Prioridad (primera valoración del notificador acerca de su urgencia).
322
Contenido de una notificación de incidencia (informe de incidencias).
• Descripción.
• Descripción breve.
• Descripción detallada de los pasos realizados durante la prueba que permitan su
reproducción y resolución, incluyendo toda la información adicional que se
considere importante (logs, datos de prueba, capturas de pantalla, etc.).
• Caso de prueba que ha provocado la incidencia (proporciona toda la información
acerca de las condiciones).
• Caso de prueba (proporciona toda la información acerca de las condiciones).
• Efecto de la incidencia.
• Origen de la incidencia.
• Referencia a notificaciones relacionadas.
• Comentarios.
• Eventualmente medidas de corrección adoptadas.
• El gestor de pruebas debe realizar adaptaciones del formato de la notificación

de incidencias a cada proyecto concreto.
323
Clases.
• La gravedad de una incidencia / error se determina según su clase:
• Las clases se pueden formar libremente.
• Las clases proporcionan diferentes niveles que se puede asignar a una
incidencia (críticas, graves, medias, ligeras).
• La base para la clasificación puede ser el grado de perjuicio en la
implantación del producto [DIN 66271].
324
Priorización.
• El tratamiento / la corrección de errores se lleva a cabo en función de la
prioridad asignada:
• Un criterio de priorización en sin duda la gravedad del error, en la que se
tienen en cuenta los efectos del mismo.
• Otros criterios pueden ser también el desarrollo del proyecto, etc. ¿En
que medida se impide el desarrollo posterior del proceso?
• Las prioridades podrían ser: eliminación indispensable, eliminación en el
siguiente tratamiento posterior del objeto, etc.
325
Estado de la incidencia.
• El estado de la incidencia determina en que fase de elaboración se
encuentra.
• Posibles caracterizaciones pueden ser:
• Nuevo – el error o incidencia ha sido notificado por primera vez por parte del
probador.
• Abierto – la notificación se liberó por parte del gestor de pruebas.
• Rechazado – la notificación fue rechazada por el gestor de pruebas.
• Investigado – el desarrollador intenta identificar el error.
• Observación – no se puede identificar el error, está en observación.
• En proceso – el error se ha liberado para su corrección (en caso contrario se
rechaza).
• Repetición de la prueba –se asigna por parte del desarrollador después de la
corrección.
• Solucionado – se asigna por el probador cuando el error se demuestra eliminado
después de la repetición de la prueba.
• No solucionado – la asigna el probador cuando el error continúa apareciendo.
326
Ejemplo de ciclo de vida de un error / incidencia.
• Se pueden dar las siguientes transiciones de estado:
Nuevo
Observación
Abierto
Rechazado
Investigado
En proceso
de corrección
No resuelto Prueba Resuelto
327
Estados.
• Sólo un probador puede confirmar un error como solucionado.
• El gestor de pruebas o el gestor de modificaciones decide si una incidencia

debe ser rechazada o trabajada en base a las informaciones disponibles
acerca del suceso y los costes de su eliminación.
• Todas las modificaciones junto a los comentarios se recogen en la gestión de

incidencias.
• Se proporciona un control constante sobre su tratamiento.
• Se puede determinar la continuación de las pruebas.
• En su caso se deben generar nuevos casos de prueba si la incidencia en
cuestión no surgió durante la comprobación mediante casos de prueba.
328
08 – Resumen
Afirmaciones importantes del capítulo.
• Para poder llevar a cabo pruebas efectivas deberían separase
organizativamente en los niveles más altos de las pruebas las actividades de
desarrollo y de pruebas.
• Dentro del proceso de pruebas se requieren colaboradores con distintos

conocimientos especiales de pruebas (p.ej., conocimientos relacionados con
la ergonomía o la seguridad).
• Junto a la competencia técnica también se requiere de una competencia

social.
• La planificación, la supervisión y la dirección de cada uno de los ciclos de

pruebas pertenecen a las tareas centrales del gestor de pruebas.
329
08 – Resumen
Afirmaciones importantes del capítulo.

• Las consideraciones económicas juegan un papel determinante en la gestión
de las pruebas.
• Un proceso de pruebas eficiente presupone una buena gestión de errores y
configuración.
• La base para un tratamiento de errores funcional es el registro común
siguiendo un esquema único a lo largo de todas las etapas del análisis de
errores.
• Las normas y estándares contienen supuestos para la ejecución técnicamente

correcta de pruebas de software.
330
331
Capítulo VII – Herramientas de
pruebas
• VII/01 Tipos de herramienta de pruebas
• VII/02 Uso efectivo de las herramientas: beneficios y
riesgos potenciales
• VII/03 La introducción de una herramienta en una
organización
• VII/04 Resumen
332
VII – Herramientas de pruebas
01.1 – Tipos de herramienta de prueba
Significado y propósito del soporte a pruebas mediante herramientas
• Las herramientas de pruebas pueden dar soporte a una o varias actividades de
pruebas. Incluyen:
• Herramientas utilizadas directamente en las pruebas, como herramientas de
ejecución de pruebas, de generación de datos y de comparación de resultados.
• Herramientas para ayudar en la gestión del proceso de pruebas y en el reporte y
monitorización de la ejecución de las pruebas.
• Herramientas usadas en la exploración (ej.: herramientas que monitorizan la
actividad de un fichero para una aplicación)
• Cualquier herramienta que de soporte a las pruebas (ej.: una hoja Excel)
• Propósitos del uso de herramientas para el soporte a pruebas:

• Mejorar la eficiencia automatizando tareas repetitivas o dando soporte a tareas
manuales de pruebas (como planificación, diseño, reporting…)
• Automatizar actividades que requieran un número significativo de recursos en
caso de hacerse manualmente (como el análisis estático)
• Automatizar actividades que no pueden ejecutarse manualmente (como las
pruebas de prestaciones a gran escala)
• Aumentar la fiabilidad de las pruebas (ej.; automatización de comparaciones de
grandes datos o simulación de comportamiento)
333
Clasificación de las herramientas de prueba
• Las tareas de pruebas pueden tanto apoyarse en herramientas (Tools) como
automatizarse mediante ellas.
• El apoyo de herramientas tiene sentido en aquellas áreas en las que se
trabaja de forma “creativa”.
• La pura ejecución de las pruebas - el doing - puede automatizarse
mediante herramientas.
• La totalidad de las herramientas se denomina en relación al concepto CASE
(Computer Aided Software Engineering), CAST-Tools (Computer Aided
Software Testing).
• Las herramientas se diferencian según su utilización. Para cada etapa del
proceso de pruebas se dispone de diferentes herramientas.
• Algunas de ellas pueden ser utilizadas para dar soporte a más de una
actividad. En tal caso se clasificará en base a la actividad a la que esté más
ligada.
334
Clasificación de las herramientas de prueba (Cont.)
• Algunas herramientas dan soporte a un tipo de actividad. Hay vendedores que
ofrecen familias de herramientas (suites) que proporcionan soporte a la
mayoría o a todas las actividades asociadas al proceso de pruebas (HP-
Quality Center, IBM-Rational, Borland…)
• Las herramientas son particularmente útiles cuando hay tareas repetitivas
proporcionando:
• Mejoras en la eficiencia
• Mejoras en la fiabilidad
• Algunas herramientas pueden ser intrusivas, pudiendo afectar al tiempo de
respuesta de la aplicación, por ejemplo: las herramientas de cobertura de
código (instrumentalización) o las de análisis de prestaciones (marcaje de
tiempos). Al tiempo adicional se le denomina efecto sonda.
• Hay herramientas que son particularmente útiles a los desarrolladores. En este
curso se marcarán con una “D”.
335
Clasificación de las herramientas de prueba (Cont.)
1.- Herramientas de soporte a la gestión y ejecución de las pruebas
A) Herramientas de gestión de pruebas
B) Herramientas de gestión de requisitos
C) Herramientas de gestión de incidencias
D) Herramientas de gestión de configuración
2.- Herramientas de soporte a las pruebas estáticas
A) Herramientas de revisión
B) Herramientas para el análisis estático (D)
C) Herramientas de modelado (D)
3.- Herramientas de soporte a la especificación de pruebas
A) Herramientas para el diseño de las pruebas
B) Herramientas de preparación de datos de prueba
4.- Herramientas de soporte a la ejecución y el registro de resultados
A) Herramientas para la ejecución de pruebas (Robots de pruebas, Depuradores (D)
y controladores de prueba).
B) Herramientas que proporcionan marcos de pruebas unitarias (frameworks) o
armazones de prueba (D).
C) Comparadores de prueba.
D) Herramientas de medida de cobertura (D).
E) Herramientas de prueba de seguridad.
5.- Herramientas de soporte al rendimiento y monitorización
A) Herramientas de análisis dinámico (D).
B) Herramientas de pruebas de rendimiento, carga y estrés.
C) Herramientas de monitorización
6.- Herramientas de soporte para áreas de aplicación específicas
7.- Otras herramientas.
336
1.- Herramientas de soporte a la gestión y ejecución de las pruebas
A) Herramientas de gestión de pruebas
• También conocidas como herramientas para la gestión de los casos y el
proceso de prueba .
• Apoyo al probador en la administración y la gestión de pruebas.
• Seguimiento de la ejecución de las pruebas y el estado de los casos de
pruebas.
• Interfaz con herramientas:
• Ejecución de casos.
• Gestión de incidencias.
• Gestión de requisitos.
• Gestión de configuración.
• Soporte a la trazabilidad de requisitos-casos-resultados-incidencias.
• Registro y administración de los casos, datos y resultados de prueba.
• Documentación de las pruebas.
• Generación automática de documentos como el plan de pruebas o los
informes de pruebas. En general, documentación de las pruebas a partir de
la información registrada (directa, resumida o procesada).
337
B) Herramientas de gestión de requisitos

• Hay quien considera que este tipo de herramientas no es, propiamente, una
herramienta de pruebas. En cualquier caso, gran parte de las pruebas se
basan en la comprobación de requisitos, por lo que las herramientas de
gestión de requisitos, que ayudan a mejorar la calidad de éstos, facilitan y
mejoran la calidad del trabajo de pruebas.
• Entre la funcionalidad que pueden proporcionar está:
• Almacenar el texto de los requisitos.
• Almacenar atributos de los requisitos (fecha de modificación, origen, tipo,
prioridad…).
• Comprobar la consistencia y la indefinición de requisitos (requisitos perdidos).
• Ayudar a la priorización de los requisitos.
• Ayudar a la trazabilidad de pruebas a requisitos, funciones y/o características (y
viceversa): trazabilidad hacia delante y hacia atrás. Trazabilidad entre niveles de
requisitos.
• Proporcionar interfaces con herramientas de gestión.
• También puede reportarse el grado de cobertura de requisitos, funciones
y/o características que proporciona un conjunto de pruebas.
338
C) Herramientas de gestión de incidencias

• En ocasiones, a estas herramientas se las denomina herramientas de
seguimiento de defectos, de gestión de defectos, “bug tracking”. Es mejor
hablar de gestión de incidencias porque puede haber anomalías no
asociadas a defectos, solicitudes de mejora, etc.
• Las herramientas de gestión de incidencias almacenan y gestionan
registros de incidencia. Asimismo, proporciona soporte a la gestión de las
incidencias de varias formas, entre las que se incluye:
• Asociar atributos para su tipificación.
• Facilitar su priorización.
• Asignar acciones a las personas (por ejemplo, corregir o realizar pruebas de
confirmación).
• Atribuirle un estado (por ejemplo, abierto, rechazado, duplicado, preparado para
probar, diferido hasta la siguiente release, cerrado). La definición de estados
suele ser “abierta”.
• Soporte a la generación de informes.
• Análisis estadístico.
• Asociar información adicional (correos, pantallazos…).
• La funcionalidad de gestión de incidencias puede (de hecho, suele) estar
incluida en herramientas de gestión de pruebas.
339
D) Herramientas de gestión de configuración

• Al igual que en los requisitos, las herramientas de gestión de la
configuración (Configuration Management - CM) no son estrictamente
herramientas de prueba, pero suelen ser necesarias para llevar a cabo el
seguimiento de las diferentes versiones del software y de las pruebas.
• Son particularmente útiles cuando se desarrolla en más de una

configuración de entornos hardware / software (por ejemplo, para diferentes
versiones de sistema operativo, diferentes librerías o compiladores,
diferentes navegadores o diferentes ordenadores).
• Las herramientas de gestión de la configuración:

• Almacenan información, no sólo de las versiones del software, sino también de
los programas relacionados con las pruebas.
• Ayudan a mantener la trazabilidad entre los productos software y el software y
documentación relacionado con las pruebas.
• Incluyen gestión de builds y releases.
• Ayudan a controlar el acceso a la información de prueba (seguridad de datos).
• Ayudan a la gestión de líneas base.
340
2.- Herramientas de soporte a las pruebas estáticas
A) Herramientas de revisión
• Dentro de los diversos tipos de revisión existentes, las herramientas de
revisión (también conocidas como herramientas de soporte al proceso de
revisión) son tanto más útiles:
• Cuanto más formal sea el proceso.
• Cuanta más gente participe en el proceso.
• Cuanto más repartida físicamente se encuentre.
• Entre las características que puede incluir una herramienta de soporte a las
revisiones están:
• Almacenar información acerca de los procesos de revisión.
• Almacenar, organizar, comunicar y ayudar al seguimiento de los comentarios.
• Generar informes acerca de los defectos y el esfuerzo necesario para su
resolución.
• Gestionar reglas y/o listas de comprobación (checklist).
• Realizar el seguimiento de la trazabilidad entre documentos y código fuente.
• Proporcionar ayuda a las revisiones online, lo que resulta útil si el equipo se
encuentre dispersado geográficamente.
• Monitorizar el estado de cada revisión (pasada, pasada con correcciones…).
• Recoger e informar métricas.
341
B) Herramientas para el análisis estático (D)

• Complementan el análisis realizado por los compiladores. De hecho,
algunos compiladores incorporan características de análisis estático
• Están asociadas al lenguaje de programación: una herramienta puede
analizar un número limitado de lenguajes. ¡Antes de adquirir una
herramienta de este tipo, hay que considerar y prever, de ser posible, las
tecnologías con las que se va a trabajar a corto y medio plazo!
• Estas herramientas pueden utilizarse, no sólo para analizar el código de la
aplicación, sino también otros elementos como requisitos, websites…
• Cálculo de métricas como los niveles de anidamiento, complejidad ciclomática,
etc. Alguna de estas métricas pueden utilizarse para análisis de riesgos: Mayor
complejidad, mayor posibilidad de error
• Refuerzo de estándares de codificación
• Análisis de flujos de control (estructuras, dependencias…)
• Soporte a la comprensión del código (representación gráfica de la estructura del
programa)
• Localización de anomalías en el flujo de datos
342
C) Herramientas de modelado (D)

• Al margen de ser una herramienta de soporte al diseño de software y, por
tanto, utilizadas por los desarrolladores, estas herramientas pueden ser
utilizadas en las pruebas:
• Validando modelos de software. Por ejemplo, un comprobador de modelos de
base de datos puede localizar defectos e inconsistencias en el modelo de datos.
Ello complementa las pruebas: se puede haber lanzado un caso de prueba
contra un dato, que el resultado sea correcto, pero que haya otro dato en la base
de datos inconsistente con el anterior y pueda generar un error.
• Ayudando a identificar y priorizar áreas de prueba
• Otras herramientas de modelado pueden localizar defectos en un modelo de
estado o de objetos.
• Estas herramientas pueden ayudar frecuentemente en la generación de algunos
casos de prueba basados en el modelo (véase también más abajo las
herramientas de diseño de pruebas)
El principal beneficio de las herramientas de análisis estático y las de

modelado es el ahorro en costes asociado a encontrar más defectos
en etapas tempranas del proceso de desarrollo (antes de lanzar las
pruebas dinámicas). Como resultado, el proceso de desarrollo
puede acelerarse y mejorarse al existir menos re-trabajo.
343
3.- Herramientas de soporte a la especificación de pruebas
A) Herramientas para el diseño de las pruebas

• Las herramientas de diseño de pruebas generan entradas o ejecutables de
prueba a partir de:
• Los requisitos.
• De una interfaz gráfica de usuario.
• De modelos de diseño (de estado, datos u objetos).
• Del código.
• De condiciones de prueba.
• También pueden generar resultados esperados (si incorpora un oráculo de
prueba).
• Este tipo de herramienta puede generar también salidas (esto es, puede
utilizar un oráculo de prueba).
• Las pruebas generadas a partir de un modelo de estados u objetos son
útiles para verificar la implementación del modelo en el software, pero son
pocas veces suficientes para verificar todos los aspectos del software o
sistema.
344
A) Herramientas para el diseño de las pruebas (Cont.)

• Pueden ser muy útiles si el objetivo es comprobar el funcionamiento de
todos y cada uno de los elementos (campos de entrada, botones, controles
de check, ramas…) de una aplicación. El problema que puede generarse
en este caso es que haya demasiados casos de prueba. En tal caso, debe
seleccionarse un subconjunto que minimice riesgos y/o que seleccione
casos significativos (ej: arrays ortogonales).
• Otras herramientas de esta categoría pueden ayudar a soportar la
generación de pruebas mediante plantillas estructuradas, denominadas a
veces marco de prueba, que generan pruebas o stubs de prueba,
acelerando así el proceso de diseño de pruebas.
• Todas las herramientas obtienen los datos a partir de formalismos o
determinadas estructuras.
• Nunca pueden sustituir al probador (persona) que dispone de creatividad,
intuición y conocimiento.
• Una elección manual de los datos o un tratamiento posterior de los datos
generados es a menudo necesario.
345
B) Herramientas de preparación de datos de prueba.

• Las herramientas de preparación de datos de prueba manipulan fuentes de
datos para establecer los datos de prueba a utilizar durante la ejecución de
las pruebas:
• Extrayendo datos de archivos o bases de datos.
• Construyendo múltiples datos similares a partir de una plantilla o perfil.
• Generando nuevos registros con datos pseudo-aleatorios.
• Son particularmente útiles:

• A efectos de protección de datos.
• En ocasiones se toman datos de producción para prueba. Estas herramientas pueden
coger el nombre de una persona, el apellido de otra, el teléfono de una tercera, etc,
generando un registro que no se corresponde con el de ninguna persona real.
• Para pruebas de fiabilidad y prestaciones en las que se necesitan grandes
volúmenes de datos realistas.
346
B) Herramientas de preparación de datos de prueba (Cont.)

• Generadores de datos de prueba basados en bases de datos.
• Obtienen datos de pruebas a partir de bases de datos o archivos.
• Reconocen estructuras y contenidos y obtienen de ellos datos de prueba.
• Generadores de datos de prueba basados en código.

• Obtienen datos de prueba a partir del código fuente.
• No pueden proporcionar valores esperados.
• Al igual que los métodos de caja blanca sólo pueden obtener datos que
investiguen “lo que hay”; las funciones que faltan etc. no son tenidas en cuenta
generalmente.
347
B) Herramientas de preparación de datos de prueba (Cont.)
• Generadores de datos de prueba basados en interfases.

• Obtienen datos de prueba en base a parámetros de interfases.
• Deducen clases de equivalencia y valores límite a partir de los rangos de
definición.
• Tampoco proporcionan valores esperados pero son adecuados para las pruebas
de robustez.
• Generadores de datos de prueba basados en requisitos.

• Obtienen datos o rangos de datos. A partir de esta información y aplicando
técnicas de partición de equivalencia o valores límite se pueden generar casos /
datos de prueba.
• Se necesita obligatoriamente una notación formal para las especificaciones.
• Las herramientas CASE pueden proporcionar modelos formales utilizables para
este tipo de generadores de datos de prueba.
348
4.- Herramientas de soporte a la ejecución y el registro de resultados.
• Se pueden distinguir los siguientes tipos:
A) Herramientas para la ejecución de pruebas.
B) Herramientas que proporcionan marcos de pruebas unitarias (frameworks) o
armazones de prueba (D).
D) Herramientas de medida de cobertura (D).
349
A) Herramientas para la ejecución de pruebas. Robots de prueba.
• Es frecuente que cuando se habla de una herramienta de pruebas, se

refiera a una herramienta de ejecución de pruebas. Las herramientas de
ejecución de pruebas permiten ejecutarlas de forma automática o
semiautomática, utilizando entradas y salidas esperadas almacenadas,
haciendo uso de un módulo de captura y reproducción y/o un lenguaje de
scripting (un lenguaje de programación).
• Aunque lo más llamativo es el módulo de captura que puede hacer pensar
que basta con grabar y reproducir, la máxima eficiencia la proporciona el
lenguaje de scripting, que hace posible manipular las pruebas con un
esfuerzo limitado, por ejemplo, repetir las pruebas con distintos datos o
probar diferentes partes del sistema que tengan pasos similares.
• En ocasiones es necesario proporcionar al script cierto grado de flexibilidad
(por ejemplo: ignorar un número secuencial que genera el sistema; al ser
siempre distinto, un script basado en una grabación “no inteligente” fallaría
siempre. Ello se consigue con programación.
350

(Cont.)
• Generalmente estas herramientas incluyen características de comparación

dinámica y proporcionan un registro de resultados de las pruebas para
cada vez que se corre una prueba.
• Las herramientas de ejecución de pruebas pueden también utilizarse para
registrar pruebas, cuando incorporan herramientas de captura y
reproducción. La captura de entradas de prueba durante las pruebas
exploratorias o no documentadas puede resultar útil para reproducir y/o
documentar una prueba, por ejemplo, si ocurre un fallo.
• La importancia que tienen estas herramientas en la automatización de la
ejecución de las regresiones hace que en ocasiones se oiga hablar de ellas
como de “herramientas de regresión”.
• Un aspecto crítico para que pueda utilizarse este tipo de herramientas es
disponer de un entorno de prueba y un conjunto de datos estable.
351
(Cont.)
• Entre las características principales de este tipo de herramientas se

encuentran:
• Captura de entradas de prueba (pulsaciones, movimientos o clicks de ratón…).
• Almacenamiento del resultado esperado.
• Ejecución de pruebas a partir de scripts almacenados y/o archivos de datos.
• Comparación dinámica.
• Registro de resultados.
• Medición de tiempos.
• Sincronización con la aplicación (esperar a que la aplicación esté preparada antes
de enviarle el siguiente comando).
• Generación de informes o envío de información a una herramienta de generación de
informes.
352
A) Herramientas para la ejecución de pruebas. Otras herramientas.
• Depuradores (D)
• Herramienta para la búsqueda de errores en un programa.
• Posibilitan un proceso secuencial del programa (ejecución de
sentencias individuales).
• El proceso puede pararse en cualquier momento para comprobar
cada una de las sentencias y condiciones.
• Las variables se pueden definir o referenciar de forma individual.
353
A) Herramientas para la ejecución de pruebas. Otras herramientas.

(Cont.)
• Controladores de pruebas
• Permiten el acceso a un objeto de prueba sin las interfases
correspondientes.
• Regulan la entrada y salida de datos y documentan el desarrollo.
• Registro de valores obtenidos.
• Pueden ser productos estándar ya preparados o se pueden programar
especialmente para el objeto de prueba a tratar.
• Proporcionan, además, por regla general, un entorno de ejecución.
354
B) Herramientas que proporcionan marcos de pruebas unitarias
(frameworks) o armazones de prueba (D).
• Un armazón de pruebas (test harness) puede facilitar la prueba de
componentes o de parte de un sistema mediante la simulación del entorno en
el que van a correr estos objetos de prueba. Esto puede llevarse a cabo ya
sea porque otros componentes de este entorno no se encuentran aún
disponibles o simplemente para proporcionar un entorno predecible y
controlable en el que pueda localizarse cualquier tipo de fallo en el objeto
bajo prueba.
• Puede crearse un marco (framework) en aquellos casos en los que puede
ejecutarse una parte del código, un objeto, método o función, unidad o
componente, llamando al objeto a probar y/o proporcionando realimentación.
Esto se puede hacer proporcionando medios artificiales de suministrar
entradas al objeto de prueba (drivers) y/o suministrando stubs que
proporcionen una salida del objeto, en lugar de disponer de salidas reales
• Las herramientas que proporcionan armazones de prueba pueden usarse
para proporcionar marcos de ejecución en los casos en los que se
comprueba middleware, donde se ha de probar de forma conjunta lenguajes,
sistemas operativos o hardware.
355
B) Herramientas que proporcionan marcos de pruebas unitarias
(frameworks) o armazones de prueba (D). (Cont.)
• Pueden ser denominadas herramientas de marco de pruebas unitarias
cuando se enfocan a este nivel de prueba. Este tipo de herramienta ayuda
a ejecutar pruebas de componente en paralelo a la construcción del código.
Dentro de esta familia de herramientas están las “xUnit”: JUnit, NUnit…
Este tipo de herramientas son muy similares a las de ejecución,
proporcionando utilidades para almacenar casos y monitorizar resultados.
Lo que no tienen es capacidad de grabar y reproducir casos.
• Algunas de las características que pueden proporcionar estas

herramientas:
• Suministro de entradas y recepción del salidas al/del objeto de prueba.
• Ejecutar y almacenar pruebas (marcos o armazones).
• Registrar resultados (marcos).
• Soporte a la depuración (marcos).
356
• Herramientas para la comparación entre valores esperados y valores

obtenidos.
• La base de la comparación pueden ser bases de datos o archivos en
diferentes formatos.
• Existen dos tipos de comparadores:
• Dinámicos (los más habituales), que hacen la comparación durante la ejecución
de la prueba. Este tipo de comparación es particularmente útil cuando el error (la
diferencia entre resultado esperado y obtenido) ocurre en medio de la prueba,
pudiéndose programar algún tipo de acción de recuperación o lanzando un
subconjunto de casos “ad hoc”.
• Post-ejecución haciendo uso de una herramienta de comparación separada. Los
sistemas operativos suelen tener herramientas que dan este tipo de soporte.
Este tipo de comparador es particularmente útil cuando hay que comparar
grandes volúmenes de datos, por ejemplo, el resultado de un batch.
• Aspecto crítico: conocer el resultado esperado. Pueden utilizar oráculos de
prueba, especialmente si están automatizados.
• Suelen incluirse filtros para seleccionar subconjuntos de resultados.
357
D) Herramientas de medida de cobertura (D)
• Miden el porcentaje de tipos específicos de estructura de código que han sido
ejercitadas (por ejemplo, sentencias, ramas o decisiones y llamadas a módulos
o funciones).
• Pueden ser intrusivas o no intrusivas (suelen ser intrusivas) dependiendo de
las técnicas de medición utilizadas, qué es lo que se mide y el lenguaje de
codificación.
• Las herramientas intrusivas, mediante una instrumentalización se instalan
contadores que registran cada acceso. Después de finalizar las pruebas las
herramientas pueden valorar a partir del estado de los contadores qué grado
de cobertura se obtiene para las pruebas.
• Puede ser aplicada a diversos niveles de prueba, pero sobre todo se usa en
pruebas de componente.
• Una cobertura de un 100% de un determinado tipo de estructura no implica
una cobertura de prueba del 100%.
358
• Hay diversos elementos que ayudan a proteger a un sistema o aplicación de
ataques externos. Un cortafuegos, por ejemplo, no es estrictamente una
herramienta de seguridad, pero puede utilizarse en las pruebas de seguridad.
• Las herramientas de prueba de seguridad buscan en el sistema
vulnerabilidades específicas. Pueden centrarse en la red, el software base, el
código de la aplicación o la base de datos.
• Pueden incluir:
• Identificación de virus.
• Detección de intrusiones.
• Simulación de ataques externos.
• Comprobación de puertos.
359
5.- Herramientas de soporte al rendimiento y monitorización.

• Son herramientas asociadas a la operación del sistema, ya sea en entornos
preproductivos o productivos.
• Se distinguen los siguientes tipos:
A) Herramientas de análisis dinámico.
C) Herramientas de monitorización.
360
A) Herramientas de Análisis dinámico (D).
• Requieren que el código se esté ejecutando.

• Llevan a cabo la supervisión y registro del estado interno del objeto:
• Utilización de memoria (memory leaks).
• Estado de los punteros (identificación de punteros nulos).
• Temporización (identificación de dependencias temporales).
• Hay herramientas que llevan a cabo el análisis de los enlaces (típico de
aplicaciones Web), para localizar enlaces no operativos.
• Otras herramientas realizan análisis de cobertura.
• Suelen utilizarse en las pruebas de componentes y de integración.
361

• También son conocidas como herramientas de pruebas de prestaciones.
• Las herramientas de pruebas de rendimiento monitorizan e informan acerca
de cómo se comporta un sistema bajo una determinada variedad de
condiciones de uso simuladas.
• Simulan carga en una aplicación, una base de datos o un entorno de
sistema, como pueden ser una red o un servidor.
• En función de la carga simulada se utiliza una nomenclatura distinta:
• Cuando simulan una carga nominal se habla de pruebas de carga.
• Cuando simulan una carga superior a la nominal, se habla de prueba de
sobrecarga o estrés
• Se suele basar en la grabación de uno o varios casos de prueba que
simulan las operativas principales. El técnico de prueba parametriza el
lanzamiento simultaneo y/o escalonado de n casos y evalúa los resultados.
• Otro tipo de prueba es la prueba de volumen que se centra en los
resultados obtenidos al lanzar una operativa contra un alto volumen de
datos (típico en sistemas batch).
362
C) Herramientas de monitorización.
• Las herramientas de monitorización no son estrictamente herramientas de
prueba, pero proporcionan información que puede utilizarse con propósitos
de prueba y que no se encuentran disponibles mediante otros medios.
• Las herramientas de monitorización analizan, verifican e informan de forma
continua y en tiempo real acerca del uso de recursos específicos del
sistema:
• Número de usuarios de una red
• Tráfico de red
• …
• Proporcionan alertas (pueden enviar mensajes a un administrador, por
ejemplo) acerca de posibles problemas en el servicio.
• Pueden guardar logs con los resultados obtenidos para su análisis posterior
(evolución histórica de datos).
• Por otra parte, pueden almacenar información acerca de la versión del
software de aplicación y del de pruebas, ayudando a mantener la
trazabilidad.
363
6.- Herramientas de soporte para necesidades de prueba específicas.
• Existen determinadas herramientas para ciertas necesidades específicas
de prueba, como por ejemplo, para el Análisis de la calidad de los datos:
• Los datos son la parte central de algunos proyectos concretos, como:
• Proyectos de conversión/migración de datos
• Algunas aplicaciones, como warehouses de datos
• Y sus atributos pueden cambiar en términos de criticidad y volumen.
• En este contexto, se necesita emplear herramientas para el análisis de la calidad
de los datos, para verificar y revisar la conversión de los datos y las reglas de
migración, de cara asegurar que los datos preparados son correctos, completos
y cumplen con un estándar predefinido para ese contexto específico.
• Existen también herramientas para las pruebas de usabilidad.
364
7.- Otras herramientas.
• Las herramientas de prueba que se han enumerado aquí no son las únicas
utilizadas por los probadores – también pueden usar hojas de cálculo, SQL
o herramientas de depuración (D), por ejemplo.
365
02.1 – Uso efectivo de herramientas
Beneficios y riesgos de usar una herramienta de soporte
• La simple compra o alquiler de una herramienta no garantiza el éxito (no
hay balas de plata ni soluciones mágicas). Cada tipo de herramienta puede
necesitar esfuerzos adicionales para lograr beneficios reales y duraderos.
En el uso de herramientas de prueba, al igual que en cualquier otra
herramienta, hay beneficios potenciales y oportunidades, pero también hay
riesgos.
• Entre los potenciales beneficios del uso de herramientas se incluyen:
• Reducción del trabajo repetitivo (por ejemplo, correr pruebas de regresión,
volver a introducir los mismos datos de prueba y verificación del cumplimiento de
estándares de codificación). Las actividades repetitivas suelen generar errores
cuando se hacen a mano.
• Mayor consistencia (puedes estar seguro que una máquina va a ejecutar
exactamente la misma prueba, en el caso de una persona no siempre está tan
claro).
• Posibilidad de repetición (por ejemplo, pruebas ejecutadas por una herramienta
y pruebas obtenidas a partir de requisitos).
• Evaluación objetiva (por ejemplo, medidas estáticas, cobertura) no hay
posibilidad de que quede información sin registrar por olvido.
• Facilidad de acceso a la información de las pruebas y a los casos de prueba (por
ejemplo, estadísticas y gráficos acerca del progreso de las pruebas, de ratios de
incidencias y de prestaciones).
366
02.1 – Uso efectivo herramientas
Beneficios y riesgos de usar una herramienta de soporte.
• Entre los riesgos asociados al uso de herramientas se incluyen:
• Expectativas no realistas acerca de la herramienta (incluyendo funcionalidad
y facilidad de uso). Una herramienta no resuelve:
• Un problema organizativo. Lo más que puede hacer es ayudar a su resolución,
reduciendo esfuerzos.
• Una mala capacitación de un probador. Se puede gestionar perfectamente casos de
prueba incorrectos o incompletos
• Subestimación del tiempo, coste y esfuerzo necesario para la introducción
inicial de una herramienta (incluyendo formación y soporte experto externo). No
sólo es que no se le saque todo el partido al principio, es que, inicialmente,
puede requerir más tiempo hacer el trabajo que cuando se hacía manualmente
• Subestimación del tiempo y esfuerzo necesario para lograr de la
herramienta beneficios significativos y continuados (incluyendo la
necesidad de cambios en el proceso de prueba y mejora continua en la forma de
utilizar la herramienta). Los beneficios se obtienen a largo plazo
• Subestimación del esfuerzo necesario para mantener los elementos de
prueba generados por la herramienta. Disponer para cada incidencia de
información del módulo que ha generado un error resultar muy útil para realizar
análisis históricos o de tendencias de la calidad del módulo, pero hay que
identificarlo y documentarlo
• Demasiada dependencia de la herramienta. A veces parece haber una fiebre
por amortizar la herramienta usándola para tareas para las que resultan más
adecuadas las pruebas manuales.
367
Beneficios y riesgos de usar una herramienta de soporte (cont.).
• Entre los riesgos asociados al uso de herramientas se incluyen (cont.):
• Descuidar el control de versiones de los elementos de prueba dentro de la
herramienta.
• Descuidar aspectos relativos a la relación e interoperabilidad entre
herramientas críticas, como herramientas de gestión de requisitos, de control
de versiones, de gestión de incidencias o seguimiento de defectos y
herramientas procedentes de múltiples proveedores.
• Proveedores de herramientas que abandonan el negocio, retiran la
herramienta o la venden a otro proveedor diferente.
• Respuesta pobre por parte del proveedor para el soporte, las actualizaciones
y el arreglo de defectos.
• Suspensión de un proyecto de herramienta open-source/libre.
• Ciertos imprevistos, como la incapacidad de soportar una plataforma nueva.
368
Consideraciones especiales para ciertos tipos de herramientas.
• Herramientas de ejecución de las pruebas
• Las herramientas de ejecución de las pruebas reproducen scripts diseñados para
implementar pruebas que han sido almacenados de forma electrónica. Este tipo de
herramienta suele requerir esfuerzos significativos para lograr beneficios
significativos.
• Los scripts pueden ser capturados grabando acciones manuales. Pero este
enfoque no permitiría cubrir un número elevado de scripts de pruebas automáticas,
porque los scripts capturados son una representación lineal con datos y acciones
específicas en cada script. Y podrían ser inestables si ocurriese algún evento
inesperado.
• Un enfoque de pruebas “data-driven” separa los datos, normalmente en hojas de
cálculo, y usa un script de pruebas más genérico que puede leer los datos de
entrada y ejecutar el mismo script con diferentes datos. Los probadores que no
conocen el lenguaje de script pueden entonces crear los datos de prueba para esos
scripts predefinidos. También se podrían utilizar algoritmos para la generación de
los datos de entrada al script.
• Se necesita, en todos los casos, disponer de experiencia técnica en el lenguaje de
script (ya sea por parte de los probadores o por especialistas en automatización de
pruebas).
• Sea cual sea la técnica de scripting utilizada, deben almacenarse los resultados
esperados de cada prueba para su posterior comparación
369
• Herramientas de análisis estático

• Las herramientas de análisis estático aplicadas al código fuente pueden ayudar
a hacer que la codificación se ajuste a estándares, pero cuando se aplica a
código “histórico” ya existente puede generar un montón de mensajes. Hay que
plantearse en estos casos hasta qué punto merece la pena tocar un código que
funciona bien desde hace mucho tiempo dado que, si bien el objetivo es facilitar
el mantenimiento, un código estable puede tener muy poco mantenimiento
• Un error puede repetirse cientos de veces en un programa. Puede que errores

importantes resulten desapercibidos.
• Una implementación gradual, empezando con filtros iniciales que excluyan

algunos mensajes sería un enfoque efectivo.
370
• Herramientas de gestión de las pruebas
• Las herramientas de gestión de las pruebas tienen que disponer de una interfaz
con otras herramientas u hojas de cálculo, con el objeto de producir información
en el mejor formato posible para las necesidades de la organización.
• Los informes tienen que diseñarse y mantenerse de forma que proporcionen

beneficio. No basta con hacer un informe y sacarlo sistemáticamente sin pensar
de cuando en cuando si la información obtenida o la forma de representarla
sigue siendo útil
• Como en el resto de los casos, hay que tener un proceso de pruebas bien
definido antes de introducir la herramienta
371
03 – Introducción de una herramienta en una organización
Generalidades.
• ¿Que tipo apoyo mediante herramientas es deseable/ necesitado?
• ¡Para esto debe analizarse los más detalladamente posible la situación
del proyecto!
• Consideraciones previas:
• Una herramienta no puede remplazar un proceso de pruebas inexistente
o compensar una forma de procedimiento descuidada.
• En principio las herramientas son tan poderosas como aquel que las
implementa (“A fool with a tool is still a fool”)
372
Elección de una herramienta.

• Cuando queda determinado qué área de las pruebas se debe contar con el
apoyo de una herramienta hay que considerar lo siguiente:
• La adquisición e introducción de una herramienta lleva unos costes
asociados – estos son a menudo muy altos.
• La implantación debe rentabilizarse a largo plazo.
373
Elección de una herramienta.
• Entre los principales aspectos a considerar a la hora de seleccionar una
herramienta para una organización se incluyen:
• Evaluación de la madurez, fortalezas y debilidades de la organización
• Identificación de las oportunidades que para la mejora de un proceso de prueba
proporcionaría el soporte de herramientas
• Definición de requisitos claros y criterios objetivos. Establecimiento de pesos. Entre
los criterios se pueden considerar:
• Adaptación a la operativa y a las necesidades específicas
• Flexibilidad
• Soporte local (incluyendo formación, soporte y aspectos comerciales)
• Hacer un estudio de mercado (selección previa)
• Evaluación de las necesidades de formación teniendo en cuenta los conocimientos
de automatización de pruebas del equipo de pruebas actual.
• Prueba(s) piloto y/o demostraciones por parte del vendedor para comprobar la
funcionalidad requerida y determinar si el producto satisface sus objetivos
• Estimación del ratio coste-beneficio basándose en una propuesta de negocio sólida.
• Evaluación, tomando en consideración los criterios y pesos
• Informe de resultados
• Revisión de resultados
• Selección de la herramienta
374
Introducción (implantación).
• Se debería establecer e instalar previamente un proceso de pruebas funcional.
• Esto es, entender qué se está haciendo y por qué se hace/se debe hacer.
• La rentabilidad de la implantación de herramientas debería ser comprobada.

• ¿En qué áreas del proceso de pruebas merece la pena la implantación de
herramientas?
• Considerar los retrasos y problemas de la implantación.

• Un programa nuevo debe ser previamente estudiado – en la fase de aprendizaje
disminuye por norma general la productividad – una formación insuficiente puede
causar una disminución de la calidad.
• Esto significa que tras la implantación se pueden producir de todas maneras
retrasos o errores en las pruebas.
375
• La introducción de una nueva herramienta debe llevarse a cabo en seis pasos:
• Proyecto piloto
• Revisión de las experiencias /resultados
• Adaptación de los procesos / de las herramientas
• Formación a los usuarios
• Introducción para la implantación general
• Formación o entrenamiento que acompañe a la implantación
376
• La introducción mencionada anteriormente parece en principio muy laboriosa,
sin embargo es necesaria.
• El proyecto piloto proporciona informaciones importantes para la implantación
posterior.
• Mediante revisiones se pueden aclarar las medidas, o eventualmente las
adaptaciones, necesarias.
• ¡La formación temprana es generalmente indispensable!
• La introducción se hará solo cuando se pueda asegurar una implantación
correcta.
377
Introducción (implantación). Factores de éxito
• Entre los factores de éxito asociados al despliegue de la herramienta en una
organización se incluyen:
• Desplegar de forma incremental la herramienta.
• Adaptar y mejorar procesos adaptados al uso de la herramienta (quede claro, el
proceso marca la selección de la herramienta, una vez seleccionada, se adaptan
para aprovechar las capacidades al máximo y mejorar la eficiencia).
• Proporcionar formación y soporte de consultas a los nuevos usuarios.
• Definir líneas guía para su uso. Elaborar manuales de usuario adaptados a la
organización.
• Implementar una forma de aprender lecciones del uso de la herramienta. Establecer
un mecanismo de mejora continua.
• Monitorizar el uso y los beneficios que proporciona la herramienta. Calcular el ROI.
• Proporcionar soporte al equipo de pruebas para una herramienta dada
• Recopilar lecciones aprendidas de todos los equipos.
378
Costes de la introducción (implantación).
• La introducción de una herramienta puede estar unida a costes relevantes.
• Adquisición,
• Mantenimiento,
• Eventualmente hardware adicional requerido y
• Formación a los colaboradores.
• Estos costes están en oposición a las ventajas esperadas con la

implantación de la herramienta.
• En este punto debe estimarse en base a criterios técnicos cuando es
rentable la implantación y cuando no.
379
Amortización de los costes de adquisición.
• La gran pregunta desde el punto de vista económico es cuándo se
amortiza una herramienta – esta pregunta no tiene lamentablemente fácil
respuesta.
• Los costes de la primera implantación (de una herramienta de
automatización) se ven normalmente aumentados todavía más por la
“nueva programación de los casos de prueba”.
• Se producen costes adicionales por la formación de los colaboradores.
• Sólo con la automatización de más casos de prueba se suma el ahorro
obtenido por caso de prueba.
• La mejora de la calidad de las pruebas individuales no se puede expresar
normalmente en términos monetarios.
• Pero la amortización sólo engloba los resultados económicos y no los
efectos sobre la calidad.
¡Solo una implantación duradera, a largo plazo y sostenida de
una herramienta de pruebas posibilita una amortización de los
costes de adquisición!
380
Amortización de los costes de adquisición.
• Sólo mediante una implantación eficiente se consigue una ventaja en costes
respecto de la actividad manual.
• Las herramientas para, p.ej., la ejecución automatizada de casos de prueba
necesitan un cierto esfuerzo para la primera preparación de los casos de
prueba.
• Aquí se producen mejoras en los costes cuando se repite la ejecución de las
pruebas – éstos mejoran cada vez más con el número de repeticiones.
• Otras herramientas deberían implantarse para “cubrir áreas” y conseguir el
mayor ahorro posible.
• En determinados casos, en función del volumen o de la complejidad de una
prueba, ésta sólo puede realizarse con el apoyo de herramientas.
• Si una herramienta se necesita obligatoriamente para las pruebas entonces los
aspectos económicos no juegan ya un papel determinante.
381
VII –Herramientas de pruebas
04 – Resumen
• Hoy en día se dispone de herramientas para cada fase del proceso de
pruebas para:
• Elaborar la automatización de las pruebas.
• Mejorar cualitativamente los trabajos de pruebas.
• Acortar los tiempos de ejecución de las pruebas.
• Solo un proceso de pruebas organizado y establecido es adecuado para la
implantación de herramientas.
• Es indispensable una elección de herramientas antes de la introducción para
poder calcular unos costes y riesgos considerables.
• Un acompañamiento constante durante la introducción de la herramienta
escogida, con entrenamiento y formación de los usuarios, es necesario para
una implantación regular y de este modo para el beneficio económico de un
proceso de pruebas automatizado.
382
383
Les agradecemos el interés mostrado
les deseamos una evaluación final exitosa

para el
“Probador Certificado – Nivel Básico”
Departamento de Formación

MTP ISTQB 28032018 - v2.0 MTP PDF

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

MTP ISTQB 28032018 - v2.0 MTP PDF

Transféré par

Droits d'auteur :

Formats disponibles

Principios de las Pruebas de Software

Formación para el “Certified Tester – Foundation Level”, Versión 2.0

Seminario “Principios de las pruebas de Software”

Los objetivos de la formación para el Probador Certificado son,

El seminario está dividido en siete capítulos de acuerdo con el plan

• Preparación teórica del material de estudio y una serie de ejemplos

• El material de apoyo se compone de:

El manual se basa en los contenidos del Certified Tester Foundation

• Tras la finalización del seminario se podrá llevar a cabo la evaluación

En cada sección del Syllabus se indican los objetivos de aprendizaje

• K1: recordar, reconocer, memorizar.

NOTA: cada tema se examinará según sus objetivos de aprendizaje (K).

Queremos dirigirnos a probadores de software en empresas

¡El aprendizaje durante toda la vida

Programa de cualificación del ISTQB

• En 1998 se definió en Gran Bretaña un programa de cualificación

Programa de cualificación del iSTQB

• Como instancia independiente, el comité verifica los cursos ofrecidos

Fallos, defectos, errores…

El software es elaborado por seres humanos

Prueba y Caso de Prueba

• Enmascaramiento del error:

Prueba y Caso de Prueba

• Explosión de casos de prueba:

• Según ISO / IEC 9126:

• Según IEEE Std 610:

Medidas constructivas para el aseguramiento de la calidad (QA)

Medidas analíticas para el aseguramiento de la calidad (QA)

Análisis de flujos Técnicas basadas

El software como factor económico

Calidad del Software

Que la calidad del software sea un factor

Ejemplo: Fallo en la unidad de coma flotante del Pentium

• Estas comprobaciones crearon una gran polémica. Intel negó inicialmente la

• La Phobos 1 despegó y tuvo un funcionamiento correcto hasta que dos meses

Otros errores software famosos

• Apolo 11 (fallo de aterrizaje).

• Mariner 1 (faltaba una coma).

• Ariadne 5 (basado en una versión anterior de sw, el equipo físico no pudo

• Therac-25 (Dosis masivas de radiación. Generó, al menos, 5 muertes).

Causas de los defectos

• El software es elaborado por seres humanos que pueden cometer errores

• Al margen de por la existencia de un defecto pueden producirse fallos por

Las Pruebas como medio de mejora de la calidad

• Un medio para conseguir la mejora de la calidad tanto de los sistemas de

• Puede exigirse por contrato un nivel mínimo de prueba.

• Las pruebas pueden requerirse también para satisfacer requisitos

• Una Funcionalidad de buena calidad implica

Calidad de software. Atributos no funcionales

Calidad de software. Atributos no funcionales

Calidad de Software. Atributos de la calidad

• Algunas características de la calidad de software influyen entre si. Puede

• A lo largo del seminario quedará claro que para las diferentes

¿Cuánto esfuerzo en pruebas es suficiente?

• Como todos los demás productos, tampoco el software está “siempre”

• Las pruebas no pueden garantizar nunca la ausencia de fallos en un

• En la práctica unas pruebas exhaustivas son rara vez posibles, sin

• Según el ámbito de aplicación y el tipo de error pueden ocasionarse

• La resolución de errores durante el desarrollo.

¿Cuánto esfuerzo en pruebas es suficiente?

• Fin del tiempo o de los recursos

¿Cuánto esfuerzo en pruebas es suficiente?