Curso ISTQB Español

2 de 418
0 Introduccin
01 Presentacin
Organizacin del curso
Agenda del curso.
Por favor mantenga su celular apagado.
Foundation Level Syllabus (2010) Traduccin por Norman Burbano. nebroc@gmail.com
3 de 418
0 - Introduccin
02 - Tabla de contenidos
El presente curso se ha desarrollado de acuerdo con el programa de estudios del ao 2010 de
Probador, Certificado Nivel Bsico, que consta de siete captulos:
Captulo 0
Captulo I
Captulo II
Captulo III
Captulo IV
Captulo V
Captulo VI
Introduccin.
Fundamentos de Pruebas.
Pruebas a travs del Ciclo de Vida Software.
Tcnicas Estticas.
Tcnicas de Diseo de Pruebas.
Gestin de Pruebas.
Herramientas de Pruebas.
4 de 418
0 - Introduccin
03 - Organizaciones internacionales
Programa de capacitacin del ISTQB*
En 1998. Se desarrolla en Gran Bretaa, un programa de capacitacin de mltiples
niveles.
Los fundamentos del proceso de pruebas software son formulados en el programa de
estudios para el nivel bsico (Syllabus for Foundation Level - edicin actual: marzo de
2010).
Desde 2004 tambin se cuenta con certificaciones para el Nivel Avanzado (Advanced
Level): Jefe de Pruebas (Test Manager). Probador Tcnico (Technical Tester). Probador
Funcional (Functional Tester)
El Nivel Experto se encuentra listo para descarga.
Los Comits de Pruebas (Testing Boards) locales de cada pas conforman la estructura de
la organizacin del "International Software Testing Qualification Board" (www.istqb.org)
Por ejemplo en Hispanoamrica: HISPANIC America Software Testing Qualification Board
(HASTQB)
*ISTQB = International Software Testing Qualification Board (Comit Internacional de
Clasificacin de pruebas de software)
5 de 418
0 - Introduccin
04 - Programa de estudios y evaluacin
El conjunto de diapositivas est basado en el
Programa de Estudios de
Probador Certificado - Nivel Bsico del ISTQB
Versin 2010 (marzo).
A continuacin del curso de formacin tendr lugar un examen al que se puede asistir
para obtener el certificado de Probador Certificado. Nivel Bsico (Certified Tester
Foundation Level).
La evaluacin es realizada por un examinador perteneciente a una organizacin
independiente (por ejemplo ISQI*).
Los temas de la evaluacin estn extrados de las secciones correspondientes a las dadas
en el curso de formacin. El examen es del tipo seleccin mltiple, con una duracin de
60 minutos.
Cada pregunta tiene una (de cuatro) nica respuesta correcta. Tienen que ser
respondidas un total de 40 preguntas, de las cuales 26 (65%) tienen que ser respondidas
de forma correcta con el objeto de aprobar el examen
* ISQI International Software Quality Institute
6 de 418
0 - Introduccin
05 - Objetivos
Objetivos principales para la formacin de Probador
Certificado
Aprender las tcnicas bsicas para planificar las pruebas.
Aplicar las tcnicas de pruebas software en proyectos.
Seleccionar las tcnicas y objetivos de pruebas apropiados.
Aprender una terminologa comn.
Audiencia
El curso est dirigido a probadores de software, desarrolladores y jefes de proyecto en un
entorno de produccin software as como en un entorno de produccin industrial que
deseen dar a su conocimiento un fundamento de mayor solidez.
Documentos
Conjunto de diapositivas propios de la presentacin.
Ejercicios y sus soluciones.
Referencias y glosario.
7 de 418
I - Fundamentos de Pruebas Software

Agenda
Captulo I - Fundamentos de Pruebas Software
I/01
I/02
I/03
I/04
I/05
I/06
Por qu es necesario Probar?

Qu son pruebas?
Los siete Principios generales del proceso de pruebas de software.
Proceso de pruebas bsico.
Psicologa en el proceso de pruebas.
Cdigo de tica.
8 de 418

01 - Por qu es necesario Probar?
La importancia econmica del software
El funcionamiento de maquinaria y equipamiento depende en gran medida del software.
No es posible imaginar grandes sistemas, en el mbito de las finanzas ni el control de
grfico, funcionando sin software.
Calidad software
Cada vez ms, la calidad software se ha convertido, en un factor determinante del xito
tcnico o comercial de sistemas y producidos.
Pruebas para la mejora de la calidad
Las pruebas y revisiones aseguran la mejora de la calidad de productos software as como
de la calidad del proceso de desarrollo en s.
9 de 418

Causas de los fallos (failures) de software
Error humano
Un defecto es introducido en el cdigo software, en los datos o en los parmetros de
configuracin.
Causas del error humano:
Plazos, demandas excesivas debidas a lo complejidad, distracciones.
Condiciones ambientales
Cambios en las condiciones ambientales.
Causas de condiciones ambientales negativas/adversas.
Radiacin, magnetismo, campos electromagnticos y polucin, manchas solares, fallo de
discos duros, fluctuaciones en el suministro de energa elctrica.
10 de 418

Error, defecto (defect), fallo (failure)
Error (IEEE 610):
Accin humana que produce un resultado incorrecto por ej. Un error de programacin.
Defecto (Defect):
Desperfecto en un componente o sistema que puede ser una causa por la cual el sistema
o componente no logre llevar o cabo su funcin especfica, por ej. Sentencia o definicin
de datos incorrectas.
Fallo (Failure):
Manifestacin fsica o funcional de un defecto. Si un defecto es encontrado durante la
ejecucin de una aplicacin puede producir un fallo.
Desviacin de un componente o sistema respecto de la prestacin, el servicio o resultado
esperados.
UN ERROR INTRODUCE UN DEFECTO, UN DEFECTO CAUSA UN FALLO.
11 de 418

Proceso de pruebas durante el proceso de desarrollo, mantenimiento y operaciones
Mejora de la calidad de un producto software:
El proceso de pruebas ayuda a proveer al software de los atributos deseados. Puede
retirar defectos que conducen a fallos.
Reduccin del riesgo de detectar errores:
Actividades de pruebas software adecuadas reducirn el riesgo de encontrar errores
durante la fase de operaciones software.
Satisfacer compromisos:
La ejecucin de pruebas puede ser un requisito obligatorio por parte del cliente o debido
a normas legales as como el cumplimiento de estndares propios de la Industria
especfica.
12 de 418

El costo de los defectos

El costo de eliminar
defectos se incrementa
con el tiempo durante el
cual el defecto permanece
en el sistema
La seleccin de errores en
etapas tempranas permite
la correccin de los
mismos
a
costos
reducidos.
13 de 418

Calidad software
Definicin: Software (segn IEEE 610):
Programas de computadora, procedimientos, y posiblemente documentacin asociada as
como los datos relacionados con la operacin de un sistema Informtico.
Definicin: Calidad software (segn ISO/IEC 9126):
La totalidad de la funcionalidad y caractersticas de un producto software que
contribuyen a su habilidad de satisfacer necesidades especificadas o implcitas
Definicin: Calidad (segn IEEE Std 610):
Grado en el cual un componente, sistema o proceso satisface los requisitos especificados
y/o necesidades del usuario/cliente y sus expectativas.
14 de 418

Calidad software
De acuerdo a la norma ISO/IEC 9126 la calidad software est constituida por:
o Funcionalidad
Atributos funcionales de calidad
o Fiabilidad
o Usabilidad
o Eficiencia
Atributos no-funcionales de calidad
o Mantenibilidad
o Portabilidad
Tipos de Aseguramiento d la Calidad (QA):
o Actividades constructivas con el objeto de prevenir defectos, por ejemplo a travs
de la aplicacin de mtodos apropiados de ingeniera de software.
o Actividades analticas con el objeto de prevenir defectos. por ejemplo a travs de
pruebas que conducen a la correccin de defectos y prevencin de fallos,
incrementando as la calidad del software.
15 de 418

Aseguramiento de la calidad constructivo
Proceso de calidad - Gestin de la calidad.
Consigna
Los defectos evitados no requieren ser
reparados.
Los errores cometidos en el pasado no
deben ser repetidos.
Prevenir defectos
16 de 418

Aseguramiento de la calidad analtico
Calidad de producto - Procedimientos de Verificacin y Pruebas
Consigna
Los defectos deben ser detectados tan
temprano en el proceso como sea
posible.
Pruebas estticas examen
ejecucin del programa.
sin
la
Pruebas dinmicas incluye la ejecucin

del programa.
17 de 418

Calidad software - Atributos funcionales de calidad
Funcionalidad significa:
Correcto: La funcionalidad satisface los atributos / capacidades requeridos.
Completitud: La funcionalidad satisface todos los requisitos (funcionales).
Funcionalidad incluye (segn ISO/IEC 9126):
Adecuacin.
Precisin.
Conformidad (Estndares).
Interoperabilidad (Componentes).
Seguridad.
18 de 418

Calidad software - Atributos no funcionales de calidad / 1
Fiabilidad
Madurez, tolerancia a defectos, recuperacin tras fallos.
Caractersticas: En determinadas condiciones, el software / sistema mantendr su
capacidad / funcionalidad a lo largo de un perodo de tiempo.
Fiabilidad = Calidad / tiempo.
Usabilidad
Facilidad de ser utilizado, facilidad de ser aprendido, facilidad de ser comprendido,
atractivo.
Caractersticas: fcil de usar, fcil de aprender, conforme o normas, uso intuitivo.
19 de 418

Calidad software - Atributos no funcionales de calidad /2
Eficiencia
Comportamiento del sistema: funcionalidad y respuesta temporal.
Caractersticas: El sistema requiere la utilizacin de un mnimo de recursos (por ejemplo
tiempo de CPU) para ejecutar una tarea determinada.
Mantenibilidad
Verificable, estable, cualidad de ser analizado, modificable.
Caractersticas: Medida del esfuerzo requerido para realizar cambios en un sistema /
componentes.
Portabilidad
Capacidad de ser reemplazado, Instalable.
Capacidad del software de ser transferido a un nuevo entorno (software, hardware,
organizacin).
Caractersticas: Fcil de instalar y desinstalar, parmetros.
20 de 418

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

Objetivos de las pruebas
Adquirir conocimiento sobre los defectos en un objeto de prueba
Los defectos propios de un objeto de prueba deben ser detectados y descritos de tal
forma que se facilite su correccin.
Comprobar la funcionalidad
La funcionalidad del sistema debe ser implementada tal y como ha sido especificada.
Generar informacin
Se debe proporcionar Informacin relativa a evitar riesgos relativos a un sistema software
antes de su entrega a los usuarios. La adquisicin de esta Informacin puede ser uno de
los objetivos de las pruebas.
Generar confianza
Un sistema software que ha sido probado de forma adecuada se considera que cumple
con la funcionalidad esperada y cuenta con un alto nivel de calidad.
22 de 418

Cuntas pruebas son suficientes?
Criterio para la finalizacin de pruebas
No encontrar (ms) defectos es un criterio apropiado para finalizar las actividades de pruebas.
Sin embargo son necesarias otras mtricas para reflejar de forma adecuada el nivel de calidad
alcanzado.
Pruebas basadas en el riesgo
o El nivel de riesgo determina el grado en el cual se ha probado, es decir:
responsabilidad en caso de fallos, probabilidad de la ocurrencia de fallos, aspectos
relativos o factores econmicos y propios del proyecto.
Pruebas basadas en plazos y presupuesto
o La disponibilidad de recursos (personal, tiempo, presupuesto) puede determinar la
medida del esfuerzo a dedicar al proceso de pruebas.
23 de 418

Caso de prueba (test case), base de una prueba (test basis)
Caso de prueba (test case):
La definicin de un caso de prueba incluye la siguiente informacin (segn IEEE Std 610):
o
o
o
o
o
Precondiciones.
Conjunto de valores de entrada.
Conjunto de resultados esperados.
Forma en la cual se debe ejecutar el caso de prueba y verificar los resultados.
Pos condiciones esperadas.
Base de la prueba (test basis o test base):

Conjunto de documentos que definen los requisitos de un componente o sistema.
Utilizado como fundamento para el desarrollo de casos de prueba.
24 de 418

Desarrollo de software y revisiones:
Cdigo (code), cdigo fuente (source code):
Programa de computadora escrito en un lenguaje de programacin que puede ser ledo
por una persona.
Depuracin (debugging):
Localizacin y correccin de defectos en el cdigo fuente
Desarrollo software (software development):
Es un proceso / secuencia de actividades cuyo objetivo es desarrollar un sistema basado
en un computador (ordenador). Normalmente sigue un modelo de desarrollo software.
Requisito (requirement):
Un requisito describe un atributo funcional deseado o considerado obligatorio.
Revisin (review):
Evaluacin de un producto o estado de un proyecto con el objeto de detectar
discrepancias con respecto o los resultados esperados (planificados) y para recomendar
mejoras (segn IEEE Std 1028).
25 de 418

Resumen:
Los fallos de software pueden causar importantes perjuicios.
La calidad software es la suma de los atributos que se refieren a la capacidad del software
de satisfacer un conjunto de requisitos dados.
El aseguramiento de la calidad constructivo se ocupa de la prevencin de defectos.
El aseguramiento de la calidad analtico se ocupa de detectar y corregir defectos.
Los atributos de la calidad funcionales y no funcionales definen la calidad total del
sistema.
Cada prueba debe contar con un criterio para la finalizacin de pruebas. Al alcanzar el
criterio de finalizacin de pruebas finalizan las actividades del proceso de pruebas.
Los probadores (testers) buscan fallos en el sistema e informan sobre los mismos
(proceso de pruebas). Los desarrolladores buscan defectos y los corrigen (depuracin).
26 de 418

Agenda
I/01
I/02
I/03
I/04
I/05
I/06

Qu son pruebas?
Cdigo de tica
27 de 418

02 - Qu son pruebas?
Otros medios de prueba ms de la ejecucin de pruebas
Ejecucin de las pruebas es slo una parte de las pruebas
El proceso de prueba incluye:
o Planificacin y control
o Eleccin de las condiciones de prueba
o Diseo y ejecucin de casos de prueba
o Control de resultados
o Evaluacin de los criterios de salida
o Presentacin de informes sobre el proceso de prueba y el sistema bajo prueba
o Finalizar o completar las actividades de cierre
Revisin de documentos, cdigos fuente y la realizacin de anlisis esttico tambin
ayudan a prevenir los defectos que aparecen en el cdigo.
28 de 418

Objetivos de pruebas
Bsqueda de defectos
Puede ser:
o En las pruebas de desarrollo: para encontrar el mayor nmero posible de errores
o En las pruebas de aceptacin: para confirmar que el sistema funciona como se
esperaba
Ganar confianza en el nivel de calidad
Proporcionar informacin para la toma de decisiones
Para evaluar la calidad del software, para dar informacin a los interesados de los riesgos
de liberar el sistema en un momento dado
Prevencin de defectos
Las pruebas de mantenimiento permiten determinar si se han introducido nuevos
defectos durante el desarrollo de cambios
29 de 418

Trmino: Desarrollo de software
Depuracin
El proceso de encontrar, analizar y eliminar las causas de fallas en el software.
Requisito (requerimiento)
Una condicin o capacidad que necesita un usuario para resolver un problema, alcanzar un
objetivo que se debe cumplir o que tenga un componente o el sistema, para satisfacer un
contrato, norma, especificacin u otro documento formalmente impuesto [despus de IEEE
610].
Revisin
La evaluacin de un estado del producto o proyecto para determinar las discrepancias de los
resultados previstos y recomendar mejoras. Las revisiones incluyen [segn la IEEE 1028]:
revisin de la gestin, revisin informal, revisin tcnica, inspeccin y walkthrough (tutorial).
30 de 418

Pruebas y depuracin (debugging)
Probar y volver a probar (re-test) son actividades propias del proceso de pruebas.
Las pruebas muestran los fallos.
Volver a probar (re-test) verifica que el defecto ha sido corregido.
La depuracin y la correccin de defectos son actividades propias del desarrollo.
A travs de la depuracin los desarrolladores pueden reproducir los fallos, analizar el
estado del programa y detectar el defecto correspondiente con el objeto de corregirlo.
31 de 418

Resumen
El proceso de pruebas fundamentales comprende:
o Pruebas de planificacin y control.
o Pruebas de anlisis y diseo.
o Pruebas de implementacin y ejecucin.
o Evaluacin de criterios de salida y presentacin de informes.
o Actividades de cierre de pruebas.
Los objetivos de pruebas pueden ser: Encontrar defectos, el nivel de calidad, informacin
para la toma de decisiones, la prevencin de defectos.
El diseo de pruebas debe iniciarse en fases tempranas del ciclo de vida del software.
Pruebas dinmicas significa la ejecucin del software, las pruebas estticas consiste en la
revisin de documentos.
Las pruebas dinmicas muestran fallas que son causadas por defectos, la depuracin
encuentra, analiza y elimina la causa de la falla.
32 de 418

Agenda
I/01
I/02
I/03
I/04
I/05
I/06

Qu son pruebas?
Los siete principios generales del proceso de pruebas de software.
Cdigo de tica
33 de 418

03 - Los siete principios generales del proceso de pruebas de software.
Principio 1: El proceso de pruebas demuestra la presencia de defectos.
El proceso de pruebas puede probar la presencia de defectos.
Las desviaciones identificadas a lo largo del proceso de pruebas demuestran la presencia
de un fallo.
La causa de un fallo puede no ser obvia.
El proceso de pruebas no puede demostrar la ausencia de defectos.
Las pruebas reducen la probabilidad de la presencia de defectos que permanecen sin ser
detectados. La ausencia de fallos no demuestra la correccin de un producto software.
El mismo proceso de pruebas puede contener errores.
Las condiciones de las pruebas pueden ser inapropiadas para detectar errores.
34 de 418

Principio 2: No es posible realizar pruebas exhaustivas
Pruebas exhaustivas (exhaustive testing).
o Enfoque del proceso de pruebas en el cual el juego de pruebas (suite de pruebas)
abarca todas las combinaciones de valores de entrada y precondiciones.
Explosin de casos de prueba (test case explosion).
o Define el incremento exponencial de esfuerzo y costo en el caso de pruebas
exhaustivas.
Prueba de muestra (sample test).
o La prueba incluyo solamente a un subconjunto (generado de forma sistemtica o
aleatoria) de todos los posibles valores de entrada.
o En condiciones normales, se utilizan generalmente pruebas de muestra. Probar
todas las combinaciones posibles de entradas y precondiciones slo es
econmicamente viable en casos triviales.
35 de 418

Principio 3: Pruebas tempranas (early testing)
La correccin de un defecto es menos costosa en la medida en la cual su deteccin se
realiza en fases ms tempranas del proceso software.
Se obtiene una mxima rentabilidad cuando los errores son corregidos antes de la
implementacin.
Los conceptos y especificaciones pueden ser probados.
Los defectos detectados en la fase de concepcin son corregidos con menor esfuerzo y
costos.
La preparacin de una prueba tambin consume tiempo.
El proceso de pruebas implica ms que slo la ejecucin de pruebas.
Las actividades de pruebas pueden ser preparadas antes de que el desarrollo se haya
completado.
Las actividades de pruebas (incluidos las revisiones) deben ser ejecutadas en paralelo a la
especificacin y diseo software.
36 de 418

Principio 4: Agrupamiento de defectos (defect clustering)
Al encontrar un defecto se encontrarn ms defectos "cerca"
Los defectos aparecen agrupados como hongos o cucarachas.
Cuando se detecta un defecto es conveniente investigar el mismo mdulo en el que ha
sido detectado.
Los probadores (testers) deben ser flexibles
Habiendo sido detectado un defecto es conveniente volver a considerar el rumbo de las
pruebas siguientes.
La identificacin de un defecto puede ser investigada con un mayor grado de detalle, por
ejemplo, realizando pruebas adicionales o modificando pruebas existentes.
37 de 418

03 - Los siete Principios generales del proceso de pruebas de software.
Principio 5: Paradoja del pesticida
Repetir pruebas en las mismas condiciones no es efectivo.
o Cada caso de prueba debe contar con una combinacin nica de parmetros de
entrada para un objeto de pruebas particular, de lo contrario no se podr obtener
informacin adicional.
o Si se ejecutan las mismas pruebas de forma reiterada no se podrn encontrar
nuevos defectos.
Las pruebas deben ser revisadas/modificadas regularmente para los distintos mdulos
(cdigo).
o Es necesario repetir una prueba tras una modificacin del cdigo (correccin de
defectos, nueva funcionalidad)
o La automatizacin de pruebas puede resultar conveniente si un conjunto de casos
de prueba se debe ejecutar frecuentemente.
38 de 418

Principie 6: Las pruebas dependen del contexto
Las pruebas se desarrollan de forma diferente en diferentes contextos.
Objetos de prueba diferentes son probados de forma diferente.
o El controlador del motor de un coche requiere pruebas diferentes respecto de
aquellas para una aplicacin de "e- Commerce".
Entorno de pruebas (cama de pruebas - test bed) vs. entorno de produccin.
o Las pruebas tienen lugar en un entorno distinto del entorno de produccin. El
entorno de pruebas debe ser similar al entorno de produccin.
o Siempre habr diferencias entre el entorno de pruebas y el entorno de produccin.
Estas diferencias introducen incertidumbre con respecto a las conclusiones que se
pudieran obtener tras las pruebas.
39 de 418

Principio 7: La falacia de la ausencia de errores
Un proceso de pruebas adecuado detectar los fallos ms importantes.
En la mayora de los casos el proceso de pruebas no encontrar todos los defectos del
sistema (ver Principio 2), pero los defectos ms importantes deberan ser detectados.
Esto en s no prueba la calidad del sistema software.
La funcionalidad del software puede no satisfacer las necesidades y expectativas de los
usuarios.
No se puede introducir la calidad a travs de las pruebas, ella tiene que construirse desde
el principio.
40 de 418

Resumen:
Las pruebas pueden ayudar a detectar defectos en el software, sin embargo las mismas
no pueden demostrar la ausencia de defectos.
Salvo en casos triviales, las pruebas exhaustivas son imposibles, las pruebas de muestra
son necesarias.
Las pruebas tempranas ayudan a reducir costos dado que los defectos descubiertos en
fases tempranas del proceso software son corregidos con menor esfuerzo.
Los defectos se presentan agrupados. El encontrar un defecto en una ubicacin
determinada significa que probablemente se encontrar otro defecto a su alrededor.
Repetir pruebas idnticas no genera nueva Informacin.
Cada entorno particular determina la forma en la cual se ejecutarn o desarrollarn las
pruebas.
Un software libre de errores no implica que sea adecuado para el uso.
41 de 418

Agenda
I/01
I/02
I/03
I/04
I/05
I/06

Qu son pruebas?
Cdigo de tica
42 de 418

04 - Proceso de pruebas bsico
El proceso de pruebas como proceso dentro del proceso de desarrollo software
Dependiendo del enfoque seleccionado, el proceso de pruebas tendr lugar en diferentes
puntos del proceso de desarrollo.
Las pruebas constituyen un proceso en s mismas.
El proceso de pruebas est determinado por las siguientes fases:
o Planificacin de pruebas.
o Anlisis de pruebas y diseo de pruebas.
o Implementacin de pruebas y ejecucin de pruebas.
o Evaluacin del criterio de finalizacin de pruebas y generacin de informes de
pruebas.
o Actividades de cierre de pruebas.
As tambin:
Control de las pruebas (todas las fases).
LAS FASES DEL PROCESO DE PRUEBAS SE PODRN SUPERPONER.
43 de 418

El proceso de pruebas a lo largo del proceso de desarrollo software
Incluye superposicin y vuelta
atras (back tracking).
El proceso de pruebas es ms
que la ejecucin de pruebas!
Cada fase del proceso de
pruebas tiene lugar de forma
concurrente con las fases del
proceso de desarrollo software.
44 de 418

Control de pruebas - tareas principales
El control de pruebas es una actividad
continua que influye en la planificacin
de las pruebas. El plan de pruebas puede
ser modificado en funcin de la
informacin adquirida a partir del
control de pruebas.
El estado del proceso de pruebas se
determina comparando el progreso
logrado con respecto al plan de pruebas.
Se iniciarn aquellas actividades que se
consideraran consecuentemente necesarias.
Se miden y analizan resultados.
El progreso de las pruebas, la cobertura de las pruebas y el cumplimiento del criterio de
finalizacin de pruebas son objeto de seguimiento y son documentados.
Se inician medidas correctivas.
Preparar y tomar decisiones.
45 de 418

Planificacin de pruebas - tareas principales
Determinar el alcance y los riesgos.
Identificar los objetivos de las pruebas y el
criterio de finalizacin de pruebas.
Determinar el enfoque: tcnicas de
pruebas, cobertura de pruebas, equipo de
pruebas.
Implementar el mtodo de pruebas /
estrategia de pruebas, planificacin del
tiempo disponible para las actividades a
seguir.
Adquirir/obtener y programar recursos
requeridos por las pruebas: personal,
entorno de pruebas, presupuesto de pruebas.
46 de 418

Trminos: Planificacin de pruebas
Plan Maestro de prueba (en alemn: Testkonzept):
Un documento que describe el alcance, el enfoque, los recursos y el calendario de actividades
de la prueba prevista. Esto incluye, pero no se limita a los recursos, los elementos de prueba,
las caractersticas de la prueba y planes de contingencia.
Estrategia de pruebas:
Una descripcin de alto nivel de los niveles de prueba a realizar y las pruebas dentro de los
niveles de una organizacin o programa (uno o ms proyectos).
Enfoque de pruebas:
La aplicacin de la estrategia de prueba para un proyecto especfico Por lo general incluye las
decisiones que siguen a los objetivos (de prueba) del proyecto y el anlisis de riesgos, puntos
de partida sobre el proceso de prueba, las tcnicas de diseo de la prueba que deben aplicarse,
los criterios de salida y tipos de prueba para llevar a cabo.
47 de 418

Trminos: Planificacin de pruebas
Criterios de salida (despus de Gilb y Graham]:
El conjunto de las condiciones genricas y especficas, acordadas con las partes interesadas,
para permitir que un proceso sea completado oficialmente. El propsito de los criterios de
salida es evitar que una tarea sea considerada completa cuando todava hay partes de la tarea
pendiente que no se han terminado. Criterios de salida se utilizan para informar y para
planificar cundo dejar de probar. Esto debe hacerse para cada nivel de prueba.
48 de 418

Anlisis y diseo de pruebas - tareas principales
Revisin de las bases de las pruebas (requisitos,
arquitectura del sistema, diseo, interfaces).
Anlisis de lo arquitectura del sistema, diseo
del sistema incluyendo las interfaces entre los
objetos de prueba.
Identificar condiciones de prueba especficas y
los datos de prueba necesarios.
Evaluar la disponibilidad de datos de prueba y/o
la viabilidad de generar dalos de prueba
Diseo de pruebas / casos de prueba.
Crear casos de prueba lgicos (casos de prueba con datos de prueba sin valores
especficos) y establecer un orden de prioridad para los mismos.
Los casos de prueba positivos comprueban la funcionalidad, los casos de prueba
negativos comprueban situaciones en las cuales se debe realizar un tratamiento de
errores
Anlisis de la posibilidad de realizar pruebas sobre el sistema.
49 de 418

Anlisis y diseo de pruebas - tareas principales
Organizacin del entorno de pruebas (cama de pruebas - test bed).
o Disponibilidad (exclusiva) del entorno de pruebas, ventanas de tiempo. etc.
o Definir el modo de operacin del entorno de pruebas, incluida la administracin de
usuarios.
o Carga de datos de prueba y parmetros del sistema.
o Conexin del entorno de pruebas con los sistemas adyacentes.
Infraestructura de pruebas y herramientas de pruebas (si fuera necesario).
o Procesos, procedimientos y responsabilidades.
o Eleccin, suministro. Instalacin y operacin de herramientas de pruebas.
50 de 418

Trminos: Anlisis y diseo de pruebas
Datos de prueba (test data):
Datos que existen en el sistema antes de que una prueba sea ejecutada y que afecta o es
afectado por el componente o sistema sujeto a pruebas.
Datos de entrada (input data):
Variable que es leda por un componente (tanto almacenada dentro del sistema como fuera del
mismo).
Cobertura de pruebas (test coverage):
Grado en el cual un elemento especifico ha sido ejecutado por un conjunto de pruebas.
Utilizado con mayor frecuencia en pruebas de caja blanca con el objeto de determinar la
cobertura del cdigo.
51 de 418

Trminos: Anlisis y diseo de pruebas
Orculo de pruebas (test oracle):
Fuente que permite determinar los resultados esperados de un software sujeto o pruebas:
comparativas (benchmarks) (tambin resultado de pruebas previas), manuales de usuario o
conocimiento especializado. No debe ser el cdigo.
52 de 418

Ejecucin de pruebas - tareas principales
Desarrollo y asignacin de un orden de
prioridad a los casos de prueba.
o Creacin de datos de prueba, desarrollo
de procedimientos de prueba.
o Creacin de secuencias de pruebas
(juegos de pruebas - test suites)
Creacin de scripts de automatizacin de
pruebas, si fuera necesario.
Configuracin del entorno de pruebas (cama
de pruebas - test bed).
Ejecucin de pruebas (de forma manual o automtica)
o Seguimiento de secuencias de pruebas establecidas en el plan de pruebas (juegos de
pruebas orden de los casos de prueba).
53 de 418

Ejecucin de pruebas - tareas principales
Registro y anlisis de los resultados de pruebas.
Reiteracin de pruebas (retest)
o Despus de correccin de defecto
Pruebas de regresin (regression testing).
o Tras una correccin o instalar una nueva funcionalidad (cambio): Repeticin de
pruebas con el objeto de asegurar que los defectos han sido corregidos y que las
correcciones o modificaciones no han Introducido nuevos defectos.
54 de 418

Trminos: Ejecucin de pruebas
Juego de pruebas (test suite) / secuencia de pruebas (test sequence):
Conjunto de casos de prueba para un componente o sistema, donde Ia poscondicin de un caso
de prueba es utilizada como precondicin para el caso de prueba siguiente.
Especificacin de procedimiento de pruebas (test procedure specification, escenario de
pruebas - test scenario):
Documento en el cual se especifica una secuencia de acciones para la ejecucin de uno prueba
Tambin conocido como guin de pruebas o guin de pruebas manuales (Segn IEEE Std 829)
Ejecucin de pruebas (test execution):
Es el proceso de llevar a cabo una prueba, aportando / generando los resultados reales.
Registro de pruebas (test log) (informe de pruebas - test report):
Relacin cronolgica de los detalles relevantes relativa a la ejecucin de pruebas cuando se
desarrollaron las pruebas, qu resultados fueron generados.
55 de 418

Trminos: Ejecucin de pruebas
Pruebas de regresin (regression tests):
Pruebas tras la modificacin de un programa previamente probado, con el objeto de asegurar
que no se han introducido o descubierto defectos en reas que no hubieran sido objeto de
modificacin como resultado de los cambios realizados. Se realizan cuando el software o su
entorno han sido modificados.
Pruebas de confirmacin (confirmation testing), reiteracin de pruebas (retest):
Repeticin de una prueba despus de la correccin de un defecto, con el objeto de confirmar
que el defecto ha sido eliminado con xito.
56 de 418

Evaluacin del criterio de salida
principales
- tareas
Evaluacin de la ejecucin de pruebas con

respecto a objetivos definidos.
Evaluacin de los registros de pruebas
(resumen de las actividades de pruebas,
resultados de prueba, comunicar criterio de
salida).
Proporcionar informacin con el objeto de
permitir la decisin con respecto a si tendrn
lugar pruebas adicionales.
57 de 418

Actividades de cierre de pruebas - tareas
principales
Recopilar datos de las actividades del
proceso de pruebas finalizadas con el objeto
de consolidar la experiencia, utensilios de
pruebas (testware), hechos y resultados
(valores).
Cierre de informes de incidencias o
generacin de solicitudes de cambio para
cualquier punto que permaneciera abierto.
Comprobar qu entregables planificados han sido entregados y probados.
Documentar la aceptacin del sistema.
Finalizar y archivar los utensilios de pruebas (testware), el entorno de pruebas y la
infraestructura de pruebas para un uso posterior, transferencia al entorno de
operaciones.
Analizar las lecciones aprendidas para futuros proyectos.
58 de 418

Resumen:
El proceso de pruebas se puede dividir en diferentes fases.
Planificacin de pruebas (test planning) abarca actividades como la definicin de la
estrategia de pruebas para todas las fases as como la planificacin de los recursos
(tiempo, personal, mquinas).
Diseo de pruebas (especificacin) abarca el diseo de casos de prueba y sus resultados
esperados.
Ejecucin de pruebas abarca la definicin de datos de pruebas, la ejecucin de pruebas y
la comparacin de resultados.
Informes de pruebas (logging) registro de los resultados de pruebas, en forma tabulada,
en base de datos o de forma escrita.
Evaluacin de pruebas abarca el anlisis de defectos y la evaluacin del criterio de salida.
Control de pruebas consiste en las actividades de control que abarcan todas las foses
anteriores.
59 de 418

Agenda
I/01
I/02
I/03
I/04
I/05
I/06

Qu son pruebas?
Cdigo de tica
60 de 418

05 - Psicologa en el proceso de pruebas
Roles y responsabilidades
Rol: Desarrollador
Implementa requisitos.
Desarrolla estructuras.
Desarrolla el software.
Crea un producto.
La
actividad
CONSTRUCTIVA
del
desarrollador
Rol: Probador (Tester)

Planifica las actividades de pruebas.
Disea casos de prueba.
Su nica preocupacin es encontrar
defectos.
Encontrar errores producidos por un
desarrollador es su xito.
Percepcin:
es
La actividad del probador (tester) es
DESTRUCTIVA
Las pruebas tambin constituyen una actividad constructiva, su propsito es la eliminacin

de defectos en un producto!
61 de 418

Caractersticas personales de un buen tester /1
Curioso, perceptivo, atento a los detalles.
o Con el objeto de comprender los escenarios prcticos del cliente.
o Con el objeto de poder analizar la estructura de una prueba.
o Con el objeto de descubrir dnde se pueden manifestar fallos.
Escptico y con actitud crtica.
o Los objetos de prueba contienen defectos. Usted solo debe encontrarlos.
o No se debe tener temor al hecho de que pueden ser descubiertos defectos serios
que tengan un impacto sobre la evolucin del proyecto.
62 de 418

Caractersticas personales de un buen tester /2
Aptitudes para la comunicacin.
o Necesarias para llevar malas noticias a los desarrolladores.
o Necesarias para vencer estados de frustracin.
o Tanto cuestiones tcnicas como prcticas, relativas al uso del sistema, deben ser
entendidas y comunicadas.
o Una comunicacin positiva puede ayudar a evitar o facilitar situaciones difciles.
o Facilitan establecer una relacin de trabajo con los desarrolladores a corto plazo.
Experiencia.
o Factores personales influyen en la ocurrencia de errores.
o La experiencia ayuda a identificar dnde se pueden acumular errores.
63 de 418

Diferencias: disear - desarrollar - probar
Las pruebas requieren una perspectiva distinta a la del diseo y desarrollo de sistemas
software.
o Objetivo comn: proveer un buen producto software.
o Cometido del diseo: ayudar al cliente a proveer/suministrar los requisitos
correctos.
o Cometido de los desarrolladores: convertirlos requisitos en funciones.
o Cometido de los probadores (testers): evaluar la correcta implementacin de los
requisitos del cliente.
En principio, una persona puede asumir los tres roles en su trabajo.
o Se deben tener en cuenta las diferencias en objetivos y modelos de conducta.
o Es difcil pero posible.
o A veces otras soluciones (pruebas independientes) pueden ser ms sencillas y
aportar mejores resultados.
64 de 418

Pruebas independientes
La separacin de las responsabilidades en el proceso de pruebas apoya/promueve la
evaluacin independiente de los resultados de las pruebas.
En el siguiente diagrama se representa el grado de independencia a travs de un grfico de
barras.
65 de 418

Tipos de organizacin de pruebas /1
Pruebas del desarrollador
o El desarrollador nunca analizar su "creacin" de forma imparcial (apego afectivo).
Sin embargo, l conoce el objeto de pruebas mejor que nadie.
Habr costos adicionales debido a la formacin/Informacin de otras personas
respecto del objeto de pruebas.
o Las personas tienden a pasar por alto sus propios defectos.
Los desarrolladores corren el riesgo de no reconocer defectos evidentes.
o Errores cometidos como consecuencia de una mala interpretacin de los requisitos
se mantendrn sin ser detectados.
Establecer grupos de prueba donde los desarrolladores prueben los productos
de otros, ayuda a evitar, o al menos, reducir la posibilidad de ocurrencia de
esto tipo de anomala (producida por negligencia).
66 de 418

Equipos de desarrollo
o Los desarrolladores hablan el mismo lenguaje.
o Los costos de formacin/informacin en lo relativo a objetos de prueba se
mantienen a un nivel moderado, especialmente cuando los equipos intercambian
objetos de prueba.
o Peligro de generacin de conflictos entre equipos de desarrollo.
Un desarrollador que busca y encuentra un defecto no ser el mejor amigo del
autor del objeto de prueba analizado.
o Mezcla de actividades de desarrollo y pruebas.
Cambios frecuentes en la forma de pensar.
Dificultad en el control del presupuest del proyecto.
67 de 418

Equipos de pruebas
o La creacin de equipos de pruebas que den servicio o diferentes reas de proyecto
mejora la calidad de las pruebas.
o Es importante que los equipos de pruebas de diferentes reas en el proyecto
trabajen de forma independiente.
68 de 418

Outsourcing de pruebas (subcontratacin)
o La separacin de las actividades de pruebas y desarrollo aportan la mxima
independencia entre los objetos de prueba y el probador (tester).
o Las actividades de pruebas subcontratadas (externalizadas) son ejecutadas por
personal con un conocimiento relativamente pequeo de los objetos de prueba y de
los antecedentes del proyecto.
Lo curva de aprendizaje Implica altos costos, por lo tanto deberan ser
Incorporados expertos Independientes en etapas tempranas del proyecto.
o Los expertos externos cuentan con un alto nivel de conocimiento (know how) del
proceso de pruebas.
Est asegurando un diseo de pruebas apropiado.
Se alcanza la optimizacin en el uso de mtodos y herramientas.
Diseo de casos de prueba de forma automtica
o Generacin de casos de prueba asistida por ordenador, por ejemplo casos de
prueba basados en documentos de especificaciones formales.
69 de 418

Dificultades /1
Incapacidad de comprensin mutua.
o Los desarrolladores deberan contar con un conocimiento bsico de pruebas.
o Los probadores (testers) deberan contar con un conocimiento bsico de desarrollo
software.
Especialmente en situaciones de tensin, la deteccin de errores cometidos por alguien
frecuentemente conduce a conflictos.
o La forma de documentar los defectos y la forma en la cual el defecto es descrito
determinar cmo se desarrollarn los hechos.
o Las personas no deberan ser criticadas, los defectos deben ser descritos en
trminos objetivos.
o La descripcin de los defectos debera ayudar al desarrollador a encontrar el error.
o Los objetivos comunes siempre deben ser la cuestin principal.
70 de 418

Dificultades /2
Lo comunicacin entre probadores (testers) y desarrolladores es insuficiente o
inexistente. Este hecho puede hacer imposible el trabajo conjunto.
o Los probadores (testers) son vistos nicamente como "portadores de malas
noticias".
o Mejora: intente ponerse en el lugar (rol) de la otra persona. Ha llegado mi
mensaje? La respuesta es suficiente?
Un proceso de pruebas slido requiere la distancia apropiada con respecto al objeto de
prueba.
o Se adquiere un punto de vista independiente e imparcial a travs de la distancia con
respecto al desarrollo.
o Sin embargo, una distancia muy grande con respecto al objeto de prueba y el equipo
de desarrollo conducir a mayores esfuerzos y tiempo para las pruebas.
71 de 418

Resumen
Las personas cometen errores, toda implementacin tiene defectos.
La naturaleza humana dificulta la posibilidad de hacer frente a los defectos propios
(ceguera a los errores).
Desarrollador y probador (tester) implican el encuentro de dos mundos distintos.
o El desarrollo es constructivo - algo que no estaba ah previamente es creado.
o El proceso de pruebas resulta destructivo a primera vista - Se delectarn defectos!
o Juntos, el desarrollo y las pruebas son constructivos en su objetivo de obtener un
producto de software con la menor cantidad de defectos posible.
Las pruebas Independientes aumentan la calidad del proceso de pruebas.
o En lugar de equipos de desarrolladores utilice equipos de prueba o equipos de
prueba con personal externo.
72 de 418

Agenda
I/01
I/02
I/03
I/04
I/05
I/06

Qu son pruebas?
Cdigo de tica
73 de 418

06 Cdigo de tica
Cdigo de tica / 1
Las personas que participan en pruebas de software, tienen acceso a informacin muy
privilegiada y crtica. Para garantizar que la informacin no es objeto de un uso inadecuado, el
cdigo de tica es necesario.
Pblico: Los probadores certificados de software actuarn segn los intereses de su cliente y su
empleador, de conformidad con el inters pblico, especialmente al trabajar en un sistema de
seguridad crtico
Cliente y Empleador: El probador certificado deber actuar segn los intereses de sus clientes y
empleadores, de acuerdo con el inters pblico. Por ejemplo, que no se filtre informacin
interna o privada, sobre el cliente o el empleador en Internet.
74 de 418

06 Cdigo de tica
Cdigo de tica / 2
Producto: Los probadores certificados de software asegurarn que las prestaciones que
ofrecen (a los productos y sistemas que ponen a prueba) cumplen con los estndares
profesionales ms altos posibles. Es decir, el trabajo como consultor de no dejar los detalles
importantes para el cliente.
Sentencia: Los probadores certificados de software debern mantener la integridad e
independencia en su juicio profesional. Tal vez un jefe de proyecto est pidiendo ocultar
defectos importantes al cliente, lo que constituye una falta a la independencia y a la tica.
Gestin: Los gerentes y lderes certificados en pruebas de software promovern un enfoque
tico a la gestin de pruebas de software. Favorecer a un probador sobre otro para obtener
beneficios personales es una seria falta a la tica empresarial.
75 de 418

06 Cdigo de tica
Cdigo de tica / 3
Profesin: Los probadores certificados de software debern promover la integridad y
reputacin de la profesin de acuerdo con el inters pblico.
Colegas: Los probadores certificados de software sern justos y apoyarn a sus colegas y
promovern la cooperacin con los desarrolladores de software.
Personal: Los probadores de software certificado se capacitarn permanentemente sobre la
prctica de su profesin y promovern un enfoque tico de la prctica de la profesin. Asistir a
cursos y leer libros puede ser una manera de mantener el conocimiento en un alto nivel.
76 de 418
II - Pruebas a lo largo del ciclo de vida software

Agenda
Captulo II - Pruebas a lo largo del ciclo de vida software
II/01 Modelos de desarrollo software.

II/02 Niveles de prueba.
II/03 Tipos de prueba - objetivos de las pruebas.
II/04 Pruebas de Mantenimiento
77 de 418

01 Modelos de desarrollo software.
Pruebas a lo largo del modelo-V general
(Modelo secuencial de desarrollo)
El modelo-V general es el modelo de desarrollo software ms utilizado.
Desarrollo y pruebas tienen dos ramas iguales.
o Cada nivel de desarrollo tiene su correspondiente nivel de pruebas.
Las pruebas (rama derecha)
se disean en paralelo al
desarrollo software (rama
izquierda).
Las actividades del proceso
de pruebas tienen lugar a lo
largo de todo el ciclo de vida
software.
78 de 418

Rama: desarrollo software.
Definicin de requisitos.
o Documentos de especificacin.
Diseo funcional del sistema.
o Diseo del flujo funcional del
programa.
Diseo tcnico del sistema.
o Definicin de arquitectura/
interfaces.
Especificacin de los componentes.
o Estructura de los componentes.
Programacin.
o Creacin de cdigo ejecutable.
79 de 418

Rama: pruebas software.
Pruebas de aceptacin.
o Pruebas formales de los requisitos
del cliente.
Pruebas de sistema.
o Sistema Integrado,
especificaciones.
Pruebas de integracin.
o Interfaces de componentes.
Pruebas de componente.
o Funcionalidad del componente.
80 de 418

Verificacin vs. Validacin
Verificacin
o Comprobacin de la conformidad con los requisitos establecidos (definicin segn
ISO 9000).
o Cuestin clave: Se ha procedido correctamente en la construccin del sistema?
o Hemos sumado 1 ms 1 correctamente?
Validacin
o Comprobacin de la idoneidad para el uso esperado (definicin segn ISO 9000).
o Cuestin clave: Hemos construido el sistema de software correcto?
o El objetivo era sumar 1 ms 1 o deberamos haber restado?
81 de 418

Verificacin dentro del modelo-V general
Cada nivel de desarrollo se verifica respecto de los contenidos del nivel que le precede.
o Verificar: comprobar la evidencia.
Verificar significa comprobar si los requisitos y definiciones de niveles previos han sido
Implementados correctamente.
82 de 418

Validacin dentro del modelo-V general
Lo validacin se refiere a la correccin de cada nivel de desarrollo.
o Validar: Dar prueba de la aportacin de valor.
Validar significa comprobar lo adecuado de los resultados de un nivel de desarrollo.
83 de 418

Modelo-W
El modelo W puede ser visto como una extensin del modelo-V general
En los estados W-modelo, ciertas actividades de control de calidad se realizar en
paralelo con el proceso de desarrollo
84 de 418

Otros modelos de prueba: modelos iterativos /1
Desarrollo software iterativo.
o Las actividades: Definicin de requisitos, diseo, desarrollo y pruebas se segmentan
en pasos reducidos y se ejecutan de formo continua.
o Se debe lograr el consentimiento con el cliente tras cada iteracin con el objeto de
modificar el rumbo del proyecto si fuera necesario.
Ejemplos de modelos iterativos:
o Modelo Prototipado: Desarrollo rpido de una representacin del sistema que
pudiera ser objeto de uso. Seguido de modificaciones sucesivas hasta que el sistema
sea finalizado.
o Desarrollo Rpido de Aplicaciones (Rapid Application Development - RAD): La
Interfaz de usuario se Implementa utilizando una funcionalidad hecha (out of the
box) simulando lo funcionalidad que posteriormente ser desarrollada.
o Proceso Unificado (Rational Unified Process - RUP): Modelo orientado a objetos y
producto de la compaa Rational/lBM. Principalmente aporta el lenguaje de
modelado UML y soporte al Proceso Unificado.
o Programacin Extrema (Extreme Programming - XP): El desarrollo y las pruebas
tienen lugar sin una especificacin de requisitos formalizada.
85 de 418

Caractersticas de los modelos iterativos:
o Cada iteracin contribuye con una caracterstica adicional del sistema bajo
desarrollo.
o Cada iteracin puede ser probada por separado.
o Las pruebas de regresin son de gran relevancia.
o En cada iteracin, la verificacin (relacin con el nivel precedente) y la validacin
(grado de correccin del producto dentro del nivel actual) se pueden efectuar por
separado.
86 de 418

Desarrollo guiado por pruebas (Test Driven Development - TDD)
o Desarrollo basado en conjunto de pruebas (Suite cases)
Preparar los ciclos de pruebas
Prueba automatizada utilizando herramientas de prueba
o Desarrollo, segn los casos de prueba
Preparar versiones tempranas del componente para probarlo
Ejecucin automtica de pruebas
Corregir los defectos en las versiones
Repetir el conjunto de pruebas hasta que no se encuentran errores
Primero se disean las pruebas, luego el software es desarrollado
87 de 418

Principios de todos los modelos
Cada actividad de desarrollo debe ser probada.
o Ninguna porcin del software puede quedar sin ser probada, tanto si ha sido
desarrollada "en una nica fase" o de forma Iterativa.
Cada nivel de pruebas debera ser probado de forma especfica.
o Cada nivel de pruebas cuenta con sus propios objetivos de prueba.
o Las pruebas llevadas a cabo en cada nivel deben reflejar estos objetivos.
El proceso de pruebas comienza con mucha antelacin a la ejecucin de pruebas.
o Tan pronto como el desarrollo comienza puede comenzar la preparacin de las
pruebas correspondientes.
o Tambin es el caso de las revisiones de documentos comenzando por los conceptos,
especificacin y el diseo en conjunto.
88 de 418

Resumen
El desarrollo de software utiliza modelos tanto para el propio desarrollo de software
como para las actividades del proceso de pruebas.
El modelo ms conocido es el modelo-V, el cual describe los niveles de desarrollo y
niveles de prueba como dos ramas relacionadas.
Los modelos iterativos ms relevantes son RUP y XP.
Las actividades de pruebas estn recomendadas en todos los niveles de desarrollo.
89 de 418

Agenda

90 de 418

02 Niveles de prueba.
Pruebas de Componente
91 de 418

Pruebas de componente
Bases de prueba (Test basis):
o Requisitos (requerimientos )de los componentes
o Diseo detallado
o Cdigo
Objetos de prueba tpicos:
o Componentes / clases / unidades / mdulos
o Programas
o Conversin de datos / programas de migracin
o Base de datos de los mdulos
92 de 418

Pruebas de Componente Definicin
Pruebas de componente (pruebas unitarias, pruebas de mdulo, pruebas
de clase, pruebas de desarrollador).
o Pruebas de cada componente tras su realizacin.
Dadas las convenciones de cada lenguaje de programacin para la asignacin de nombres
a sus respectivos componentes, se podr hacer referencia a un componente como:
o Prueba de mdulo (module test) (por ejemplo en C).
o Prueba de clase (por ejemplo en Java o C++).
o Prueba de unidad (por ejemplo en Pascal).
Los componentes son referidos como mdulos, clases o unidades. Dado que los
desarrolladores posiblemente pueden estar Involucrados en la ejecucin de pruebas,
stas tambin son denominadas pruebas de desarrollador (developer test).
93 de 418

Pruebas de componente Alcance
Slo se prueban componentes individuales.
o Un componente puede estar constituido por un conjunto de unidades ms
pequeas.
o Los objetos de prueba no siempre pueden ser probados en solitario (de forma
autnoma).
Cada componente es probado de forma independiente.
o Descubriendo defectos internos.
o Los efectos cruzados entre componentes quedan fuera del alcance de estas
pruebas.
Los casos de pruebas pueden ser derivados de:
o Especificacin de componentes
o Diseo de Software
o Modelos de datos
94 de 418

Pruebas de componente - Pruebas Funcionales y No Funcionales /1.
Pruebas de funcionalidad
o Toda funcionalidad debe ser probada, por lo menos, con un caso de prueba.
Las funciones: Se realizan correctamente? La funcionalidad: Cumple todas
las especificaciones?
o Defectos descubiertos habitualmente:
Defectos en el tratamiento de datos, normalmente en los valores fronteras
(boundary values).
Funciones ausentes (missing functions).
95 de 418

Pruebas de componente - Pruebas Funcionales y No Funcionales /2.
Probar la robustez (testing robustness) (resistencia a datos de entrada invlidos).
o Los casos de prueba que comprueban datos de entrado Invlidos se denominan
pruebas negativas
o Un sistema robusto aporta un tratamiento apropiado para datos de entrada
errneos.
La aceptacin por parte del sistema de datos de entrada errneos puede
producir fallos en un futuro procesamiento de los mismos (datos de salida
errneos, fallo del sistema - system crash).
Otros atributos No Funcionales pueden ser probados
o Por ejemplo pruebas de estrs y rendimiento
96 de 418

Pruebas de componente - Arns de pruebas
La ejecucin de pruebas de componente requiere, frecuentemente, de DRIVERS y STUBS.
o Un DRIVER procesa la interfaz de un componente.
Los DRIVERS simulan datos de entrada, registran datos de salida y aportan un
arns de pruebas (test harness).
Los DRIVERS utilizan herramientas de programacin.
Un STUB reemplaza o simula un componente que an no se
encuentro disponible.
Para programar un DRIVER o un STUB, el probador debe>
o Tener conocimientos de programacin
o Tener el cdigo fuente disponible
o Puede necesitar herramientas especiales
97 de 418

Pruebas de componente - mtodos
El cdigo fuente se encuentra disponible para el probador (tester).
o Caso probador (tester) = desarrollador: Las pruebas se desarrollan con una fuerte
orientacin hacia el desarrollo.
o El conocimiento de la funcionalidad, estructura de componentes y variables puede
ser aplicado para el diseo de casos de prueba.
o Las pruebas funcionales pueden ser aplicadas (con frecuencia).
o Adicionalmente, el uso de depuradores (debuggers) y otras herramientas de
desarrollo permitirn acceso directo a las variables del programa.
El conocimiento del cdigo fuente permitir la aplicacin de mtodos de caja blanca
(white box) para pruebas de componente.
98 de 418

Pruebas de componente - Resumen
Un componente es la unidad ms pequea especificada de un sistema.
Prueba de mdulo, de clase, de unidad y de desarrollador son utilizados como sinnimos.
Los DRIVERS ejecutarn las funciones de un componente y las funciones adyacentes que
son reemplazadas por STUBS.
Las pruebas de componente podrn comprobar caractersticas funcionales y no
funcionales de un sistema.
99 de 418

Pruebas de Integracin
100 de 418

Pruebas de integracin
Base de la prueba:
o Software y diseo de sistemas
o Arquitectura
o Diagramas de Flujo
o Casos de Uso
Objetos de prueba tpicos:
o Sub-sistemas de implementacin de bases de datos
o Infraestructura
o Interfaces
Configuracin del sistema:
o Configuracin de datos
101 de 418

Pruebas de Integracin Definicin
Tambin llamadas pruebas de interfaz
Comprueba la interaccin entre elementos software (componentes) tras la integracin
del sistema.
La integracin es la actividad en la cual se combinan los componentes de software
individuales en subsistemas ms amplios.
La integracin adicional de subsistemas tambin es parte del proceso de integracin del
sistema.
Cada componente ya ha sido probado en lo referente a su funcionalidad interna (prueba
de componente). Las pruebas de integracin comprueban las funciones externas.
Puede ser ejecutada por los desarrolladores y/o los testers
102 de 418

Pruebas de integracin - Alcance /1
Las pruebas de integracin asumen que los componentes ya han sido probados.
Las pruebas de integracin comprueban la interaccin mutua entre componentes
(subsistemas) de software:
o Interfaces con otros componentes.
o Interfaces GUIs / MMIs.
Las pruebas de integracin comprueban las interfaces con el entorno del sistema.
o En la mayora de los casos la Interaccin probada es el comportamiento del
componente y el entorno simulado.
o En condiciones reales factores adicionales del entorno pueden influir en el
comportamiento del componente. Por lo tanto las pruebas de integracin no
pueden garantizar un comportamiento correcto en el entorno real del sistema.
Los casos de prueba pueden ser derivados de la especificacin de interfaz, diseo
estructural o modelos de datos
103 de 418

Ser probado un (subsistema) sistema compuesto de componentes Individuales.
o Cada componente tiene una Interfaz externa y/o una interfaz que interacta con
otro componente dentro del mismo (subsistema) sistema.
Son necesarios DRIVERS de prueba (los cuales aportan el entorno al proceso del sistema o
subsistema)
o Con el objeto de tener en cuenta o producir entradas y salidas del (subsistema)
sistema.
o Con el objeto de registrar datos.
Los DRIVERS de prueba propios de las pruebas de componente pueden ser reutilizadas en
estas pruebas.
104 de 418

Herramientas de control (monitoring tools): pueden apoyar las actividades de pruebas
registrando datos y controlando las mismas pruebas.
Un STUB reemplaza un componente faltante.
o Un STUB programado reemplazar datos o funcionalidad de un componente que
an no ha sido integrado.
o Un STUB asumir las tareas elementales de un componente faltante.
105 de 418

Pruebas de integracin - Enfoque
El propsito de las pruebas de Integracin es detectar defectos en las interfaces. Las
pruebas de integracin comprueban la correcta interaccin entre componentes.
o Con el objeto de comprobar, entre otros, aspectos relativos al rendimiento y la
seguridad, requiriendo pruebas adicionales (no funcionales).
Al reemplazar DRIVERS y STUBS de prueba por componentes reales se pueden generar
nuevos defectos tales como:
o Prdida de datos, manipulacin errnea de dalos o entradas errneas.
o El componente involucrado Interpreta los datos de entrada de una manera distinta.
o Los dalos son transferidos en un momento incorrecto: antes de tiempo, despus de
tiempo, a una frecuencia distinta de la requerida.
106 de 418

Pruebas de integracin - Estrategias /1
Hay diferentes estrategias para las pruebas de Integracin.
o El enfoque Incremental es un elemento comn a la mayora de las estrategias (excepcin:
estrategia BIG BANG).
o Las estrategias ascendentes (BOTTOM-UP) y descendente (TOP-DOWN) son los utilizados
con mayor frecuencia.
La eleccin de la estrategia debe considerar tambin aquellos aspectos relativos a la eficiencia
de las pruebas.
o La estrategia de integracin determina la magnitud del esfuerzo requerido para las
pruebas (por ejemplo el uso de herramientas, programacin de DRIVERS y STUBS, etc.).
o La finalizacin de lo construccin de componentes determina, para todos los tipos de
estrategias, el intervalo temporal en el cual el componente estar disponible. Por lo tanto,
la estrategia de desarrollo Influye en lo estrategia de integracin.
En cada proyecto especfico se debe considerar el compromiso entre la reduccin de tiempo y
la reduccin de esfuerzo en pruebas:
o Probar aquello que se encuentra finalizado: mayores costos en pruebas y menor tiempo
ocioso.
o Seguir un plan de pruebas de integracin estricto: menores costos y mayor tiempo ocioso.
107 de 418

Pruebas de integracin - Estrategias /2
Integracin AD HOC.
o Los componentes sern probados, si es posible, inmediatamente despus de haber
sido finalizada su construccin y se hayan finalizado las pruebas de componente.
Caractersticas de la integracin AD HOC.
o Inicio temprano de las actividades de prueba, dando lugar a un proceso de
desarrollo de software ms corto en trminos globales.
o DRIVERS y STUBS sern necesarios dependiendo del tipo de componentes
finalizados.
Uso de la Integracin AD HOC.
o Es una estrategia que puede ser aplicada en cualquier etapa del proyecto.
o Es una estrategia que normalmente se aplica combinada con otras.
108 de 418

Pruebas de integracin - Resumen
Integracin significa construir grupos de componentes.
Las pruebas de integracin comprueban la interaccin entre componentes respecto de la
especificacin de interfaces.
La integracin ocurre de forma ascendente (BOTTOM-UP), descendente (TOP-DOWN) o
en forma de BIG BANG.
Integracin de subsistemas (estn constituidos por componentes integrados) tambin es
un forma de integracin.
Cualquier estrategia de integracin distinta a las anteriores es integracin AD HOC.
109 de 418

Pruebas de Sistema
110 de 418

Pruebas de Sistema
Base de pruebas:
o Especificacin de requerimientos del sistema y del software
o Casos de uso
o Especificacin funcional
o Informes de anlisis de riesgo
o Manuales de operacin del sistema y de usuario
o Configuracin del sistema
Parametrizacin (Datos de configuracin)
111 de 418

Pruebas de Sistema - Definicin
El proceso de pruebas de un sistema integrado comprueba si cumple con los requisitos
especificados.
Las pruebas del sistema verifica el comportamiento de todo el sistema
El alcance de las pruebas se define en el Plan Maestro de pruebas o en el Plan de niveles
de pruebas
Se busca que la calidad del software este determinado por el punto de vista del usuario
Pruebas del sistema se refieren (segn ISO 9126)
o Requisitos funcionales (funcionalidad y no funcionales (fiabilidad, usabilidad,
eficiencia, mantenibilidad, portabilidad)
Las caractersticas de la calidad de los datos son las bases para las pruebas
Los casos de prueba se pueden derivar de:
Especificaciones funcionales
Casos de uso
Procesos de negocio
Informes de anlisis de riesgo
112 de 418

Pruebas de Sistema Alcance
Pruebas de un sistema integrado desde el punto de vista del usuario.
o Implementacin completa y correcta de los requerimientos.
o Despliegue en el entorno real del sistema con datos reales.
El entorno de pruebas debera coincidir con el entorno real.
o No son necesarios STUBS o DRIVERS.
o Todas las interfaces externas son probadas en condiciones reales.
o Emulacin prxima al futuro entorno real del sistema
No se realizan pruebas en el entorno real
o Los defectos inducidos podran daar el entorno real.
o Un software objeto de despliegue se encuentra en un estado de cambio constante.
Muchas pruebas no sern reproducibles.
113 de 418

Pruebas de Sistema Requerimientos funcionales /1
Objetivo: comprobar que la funcionalidad implementada expone las caractersticas
requeridas.
Las caractersticas a ser probadas incluyen (segn ISO 9126):
o Adecuacin/idoneidad (Suitability).
Las funciones Implementadas son adecuadas paro su uso esperado?
o Exactitud (Accuracy).
Las funciones presentan los resultados correctos (acordados)?
o Interoperabilidad (Interoperability).
Las interacciones con el entorno del sistema presentan algn problema?
o Conformidad (Compliance).
El sistema cumple con normas y reglamentos aplicables?
o Seguridad (security).
Estn protegidos los datos/programas contra acceso no deseado o prdida?
114 de 418

Pruebas de Sistema Requerimientos funcionales /2
Tres enfoques para probar requisitos funcionales:
o Pruebas basadas en requerimientos.
Los casos de prueba se derivan de la especificacin de requerimientos.
El nmero de casos de prueba variar en funcin del tipo/profundidad de las
pruebas basadas en la especificacin de requerimientos.
o Pruebas basadas en procesos de negocio.
Cada proceso de negocio sirve como insumo para derivar/generar pruebas.
El orden de relevancia de los procesos de negocio pueden ser aplicados para
asignar prioridades a los casos de prueba.
o Pruebas basadas en casos de uso:
Los casos de prueba se derivan/generan a partir de las secuencias de usos
esperados o razonables.
Las secuencias utilizadas con mayor frecuencia reciben uno prioridad ms alta.
115 de 418

Pruebas de Sistema Requerimientos no funcionales
La conformidad con requisitos no funcionales es difcil de lograr:
o Con frecuencia la definicin de estos requisitos es muy vaga (por ejemplo fcil de
operar, interfaz de usuario bien estructurada, etc.).
o Los requisitos no funcionales no son establecidos de forma explcita, son una parle
implcita de lo descripcin del sistema. Sin embargo se espera que sean satisfechos.
o La cuantificacin de requisitos no funcionales es difcil debido al hecho de que se
dispone de pocas o ninguna mtrica objetiva para su medicin: Las personas
exponen su punto de vista subjetivo (por ejemplo que sea bonito, muy seguro, fcil
de aprender, etc.).
Ejemplo: Prueba / inspeccin de documentacin.
o Est actualizada la documentacin de programas con la versin actual del sistema?
La documentacin es completa, concisa y fcil de entender?
Ejemplo: Prueba de mantenibilidad.
o Los programadores han cumplido con los estndares de codificacin respectivos?
o El sistema ha sido diseado de una forma estructurada y modular?
116 de 418

Pruebas de Sistema Resumen
Las pruebas de sistema se desarrollan utilizando casos de prueba funcionales y no
funcionales.
Las pruebas de sistema funcionales confirman que los requisitos para un uso especfico
previsto han sido satisfechos (validacin).
Las pruebas de sistema no funcionales verifican los atributos de calidad no funcionales,
por ejemplo usabilidad, eficiencia, portabilidad, mantenibilidad y fiabilidad.
Con frecuencia, los atributos de calidad no funcionales son una parte Implcita en los
requisitos, esto hace difcil validarlos.
117 de 418

Pruebas de Aceptacin
118 de 418

Pruebas de Aceptacin - Definicin
Base de Pruebas:
o Requerimientos de usuarios
o Requerimientos del sistema
o Casos de uso
o Procesos de negocio
o Informes de anlisis de riesgo
Objetos tpicos de prueba:
o Procesos de negocio totalmente integrados en el sistema
o Procesos operativos y de mantenimiento
o Procedimientos de usuario
o Formularios
o Informes
Parametrizacin (Datos de configuracin)
119 de 418

Pruebas de Aceptacin Aceptacin contractual
El software satisface todos los requisitos contractuales?
o Con la aceptacin formal se cumplen los hitos legales: comienzo de fase de garanta,
hitos de abono (pago), acuerdos de mantenimiento, etc.
o Criterios de aceptacin verificables definidos en el momento del acuerdo
contractual constituyen una garanta para ambas parles.
o Las pruebas de aceptacin deben tener en cuenta normas y reglamentos
gubernamentales, legales, industriales y de otro tipo.
120 de 418

Pruebas de Aceptacin Aceptacin de usuario
Normalmente el cliente selecciona casos de prueba para las pruebas de aceptacin.
o Es posible que surjan malas Interpretaciones con respecto a los requerimientos y
pueden ser discutidos. EI diente conoce su negocio".
Las pruebas se realizan utilizando el entorno del cliente.
o El entorno del cliente puede producir nuevos fallas.
121 de 418

Pruebas de Aceptacin Aceptacin operacional
Requiere que el software sea apto para su uso en el entorno productivo
o Integracin de software en la infraestructura IT (Information Technology) del cliente
(Copia de seguridad, sistemas de recuperacin, etc.)
o Administracin de usuarios, interfaz con las estructuras de archivos y directorios en
uso
o Compatible con otros sistemas (otros ordenadores, servidores de bases de datos,
etc.)
o Tareas de mantenimiento
o Datos de carga y tareas de migracin
o Controles peridicos de vulnerabilidades del sistema
Pruebas de aceptacin operacional se hacen a menudo por el administrador del sistema
del cliente
122 de 418

Pruebas de Aceptacin Pruebas ALPHA Y BETA
Una versin preliminar y estable del software (versin BETA) se entrega a un conjunto
especfico (seleccionado) de clientes.
o El cliente ejecuta las pruebas en dependencias propias (pruebas BETA, tambin
denominadas pruebas de campo), los problemas son registrados e Informados o los
desarrolladores para su correccin.
o El cliente utiliza el software para hacer el tratamiento de sus procesos cotidianos o
ejecuta un juego de pruebas seleccionado.
o El software se prueba mejor en los distintos entornos del cliente.
o Previo a las pruebas BETA l cliente pueden probar el nuevo software en las
dependencias del desarrollo.
Las pruebas ALPHA se desarrollan en las dependencias de lo organizacin que desarrolla.
Ventajas de estas pruebas.
o Reducen el costo de los pruebas de aceptacin
o Se utilizan distintos entornos de cliente
o Involucran a un alto nmero de usuarios.
123 de 418

Pruebas de Aceptacin Resumen
Las pruebas de aceptacin son las pruebas de sistema por parte del cliente.
La prueba de aceptacin es una actividad de carcter contractual, se verificar entonces
que el software satisface los requerimientos del cliente.
Las pruebas ALPHA y BETA son pruebas ejecutadas por clientes reales o potenciales
Las Pruebas ALPHA se ejecutan en las dependencias del desarrollador
Las pruebas BETA se ejecutan en las dependencias del cliente
124 de 418

Agenda

125 de 418

03 Tipos de prueba: Objetivos de las pruebas.
Tipos de pruebas y niveles de pruebas
Niveles de pruebas.
o En la seccin previa se han explicado los distintos niveles de pruebas, es decir
pruebas de componente, pruebas de integracin, etc.
o (En cada nivel de prueba los objetivos de las pruebas tienen un enfoque diferente
o Por lo tanto, se aplican distintos tipos de pruebas durante los distintos niveles de
pruebas.
Tipos de pruebas.
o
o
o
o
Pruebas funcionales
Pruebas no funcionales
Pruebas estructurales
Pruebas relacionadas con los cambios
Objetivo: Probar la funcin.

Objetivo: Probar las caractersticas del producto.
Objetivo: probar la estructura/arquitectura software.
Objetivo: probar despus de cambios.
126 de 418

Pruebas funcionales
Objetivo: Validar la funcionalidad del objeto de prueba.
o La funcionalidad puede ser vinculada a los datos de entrada y salida de un objeto de
prueba.
o Los mtodos de caja negra (black box) se utilizan en el diseo de casos de prueba
relevantes.
o Las pruebas se desarrollan teniendo en cuento los requisitos funcionales establecidos
en las especificaciones: Conceptos, casos de estudio, reglas de negocio o documentos
relacionados.
mbito de aplicacin.
o Los pruebas funcionales se pueden llevar a cobo en todos los niveles de prueba
Ejecucin.
o El objeto de prueba es ejecutado utilizando combinaciones de datos de prueba
derivados a partir de los casos de prueba.
o Los resultados de la ejecucin de la prueba son comparados con los resultados
esperados
Pruebas de Seguridad
o Tipo de pruebas funcionales que examina elementos externos de la aplicacin
o Ataques maliciosos pueden daar programas y datos
127 de 418

Pruebas no funcionales
Objetivo: Validar las caractersticas del producto software.
o De qu formo el software lleva o cabo la funcin?
o Valida caractersticas no funcionales del software (Segn ISO 9126: Fiabilidad, usabilidad.
eficiencia, mantenibilidad. portabilidad)
o A menudo las caractersticas no funcionales a menudo son vagas, incompletas o Inexistentes,
dificultando las pruebas asociadas a las mismas.
mbito de aplicacin.
o Las pruebas no funcionales se pueden llevar o cabo en todos los niveles.
o Pruebas no funcionales tpicas:
Pruebas de rendimiento (Performance testing), Pruebas de carga (Load testing), pruebas
de estrs (Stress testing), pruebas de volumen (Volume testing)
Pruebas de las caractersticas de seguridad para el software (Testing of security features),
pruebas de las caractersticas de seguridad del software (Testing of safety features).
Pruebas de estabilidad y robustez: (Stability and robustness testing)
Pruebas de compatibilidad (Compatibility testing")
Pruebas de usabilidad (Usability testing)
Pruebas de configuracin (Configuration testing)
Ejecucin.
o La conformidad con los requisitos no funcionales se miden utilizando requerimientos
funcionales (seleccionados).
128 de 418

Pruebas no funcionales (Pruebas de sistema) / 1
Prueba de carga (Load test).
o Sistema bajo carga (carga mnima, ms usuarios/transacciones).
Prueba de rendimiento (Performance test).
o Rapidez con la cual un sistema ejecuta una determinada funcin.
Prueba de volumen (Volume test).
o Procesamiento de grandes cantidades de datos / Archivos.
Prueba de estrs (Stress test).
o Reaccin a la sobrecarga / recuperacin tras el retorno a un carga normal.
Prueba de estabilidad (Stability test).
o Rendimiento en "modo de operacin continua".
Prueba de robustez (Test for robustness).
o Reaccin a entradas errneas o datos no especificados. Reaccin a fallos hardware /
recuperacin ante situaciones de desastre.
129 de 418

Pruebas no funcionales (Pruebas de sistema) / 2
Pruebas de seguridad para el software (de datos) (Test for data) security).
o Proteccin contra accesos no autorizados.
o Proteccin contra el robo y dao de dalos.
Pruebas de cumplimiento (Compliance test).
o Cumplimiento de normas y regulaciones (Internos / externos).
Pruebas de usabilidad (Test for usability).
o Estructurado, comprensible, fcil de aprender para el usuario.
Otros aspectos no funcionales de la calidad:
o Portabilidad: Capacidad de ser remplazado, de ser Instalado, adaptabilidad
o Mantenible: Verificable, estable, analizable, modificable.
o Fiabilidad: Madurez, robustez, capacidad de recuperacin.
130 de 418

Pruebas estructurales
Objetivo: Validar cobertura de estructura
o Anlisis de lo estructura de un objeto de prueba (enfoque: caja blanco).
o La finalidad de las pruebas es medir el grado en el cual la estructura del objeto de
prueba ha sido cubierta por los casos de prueba.
mbito de aplicacin.
o Las pruebas estructurales son posibles en todos los niveles de pruebas, se realizan
de forma conjunta a las pruebas de componente y de Integracin mediante el uso
de herramientas.
o El diseo de pruebas estructurales finaliza tras haber sido diseadas las pruebas
funcionales con el propsito de obtener un alto grado de cobertura.
Ejecucin.
o Se probar la estructura Interna de un objeto de prueba (por ejemplo el control de
flujo en el Interior de un componente, el flujo a travs de lo estructura de un men).
o Objetivo: Todos los elementos estructurales identificados deben estar cubiertos por
casos de prueba.
131 de 418

Pruebas relacionadas con los cambios /1
Las pruebas relacionadas con los cambios son:
o Pruebas de confirmacin (re-testing): Pruebas
despus de correccin de un defecto
o Pruebas de regresin: Pruebas para descubrir
nuevos defectos introducidos por un cambio.
Objetivo: Validar objeto de pruebas despus de
cambios.
o Dos razones principales
Correccin de defectos
Extensin o cambio de la funcionalidad
o Despus de que un objeto de pruebas o el entorno de su sistema ha sido objeto de
modificacin todos los resultados de pruebas resultan invlidos, por lo que los
pruebas deben ser repetidas.
o Es necesario volver o probar zonas adyacentes debido a efectos colaterales no
deseados de uno funcionalidad extendida o nueva.
132 de 418

mbito de aplicacin.
o Las pruebas relacionadas con los cambios pueden ser ejecutadas en todos los
niveles de pruebas.
o Repetir una prueba de funcionalidad que ya haba sido verificada se llama prueba de
regresin.
o El alcance de las pruebas de regresin depende del riesgo e impacto de la nueva
funcionalidad implementada (extensin o correccin de defectos)
o El anlisis de riesgo se llama anlisis de impacto
133 de 418

Ejecucin
o Bsicamente lo ejecucin tiene lugar de la misma forma en la cual se han ejecutado
las pruebas en iteraciones previas.
o En la mayora de los casos, una prueba de regresin completa no es viable dado sus
altos costos y duracin.
o Un alto grado de modularidad en el software permite reducir las pruebas de
regresin.
o Criterios para la seleccin de casos de prueba de regresin:
Casos de prueba de alta prioridad.
Probar solamente la funcionalidad estndar, saltarse casos y variaciones
especiales.
Probar solamente la configuracin utilizada con mayor frecuencia.
Probar solamente subsistemas / zonas seleccionadas del objeto de pruebas
o Si durante fases tempranas del proyecto resulta evidente que ciertas pruebas son
adecuadas para las pruebas de regresin, se deber considerar la automatizacin de
estas pruebas.
134 de 418

Resumen
En niveles de pruebas distintos se utilizan diferentes tipos de pruebas.
Los tipos de pruebas son: funcionales, no funcionales. estructurales y pruebas
relacionadas con los cambios.
Las pruebas funcionales comprueban el comportamiento de entradas y salidas de un
objeto de pruebas.
Las pruebas no funcionales comprueban las caractersticas de un producto
Las pruebas no funcionales incluyen, pero no estn limitadas a: pruebas de carga, pruebas
de estrs, pruebas de rendimiento, pruebas de robustez.
Las pruebas estructurales habituales son pruebas que comprueban el flujo de control y de
datos midiendo la cobertura en el objeto de prueba.
Pruebas importantes despus de un cambio: pruebas de confirmacin (retest) y pruebas
de regresin.
135 de 418

Agenda

136 de 418

04 Pruebas de Mantenimiento
Pruebas despus de la aceptacin del producto /1
El cliente ha aprobado el producto y es puesto en produccin.
o El ciclo de desarrollo inicial, incluidas las pruebas asociadas, ha sido completado.
El mismo software se encuentra al comienzo del ciclo de vida:
o Ser utilizado por muchos aos, ser ampliado.
o Es muy probable que an contenga defectos, por lo tanto ser modificado y
corregido.
o Necesitar adaptarse a nuevas condiciones y deber integrarse a nuevos entornos.
o Necesitar cambiar o extender la parametrizacin (datos de configuracin).
o El software ser retirado, puesto fuera de servicio.
Cualquier nueva versin del producto, cada nueva actualizacin y cada cambio del
software requiere pruebas adicionales.
137 de 418

Configuracin:
o La composicin de un componente o sistema est definido como el nmero,
naturaleza e interconexiones de sus partes.
Anlisis de Impacto
o Se realiza evaluacin de impacto basndose en la documentacin de despliegue,
documentacin de pruebas y componentes, para implementar un cambio de un
requerimiento especifico
Pruebas de Mantenimiento
o Se prueban los cambios de un sistema que se encuentra operativo o el impacto de
un cambio en el ambiente del sistema que se encuentra operativo
138 de 418

El mantenimiento de software cubre dos diferentes campos:
o Mantenimiento como tal: Correccin de defectos o implementacin de parches
(HOT-FIXES), que eran parte de la versin inicial del software
o Versiones planificadas del sistema: Adaptacin como resultado de un cambio en el
ambiente o nuevos requerimientos de los clientes
Alcance de las pruebas de mantenimiento
o Parches y correccin de defectos requieren pruebas de confirmacin (retest)
o Extensin de la funcionalidad requiere de nuevos casos de prueba
o Migracin a otras plataformas requiere de pruebas operacionales
o Adicionalmente, intensivas pruebas de regresin son necesarias
139 de 418

El alcance de las pruebas est determinado por el impacto del cambio
o El anlisis de impacto es usado para determinar las reas afectadas para decidir la
cantidad de pruebas de regresin
o Pueden ocurrir problemas si la documentacin del software antiguo es incorrecta o
incompleta
Retiro del software
o Las pruebas despus de que el software es retirado puede incluir
Pruebas de migracin de datos
Verificar archivado de datos y de programas
Pruebas en paralelo del antiguo y el nuevos sistema
140 de 418

Resumen
El software desarrollado y que se encuentra operativo, necesita ser adaptado a nuevas
condiciones, los errores deben ser corregidos
Un anlisis de impacto puede ayudar a determinar los riesgos relacionados con los
cambios
Las pruebas de mantenimiento aseguran que:
o Nuevas funcionalidades ha sido implementadas correctamente (nuevos casos de
uso)
o Errores han sido corregidos (antiguos casos de uso)
o La funcionalidad ya ha sido verificada y no fue afectada (pruebas de regresin)
o Si el software se retira, pruebas de migracin o pruebas en paralelo pueden ser
necesarias
141 de 418
III Tcnicas Estticas

Agenda
Captulo III Tcnicas Estticas
III/01 Tcnicas Estticas y el proceso de pruebas
III/02 Proceso de Revisin
III/03 Anlisis Esttico por Herramientas
142 de 418

01 Tcnicas Estticas y el proceso de pruebas
Enfoque Bsico
Las tcnicas estticas de pruebas comprenden varios mtodos que no ejecutan el
componente o sistema objeto de la prueba.
Las pruebas estticas incluyen:
o Revisiones (Actividad manual).
o Anlisis esttico (Actividad basada en herramientas).
Las tcnicas estticas complementan los mtodos dinmicos.
o Las pruebas estticas detectan defectos en lugar de fallos.
o Los conceptos tambin son analizados, no slo el cdigo ejecutable.
o Los defectos / desviaciones son detectados en una fase temprana, antes de que el
cdigo sea implementado
o Las pruebas estticas encuentran defectos que no son posibles de encontrar con las
pruebas dinmicas
Documentos de alta calidad conducen a productos de alta calidad.
o Incluso si una especificacin revisada no contiene ningn delecto, lo interpretacin
de la especificacin y creacin del diseo pueden ser defectuosas
143 de 418

Objetivos de las Revisiones
Las revisiones se realizan con el objeto mejorar la calidad del producto.
o Las revisiones se utilizan para verificar la correcta transicin de una fase a la
siguiente, segn est definido en el lado izquierdo del modelo-V.
La deteccin temprana de errores ahorra
costos.
En el transcurso de las revisiones se podran
detectar los siguientes defectos:
o Defectos en las especificaciones.
o Defectos en el diseo y arquitectura del
software.
o Defectos en las especificaciones de
interfaces.
o Insuficiencia de mantenibilidad (Cdigo
sin comentarios)
o Desviaciones con respecto a estndares
acordados
144 de 418

Ventajas y Desventajas de las Revisiones
Ventajas.
o Costos ms bajos y ahorro potencial relativamente alto.
o Defectos en la documentacin son delectados y corregidos tempranamente.
o Los documentos de alta calidad mejoran el proceso de desarrollo.
o Mejora el ndice de comunicacin / Intercambio de conocimiento (Know-how).
Desventajas.
o Se podran presentar situaciones de tensin por confrontaciones directas con el
autor.
o Los expertos involucrados en las revisiones deben adquirir conocimientos
especficos del producto. Es necesaria una buena preparacin.
o Inversin considerable de tiempo (del 10% al 15% del presupuesto total).
o Moderador y participantes influyen directamente en la calidad de la revisin.
145 de 418

Agenda
146 de 418

02 Proceso de Revisin
Introduccin
Las REVISIONES validan los productos derivados del desarrollo de software desde
diferentes perspectivas.
Las listas de verificacin pueden hacer el proceso de revisin ms eficiente.
Una lista de verificacin con problemas tpicos pueden ayudar a encontrar incidencias
(ISSUES) indetectables.
147 de 418

Actividades de una Revisin Formal /1
Planificacin
o Definicin de criterios de revisin (Listas de Chequeo, tipos de revisin)
o Seleccin de personal (Revisores, moderadores, etc.)
o Asignacin de roles y tiempos en el cronograma de proyecto (quien hace que)
Definicin de criterios de entrada y de salida para los tipos de revisin formal
o Definir que partes de los documentos se someten a revisin (depende de
importancia y complejidad)
KICK-OFF
o Distribucin de documentos
o Explicar los objetivos, procesos y documentos
Verificar los criterios de entrada (para ms tipos de revisin formal)
Preparacin individual
o Revisores inspeccionan objetos, toman notas de puntos/elementos a clarificar
Sealar posibles defectos, preguntas y comentarios
148 de 418

Actividades de una Revisin Formal /2
Reunin de revisin
o Reunin de todos los participantes de la revisin, revisores presentan sus resultados
o Discusin y registro con documentacin de resultados
o Se sealan defectos, se realizan recomendaciones para el manejo de defectos, se
toman decisiones acerca de los defectos.
Examinar, Evaluar, Registrar
o Se enva al grupo de revisin comunicaciones electrnicas lo acontecido en las
reuniones de seguimiento
REWORK
o Los autores corrigen los defectos encontrados por los revisores
o Se registran los estados actualizados de los defectos
Seguimiento (FOLLOW UP)
o Verificar que los defectos se han abordado
o Decidir si una segunda revisin es necesaria
Verificar criterios de salida para tipos de revisin formal.
o Se entrega el visto bueno al objeto de revisin
149 de 418

Roles y responsabilidades /1
Director - Responsable - Jefe de proyecto.
o Inicia la revisin, decide los participantes
o Asigna tiempos y recursos en el cronograma de proyecto
o Determina si los objetivos de la revisin se han cumplido
Moderador.
o Dirige la reunin/discusin, hace de mediador, concluye resultados.
o Planifica y ejecuta las revisiones, realiza seguimiento posterior
o De l depende el xito de la revisin
Autor.
o Principal responsable del objeto de revisin
o Expone su trabajo a la crtica, lleva a cabo los cambios recomendados.
150 de 418

Roles y responsabilidades /2
Revisor (Inspector, Evaluador).
o Individuos con un conocimiento especifico tcnico o del negocio
o Detecta defectos, desviaciones, reas problemticas, etc.
o Deben estar presentes en cualquier reunin de revisin
Escritor (Escriba, Escribano).
o Documenta todos los asuntos, problemas y puntos que hubieran sido identificados
durante las reuniones de revisin
151 de 418

Tipos de revisiones (IEEE 1028) /1
El proceso bsico de una revisin (como se esquematiza aqu) se aplica a las siguientes
variaciones de las revisiones (tipos de revisin):
o Inspeccin, Walklhrough, Revisin Tcnica, Revisin Informal.
Una diferencia adicional de las revisiones se presenta dependiendo de la naturaleza del
objeto, producto o proceso de la revisin.
o Proceso de desarrollo de Software o proceso del proyecto.
CMMI, IEC 12207 y TPI son trminos relacionados con la mejora de procesos
Tambin denominada revisin de gestin (management review). Estas
revisiones no Interfieren directamente en el proceso de pruebas, no forman
parte de este curso.
o Documentos / productos del proceso de desarrollo.
Estas son las revisiones tratadas en el presente curso.
152 de 418

Inspeccin: Caractersticas Relevantes.
o Los revisores inspeccionan el objeto en revisin usando listas de comprobacin
(verificacin) y mtricas.
o Un moderador capacitado (formacin especfica) e independiente dirige la revisin.
o La viabilidad de la revisin del objeto es valorada de forma previa a la revisin.
o Especifica criterios de entrada y de salida para aceptacin del producto de software
o Proceso formal basado en reglas y listas de comprobacin para las actividades de
preparacin, ejecucin, documentacin y seguimiento.
o Usualmente emplea examinacin por pares
o Requiere reuniones previas de preparacin
o El reporte de revisin incluye lista de resultados
153 de 418

Inspeccin: Ventajas y Desventajas.
o
o
o
o
Sesiones formales y organizadas con roles claramente definidos.

Requiere actividades Intensivas de preparacin y seguimiento.
Son necesarios el moderador y el escriba.
Propsito principal: Encontrar defectos utilizando un mtodo estructurado.
154 de 418

Walkthrough: Caractersticas Relevantes.
o
o
o
o
o
o
Opcionalmente puede haber una reunin previa de preparacin de los revisores.

Sesiones de inicio y finalizacin
Puede tomar la forma de escenarios, con examinacin por pares
La reunin es dirigida por el autor que explica el objeto en revisin.
No es necesario un moderador distinto (el autor modera).
A lo largo de la presentacin por parte del autor, los revisores tratan de localizar
desviaciones y/o reas que representen un problema.
o Ejemplos para el uso de Walkthroughs:
Walkthrough de documentos.
Walkthrough de un diseo preliminar de interfaz de usuario.
Walkthrough de un modelo de datos del proceso de negocio.
155 de 418

Walkthrough: Ventajas y Desventajas.
o Esfuerzo reducido en la preparacin de la sesin de revisin, pero es una sesin
cuyo resultado puede quedar abierto.
o Una sesin puede ser iniciada a travs de notificaciones realizadas con poca
antelacin.
o El autor tiene una gran influencia sobre el resultado: dado que l mismo modera la
revisin, hay un riesgo de dominacin por su parte (puntos crticos no abordados en
profundidad).
o Posibilidad limitada de control, dado que el autor tambin se encuentra a cargo de
cualquier actividad de seguimiento.
156 de 418

Revisin tcnica: Caractersticas relevantes /1
o La meta del examen es un aspecto tcnico del objeto en revisin: Es apto para el
uso?
o Son necesarios expertos, preferentemente externos con participacin opcional del
Director
o Puede ser ejecutada como revisin por pares sin la participacin del Director
o Idealmente dirigida por un moderador capacitado que no sea el autor.
157 de 418

Revisin tcnica: Caractersticas relevantes /2
o
o
o
o
o
La reunin puede tener lugar sin la presencia del autor.

Requiere reuniones previas de preparacin por parte de los revisores
Usa listas de verificacin para no olvidar cosas importantes
Un panel de expertos presenta sus recomendaciones con carcter unnime.
Preparacin de un reporte de revisin que incluye lista de hallazgos y el veredicto
acerca de si el producto de software cumple los requerimientos
o La revisin tcnica puede ser formal o informal de pendiendo de su importancia
158 de 418

Revisin tcnica: Objetivos principales.
o
o
o
o
o
o
Discusiones durante las revisiones

Toma de decisiones
Evaluacin de alternativas
Encontrar defectos
Resolver problemas tcnicos
Verificar conformidad con : estndares, planeacin, especificaciones y regulaciones
159 de 418

Revisiones informales: Caractersticas relevantes.
o
o
o
o
o
o
Es lo forma de revisin ms simple.

Frecuentemente Iniciada por el autor.
Solamente estarn involucrados los evaluadores (uno o ms).
No es necesaria ninguna reunin.
Los resultados pueden ser registrados en forma de una lista de accin
Frecuentemente desarrolladas o travs de la solicitud de revisin de un documento
o un compaero de trabajo.
o Tambin denominada: revisin por pares (peer review).
160 de 418

Revisiones informales: ventajas y desventajas.
o Fcil de ejecutar, incluso en los casos de notificaciones realizadas con poca
antelacin.
o Rentable.
o No requiere protocolo.
161 de 418

Factores de xito de una revisin /1
Las revisiones se deben desarrollar orientadas al logro de objetivos. Las desviaciones en el
objeto revisado deben ser establecidas de forma Imparcial.
El autor del objeto revisado deber ser motivado de una forma positiva para la revisin
("su documento ser an mejor" en lugar de "su documento es de baja calidad").
Uso sistemtico (entre otras) de las tcnicas y plantillas.
El uso de listas de verificacin mejorar la eficiencia de la revisin.
Para la ejecucin apropiada de las revisiones ser necesario un presupuesto suficiente
(10% al 15% del costo total del desarrollo).
Hacer uso de las lecciones aprendidas, utilizar la retroalimentacin para implementar un
proceso de mejora continua.
Los directores de proyecto pueden dar soporte para realizar un buen proceso de revisin
162 de 418

Factores de xito de una revisin /2
Las revisiones deben ser desarrolladas en un ambiente de confianza.
Los resultados no deben ser usados para evaluar a los participantes.
Los testers o probadores realizan las principales contribuciones al proceso de revisin y
aprenden del producto para poder realizar la preparacin de pruebas tempranas.
Para cumplir los objetivos de las revisiones deben estar involucradas las personas
correctas.
Hay un nfasis en el aprendizaje y en el proceso de mejoras
163 de 418

Resumen
En el transcurso de las pruebas estticas no se ejecuta el objeto de prueba.
Las revisiones pueden tener lugar en fases tempranas del proceso de desarrollo, ellas
complementan/extienden los mtodos de pruebas dinmicas.
Fases de una revisin:
o Planificacin - preparacin - preparacin individual - reunin - rework - seguimiento.
Roles y tareas para una revisin:
o Director - moderador - autor - evaluador - escriba.
Tipos de revisiones:
o Inspeccin - walklhrough - revisin tcnica - revisin informal.
164 de 418

Agenda
165 de 418

03 Anlisis Esttico por Herramientas
Terminologa y definiciones
Anlisis esttico (Definicin):
Es aquella actividad que consiste en el anlisis de un objeto de prueba. Por ejemplo
cdigo fuente, guin (script), requisito) llevado a cabo sin ejecutar el producto software.
Posibles aspectos o ser comprobados con anlisis esttico:
o Reglas y estndares de programacin.
o Diseo de un programa (anlisis del flujo de control).
o Uso de datos (anlisis del flujo de datos).
o Complejidad en la estructura del programa. (Mtricas, por ejemplo nmero
ciclomtico)
166 de 418

Aspectos generales /1
Todos los objetos de prueba deben tener una estructura formal.
o Esto es especialmente importante cuando se utilizan herramientas de pruebas.
o Con mucha frecuencia no se generan documentos formalmente.
o En la prctica, lenguajes de modelado, programacin y de guin (scripting) cumplen
con la regla, de la misma forma que algunos diagramas.
El anlisis esttico de un programa mediante el uso de herramientas se desarrolla con un
menor esfuerzo que el necesario en una revisin.
o Frecuentemente el anlisis esttico se ejecuta antes de que tenga lugar una
revisin.
Para encontrar un error lgico (potenciales loops infinitos)
Para descubrir construcciones complicadas, vulnerabilidades de seguridad,
interfaces inconsistentes, etc.
167 de 418

El valor del anlisis esttico es la prevencin de defectos

Encontrar defectos tempranamente antes de la ejecucin de pruebas
Advertir de aspectos sospechosos en el cdigo
Detectar discrepancias en el diseo y para el clculo de medidas de alta complejidad
Detectar inconsistencias y dependencias
Verificar la mantenibilidad del diseo del cdigo
Estos defectos no son fciles de detectar con pruebas dinmicas
168 de 418

Herramientas como compiladores y herramientas de anlisis (analizador) pueden ser usadas
Compilador:
o Detecta errores de sintaxis en el cdigo fuente de un programa.
o Crea datos de referencia en el programa. Por ejemplo lista de referencias cruzadas,
llamada Jerrquica, tabla de smbolos.
o Comprueba la consistencia entre los tipos de variables.
o Encuentra variables no declaradas y cdigo Inaccesible (cdigo muerto).
Analizador, trata aspectos adicionales tales como:
o Convenciones y estndares.
o Mtricas de complejidad.
o Acoplamiento de objetos
169 de 418

Anlisis del flujo de control /1
Propsito.
o del cdigo (ramas muertas, cdigo muerto, etc.).
Mtodo.
o La estructuro del cdigo se representa como un
diagrama de control de flujo.
o Grafo dirigido.
Los nodos representan sentencias o
secuencias de sentencias.
Las aristas representan la transferencia del
flujo de control, como decisiones y bucles.
Construccin mediante herramientas.
170 de 418

Anlisis del flujo de control /2
Resultados.
o Mayor visin y comprensin del cdigo del
programa.
o Las anomalas pueden ser fcilmente
detectadas, los defectos se hacen evidentes.
Salida de un Bucles por un salto.
Ramas muertas.
Retornos mltiples.
171 de 418

Anlisis del flujo de datos /1
Propsito.
Deteccin de anomalas en el flujo de datos con la ayuda de los diagramas de control de
flujo y conjeturas racionales con respecto de las secuencias del flujo de datos.
Beneficios.
Deteccin fiable de anomalas en el flujo de datos. Se puede detectar fcilmente la
localizacin exacta de defectos. Es un buen complemento para otros mtodos de
pruebas.
Desventajas.
Limitado a un rango reducido de tipos de defectos.
172 de 418

Mtodo.
Una variable x puede tener los siguientes estados a lo largo del la ejecucin de un
programa:
o x se encuentra indefinida (u): no ha sido asignado valor alguno a la variable x.
o x se encuentra definida (d): ha sido asignado un valor a x. Por ejemplo x = 1.
o x est referenciada (r): ha sido tomada una referencia, el valor de x no cambia. Por
ejemplo x > 0, a = b + x.
o x no ha sido utilizada (e): x no ha sido referenciada (ni en lectura ni en escritura).
El flujo de datos de una variable puede ser expresado como una secuencia de estados: d,
u, y r. Por ejemplo x u d r d r r u
Si una de estas secuencias contiene una sub-secuencia que no tiene sentido, entonces ha
tenido lugar una anomala en el flujo de datos.
o Anomala ur: Valores indefinidos han sido referenciados
o Anomala du: Definicin de un valor y luego es indefinido antes de lectura
o Anomala dd: Definicin de un valor y se define nuevamente antes de lectura
173 de 418

Ejemplo de anomala en el flujo de datos
Para este ejemplo, los valores
de
dos
variables
son
intercambiados a travs de una
variable auxiliar, si no estn
ordenados por valor.
void MinMax (int Min, int Max)
{
int Help;
if (Min>Max)
{
Max = Help;
Max = Min;
Help = Min;
}
End MinMax;
El anlisis de flujo de datos muestra:

La Variable Help se encuentra
indefinida (undefined) cuando es
referenciada: Anomala ur.
La variable Max se define dos
veces sin ninguna referencia entre
ambas definiciones: Anomala dd.
El valor definido para la variable
Help se vuelve indefinido al final
del programa sin referencia:
Anomala du.
El
ejemplo
puede
fcilmente corregido.
ser
void MinMax (int Min, int Max)

{
int Help;
if (Min>Max)
{
Help = Max;
Max = Min;
Min = Help;
}
End MinMax;
174 de 418

Las mtricas y su clculo
Ciertos aspectos de la calidad de un programa pueden ser medidos utilizando mtricas.
o Lo mtrica slo tiene relevancia para el aspecto medido (considerado).
Lo complejidad esttica de un programa puede ser medida.
o Actualmente hay aproximadamente 100 mtricas diferentes disponibles.
Mtricos diferentes tratan aspectos diferentes de lo complejidad de programa.
o Tamao del programa. Por ejemplo lneas de cdigo.
o Estructuras de control del programa. Por ejemplo nmero ciclomtico.
o Estructuras de control de datos. Por ejemplo mtrica de Halstead
Es difcil comparar dos mtricas diferentes, incluso cuando ambas abordan el mismo
atributo del programa!
175 de 418

Las mtricas y su implicacin /1
Nmero Ciclomtico: v(G) = e n + 2p
Mtrica que mide la complejidad esttica de un programa
basada en su grafo de flujo de control.
Mide los caminos linealmente independientes, como ndice
de la testabilidad y mantenibilidad.
El nmero ciclomtico se define de la siguiente forma:
o Nmero de aristas: e.
o Nmero de nodos: n.
o Nmero de partes del programa Independientes
Inspeccionadas: p (normalmente 1).
Valores hasta 10 son aceptables. Para valores superiores el
cdigo debe ser mejorado (reworked - buena prctica
segn McCabe).
176 de 418

Ejemplo Nmero Ciclomtico.
El grafo de la derecha tiene:
1 Partes independientes: p = 1
15 Nodos:
n = 15
20 Aristas:
e = 20
v(G) = e n + 2p
v(G) = 7
177 de 418

Nmero ciclomtico (por McCabe) - implicacin.
El nmero ciclomtico puede ser utilizado como un valor objetivo para una revisin de
cdigo.
El nmero ciclomtico tambin puede ser calculado como el nmero de decisiones
independientes ms uno. Si las dos formas de clculo aportan resultados diferentes se
puede deber a:
o Ramas superfluas
o Ramas faltantes.
El nmero ciclomtico tambin aporta un ndice del nmero de casos de prueba
necesarios para alcanzar cobertura de decisin.
178 de 418

Resumen
Anlisis Esttico.
o Con el uso de herramientas para la realizacin de anlisis esttico (compiladores,
analizadores) el cdigo del programa puede ser objeto de Inspeccin sin ser
ejecutado.
o Con el uso de herramientas se puede realizar el anlisis esttico de un programa con
un esfuerzo menor que el necesario para una Inspeccin.
Resultado del Anlisis.
o El diagrama de control de flujo presenta el flujo del programa y permite la deteccin
de ramas muertas y cdigo inalcanzable.
o Las anomalas en los datos se detectan utilizando el anlisis del flujo de datos.
o Las mtricas pueden ser utilizadas para evaluar la complejidad estructural
conduciendo o uno estimacin del esfuerzo en pruebas esperado.
179 de 418
IV Tcnicas de Diseo de Pruebas

Agenda
Captulo IV Tcnicas de Diseo de Pruebas
IV/01 Pruebas en el proceso de desarrollo

IV/02 Categoras de las tcnicas de diseo de pruebas.
IV/03 Tcnicas de caja negra (black box) o basadas en la especificacin.
IV/04 Tcnicas de caja blanca (white box) o basadas en la estructura.
IV/05 Tcnicas basadas en la experiencia.
IV/06 Seleccin de las tcnicas de pruebas.
180 de 418

01 Pruebas en el proceso de desarrollo
Obtencin de casos de prueba a partir de requisitos
El diseo de casos de prueba debe ser un proceso controlado.
Los casos de prueba pueden ser creados formal o informalmente, dependiendo de las
caractersticas del proyecto y la madurez del proceso en uso.
Escenarios de Pruebas
objeto de
pruebas y
requisitos sobre
el objeto de
pruebas
Definicin de
los requisitos
de las pruebas
y criterios de
prueba
Caso de
Prueba 1
Caso de
Prueba 1
Caso de
Prueba 1
Caso de
Prueba 1
Caso de
Prueba 1
Caso
de
Caso
de
Caso
Prueba
1de
Prueba
Prueba14
Caso
de
Caso
de
Caso
Prueba
1de
Prueba
Prueba11
181 de 418

Trazabilidad
Las pruebas deben ser trazables: Qu casos de prueba han sido incluidos en el catlogo de
pruebas, basados en qu requisitos?
Las consecuencias de los cambios en los requerimientos sobre las pruebas a realizar se pueden
identificar directamente
La trazabilidad tambin ayuda a determinar la cobertura de requisitos.
Escenarios de Pruebas
objeto de
pruebas y
requisitos sobre
el objeto de
pruebas
Definicin de
los requisitos
de las pruebas
y criterios de
prueba
Caso de
Prueba 1
Caso de
Prueba 1
Caso de
Prueba 1
Caso de
Prueba 1
Caso de
Prueba 1
Caso
de
Caso
Casode
Prueba
1de
Prueba
Prueba14
Caso
de
Caso
Casode
Prueba
1de
Prueba
Prueba11
182 de 418

Definiciones
Objeto de pruebas (test object):
o El elemento o ser revisado: un documento o una pieza de software en el proceso de
desarrollo de software.
Condicin de la prueba (test condition):
o Un elemento o evento: una funcin, una transaccin, un criterio de calidad o un
elemento en el sistema.
Criterios de prueba (test criteria):
o El objeto de prueba debe cumplir los criterios de prueba con el objeto de superar la
prueba.
Cronograma de ejecucin de pruebas (test execution schedule):
o Un cronograma para la ejecucin de los procedimientos de pruebas Los
procedimientos son incluidos en el cronograma de ejecucin de pruebas en su
contexto y en el orden que debe ser ejecutado.
183 de 418

Descripcin de un caso de prueba segn el estndar IEEE 829:
Identificador nico (distinguible) (distinct identification): identificador o cdigo nico del
caso de prueba.
Precondiciones (preconditions): situacin previa a la ejecucin de pruebas o
caractersticas de un objeto de pruebas antes de llevar a la prctica (ejecucin) un caso de
prueba.
Valores de entrada (Input values): descripcin de los datos de entrada de un objeto de
pruebas.
Resultados esperados (expected results): datos de salida que se espera produzca un
objeto de pruebas
Poscondiciones (post conditions): caractersticas de un objeto de pruebas tras la
ejecucin de pruebas, descripcin de su situacin tras la ejecucin de las pruebas.
Dependencias (dependencies): orden de ejecucin de casos de prueba, razn de las
dependencias.
Requisitos (requirements): caractersticas del objeto de pruebas que el caso de prueba
debe evaluar.
184 de 418

Combinacin de casos de prueba
Los casos de prueba se pueden combinar en set de pruebas (juegos de pruebas - test
suites) y escenarios de pruebas.
Una especificacin de procedimiento de prueba, define Ia secuencia de acciones para la
ejecucin de un caso de prueba Individual o un set de pruebas. Es un guin o esquema de
pruebas describiendo los pasos, el tratamiento y/o las actividades necesarias para la
ejecucin de pruebas.
Los juegos de prueba pueden ser codificados y ejecutados de forma automtica con el
uso de herramientas adecuadas.
El plan de pruebas (test plan), establece la secuencia de los pruebas planificadas, quien
debe ejecutarlas y cundo. Las restricciones a considerar son las prioridades, la
disponibilidad de recursos, la infraestructura de pruebas, etc.
185 de 418

Resumen
Los casos de prueba y los set de pruebas (juegos de pruebas - test suites) son obtenidos a
partir de los requisitos o caractersticas de los objetos de pruebas.
Componentes de la descripcin de un caso de prueba:
o Cdigo / identificador nico.
o Precondiciones (pre-conditions).
o Valores de entrada (Input values).
o Resultados esperados (expected results).
o Poscondiciones (post-conditions).
o Dependencias (dependencies).
o Requisitos a partir de los cuales se ha obtenido el caso de prueba.
186 de 418

Agenda

187 de 418

02 Categoras de las tcnicas de diseo de pruebas
Pruebas de caja negra (black box) y caja blanca (white box)
Las pruebas dinmicas se dividen en categoras / grupos:
La agrupacin se realiza en funcin del
carcter bsico del mtodo utilizado para
obtener los casos de prueba.
Cada grupo tiene sus propios mtodos
para disear casos de prueba.
188 de 418

Tcnicas de caja negra (black box) o basadas en la especificacin
El probador observa el objeto de prueba como una caja negra.
o La estructura Interna del objeto de prueba es irrelevante o desconocida.
Los casos de prueba se obtienen a partir del anlisis de la especificacin (funcional y no
funcional) de un componente o sistema.
o Prueba del comportamiento entrada / salida (input / output).
La funcionalidad es el foco de atencin
o La tcnica de caja negra tambin se denomina prueba funcional o prueba orientada
a la especificacin.
189 de 418

Tcnicas de caja blanca (white box) o basadas en la estructura
El probador conoce la estructura Interna del programa / cdigo.
o Por ejemplo jerarqua de los componentes, flujo de control, flujo de datos, etc.
Los casos de prueba son seleccionados en base a la estructura interna del programa /
cdigo.
o A lo largo de las pruebas es posible que se interfiera con la ejecucin de las pruebas.
La estructura del programa es el foco de atencin
o La tcnica de caja blanca tambin es conocida como prueba estructural o pruebas
basados en el flujo de control.
190 de 418

Categoras de las tcnicas de diseo de pruebas - visin general
Mtodos basados en la especificacin.
o El objeto de prueba ha sido seleccionado de acuerdo con el modelo funcional de
software.
o La cobertura de la especificacin puede ser medida (por ejemplo, el porcentaje de la
especificacin cubierta por casos de prueba).
Mtodos basados en la estructura.
o La estructura Interna del objeto de prueba es utilizada para disear los casos de
prueba (cdigo/sentencias. mens, llamados, etc.).
o El porcentaje de cobertura es medido y utilizado como fuente para la creacin de
casos de prueba adicionales.
Mtodos basados en la experiencia.
o El conocimiento y experiencia respecto de los objetos de prueba y su entorno son
las fuentes para el diseo de casos de prueba.
o El conocimiento y experiencia respecto de posibles puntos dbiles, posibles errores
y errores previos son utilizados para determinar / definir casos de prueba.
191 de 418

Resumen
Los casos de prueba pueden ser diseados utilizando diferentes mtodos.
o Si la funcionalidad especificada es el objetivo de las pruebas, los mtodos utilizados
se denominan mtodos basados en la especificacin o mtodos de caja negra (black
box).
o SI la estructura interna de un objeto es Investigada, los mtodos utilizados se
denominan mtodos basados en la estructura o mtodos de caja blanca (white box).
o Los mtodos basados en la experiencia utilizan el conocimiento y la habilidad del
personal involucrado en el diseo de casos de prueba.
192 de 418

Agenda

193 de 418

03 Tcnicas de caja negra (black box) o basadas en la especificacin
Tcnicas de caja negra (black box) o basadas en la especificacin - Visin general
En el presente apartado s explicarn en detalle los siguientes mtodos de caja negra:
o Particin de equivalencias o clases de equivalencia.
o Anlisis de valores lmite.
o Tablas de decisin y grficos causa y efecto.
o Pruebas de transicin de estado.
o Pruebas de caso de uso.
Estos son los mtodos ms importantes y conocidos.
Otros mtodos de caja negra son:
o Pruebas estadsticas.
o Pruebas duales (algoritmo dual - pairwise).
o Pruebas de humo.
194 de 418

General
Las pruebas funcionales estn dirigidas a verificar la correccin y la completitud de una
funcin.
o Estn disponibles en el mdulo todas las funciones especificadas?
o Las funciones ejecutadas presentan resultados correctos?
La ejecucin de casos de prueba debe tener una baja redundancia, sin embargo debe ser
integral.
Probar lo menos posible, probar tanto como sea necesario.
195 de 418

Tcnicas de caja negra (black box)
Particin de equivalencias o clases de equivalencia.

Anlisis de valores lmite.
Tablas de decisin y grficos causa y efecto.
Pruebas de transicin de estado.
Pruebas de caso de uso.
196 de 418

Particin de equivalencia
La particin en clases de equivalencia es lo que la mayora de los probadores hacen de
forma Intuitiva. Dividen los posibles valores en clases, mediante lo cual observan.
o Valores de entrada (Input vales) de un programa (uso habitual del mtodo CE).
o Valores de salida (output vales) de un programa (uso poco habitual del mtodo CE)
El rango de valores definido se agrupa en clases de equivalencia para las cuales se aplican
las siguientes reglas:
o Todos los valores para los cuales se espera que el programa tenga un
comportamiento comn se agrupan en una clase de equivalencia (CE)
o Las clases de equivalencia pueden no superponerse y pueden no presentar ningn
salto (discontinuidad)
o Las clases de equivalencia pueden consistir en un rango de valores (por ejemplo
0<x<10) o un valor aislado (por ejemplo x=Verdadero).
197 de 418

Particin de equivalencia Vlida e Invlida
Las clases de equivalencia de cada variable (elemento) se puede dividir en:
o CE Vlida: Todos los valores que estn definidos en un rango combinado en una
clase de equivalencia, si estos son manejados idnticamente por el objeto de
pruebas
o CE Invlida: Se distinguen dos casos para valores por fuera del rango definido:
Valores con un formato correcto pero por fuera del rango que puede ser
combinado en una o ms CE
Valores con un formato incorrecto son generalmente definidos en una CE
separada
Las pruebas se ejecutan utilizando un nico representante de cada CE
o Para todo otro valor perteneciente a la CE se espera el mismo comportamiento que
para el valor seleccionado
198 de 418

Particin de equivalencia Ejemplo
Las clases de equivalencia se escogen para entradas (inputs) vlidas e invlidas.
o Si el valor x se define como 0 < x < 10. entonces, inicialmente se pueden identificar
tres clases de equivalencia:
x<0
(valores de entrada no vlidos)
0 x 100
(valores de entrada vlidos)
x >100
(valores de entrada no vlidos)
o Se pueden definir CE adicionales, contenidas pero no limitadas a:

Entradas no numricas
Nmeros muy grandes o muy pequeos.
Formatos numricos no admitidos
199 de 418

Particin de equivalencia Variables de entrada
Todas las variables de entradas (input variables) del objeto de prueba son identificadas,
por ejemplo:
o Campos de una Interfaz Grfica de Usuario (GUI)
o Parmetros d una funcin.
Se define un rango para cada valor de entrada (input).
o Este rango define la suma del todas las clases de equivalencia vlidas (CEv).
o Las clases de equivalencia Invlidas (CEi) contienen los valores que no pertenecen al
rango.
o Aquellos valores que deben ser tratados de una forma diferente (conocidos o
sospechosos) son asignados a una clase de equivalencia aparte.
200 de 418

Particin de equivalencia Ejemplo Porcentajes /1
Un programa espera el valor expresado en porcentaje de acuerdo a los siguientes
requerimientos:
o Solo enteros son permitidos
o 0 es el valor inferior vlido lmite del rango
o 100 es el valor superior lmite del rango
Vlidos son: todos los nmeros entre 0 y 100.
Invlidos son: todos los nmeros negativos, los mayores a 100, nmeros decimales y
valores no numricos.
o Una clase de equivalencia vlida
(CEv)
0 x 100
o Primera clase de equivalencia invlida
(CEi)
x<0
o Segunda clase de equivalencia invlida
(CEi)
x > 100
o Tercera clase de equivalencia invlida
(CEi)
x = no entero
o Cuarta clase de equivalencia invlida
(CEi)
x = no numrico
201 de 418

El valor del porcentaje ahora se mostrar en un diagrama de barras. Los siguientes son
requerimientos adicionales (los valores se incluyen en los rangos de cada CE)
o Valores entre 0 y 15
barra gris
barra verde
barra amarilla
barra naranja
Ahora son cuatro en lugar de una las clases de equivalencia vlidas (CEv)
o Primera clase de equivalencia vlida
(CEv)
0 x 15
o Segunda clase de equivalencia vlida
(CEv)
16 x 50
o Tercera clase de equivalencia vlida
(CEv)
51 x 85
o Cuarta clase de equivalencia vlida
(CEv)
86 x 100
202 de 418

Eleccin de nmeros representativos de cada CE
o Se determina un representante de cada CE y se define el resultado esperado para
este.
Variable
Clase de equivalencia
CE1:
0 x 15
CE2:
16 x 50
Valor de porcentaje VLIDO
CE3:
51 x 85
CE4: 86 x 100
CE5:
x<0
CE6:
x >100
Valor de porcentaje INVLIDO
CE7: x = no entero
CE8: x = no numrico
Representativo
+10
+20
+80
+90
-10
+200
+1,5
A
203 de 418

Particin de equivalencia Ejemplo Tienda de Computadores /1
Anlisis de la especificacin
o Parte del cdigo de un programa trata el precio final de un artculo en base a su
precio de venta al pblico, un descuento en % y el costo del envo (6,9 o 12 Euros,
dependiendo del tipo de envo).
Suposiciones
El precio de venta de un
artculo esta dado por un nmero
con dos decimales
El descuento es el valor
porcentual sin decimales entre 0%
y 100%
El precio del envo puede ser
6, 9 o 12
204 de 418

Casos de prueba para CE vlidas
o Las clases de equivalencia vlidas aportan las siguientes combinaciones o casos de
prueba: T01. T02 y T03.
205 de 418

Casos de prueba para CE invlidas
o Los siguientes casos de prueba han sido generados utilizando CE no vlidas, cada
una en combinacin con CE vlidas de otros elementos:
206 de 418

Todos los casos de pruebas
o Se obtienen 10 casos de prueba: 3 casos de prueba positivos (valores vlidos) y 7
casos de prueba negativos (valores no vlidos).
207 de 418

Particin de equivalencia Basada en la salida (output based)
Las clases de equivalencia tambin pueden ser generadas a partir de los valores de salida
esperados.
o El mtodo utilizado es anlogo al anterior, aplicando los valores de salida.
o La variable (elemento) es entonces la salida (output), por ejemplo, el valor de un
campo en la Interfaz Grfica de usuario GUI").
o Las clases de equivalencia son generadas para todos los posibles valores de la salida
definidos.
o Se determina un representante para cada clase de equivalencia de los valores de
salida.
Entonces, el valor de entrada, que conduce al valor representante es
obtenido/identificado. Mayores costos y esfuerzo dado que los valores de entrada deben
ser obtenidos para una salida determinada de forma recursiva.
208 de 418

Particin de equivalencia En general /1
Particin.
o La calidad de la prueba depende de la segmentacin precisa de variables/elementos
en clases de equivalencia.
o Las CE que no hubieran sido Identificadas presentan el riesgo de posibles omisiones,
dado que los representantes utilizados no cubren todas las posibilidades.
Casos de prueba.
o El mtodo de la clase de equivalencia aporta casos de prueba para los cuales aun
debe ser seleccionado un representante.
o Las combinaciones de datos de prueba son seleccionadas definiendo el o los
representantes de cada clase de equivalencia.
209 de 418

Particin de equivalencia En general /2
Seleccin de representantes.
o Cada valor perteneciente a la CE puede ser un representante. Los ptimos son:
Valores caractersticos (valores tpicos o utilizados con frecuencia).
Valores problemticos (valores que se sospecha pueden producir fallos)
Valores lmite (valores en la frontera de la CE).
o Durante la creacin de casos de prueba, los representantes de cada CE invlidos
deben combinarse siempre con los mismos valores de otros CE vlidos
(combinaciones estndar).
o Dado el posible enmascaramiento de errores, se debe evitar las combinaciones de
representantes de CE invlidas con representantes de otras CE invlidas en un
mismo caso de prueba.
o La seleccin de representantes implica que la funcin implementada por el
programa/sistema utiliza comparadores.
210 de 418

Particin de equivalencia Cobertura
La cobertura de clases de equivalencia puede ser utilizada como criterio de salida para
finalizar las actividades del proceso de pruebas.
(
211 de 418

Particin de equivalencia Transicin
La transicin de la especificacin o definicin de la funcionalidad para la creacin de la
clase de equivalencia.
o Con frecuencia es una tarea difcil debido a la carencia de documentacin precisa y
completa.
o Los lmites no definidos o las descripciones faltantes hacen difcil la definicin de las
clases de equivalencia.
o Con frecuencia, es necesario mantener contacto con el cliente con el objeto de
completar la informacin.
212 de 418

Particin de equivalencia Beneficios
Mtodo sistemtico para el diseo de casos de prueba, por ejemplo, con una mnima
cantidad de casos de prueba se puede esperar un valor de cobertura especfico.
La particin del rango de valores en clases de equivalencia a partir de las especificaciones
cubre los requisitos funcionales.
La asignacin de prioridades a la clases de equivalencia puede ser utilizada para la
asignacin de prioridades a los casos de prueba (los valores de entrada utilizados con
poca frecuencia deben ser los ltimos en ser probados).
Las pruebas de las excepciones conocidas est cubierta por los casos de prueba de las
clases de equivalencia negativas.
La particin de equivalencias es aplicable en todos los niveles de pruebas.
La particin de equivalencias puede ser usada para lograr la cobertura de los objetivos de
entrada y salida.
Puede ser aplicado por entradas manuales usando las interfaces grficas de usuario (GUI)
o por las interfaces de parmetros en las pruebas de integracin.
213 de 418


214 de 418

Anlisis de valores lmite Generalidades /1
El anlisis de valores lmite ampla la tcnica de particin en clases de equivalencia
introduciendo una regla para seleccionar a los representantes.
Los valores frontera (valores lmite) de la clase de equivalencia deben ser probados de
forma intensiva.
Porqu prestar ms atencin a los lmites?
o Frecuentemente los lmites del rango de valores no estn bien definidos o conducen
a distintos interpretaciones.
o Comprobar si los limites han sido implementados (programados) correctamente
Importante:
o La experiencia demuestra que con mucha frecuencia, los errores tienen lugar en los
lmites del rango de valores.
El anlisis de valores lmite puede ser aplicado en todos los niveles de prueba. Es fcil de aplicar
y tiene una alta capacidad de encontrar defectos basndose en el detalle de las
especificaciones.
215 de 418

Anlisis de valores lmite Generalidades /1
El anlisis de valores lmite supone que:
o La clase de equivalencia est compuesta de un rango continuo de valores (no por un
valor Individual o un conjunto de valores discretos).
o Se pueden definir los lmites para el rango de valores.
Por ser una extensin a la particin en clases de equivalencia el anlisis de valores lmite
es un mtodo que sugiere la seleccin de representantes.
o Particin en clases de equivalencia:
Evala un valor tpico de lo clase de equivalencia
o Anlisis de valores lmite:
Evalo los valores lmite (frontera) y su entorno.
Se utiliza el siguiente esquema:
216 de 418

Anlisis de valores lmite - Definicin de valores lmite
El esquema bsico slo puede ser aplicado cuando el rango de valores ha sido definido de
conformidad con el mismo esquema.
o En este caso no son necesarias pruebas adicionales para un valor intermedio del
rango de valores.
SI un CE est definido como un nico valor numrico, por ejemplo x = 5, los valores
correspondientes al entorno tambin sern utilizados.
o Los representantes (de la clase y su entorno) son: 4 - 5 - 6.
217 de 418

Anlisis de valores lmite - CE no vlidas
Los valores lmite para clases de equivalencia no vlidas tienen poco sentido.
o Los representantes de una CE no vlido en la frontera de una CE vlida ya se
encuentran cubiertas a travs del esquema bsico.
Para rangos de valores definidos como un conjunto de valores, en general, no es posible
definir los valores lmite.
o Por ejemplo: Soltero, casado, divorciado, viudo.
218 de 418

Anlisis de valores lmite Ejemplo rango de descuento 1
El rango de valores para un descuento est definido entre: 0,00 % x 100,00%
Definicin de CE
3 clases:
o CE: x < 0,99
o CE: 0,00 x 100,00
o CE: x > 100,01
Extiende los representantes a:
o CE: | -0,99 | 0,00 | 0,01 | 99,99 | 100,00 | 100,01 |
Nota importante:
En lugar de un representante para la CE vlida, ahora hay seis representantes (cuatro
vlidos y dos no vlidos).
219 de 418

Anlisis de valores lmite Ejemplo rango de descuento 2
Esquema bsico: seleccionar tres valores con el objeto de ser probados - el valor lmite
exacto y dos valores pertenecientes al entorno (dentro y fuera de la CE).
Punto de vista alternativo: dado que el valor lmite pertenece a la CE, solo son necesarios
dos valores para las pruebas, uno perteneciente a la CE y otro no perteneciente a la CE.
El rango de valores para un descuento est definido entre: 0,00 % x 100,00%
o CE vlida: 0,00 x 100,00
o Anlisis de valores lmite:
Los representantes adicionales son:
| -0,99 | 0,00 | 0,01 | 99,99 | 100,00 | 100,01 |
0,01 tiene el mismo comportamiento que 0,00
99,99 tiene el mismo comportamiento que 100,00
Un error de programacin causado por un operador de comparacin errneo ser
detectado con los dos valores lmite (frontera).
220 de 418


221 de 418

Tablas de decisin y grficos causa y efecto Definicin /1
La particin en clases de equivalencia y el anlisis de valores lmite tratan entradas en
condiciones aisladas.
Sin embargo, una condicin de entrada puede tener efectos slo en combinacin con
otras condiciones de entrada.
Todos los mtodos descritos previamente no tienen en cuenta el efecto de dependencias
y combinaciones.
El uso del conjunto completo de las combinaciones de todas las clases de equivalencia de
entrada, conduce normalmente a un nmero muy alto de casos de prueba (explosin de
casos de prueba).
Con la ayudad de diagramas causa y efecto y tablas de decisiones, se puede determinar la
cantidad de combinaciones posibles y se pueden reducir de forma sistemtica a un
subconjunto.
222 de 418

Tablas de decisin y grficos causa y efecto Definicin /2
El diagrama causa y efecto utiliza un lenguaje formal.
El diagrama causa y efecto se genera traduciendo la especificacin (normalmente informal) de
un objeto de prueba a un lenguaje formal.
El objeto de prueba est sometido a una determinada cantidad de efectos que se remontan a
sus respectivas causas.
223 de 418

Tablas de decisin y grficos causa y efecto Smbolos
Nombre
aseveracin (assertion)
negacin (negation)
Definicin
Si causa A, entonces efecto E.
Si causa A, entonces no efecto E
Smbolo
A
o (or)
Si causa A o B, entonces efecto E
y (and)
Si causa A y B, entonces efecto E
exclusivo (exclusive)
o causa A, o causa B
Ex
inclusivo (inclusive)
Por lo menos una de las 2 causas, A o B
uno y solo uno (one and only one)
Una y exactamente una de las 2 causas, A o B
B
A
B
A
B
A
B
A
B
A
requerido (required)
Si causa A entonces causa B
224 de 418

Tablas de decisin y grficos causa y efecto Ejemplo Banca Online /1
El usuario se Identifica a travs de su nmero de cuenta y PIN. Si tiene suficiente cobertura
podr realizar una transferencia. Para poder realizar la transferencia debe introducir los datos
del receptor y un TAN (Nmero de Autenticacin de Transferencia) vlido.
Cobertura
Receptor
correcto
TAN
Vlido
~
~
~
Realizar
Transferencia
TAN identificado
como utilizado
Denegar
Transferencia
Solicitar TAN
nuevamente
225 de 418

Tablas de decisin y grficos causa y efecto Ejemplo Banca Online /2
Tabla de decisin
Causa
Efecto
Descripcin
T01
T02
T03
T04
T05
Suficiente cobertura
Receptor correcto
TAN vlido
Realizar Transferencia
Marcar TAN como utilizado
Denegar transferencia
Solicitar TAN nuevamente
S
S
S
S
S
No
No
No
No
No
S
No
No
No
No
S
No
No
No
No
No
S
Cada columna de la tabla representa un caso de prueba.

Construccin de la tabla de decisin:
o Seleccionar un efecto.
o Regresar al diagrama para identificar las causas.
o Cada combinacin de causas est representada por una columna en la tabla de decisin (un caso
de prueba).
o Combinaciones de causas idnticas que conducen a efectos distintos, se pueden fusionar para
formar un nico caso de prueba.
226 de 418

Tablas de decisin y grficos causa y efecto Uso Prctico
La especificacin est dividida en partes fciles de gestionar, por lo que conlleva a una
tabla de decisin con un tamao prctico.
Es difcil deducir valores lmite a partir del diagrama causa y efecto o de la tabla de
decisin.
Es recomendable combinar casos de prueba obtenidos a partir de tablas de decisin con
los obtenidos a partir de un anlisis de valores lmite.
El nmero de causas y efectos analizados determinarn la complejidad del diagrama
causa y efecto: para n precondiciones cuyos posibles valores puedan ser verdadero o
falso, se pueden generar 2n casos de prueba.
Para sistemas de mayor tamao este mtodo slo es controlable con el apoyo de
herramientas.
227 de 418

Tablas de decisin y grficos causa y efecto Beneficios y Desventajas
Beneficios.
o Identificacin sistemtica de combinaciones de entradas (combinaciones de causas)
que no podran ser identificados utilizando otros mtodos.
o Los casos de prueba son fciles de obtener a partir de la tabla de decisin.
o Facilidad de determinar una cobertura suficiente de casos de prueba, por ejemplo,
por lo menos un caso de prueba por cada columna de la tabla de decisin.
o El nmero de casos de prueba se puede reducir por la fusin sistemtica de
columnas de la tabla de decisin.
Desventajas.
o El establecimiento de un gran nmero de causas conduce a resultados complejos y
extensos.
o Por lo tanto, se puede incurrir en muchos errores en la aplicacin de este mtodo.
o Esto hace necesario el uso de una herramienta.
228 de 418


229 de 418

Pruebas de transicin de estado Definicin
Muchos mtodos slo tienen en cuenta el comportamiento del sistema en trminos de
datos de entrada (input data) y datos de salida (output data).
No se tiene en cuenta los diferentes estados que pueda tomar el objeto de prueba.
o Por ejemplo, el resultado de acciones que hubieran ocurrido en el pasado, acciones
que hubieran causado que el objeto de prueba adquiera un determinado estado
Interno.
Los distintos estados que puede tomar un objeto de prueba se modelan a travs de
diagramas de transicin de estado.
El anlisis de la transicin de estado se utiliza para definir casos de prueba basados en la
transicin de estado.
230 de 418

Pruebas de transicin de estado rbol de Transicin de Estados
Para determinar casos de prueba usando un
grfico de transicin de estado, se construye un
rbol de estados:
o La raz del rbol es el estado inicial
o Para todos los estados, las posibles transiciones
de un estado a otro se representan como ramas.
o Para cada estado que puede ser alcanzado
desde el estado inicial, se crea un nodo que est
conectado a la raz a travs una rama.
o Esta operacin se repite para todos los estados
sucesivos.
o La creacin de ramas finaliza si:
El estado correspondiente al nodo es un
estado final (hoja del rbol)
Un mismo nodo con el mismo estado ya
es parte del rbol.
Las hojas del rbol o nodos finales representan un
estado final.
Fallecido
Fallecido
Casado
fallece
fallece
Casado
se casa
Divorciado
Viudo
se casa
muerte
pareja
se divorcia
Casado
fallece
Fallecido
fallece
Fallecido
se casa
soltero
es soltero
no nacido
231 de 418

Pruebas de transicin de estado Tabla de Transicin de Estados
Cada camino o ruta desde la raz hasta la hoja representa un caso de prueba para las
pruebas de transicin de estados
Para el ejemplo del grfico anterior tenemos 6 casos de prueba
Casos de
Prueba
T01
T02
T03
T04
T05
T06
Estado1
(Inicial)
no nacido
no nacido
no nacido
no nacido
no nacido
no nacido
Estado2
Estado3
soltero
soltero
soltero
soltero
soltero
soltero
fallecido
casado
casado
casado
casado
casado
Estado4
fallecido
viudo
viudo
divorciado
divorciado
Estado5
Estado final
fallecido
casado
fallecido
casado
fallecido
fallecido
fallecido
casado
fallecido
casado
232 de 418

Pruebas de transicin de estado rbol de Transicin de Estados
El rbol de transicin de estados de nuestro
ejemplo puede ahora ser extendido usando
transiciones invlidas (casos de prueba
negativos, pruebas de robustez).
Se muestran dos posibles transiciones
invlidas (entre otras)
Las transiciones imposibles entre estados
no pueden ser probadas
Fallecido
Fallecido
Casado
fallece
fallece
Casado
se casa
Divorciado
Viudo
se casa
muerte
pareja
se divorcia
error
Casado
Soltero
muerte
pareja
es soltero
No nacido
Fallecido
fallece
Fallecido
se casa
se divorcia
error
fallece
233 de 418

Pruebas de transicin de estado Resumen
Criterio de salida de la prueba.
o Cada estado debe haber sido alcanzado al menos una vez.
o Cada transicin debe haber sido ejecutada al menos una vez.
Beneficios / Desventajas de este mtodo.
o Buen mtodo de pruebas para aquellos objetos de prueba que pueden ser descritos
como una mquina de estados.
o Buen mtodo de pruebas para probar clases, slo en el caso de disponer del ciclo de
vida del objeto.
o Con frecuencia, los estados son ms bien complejos, es decir, es necesario un gran
nmero de parmetros para describir el estado.
En estos casos, disear casos de prueba y analizar los resultados de las pruebas
puede ser difcil y puede implicar un consumo de tiempo considerable.
o La sola cobertura de todos los estados no garantiza una cobertura completa de las
pruebas.
234 de 418


235 de 418

Pruebas de caso de uso Definicin
Los casos de prueba se obtienen directamente a partir de los casos de uso del objeto de prueba.
o El objeto de pruebo es visto como un sistema reaccionando con sus actores.
o Un caso de uso describe la interaccin de todos los actores involucrados conduciendo a
un resultado final por parte del sistema.
o Todo caso de uso tiene precondiciones que deben ser cumplidas con el objeto de ejecutar
el caso de uso (caso de prueba) de forma satisfactoria.
o Todo caso de uso tiene poscondiciones que describen el sistema tras la ejecucin del caso
de uso (caso de pruebo).
Los casos de uso son elementos del Lenguaje Unificado de Modelado (Unified Modeling
Language - UML).
o El diagrama de casos de uso es uno de los 13 diferentes tipos de diagramas utilizados por
UML.
o Un diagrama de casos de uso describe un comportamiento, no describe una secuencia de
eventos.
o Un diagrama de casos de uso muestra la reaccin del sistema desde el punto de vista del
usuario.
UML es un lenguaje de especificacin propietario para el modelado de objetos
236 de 418

Pruebas de caso de uso Ejemplo de Restaurante
(fuente: Wikipedia).
El diagrama describe la funcionalidad de
RESTAURANTE
un Sistema de Restaurante sencillo.
Los casos de uso estn representados por
Ordenar
comida
valos y los actores estn representados
por figuras humanas.
Servir
Mesero
Preparar
El actor Cliente puede comer comida,
comida
comida
pagar por la comida o beber Vino.
El actor Cocinero slo puede preparar
Comer
comida.
Frontera del
Los actores Cliente y Cajero estn Cliente
sistema
Tomar vino
involucrados en el caso de uso pagar por la
comida.
Pagar por la
La caja define los lmites del sistema del
comida
Cajero
Restaurante, es decir, los casos de uso
representados son parte del sistema a modelar y no los actores.
Cocinero
237 de 418

Pruebas de caso de uso Generalidades
Cada caso de uso describe una cierta tarea (interaccin usuario - sistema).
La descripcin de un caso de uso incluye, pero no est limitado a:
o Precondiciones.
o Resultados esperados / comportamiento del sistema.
o Poscondiciones.
Estos elementos descriptivos tambin son utilizados para definir el caso de prueba
correspondiente.
Cada caso de uso puede ser utilizado como la fuente para un caso de prueba.
Cada alternativa en el diagrama corresponde a un caso de prueba separado.
Normalmente la Informacin aportada por un caso de uso no tiene suficiente detalle para
definir casos de prueba. Son necesarios datos adicionales (datos de entrada, resultados
esperados) para construir o desarrollar un caso de prueba.
238 de 418

Pruebas de caso de uso Resumen
Beneficios.
o Pruebas apropiadas Para pruebas de aceptacin y pruebas de sistema, dado que
cada caso describe un escenario a probar.
o Pruebas apropiadas si las especificaciones del sistema se encuentran disponibles en
UML.
Desventajas.
o Nula obtencin de casos de prueba adicionales ms all de la informacin aportada
por el caso de uso.
o Por lo tanto este mtodo debera ser utilizado slo en combinacin con otros
mtodos de diseo sistemtico de casos de prueba.
239 de 418

Tcnicas de caja negra (black box) o basadas en la especificacin Conclusiones Generales /1
El objetivo principal de las pruebas de caja negra (black box) es probar la funcionalidad
del sistema.
o Por lo tanto, el resultado de las pruebas depende de la calidad de la especificacin
del sistema (por ejemplo, la completitud, especificaciones faltantes o errneas
conducen a malos casos de prueba).
Si las especificaciones son errneas, tambin sern errneos los casos de
prueba. Las pruebas se desarrollan solamente para las funciones descritas.
Una especificacin faltante de una funcionalidad requerida no ser detectada
durante las pruebas.
Si el objeto de prueba posee funciones que no han sido especificadas, stas no sern
evaluadas.
o Tales funciones superfluas pueden causar problemas en las reas de la estabilidad y
seguridad (por ejemplo, software para un cajero automtico).
240 de 418

Tcnicas de caja negra (black box) o basadas en la especificacin Conclusiones Generales /2
A pesar de estas desventajas, las pruebas funcionales constituyen la actividad de pruebas
ms importante.
o Los mtodos de caja negra (black box) siempre son utilizados en el proceso de
pruebas.
o Las desventajas pueden ser compensadas con el uso de mtodos adicionales de
diseo de casos de prueba, por ejemplo, pruebas de caja blanca o pruebas basadas
en la experiencia.
241 de 418

Tcnicas de caja negra (black box) o basadas en la especificacin Resumen
Mtodos de caja negra (black box):
o Particin de equivalencias o clases de equivalencia.
o Anlisis de valores lmite.
o Tablas de decisin y grficos causa y efecto.
o Pruebas de transicin de estado.
o Pruebas de caso de uso.
Las pruebas de caja negra (black box) verifican funciones especificadas, si los funciones no
son especificadas, stas no son probadas.
El cdigo sobrante no puede ser detectado utilizando pruebas de caja negra (black box).
242 de 418

Agenda

243 de 418

04 Tcnicas de caja blanca (white box) o basadas en la estructura
Tcnicas de caja blanca (white box) o basadas en la estructura Visin General /1
En el presente apartado se explicarn en detalle las siguientes tcnicas de caja blanca
(white box):
o Pruebas de sentencia y cobertura.
o Pruebas de decisin o rama (branch) y cobertura.
o Pruebas de camino (path) y cobertura.
o Pruebas de condicin y cobertura.
Observacin:
o Estas tcnicas representan las tcnicas de pruebas dinmicas ms importantes y
utilizadas de forma ms frecuente. Estas tcnicas estn relacionadas con las tcnicas
de anlisis esttico descritas anteriormente.
Otras tcnicas de caja blanca (pero no limitadas a estas) son:
o LCSAJ (linear Code Sequence And Jump): Secuencia lineal de cdigo y sallo.
o Tcnicas basadas en el flujo de datos.
244 de 418

Tcnicas de caja blanca (white box) o basadas en la estructura Visin General /2
Se basa en identificar la estructura del software o el sistema:
o Nivel de Componente: La estructura de un componente de software, por ejemplo:
sentencias, decisiones, ramas, caminos (paths).
o Nivelo de Integracin: La estructura puede ser llamada rbol (un diagrama con
mdulos y llamados a otros mdulos).
o Nivel de Sistema: La estructura puede ser un men, procesos de negocio, o la
estructura de una pgina web.
Las tres anteriores estn relacionadas con las tcnicas diseo de las pruebas de estructura
por la cobertura del cdigo basada en sentencias, decisiones y caminos.
245 de 418

Tcnicas de caja blanca (white box) o basadas en la estructura Herramientas /1
Durante los pruebas de caja blanca, el programa objeto de pruebas es ejecutado de
misma forma que las pruebas de caja negra. Ambas categoras (caja blanca y caja negra)
conforman las pruebas dinmicas.
o La teora establece que todas las partes de un programa deberan ser ejecutadas por
lo menos una vez.
El grado de cobertura de un programa se mide con el uso de herramientas (por ejemplo,
analizadores de cobertura):
o La instrumentacin del cdigo se lleva a cabo con el objeto de contar la ejecucin de
caminos, es decir se insertan contadores en el cdigo del programa del objet de
prueba.
o Estos contadores son inicializados en cero, cada ejecucin del camino especfico
Incrementar el contador correspondiente.
o Los contadores que mantienen el valor cero tras las pruebas indican las partes del
programa que an no han sido ejecutadas.
246 de 418

Tcnicas de caja blanca (white box) o basadas en la estructura Herramientas /2
Las tcnicas de caja blanca requieren el apoyo de herramientas en muchas reas a saber:
o Especificacin de caso de prueba.
Generacin automtica del diagrama del flujo de control a partir del cdigo
fuente del programa.
o Ejecucin de la prueba.
Herramientas para monitorizar y controlar el flujo del programa dentro del
objeto de prueba.
El soporte de herramientas asegura la calidad de las pruebas e incrementa su eficiencia.
o Dada la complejidad de las mediciones necesarias para las pruebas de caja blanca, la
ejecucin manual de pruebas implica:
Consumo excesivo de tiempo y de recursos.
Dificultad en la implementacin y propensin o errores.
247 de 418

Pruebas de caja blanca (White box)
Cobertura de sentencia.
Cobertura de decisin o rama (branch).
Cobertura de camino (path).
Cobertura de condicin.
248 de 418

Cobertura de sentencia (Statement coverage) - Definicin
El foco de la atencin son las sentencias del cdigo de un programa.
o Qu casos de prueba son necesarios con el objeto de ejecutar todas (o un
porcentaje determinado) las sentencias del cdigo existentes?
La base de este anlisis es el diagrama de flujo de control.
o Todas las instrucciones o sentencias estn representadas por nodos y el flujo de
control entre instrucciones est representado por una arista (flecha).
o Las instrucciones mltiples se combinan en un nodo independiente si solamente
pueden ser ejecutados en una secuencia particular.
El objetivo de la prueba (criterio de salida) es lograr la cobertura de un porcentaje
especfico de todas las sentencias denominado cobertura de sentencia. (C 0 cobertura de
cdigo - code coverage).
(
249 de 418

Cobertura de sentencia (Statement coverage) Ejemplo (1) /1
Se evala el siguiente segmento de cdigo de un programa, que
est representado por el diagrama del flujo de control.
if (i > 0) {
j = f(i);
if (j > 10){
while (k > 10){
}
}
}
250 de 418

Cobertura de sentencia (Statement coverage) Ejemplo (1) /2
Considerar el programa representado por l diagrama de flujo
de control.
o Contiene dos sentencias if y un bucle do-while dentro de
la segunda sentencia if.
Hay tres caminos diferentes a travs del segmento de
programa.
o La primera sentencia if permite dos direcciones.
o La direccin de la derecha de la primera sentencia if se
divide nuevamente a partir de una segunda sentencia if.
Todas las sentencias de este programa pueden ser alcanzadas
haciendo uso del camino de la derecha.
o Un solo caso de prueba ser suficiente para alcanzar el
100% de cobertura de sentencia.
251 de 418

Cobertura de sentencia (Statement coverage) Ejemplo (2)
En este ejemplo el diagrama es ligeramente ms
complejo:
o El programa contiene las sentencias if y un bucle
(dentro de una sentencia if)
Cuatro rutas diferentes conducen a la cobertura de
sentencias de este segmento de programa.
o En cada rama de la sentencia if, existe otra
sentencia if que permite dos direcciones
diferentes.
Utilizando un caso de prueba (azul, verde o naranja) un
mximo de 7 de 12 sentencias pueden ser cubiertas,
esto resulta en un valor de C0 = 58,33%
Utilizando el caso de prueba (rojo) un mximo de 6 de
12 sentencias pueden ser cubiertas, esto resulta en un
valor de C0 = 50%
Para una cobertura de sentencia del 100% hacen falta cuatro casos de prueba.
252 de 418

Cobertura de sentencia (Statement coverage) Conclusiones generales
La medicin de la cobertura se realiza con el uso de herramientas diseadas de forma
especfica.
o Estas herramientas se denominan Herramientas de Anlisis de Cobertura (Coverage
Analysis Tools) o Analizadores de Cobertura (Coverage Analyzers).
Beneficios/desventajas d este mtodo.
o El cdigo muerto (cdigo constituido por sentencias que nunca se ejecutan) ser
detectado.
Si hay cdigo muerto en el programa, no se podr lograr una cobertura del
100%.
o Instrucciones faltantes (cdigo faltante que es necesario para cumplir con la
especificacin) no puede ser detectado.
Las pruebas se desarrollan solamente para las sentencias ejecutadas: Todo el
cdigo puede ser alcanzado/ejecutado?
El cdigo faltante no puede ser detectado utilizando tcnicos de caja blanca.
253 de 418

254 de 418

Cobertura de decisin o rama (decision coverage) Definicin
En lugar de las sentencias, la cobertura de decisin se centra en el flujo de control en un
segmento de programa (no los nodos sino las aristas del diagrama de flujo de control).
o Todas las aristas del diagrama de flujo de control tienen que ser cubiertas al menos una
vez.
o Qu casos de prueba son necesarios para cubrir cada arista del diagrama de flujo de
control al menos una vez?
El propsito de esta prueba (criterio de salida) es lograr la cobertura de un porcentaje
especfico de todas las decisiones denominado cobertura de decisin (C1 cobertura de cdigo code coverage)
( )
Sinnimo de:
( )
255 de 418

Cobertura de decisin o rama (decision coverage) Ejemplo (1)
El diagrama de flujo de control representa el segmento de
un programa objeto de la evaluacin.
Tres caminos diferentes son posibles en este segmento de
programa.
o La primera sentencia if conduce a dos direcciones
diferentes.
o Un camino de la primera sentencia if se divide
nuevamente en dos caminos diferentes, uno de los
cuales contiene un bucle.
o Solamente se puede alcanzar todas las aristas a travs
de una combinacin de los tres caminos posibles.
o Son necesarios tres casos de prueba para alcanzar una
cobertura de decisin del 100%.
o Utilizando solamente las dos direcciones de la derecha
pueden ser cubiertas 9 de 10 aristas (C1 = 90%)
256 de 418

Cobertura de decisin o rama (decision coverage) Ejemplo (2)
En este ejemplo el diagrama es ligeramente ms
complejo.
Cuatro caminos diferentes conducen a travs del
segmento de programa.
o En ambas ramas de la sentencia if, otra sentencia
if permite nuevamente dos direcciones diferentes.
o En este ejemplo, el bucle no se cuenta como una
decisin adicional.
Utilizando un caso de prueba (el naranja), pueden ser
cubiertas 7 de 15 aristas. Esto resulta en un valor de
C1=46,67%.
o Son necesarios cuatro casos de prueba para lograr
una cobertura de decisin del 100% (el mismo
nmero de casos para lograr una cobertura de sentencia del 100%).
257 de 418

Cobertura de decisin o rama (decision coverage) Conclusiones Generales
Lograr una cobertura de decisin del 100% requiere, al menos de los mismos casos de
prueba que requiere la cobertura de sentencia (ms en la mayora de los casos).
o Una cobertura de decisin del 100% siempre incluye una cobertura de sentencia del
100%.
La mayora de las aristas son cubiertas en mltiples ocasiones.
Desventajas.
o No se pueden detectar sentencias faltantes.
o No es suficiente para probar condiciones complejas.
o No es suficiente para probar bucles de forma extensiva.
o No se consideran las dependencias entre bucles.
258 de 418

Cobertura de sentencia y cobertura de decisin
Ambos mtodos se refieren a caminos a travs del diagrama de flujo de control.
o Difieren en la cantidad de casos de prueba necesarios para lograr el 100% de
cobertura.
Slo se considera el resultado final de una condicin, a pesar de que la condicin
resultante puede estar constituida por mltiples condiciones atmicas.
o La condicin if ((a > 2) OR (b < 6)) slo puede ser verdadera o falsa.
o El camino (del programa) a ejecutar depende solamente del resultado final de la
condicin combinada.
o Aquellos fallos debidos o una Implementacin errnea de las partes de una decisin
combinada pueden no ser detectados.
259 de 418

260 de 418

Cobertura de camino (path coverage) Definicin /1
La cobertura de camino se centra en la ejecucin de todos los posibles caminos a travs
de un programa.
o Un camino es una combinacin de segmentos de programa (en un diagrama de flujo
de control es una secuencia alternada de nodos y aristas)
Los bucles en la cobertura de caminos
o Para la cobertura de decisin, un solo camino a travs de un bucle es suficiente.
o Para la cobertura de camino hay casos de prueba adicionales:
Un caso de prueba que no entre al bucle.
Un caso de prueba adicional por cada iteracin en el bucle.
Esto puede conducir o un alto nmero de casos de prueba.
261 de 418

Cobertura de camino (path coverage) Definicin / 2
El foco del anlisis de cobertura es el diagrama de flujo de control.
Las sentencias son nodos.
El flujo de control est representado por las aristas.
Cada camino es una va nica desde el inicio hasta el final del diagrama de flujo de control.
El objetivo de esta prueba (criterio de salida) es alcanzar un porcentaje definido de cobertura
de caminos.
262 de 418

Cobertura de camino (path coverage) Ejemplo (1)
El diagrama de flujo de control, representa el segmento de
programa a ser evaluado. Contiene tres sentencias if.
Tres caminos diferentes conducen a travs del diagrama de
este segmento de programa logran una cobertura de decisin
completa.
Sin embargo, pueden ser ejecutados cinco posibles caminos
distintos.
o Son necesarios cinco casos de prueba para lograr un
100% de cobertura de camino.
o Slo dos son necesarios para un 100% de cobertura de
sentencia (C0), tres son necesarios para un 100% de
cobertura decisin (C1).
263 de 418

Cobertura de camino (path coverage) Ejemplo (2)
El diagrama de flujo de control de la imagen, representa el
segmento de programa a ser evaluado. Contiene dos sentencias
if y un bucle en el Interior de la segunda sentencia if.
Tres caminos diferentes conducen a travs del diagrama de este
segmento de programa logran una cobertura de decisin
completa.
Si el bucle se ejecuta dos veces son posibles cuatro caminos
diferentes.
Cada incremento en el contador del bucle aade un nuevo caso
de prueba.
264 de 418

Cobertura de camino (path coverage) Conclusiones generales
El 100% de cobertura de camino slo se puede lograr en programas muy simples.
o Un solo bucle puede conducir a uno explosin de casos de prueba dado que todo
nmero posible de ejecuciones de un bucle constituye un nuevo caso de prueba.
o Tericamente es posible un nmero indefinido de caminos.
La cobertura de camino es ms exhaustiva que la cobertura de sentencia y de decisin.
o Cada posible camino a travs del programa es ejecutado.
100% de cobertura de camino incluye 100% de cobertura de decisin y de sentencia.
265 de 418

266 de 418

Cobertura de condicin Definicin
Se tiene en cuenta la complejidad de una condicin que est constituida por mltiples
condiciones atmicas.
o Una condicin atmica no puede ser dividida en sentencias condicionales ms
pequeas.
ste mtodo tiene por objetivo detectar defectos que resulten de la Implementacin de
condiciones mltiples (condiciones combinadas).
o Las condiciones mltiples estn constituidas por condiciones atmicas que se
combinan con el uso de operadores lgicos como: OR, AND, XOR, etc.
Ejemplo ((a>2) OR (b<6))
o Las condiciones atmicas no contienen operadores lgicos, slo contienen
operadores relacionales y el operador NOT (=, >, <, etc.).
Hay tres tipos de cobertura de condicin.
o Cobertura de condicin simple (simple condition coverage).
o Cobertura de condicin mltiple (multiple condition coverage).
o Mnima cobertura de condicin mltiple (minimum multiple condition coverage).
267 de 418

Cobertura de condicin simple (simple condition coverage)
Cada sub-condicin atmica de una sentencia condicional combinada debe tomar alguna
vez, los valores lgicos verdadero (true) y falso (false).
Este ejemplo se utiliza para explicar la
cobertura de condicin utilizando una
expresin con una condicin mltiple.
Considere la siguiente condicin

a > 2 OR b < 6
Ejemplos de casos de prueba para
cobertura de condicin simple
Con slo dos casos de prueba se puede

a = 3 (true)
b = 7 (false)
a > 2 OR b < 6 (true)
a > 2 OR b < 6 (true)
lograr una cobertura de condicin a = 1 (false) b = 5 (true)
simple.
o Cada sub-condicin ha tomado los valores verdadero (true) y falso (false).
Sin embargo, el resultado combinado es verdadero (true) en ambos casos.
o true OR false = true
o false OR true = true
268 de 418

Cobertura de condicin mltiple (multiple condition coverage)
Todas las combinaciones que puedan ser creados utilizando permutaciones de las sub
condiciones atmicas deben formar parte de las pruebas.

a > 2 OR b < 6
cobertura de condicin multiple
Con cuatro casos de prueba se puede lograr

a = 3 (true)
b = 7 (false)
a > 2 OR b < 6 (true)
una cobertura de condicin mltiple.
a = 3 (true)
b = 5 (true)
a > 2 OR b < 6 (true)
o Se
han
creado
todas
las a = 1 (false)
b = 5 (true)
a > 2 OR b < 6 (true)
combinaciones de los valores a = 1 (false) b = 7 (false)
a > 2 OR b < 6 (false)
verdadero (true) y falso (false).
o Se han logrado todos los posibles resultados de la condicin mltiple.
El nmero de caso de prueba se incrementa de forma exponencial:
o n = nmero de condiciones atmicas.
o 2n = nmero de casos de prueba.
269 de 418

Mnima cobertura de condicin mltiple (minimum multiple condition coverage)
Todas las combinaciones que puedan ser creadas utilizando los resultados lgicos de cada
sub condicin cambia el resultado de la condicin combinada.

a > 2 OR b < 6
cobertura de condicin multiple
a = 3 (true)
b = 7 (false)
a > 2 OR b < 6 (true)
Los cambios de una sub condicin,
a = 3 (true)
b = 5 (true)
a > 2 OR b < 6 (true)
cambian el resultado global para tres de
a = 1 (false)
b = 5 (true)
a > 2 OR b < 6 (true)
los cuatro casos de prueba.
a = 1 (false)
b = 7 (false)
a > 2 OR b < 6 (false)
o Slo para el caso dos (true OR true
= true) el cambio en la sub condicin no resultar en un cambio en la condicin
global. Este caso de prueba puede ser omitido.
El nmero de casos de prueba se puede reducir a un valor entre n+1 y 2n
270 de 418

Cobertura de condicin - Conclusiones Generales
La cobertura de condicin simple es un instrumento dbil para probar condiciones
mltiples.
La cobertura de condicin mltiple es un mtodo mucho mejor.
Asegura cobertura de sentencia y decisin.
o Sin embargo, tiene como resultado un alto nmero de cosos de prueba: 2n
o La ejecucin de algunas combinaciones no es posible.
o Por ejemplo x > 5 AND x < 10 ambas sub condiciones no pueden ser falsas al mismo
tiempo.
La mnima cobertura de condicin mltiple es Incluso mejor, debido a:
o Reduce el nmero de casos de prueba entre n+1 a 2n.
o Las coberturas de sentencia y decisin tambin son cubiertas.
o Tiene en cuenta la complejidad de las sentencias de decisin.
Todas las decisiones complejas deben ser probadas, la mnima cobertura de condicin
mltiple es adecuada para lograr este objetivo.
271 de 418

Tcnicas de caja blanca - Resumen
Los mtodos de caja blanca y caja negra son mtodos dinmicos, el objeto de prueba es
ejecutado durante las pruebas.
El mtodo de caja blanca (White box) comprende:
o Cobertura de sentencia (statement coverage).
o Cobertura de decisin (decision coverage).
o Cobertura de camino (path coverage).
o Cobertura de condicin (condition coverage): simple, mltiple, mnimo mltiple.
Slo se puede probar cdigo existente. No se pueden hallar funciones faltantes.
Sin embargo el cdigo muerto o superfluo puede ser detectado con las pruebas de caja
blanca. Principalmente, los mtodos de caja blanca son utilizados en pruebas de bajo
nivel como pruebas de componente o pruebas de integracin.
Los mtodos difieren en la intensidad de las pruebas (profundidad de la prueba).
o Dependiendo del mtodo, el nmero de casos de prueba es distinto.
272 de 418

Agenda

273 de 418

05 Tcnicas basadas en la experiencia
Tcnicas basadas en la experiencia Definicin
Prctica para la creacin de casos de
prueba sin un claro enfoque
metodolgico, basada en la intuicin
y experiencia del probador
Los casos de prueba se basan en la
Intuicin y experiencia.
o Dnde se han acumulado
defectos en el pasado?
o Dnde falla el software con
frecuencia?
274 de 418

Tcnicas basadas en la experiencia Fundamentos
Las pruebas basadas en la experiencia tambin se denominan pruebas intuitivas (intuitive
testing) e incluye: prediccin de errores (pruebas orientadas a puntos dbiles) y pruebas
de exploracin (pruebas iterativas basadas en el conocimiento adquirido sobre el
sistema).
Principalmente se aplica con el objeto de complementar otros casos de prueba generados
con mayor formalismo.
o No cumple los criterios de un proceso de pruebas sistemtico.
o Frecuentemente produce casos de prueba adicionales que no podran ser creados
con otras prcticas, por ejemplo:
Problemas conocidos del pasado.
Conjuntos vacos en valores de entrada.
Una aplicacin similar ha tenido errores en estas circunstancias.
275 de 418

Tcnicas basadas en la experiencia Diseo de casos de prueba
El tester debe tener experiencia y conocimientos aplicables
Intuicin: Donde pueden existir defectos ocultos?
o La intuicin caracteriza a un buen tester.
Experiencia: Qu defectos se han encontrado en el pasado?
o Conocimiento basado en la experiencia.
o Creacin de listas de errores recurrentes.
Conocimiento / conciencia: Cules son los defectos especficos esperados?
o Detalles especficos del proyecto son incorporados.
o Cules son los posibles defectos ocasionados por presin de tiempo o
complejidad?
o Estn involucrados programadores inexpertos?
276 de 418

Tcnicas basadas en la experiencia Diseo intuitivo de casos de prueba, posibles fuentes
Resultados de pruebas y experiencia prctica con sistemas similares.
o Posiblemente un predecesor del software u otro sistema con funcionalidad similar.
Experiencia de usuario.
o Intercambio de experiencia con el sistema como usuario.
Enfoque del despliegue.
o Qu partes del sistema sern utilizadas con mayor frecuencia?
Problemas de desarrollo.
o Hay algn punto dbil como resultado de dificultades en el proceso de desarrollo?
277 de 418

Tcnicas basadas en la experiencia Prediccin de errores en la prctica
Lista de comprobacin de errores.
o Enumerar posibles errores.
o Factores ponderados dependientes del riesgo y probabilidad de ocurrencia.
Diseo de caso de prueba
o Creacin de casos de prueba dirigidos a producir los errores de la lista.
o Asignar prioridades a los casos de prueba considerando el valor de su riesgo.
Actualizar la lista de errores durante las pruebas.
o Procedimiento iterativo.
o Es til una coleccin estructurada de experiencia cuando se repite el procedimiento
en futuros proyectos.
278 de 418

Pruebas exploratorias
Es un procedimiento de diseo de casos de prueba especialmente apropiado cuando la
informacin base se encuentra poco estructurada.
Tambin es til cuando el tiempo disponible para pruebas es escaso.
Procedimiento:
o Revisar las partes constituyentes (Individuales / identificables) del objeto de prueba.
o Ejecutar un nmero reducido de casos de prueba, exclusivamente sobre aquellas
partes que deben ser probadas, aplicando prediccin de errores (error guessing).
o Analizar los resultados, desarrollar un modelo preliminar (rough model) de cmo
funciona el objeto de prueba.
o Iteracin: Disear nuevos objetos de prueba aplicando el conocimiento adquirido
recientemente.
o Concentrarse en las reas relevantes y explorar caractersticas adicionales del objeto
de prueba.
o Herramientas de captura pueden ser tiles para registrar las actividades de pruebas.
279 de 418

Pruebas exploratorias - Principios
Seleccionar objetos pequeos y/o concentrarse en aspectos particulares del objeto de
pruebas.
o Una iteracin unitaria no debera llevar ms de 2 horas.
Los resultados de una iteracin constituyen la base de informacin para la siguiente
iteracin.
o Se obtienen casos de prueba adicionales o partir de la situacin particular de la
prueba.
El modelado tiene lugar durante el proceso de pruebas.
o Se genera un modelo del objeto de prueba durante las pruebas.
o Un objetivo de las pruebas es el refinamiento continuo del modelo.
Preparacin de pruebas adicionales
o Con esto, el conocimiento puede ser adquirido para apoyar la eleccin apropiada de
mtodos de diseo de casos de prueba.
280 de 418

Diseo intuitivo de casos de prueba vs. Diseo sistemtico de casos de prueba
El diseo intuitivo de casos de prueba es un buen complemento a los enfoques
sistemticos.
o An debe ser tratado como una actividad complementaria.
o No puede dar constancia de completitud, el nmero de casos de prueba puede
variar de forma considerable.
Las pruebas son ejecutadas de la misma manera que las pruebas definidas de forma
sistemtica.
La diferencia es la forma en la cual los casos de prueba han sido diseados / identificados.
A travs de pruebas Intuitivas se pueden detectar defectos que no podran ser detectados
con mtodos sistemticos de prueba.
281 de 418

Tcnicas basadas en la experiencia Resumen
Las tcnicas basadas en la experiencia complementan las tcnicas sistemticas para
determinar casos de prueba.
Las tcnicas basadas en la experiencia dependen en gran medida de la habilidad
individual del probador.
La prediccin de errores y las pruebas exploratorias son dos de las tcnicas ms utilizadas
de las pruebas basadas en la experiencia.
282 de 418

Agenda

283 de 418

06 Seleccin de las tcnicas de pruebas
Criterios para seleccionar la tcnica de pruebas apropiada /1
Estado de la informacin respecto del objeto de prueba.
o Se pueden realizar pruebas de caja blanca de alguna manera?
o Hay suficiente material de especificacin para definir pruebas de caja negra, o son
necesarias pruebas exploratorias para comenzar?
Objetivos de prueba predominantes.
o Las pruebas funcionales han sido solicitadas de forma explcita?
o Qu pruebas no funcionales son necesarias?
o Son necesarias pruebas estructurales para lograr los objetivos del proceso de
pruebas?
Riesgos.
o Se espera un dao / perjuicio serio proveniente de defectos ocultos?
o Es muy alta la frecuencia de uso del objeto de prueba?
o Hay algn estndar legal o contractual, respecto de la ejecucin de pruebas y
cobertura de pruebas que deban ser cumplidos?
284 de 418

Precondiciones del proyecto.
o Cunto tiempo y quien est planificando/asignando las pruebas?
o Cul es el riesgo de que el proceso de pruebas no sea finalizado segn la
planificacin?
o Qu mtodo de desarrollo es utilizado?
o Cules son los puntos dbiles del proceso asociado al proyecto?
Caractersticas del objeto d prueba.
o Qu posibilidades de ser probado ofrece el objeto de prueba?
o Cul es la disponibilidad del objeto de prueba?
Requisitos contractuales y del cliente.
o Ha habido algn acuerdo especfico entre el cliente / iniciador del proyecto
respecto de los procedimientos de prueba?
o Qu documentos deben ser entregados en el momento del despliegue del sistema?
285 de 418

Buenas prcticas.
o Qu enfoques han demostrado ser apropiados para estructuras similares?
o Qu experiencias han sido adquiridas con los enfoques en el pasado?
Niveles de prueba.
o En qu niveles de prueba se deben realizar pruebas?
Se deben aplicar criterios adicionales dependiendo de la situacin especifica
286 de 418

Intereses distintos causan enfoques diferentes en el diseo de pruebas
Inters del jefe de proyecto:
o Desarrollar software de la calidad requerida.
o Cumplir las restricciones de tiempo y presupuesto.
Intereses del cliente / Iniciador del proyecto:
o Recibir software de la ms alta calidad (funcionalidad, confiabilidad, usabilidad,
eficiencia, portabilidad y mantenibilidad).
o Cumplir las restricciones de tiempo y presupuesto.
Intereses del jefe de pruebas:
o Pruebas suficientes e Intensivas. Despliegue adecuado de las tcnicas necesarias
desde el punto de vista del proceso de pruebas.
o Evaluar / valorar el nivel de calidad alcanzado por el proyecto.
o Asignar y utilizar los recursos planificados para las pruebas de forma ptima.
287 de 418

Seleccin de las tcnicas de pruebas - Resumen
Criterio para seleccionar el enfoque apropiado de diseo de casos de prueba:
o Fuente de pruebas (Fuente de la informacin respecto de los objetos de prueba).
o Objetivos del proceso de pruebas (Qu conclusiones se deben obtener a travs de
las pruebas).
o Aspectos asociados al riesgo.
o Estructura del proyecto / precondiciones.
o Requisitos contractuales / cliente.
288 de 418
V Gestin de Pruebas
Agenda
Captulo V Gestin de Pruebas
V/01 Organizacin de pruebas.

V/02 Planificacin y estimacin de pruebas.
V/03 Seguimiento y control del estado de pruebas.
V/04 Gestin de la configuracin.
V/05 Riesgo y pruebas.
V/06 Gestin de incidencias.
289 de 418
V Gestin de Pruebas
01 Organizacin de pruebas
La gestin de pruebas como parte del proceso de pruebas
El proceso de pruebas es una actividad que cubre el proceso de desarrollo software en su
totalidad.
Las actividades propias de la gestin de pruebas son necesarias a lo largo de todo el
proceso de pruebas.
Actividad
Concepcin de pruebas
Planificacin de pruebas
Control de pruebas
Pruebas de aceptacin
Producto resultado del trabajo

Plan de pruebas maestro (esttico)
Plan de pruebas (dinmico)
Informe de estado, accin de control
Liberacin del producto software
290 de 418
V Gestin de Pruebas
Los equipos de prueba deberan ser independientes
Ventajas.
o Imparcialidad, no hay vinculacin personal con el objeto de prueba.
o Se pueden cuestionar hechos respecto de la base de pruebas (test basis) y verificar
las suposiciones hechas durante al diseo de pruebas.
Desventajas.
o Aumenta el esfuerzo dedicado a la comunicacin, presentacin de conflictos del tipo
"tener la ltima palabra".
o Desarrolladores pierden el sentido de responsabilidad
291 de 418
V Gestin de Pruebas
Otras formas de conformar equipos de prueba
Los desarrolladores prueban sus propios programas.
Los probadores tambin son miembros del equipo de desarrollo.
Los probadores tambin son miembros del equipo del proyecto o estructura de la
organizacin.
Especialistas para tareas especficas.
Equipos de prueba externos.
292 de 418
V Gestin de Pruebas
Perfiles del personal de pruebas
El proceso de pruebas requiere personas con una amplia variedad de habilidades y
cualidades.
Se explicarn en detalle los siguientes roles asociados al proceso de pruebas:
o Jefe de pruebas o director de pruebas (test manager).
o Diseador de pruebas (test designer).
o Ingeniero de automatizacin de pruebas (test automation engineer).
o Administrador de pruebas (test administrator) / Administrador del sistema de
pruebas (test system administrator).
o Probador (tester).
o Experto tcnico (technical expert).
Nota:
Se pueden especificar roles adicionales, por ejemplo administrador de base de datos, probador
de carga.
293 de 418
V Gestin de Pruebas
Jefe de pruebas (test leader) o director d pruebas (test manager) o coordinador de pruebas
(test coordinator)
Planifica, realiza el seguimiento y control del proyecto de pruebas.
Competencias especiales necesarias:
o Gestin de pruebas y calidad software.
o Planificacin y control de pruebas.
o Experiencia como jefe de proyecto.
o Habilidades de gestor.
294 de 418
V Gestin de Pruebas
Diseador de pruebas (test designer)
Disea los casos de prueba necesarios y establece el orden en el cual tendr lugar la
ejecucin de los casos de prueba.
Competencias especiales necesarias en el rea de:
o Conocimiento de desarrollo y pruebas.
o Conocimiento de ingeniera de software.
o Conocimiento de especificaciones tcnicas.
o Conocimiento de requisitos funcionales.
295 de 418
V Gestin de Pruebas
Ingeniero de automatizacin de pruebas (test automation engineer)
Evala las posibilidades de la automatizacin de pruebas y las implementa.
o Experiencia como probador (tester).
o Conocimiento tcnico (know how) en el diseo y automatizacin de pruebas.
o Conocimientos de programacin.
o Amplios conocimientos en el uso de las herramientas.
296 de 418
V Gestin de Pruebas
Administrador del sistema de pruebas (Test system administrator)
Prepara y opera el entorno de pruebas.
o Es responsable de cumplir los requisitos del sistema de pruebas.
o Administracin de sistemas (o acceso a la administracin del sistema).
o Conocimiento de herramientas de desarrollo y pruebas.
o Sistemas de base de datos, si aplica.
o Redes, s aplica.
o Instalacin y operacin del sistema (por ejemplo el sistema operativo)
297 de 418
V Gestin de Pruebas
Probador software (software tester)
Ejecuta las pruebas de acuerdo con la especificacin de casos de prueba.
o Conocimiento bsico del software.
o Conocimiento bsico de pruebas.
o Operacin y uso de herramientas de pruebas.
o Experiencia en la ejecucin de pruebas.
o Conocimiento de los objetos de prueba.
298 de 418
V Gestin de Pruebas
Experto tcnico (Technical expert)
Asiste al equipo de pruebas cuando es necesario.
o Administracin de bases de datos o diseo de bases de datos.
o Experto en Interfaces de usuario.
o Experto en redes.
Dependiendo del tipo de problema o del entorno de pruebas puede ser necesario que
expertos adicionales en pruebas formen parte del equipo de pruebas.
o En algunas ocasiones son necesarias competencias especiales que no que no se
encuentren directamente relacionadas con las pruebas, por ejemplo expertos en
usabilidad, expertos en seguridad, etc.
299 de 418
V Gestin de Pruebas
Competencias no tcnicas (soft skills)
Adicionalmente a las competencias tcnicas, los miembros del equipo de pruebas
requieren de las siguientes competencias y experiencias:
o Miembros del equipo: diplomacia.
o Disposicin a preguntar sobre hechos aparentemente obvios.
o Persistencia, fuerte personalidad.
o Meticulosidad y creatividad.
o Capacidad para tratar situaciones complejas.
o Facilidad de aprendizaje
300 de 418
V Gestin de Pruebas
Organizacin de equipos de pruebas
Utilizar una organizacin apropiada para cada proyecto especfico.
Direccin de equipo
de pruebas
Que
Quien
Jefe de pruebas
Planificacin
Especificacin
Ejecucin
Evaluacin y control
Actividades de
infraestructura de
pruebas
Diseo de casos de
prueba
Ejecucin de pruebas
Evaluacin de
pruebas
Equipo de pruebas
Equipo de pruebas
funcionales
Equipo de pruebas
Equipo de pruebas
funcionales
No todos los roles los asume una persona independiente. En equipos de pruebas pequeos una
persona asume mltiples roles
301 de 418
V Gestin de Pruebas
Tareas del jefe de pruebas Introduccin
Organizacin del equipo de pruebas.

Planificacin de pruebas (de acuerdo con el plan de calidad corporativo).
Planificacin de los ciclos de pruebas.
Enfoque (Estrategia) y automatizacin de pruebas.
Medicin y control de pruebas.
Introduccin de un sistema de gestin de Incidencias adecuado.
Introduccin de un sistema de gestin de la configuracin*.
Informes de resultado y progreso para la direccin de la organizacin/compaa.
* Esta no es una tarea particular del jefe de pruebas, la administracin de la configuracin es necesaria en
todas las fases del desarrollo de software.
302 de 418
V Gestin de Pruebas
Tareas del jefe de pruebas - Gestin de las pruebas
Redaccin del plan de pruebas.
o Creacin de un documento que soporta mtodos, recursos y plazos para las
actividades del proceso de pruebas.
303 de 418
V Gestin de Pruebas
Tareas del jefe de pruebas Planificacin de pruebas, Planificacin del ciclo de pruebas /1
Direccin de equipo
de pruebas
Que
Quien
Jefe de pruebas
Planificacin
Especificacin
Ejecucin
Evaluacin y control
Actividades de
infraestructura de
pruebas
Diseo de casos de
prueba
Ejecucin de pruebas
Evaluacin de
pruebas
Equipo de pruebas
Equipo de pruebas
funcionales
Equipo de pruebas
Equipo de pruebas
funcionales
304 de 418
V Gestin de Pruebas
Tareas del jefe de pruebas Planificacin de pruebas, Planificacin del ciclo de pruebas /2
Enfoque de pruebas: implementacin de una estrategia de pruebas para un proyecto
especfico.
Ciclo de pruebas: ciclo a travs del proceso de pruebas para un objeto de prueba
especfico.
Actividades
del
(recordatorio):
o
o
o
o
o
proceso
de
pruebas
Planificacin y control de pruebas.

Especificacin de pruebas.
Ejecucin de pruebas.
Evaluacin y Reporte de criterios de salida
Cierre de pruebas
305 de 418
V Gestin de Pruebas
Tareas del jefe de pruebas Planificacin de pruebas, planificacin del ciclo de pruebas /3
Planificacin de pruebas.
o Planificacin del proceso de pruebas: debe ser desarrollado en una fase temprana
del proyecto. El resultado debe estor reflejado en un documento (plan de pruebas
esttico - static test plan).
Planificacin del ciclo de pruebas
o Planificacin detallada de un ciclo de pruebas: El plan de pruebas esttico ser
detallado para describir un ciclo de pruebo especfico. Los detalles dependen de la
situacin particular del proyecto (por ejemplo progreso del desarrollo, resultados de
pruebas, disponibilidad de recursos).
Tareas del jefe de pruebas:
o Iniciacin, control y supervisin de pruebas y ciclos de pruebas.
306 de 418
V Gestin de Pruebas
La planificacin de las pruebas comienza al Inicio del proyecto.
Hitos, presupuesto y prioridades de las diversas actividades del proceso de pruebas
requieren ser abordados.
Elije herramientas de pruebas y decide sobre la automatizacin de pruebas
o Diferentes herramientas y grados de automatizacin para los diferentes niveles de
pruebas.
307 de 418
V Gestin de Pruebas
Los recursos deben ser planificados.
o stos son escasos y con frecuencia, deben ser asignados de forma Individual.
o Durante los ciclos de pruebas, pueden ocurrir retrasos de tal forma que la
planificacin de los recursos de pruebas debe ser revisada.
El desarrollo del proyecto debe ser tenido en cuenta.
o A lo largo del proyecto pueden ocurrir retrasos de tal forma que puedan poner en
peligro a la planificacin (plazos). La planificacin puede ser modificada.
o En este caso, los casos de prueba planificados tienen que ser filtrados con el objeto
de cumplir con los hitos. sta es, con mucha frecuencia la primera medida tomada
cuando los plazos se reducen.
308 de 418
V Gestin de Pruebas
Se debe tener en cuenta las evaluaciones de pruebas anteriores.
o Los resultados actuales de las actividades de pruebas, pueden influir en la
planificacin de otras actividades. Por ejemplo, dependiendo del nmero de errores
encontrados en un primer ciclo de pruebas, el segundo ciclo va a ser ms corto o
ms largo.
El control de las pruebas en ejecucin se realiza usando mtricas establecidos en el plan
de pruebas
309 de 418
V Gestin de Pruebas
Tareas del jefe de pruebas Especificacin de pruebas /1
Direccin de equipo
de pruebas
Que
Quien
Jefe de pruebas
Planificacin
Especificacin
Ejecucin
Evaluacin y control
Actividades de
infraestructura de
pruebas
Diseo de casos de
prueba
Ejecucin de pruebas
Evaluacin de
pruebas
Equipo de pruebas
Equipo de pruebas
funcionales
Equipo de pruebas
Equipo de pruebas
funcionales
310 de 418
V Gestin de Pruebas
Tareas del jefe de pruebas Especificacin de pruebas /2
El objetivo principal del proceso de pruebas es detectar la mayor cantidad de defectos
relevantes con el menor esfuerzo posible.
Todas las pruebas documentadas en el plan de pruebas son especificadas, es decir, se
establece como se estructuran y como deben ser ejecutadas. Este proceso es iniciado por
el jefe de pruebas.
o Los casos de prueba estn constituidos por pasos unitarios, cada paso consta de uno
accin y de un resultado esperado.
o Los casos de prueba deberan ser obtenidos con la colaboracin del personal que
cuente con conocimiento de los requisitos funcionales del software
o Los casos de prueba deberan ser diseados teniendo en mente su carcter
repetitivo.
311 de 418
V Gestin de Pruebas
Tareas del jefe de pruebas Ejecucin de pruebas /1
Direccin de equipo
de pruebas
Que
Quien
Jefe de pruebas
Planificacin
Especificacin
Ejecucin
Evaluacin y control
Actividades de
infraestructura de
pruebas
Diseo de casos de
prueba
Ejecucin de pruebas
Evaluacin de
pruebas
Equipo de pruebas
Equipo de pruebas
funcionales
Equipo de pruebas
Equipo de pruebas
funcionales
312 de 418
V Gestin de Pruebas
Tareas del jefe de pruebas Ejecucin de pruebas /2
Comparacin de resultados esperados y obtenidos en el proyecto.
o Cada ciclo de pruebas requiere ser ajustado al plan de pruebas.
Han ocurrido retrasos o cambios?
Los resultados obtenidos se encuentran dentro del rango esperado?
El nmero de defectos detectados, tiempo utilizado en correcciones,
repeticin de pruebas, etc.
Todas las desviaciones deben ser informadas y tenidas en cuenta.
o Habitualmente las medidas correctivas deben ser tomadas de acuerdo con el plan
de pruebas y las actividades de pruebas en curso, por ejemplo:
Ajuste de fechas para las pruebas planificadas.
Ajusta de recursos para la ejecucin de pruebas
Ejecutar ciclos de pruebas adicionales, omitir ciclos de pruebas.
Identificar la prioridad de los ciclos de pruebas.
313 de 418
V Gestin de Pruebas
Tareas del jefe de pruebas Evaluacin y control de pruebas /1
Direccin de equipo
de pruebas
Que
Quien
Jefe de pruebas
Planificacin
Especificacin
Ejecucin
Evaluacin y control
Actividades de
infraestructura de
pruebas
Diseo de casos de
prueba
Ejecucin de pruebas
Evaluacin de
pruebas
Equipo de pruebas
Equipo de pruebas
funcionales
Equipo de pruebas
Equipo de pruebas
funcionales
314 de 418
V Gestin de Pruebas
La gestin de pruebas proporciona transparencia a la evolucin del proceso de pruebas y
aporta Indicadores a la direccin del proyecto.
Informes generados durante la ejecucin de pruebas (por ejemplo Informe de errores,
Inventario organizado por tipo de defectos, estadsticas), el seguimiento de defectos e
Informes al cliente son una importante fuente de informacin para el jefe de proyecto y la
direccin de la compaa (por ejemplo como base para la planificacin de recursos y
plazos).
El uso de herramientas y planillas aumentarn la calidad y pueden reducir la carga de
trabajo.
315 de 418
V Gestin de Pruebas
La gestin de pruebas Incluye la aceptacin de resultados del proyecto, significa: el
producto debe cumplir los requisitos definidos y la especificacin.
El jefe de proyecto, de acuerdo con el Jefe de pruebas, decide respecto de la aceptacin
de los objetos de prueba (por ejemplo pasar a un siguiente nivel de pruebas).
Los informes extensivos (documentacin) aseguran la ejecucin completa de las
actividades de pruebas.
316 de 418
V Gestin de Pruebas
Tareas del probador *(tester) - Introduccin
Asiste la implementacin del plan de pruebas.

Lleva a cabo el diseo de casos de prueba y ejecuta las pruebas
Revisa los casos de prueba diseados por otros testers
Asiste el reporte de pruebas
Asiste la implementacin de automatizacin de pruebas
* Probador (tester) es usado como un trmino genrico y puede incluir varios roles diferentes
al de jefe de pruebas
317 de 418
V Gestin de Pruebas
Tareas del probador (tester) /1
Asiste en la implementacin del plan de pruebas.
o Especifica y comprueba planes de prueba.
o Analiza y evala bases de prueba.
o Desarrolla especificaciones de prueba
o Formula y selecciona casos de prueba y combinaciones de datos de prueba
o Formula resultados esperados
o Prepara, configura y administra el entorno de pruebas (conjuntamente con los
administradores de la red y de sistema)
318 de 418
V Gestin de Pruebas
Ejecucin de pruebas (pruebas manuales).
o Implementacin de las pruebas a todos los niveles.
o Ejecuta pruebas y registra resultados en un protocolo de pruebas.
o Evala los resultados de las pruebas.
319 de 418
V Gestin de Pruebas
Asiste en la implementacin de automatizacin de pruebas.
o Crea guiones (scripts) de pruebas.
o Crea / opera herramientas de prueba.
o Realiza actividades de automatizacin de pruebas, control, captura, repeticin,
ejecucin.
o Analiza y evala resultados
Tratamiento despus de pruebas (test post processing).
o Creacin de protocolo de pruebas.
o Trazar notas relativas a desviaciones.
o Ejecutar repeticin de pruebas.
o Preparar documentacin de aceptacin.
320 de 418
V Gestin de Pruebas
Organizacin de pruebas - Resumen
La efectividad para encontrar defectos se incrementa con la independencia de pruebas
del equipo de pruebas.
El jefe de pruebas establece el equipo de pruebas en una fase temprana y:
o Planifica y prepara todas las pruebas.
o Establece un enfoque (estrategia) de pruebas.
o Organiza la gestin de desviaciones y la gestin de la configuracin.
o Controla la ejecucin de pruebas.
o Evala los resultados de las pruebas.
El jefe de pruebas informa a la direccin de la compaa y al jefe de proyecto.
El probador apoya las actividades de preparacin de pruebas, ejecuta pruebas, crea la
documentacin relativa a mensajes de desviacin y resultados de pruebas. Tambin asiste
en la implementacin de la automatizacin de pruebas.
321 de 418
V Gestin de Pruebas
Agenda

322 de 418
V Gestin de Pruebas
02 Planificacin y estimacin de pruebas
Actividades de planificacin de pruebas.
La planificacin de pruebas es la planificacin de proyectos.
o Todas las tareas y actividades deben ser planificadas con antelacin.
o Para las distintas tareas definidas se deben asignar recursos (personal, presupuesto,
herramientas, entornos de prueba, etc.).
o Concretar las actividades de pruebas en un plan de pruebas y coordinarlas con el
plan de proyecto.
o Definir el nivel de calidad (por ejemplo profundidad de las pruebas) para los
distintos niveles de pruebas.
o La planificacin de pruebas es una actividad continua, debe ser controlada de forma
constante.
o La informacin proveniente de las actividades de pruebas podra imponer ajustes en
el plan de pruebas con el objeto de afrontar riesgos sujetos a cambios.
323 de 418
V Gestin de Pruebas
La planificacin de pruebas es parte de la planificacin de la calidad en su conjunto.
La planificacin de pruebas es una parte importante del aseguramiento de la calidad, pero
no es la nica parte.
La estructura y contenidos de un plan de calidad pueden ser encontrados en el estndar
IEEE 730 (con informacin adicional en el estndar IEEE 983).
Elementos de un plan de aseguramiento de la calidad de acuerdo con el estndar IEEE
730, planificacin y descripcin de:
o Organizacin del proyecto
o Documentos que cubren el ciclo de vida de desarrollo.
o Estndares, mtodos y convenciones. Mecanismos que aseguran que estos son
cumplidos.
o Revisiones y auditorias durante el ciclo de vida de desarrollo.
o Proceso de pruebas.
o Documentacin de errores, soluciones.
324 de 418
V Gestin de Pruebas
Plan de pruebas (esttico)
Tras definir el rol del proceso de pruebas en el marco de las actividades de aseguramiento
de la calidad (QA), el proceso de pruebas comienza su fase de planificacin.
El primer paso de la planificacin es la creacin de un plan de pruebas esttico.
o El plan de pruebas cubre todas las fases del proceso de pruebas.
o Las reglas se fijan de acuerdo los objetivos de las pruebas, recursos, actividades de
pruebas, hitos, etc.
El plan de pruebas maestro es posteriormente ampliado con el objeto de cubrir los
resultados logrados en la fase de planificacin de detalle.
o La planificacin dependiente del proyecto complementa la primera versin del plan
de pruebas.
o El plan de pruebas cuenta con una extensin dinmica, que ser ajustada durante el
ciclo de vida del proyecto, si eso fuera necesario.
o El estndar IEEE 829 aporta una estructura de plan de pruebas acreditada.
325 de 418
V Gestin de Pruebas
Plan de pruebas de acuerdo al estndar IEEE 829.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
Introduccin.
Supuestos.
tems de prueba.
Caractersticas sujetas a pruebas.
Caractersticas no sujetas a pruebas.
Enfoque.
Criterios de xito / fracaso para un tem.
Criterios de suspensin / reanudacin.
Entregables de pruebas.
Tareas de pruebas.
Necesidades relativas al entorn.
Responsabilidades.
Dotacin de personal y formacin.
Calendario.
Riesgos y contingencias.
Aprobacin.
326 de 418
V Gestin de Pruebas
Actividades de planificacin de pruebas.
La planificacin de pruebas comienza al Inicio de un proyecto de desarrollo y se ajusta a lo
largo del ciclo de vida del proyecto.
Lo planificacin de pruebas tambin cubre la creacin y actualizacin del plan de pruebas.
Las siguientes actividades se explican con mayor detalle:
o
o
o
o
Estrategia de pruebas (test strategy).

Planificacin de recursos (resource planning).
Prioridad de las pruebas (priority of tests).
Soporte de herramientas (tool support).
327 de 418
V Gestin de Pruebas
Actividades de planificacin de pruebas - Estrategia de pruebas (test strategy).
La estrategia describe los niveles de pruebas a desarrollar y la intensidad de las pruebas
en esos niveles.
La estrategia de pruebas tambin establece los criterios de entrada y salida para cada
nivel, incluyendo las mtricas para evaluar estos criterios.
Es necesaria una estrategia de pruebas dado que probar un sistema de forma completa
no es viable.
o Probar con todas las combinaciones de datos de prueba, estados internos y
restricciones temporales es prcticamente imposible.
La valoracin de riesgos ayuda a centrar la atencin en aquellas reas en que las
actividades de pruebas presentan un riesgo de fallo ms alto.
328 de 418
V Gestin de Pruebas
Actividades de planificacin de pruebas - Planificacin de recursos (resource planning).
El objetivo principal de la planificacin de recursos es estimar el esfuerzo de los miembros
del equipo, incluyendo sus necesidades en trminos de tiempo, herramientas, actividades
de apoyo, etc.
o Estas estimaciones se convierten en parte del plan de pruebas (dinmico).
Este plan de pruebas cuenta con un calendario (time table) detallado, incluyendo hitos,
asignacin de personal a actividades.
o Este plan es un Instrumento para gestionar la tarea global de la ejecucin de
pruebas con todas sus actividades.
329 de 418
V Gestin de Pruebas
Actividades de planificacin de pruebas - Planificacin de pruebas (test planning)
Gestionar tiempos: Muchos proyectos experimentan intensos problemas de tiempo en
torno a las fases finales. Esto puede conducir a decisiones sobre la reduccin de
actividades de pruebas u omitir pruebas de forma completa.
Priorizar pruebas: Dado que la distribucin de software sin haber sido probado
suficientemente conlleva un alto riesgo, es necesario asignar prioridades a las actividades
de pruebas. Esto debe ser realizado de tal forma que los casos de prueba ms
Importantes sean ejecutados de forma temprana. De esta forma, partes crticas de los
programas son probadas incluso en el caso en el que actividades de pruebas sean
abortadas de forma prematura.
Seleccin de herramientas: Decidir respecto de qu herramientas deben ser utilizadas
para probar, si las herramientas disponibles son suficientes o si hay necesidad de
herramientas adicionales.
Documentar: Definir el nivel de detalle, estructura y plantillas para la documentacin de
pruebas.
330 de 418
V Gestin de Pruebas
Criterios de entrada
Los criterios de entrada definen cuando inician las pruebas y el comienzo de un nivel de
pruebas o cuando un set de pruebas est listo para ejecucin.
Criterios tpicos de entrada:
o Preparacin y disponibilidad del ambiente de pruebas.
o Preparacin de herramientas de pruebas.
o Disponibilidad de cdigo para ser probado.
o Disponibilidad de los datos de prueba.
o Disponibilidad del recurso humano.
o Probadores (testers) estn listos y preparados
331 de 418
V Gestin de Pruebas
Criterios de salida /1
Los criterios de salida que indican la finalizacin de una fase de pruebas, deben ser
establecidos para cada nivel de pruebas. Son necesarias mtricas para controlar estos
criterios de salida.
Ejemplos:
o Cobertura de cdigo (code coverage).
Porcentaje de cdigo (de un programa) que ha sido ejecutado.
Porcentaje de todos las funciones / todas las opciones de men que han sido
cubiertas.
o Cobertura de riesgo (risk coverage).
Casos de prueba de una clase de riesgo predefinido (por ejemplo el nivel de
riesgo ms alto) han sido ejecutados con xito en su totalidad.
332 de 418
V Gestin de Pruebas
Aborto de pruebas debido a razones de tiempo, costos calidad.
o Las actividades de pruebas son paralizadas / suspendidas cuando se alcanza la fecha
de entrega o el presupuesto se agota. Es muy frecuente que sta sea la realidad en
proyectos, en muchas ocasiones esta circunstancia tiene un alto coste en tiempo y
dinero con posterioridad.
o Si no ha sido alcanzado un mnimo de calidad, las pruebas pueden ser suspendidas o
incluso no ser iniciadas (muchos defectos crticos).
Tasa de deteccin de errores (error finding rate)
o El nmero de nuevos errores detectados cae por debajo de un valor
predeterminado. Por ejemplo, Las pruebas han sido suspendidas si se han detectado
menos de un error por hora.
o Las economas del proceso de pruebas deben ser tenidas en cuenta. Ms all de una
cierta tasa de deteccin de errores puede resultar ms barato corregir errores
reportados por los usuarios que buscar y eliminar errores en el proceso de pruebas.
333 de 418
V Gestin de Pruebas
Costos
Economa del proceso de pruebas.

o Un grado creciente de la calidad
representa un costo ms bajo de error,
pero costos ms altos en prevencin de
errores.
Costo mnimo de calidad
o Inicialmente, el costo de la revisin se
incrementa, luego se reduce (las
Costo total de la calidad
revisiones no aportan beneficios en los
Costo del error
fases finales del proyecto).
Costo de revisiones
o Inicialmente, el costo total de la calidad se
reduce, luego se incrementa, los costos de
la calidad son los ms bajos donde la
Costo de prevencin de errores
curva presenta su mnimo.
Grado de calidad
o Frecuentemente es necesario aportar un
mnimo de calidad con el objeto de poder mantenerse en el negocio.
o Las pruebas deben continuar aunque los costos de prevencin de errores se eleve con el
fin de disminuir el costo de errores.
334 de 418
V Gestin de Pruebas
Enfoque de pruebas, estrategia de pruebas /1
El enfoque de pruebas es la implementacin de la estrategia de pruebas para un proyecto
especfico. El enfoque de pruebas es definido y redefinido en la planificacin y diseo de
pruebas. Son incluidas generalmente las decisiones tomadas basadas en los objetivos del
proyecto y la gestin de riesgos. Enfoques y estrategias pueden ser combinadas.
Estos son variedades de enfoques de pruebas:
Enfoque preventivo.
o Las pruebas son diseadas tan pronto como sea posible.
Enfoque reactivo.
o Primero se disea el sistema y el software, luego se disean las pruebas.
Enfoque analtico.
o Se realiza un anlisis como prioridad de pruebas. Por ejemplo, pruebas basadas en
riesgo.
Enfoque heurstico.
o Las pruebas son ms reactivas. Por ejemplo pruebas exploratorias.
335 de 418
V Gestin de Pruebas
Enfoque de pruebas, estrategia de pruebas /2
Otros enfoques y estrategias de pruebas:
Enfoque de reutilizacin: Uso de set y resultados de pruebas de proyectos anteriores con
el fin de lograr avances rpidos.
Enfoque orientado a fallas: Adivinacin de errores.
Enfoque basado en listas de comprobacin: Uso de listas de comprobacin de
prioridades.
Enfoque basado en consultora: Expertos externos y tecnologas, guan el proceso de
pruebas.
Enfoque de cumplimiento de procesos y estndares: Se basa en estndares de
desarrollo de software.
Enfoque basado en modelos: Pruebas estocsticas basadas en informacin estadstica,
por ejemplo, informacin porcentual de fallas del sistema.
Ms enfoques pueden ser definidos. En la prctica, los enfoques son combinados
336 de 418
V Gestin de Pruebas
Estimacin de pruebas - factores de influencia (sntesis)
Caractersticas del producto (por ejemplo complejidad).

Calidad d la base de pruebas.
Requisitos de Habilidad y seguridad del producto.
Complejidad del proceso de desarrollo. Estabilidad de la organizacin, madurez del
proceso utilizado.
Personal Involucrado, restricciones temporales.
Mtodos para estimar el esfuerzo en el proceso de pruebas.
o Estimacin basada en expertos (estimacin basada en tareas).
o Estimacin basada en analogas.
o Estimacin basada en porcentajes.
337 de 418
V Gestin de Pruebas
Estimacin de pruebas - Estimacin basada en expertos (estimacin basada en tareas) /1
Mtodo.
o Identificar todas las tareas a ejecutar, normalmente utilizando un enfoque
descendente (top down).
o Obtener estimaciones para cada tarea por los responsables de su ejecucin o por
expertos.
o Sumar todos los valores de las tareas. Incluir los factores de correccin (si hay
experiencias sobre la exactitud de las estimaciones realizadas).
o Incluir elementos adicionales (buffers) con el objeto de cubrir tareas omitidas o
subestimadas.
338 de 418
V Gestin de Pruebas
Estimacin de pruebas - Estimacin basada en expertos (estimacin basada en tareas) /2
Ventajas.
o Las actividades de estimacin pueden estar estrechamente vinculadas a la
planificacin del proyecto.
o La estimacin da origen a informacin detallada que puede ser controlada y
ajustada a lo largo del ciclo de vida del proyecto.
o Las tareas pueden ser asignadas a grupos (por ejemplo pequeo, mediano, grande)
y los esfuerzos son estimados para un representante del mismo.
Desventajas.
o Este mtodo es extensivo y costoso.
o Este mtodo requiere de una idea clara respecto de la estrategia de pruebas y
actividades de pruebas en una fase temprana del proyecto.
o La experiencia demuestra que las estimaciones son en la mayora de los casos a la
baja. Esto podra deberse a la omisin o subestimacin de tareas.
o Los elementos incorporados (buffers) son recortados durante la planificacin del
proyecto.
o Los errores relativos a la planificacin de proyecto son heredados.
339 de 418
V Gestin de Pruebas
Estimacin de pruebas - Estimacin basada en analogas /1
Mtodo.
o Clasificar las tareas de pruebas requeridas.
o Buscar un proyecto que se haya desarrollado en el pasado que contenga una tarea
similar a una especfica.
o Utilizar el esfuerzo real de esta tarea como base de la estimacin.
o A travs del uso de mtricas (lneas de cdigo, nmero de mdulos, nmero de
casos de prueba, etc.) como base, calcular el valor de la estimacin total.
o Considerar factores de correccin.
340 de 418
V Gestin de Pruebas
Estimacin de pruebas - Estimacin basada en analogas /2
Ventajas.
o El mtodo es simple y efectivo.
o Se pueden lograr valores muy precisos para la estimacin si se cuenta con suficiente
experiencia.
Desventajas.
o Se requiere personal con experiencia y/o informacin detallada respecto del
proyecto actual y las tareas a estimar.
o Los criterios para la clasificacin de proyectos pueden no cubrir lodos los aspectos
de un proyecto.
o Frecuentemente conduce a debates con la direccin respecto de la validez de la
estimacin.
341 de 418
V Gestin de Pruebas
Estimacin de pruebas - Estimacin basada en porcentajes /1
Mtodo.
o El esfuerzo para las actividades de pruebas se estima sobre la base de la totalidad de
las actividades del proyecto.
o El valor del porcentaje (fraccin) requiere ser determinado basndose en la
experiencia.
o Ejemplo: Spillner, Linz habla de un porcentaje del 50% de actividades de pruebas
respecto de la totalidad de las actividades del proyecto
o Este mtodo tambin puede ser utilizado para otras partes del proyecto (por
ejemplo estimacin para los costos de gestin de proyecto, estimacin del esfuerzo
de pruebas para las pruebas del sistema).
o La estimacin basada en porcentaje no tiene en cuenta el esfuerzo en pruebas de
regresin, las cuales hacen parte importante en las pruebas de mantenimiento y las
pruebas relacionadas con los cambios.
342 de 418
V Gestin de Pruebas
Estimacin de pruebas - Estimacin basada en porcentajes /1
Ventajas.
o Tcnica de estimacin muy simple y ptenle que no requiere excesiva informacin
de entrada.
Desventajas.
o No muy precisa, dado que no tiene en cuenta las hechos particulares del proyecto
o Es necesaria mucha experiencia e intuicin por parte del estimador con el objeto de
obtener estimaciones vlidas.
o La decisin respecto del valor del porcentaje puede conducir a debates difciles.
o Tiene en cuenta actividades que ya forman parte de las estimaciones de la
planificacin del proyecto, por ejemplo El esfuerzo de pruebas del desarrollador
forma parte de la estimacin correspondiente al desarrollo o debe formar parte de
las estimaciones del proceso de pruebas?
343 de 418
V Gestin de Pruebas
Resumen
La planificacin de pruebas forma parte del plan de calidad corporativo.
El plan de pruebas es el elemento bsico de toda la planificacin de las actividades de
pruebas. Debe ser desarrollado de forma temprana en el proyecto.
o Plantilla de plan de pruebas: IEEE 829.
La estimacin d pruebas puede ser realizada utilizando varios mtodos. Tres mtodos
habituales son:
o Estimacin basada en expertos (estimacin basada en tareas).
o Estimacin basada en analogas.
o Estimacin basada en porcentajes.
344 de 418
V Gestin de Pruebas
Agenda

345 de 418
V Gestin de Pruebas
03 Seguimiento y control del estado de pruebas
Seguimiento y control del estado de pruebas
Planificacin de pruebas (test planning): Las pruebas deben ser Iniciadas.
Seguimiento de pruebas (test monitoring): Control de las actividades de pruebas con el
objeto de detectar desviaciones respecto del plan.
Control de pruebas: Correccin del rumbo de las actividades de pruebas cuando sea
necesario.
El seguimiento debe ser realizado en base a consideraciones medibles.
o Mtricas en base a errores, por ejemplo utilizando informacin del sistema de
gestin de incidentes.
o Mtricas en base a casos de prueba, por ejemplo utilizando Informacin del sistema
de gestin de pruebas.
o Mtricas en base a objetos de prueba, por ejemplo utilizando Informacin del
sistema de gestin de la configuracin.
o Mtricas en base a costos, por ejemplo utilizando Informacin del sistema de
control del proyecto.
Los resultados obtenidos de la medicin deben ser informados de forma regular.
346 de 418
V Gestin de Pruebas
Informe de estado de pruebas o reporte de pruebas /1
La Informacin de las actividades de pruebas se consolida en un reporte de pruebas (test
reporting).
Ejemplo del contenido de un informe de estado de pruebas (segn IEEE 829).
o Objetos de prueba.
o Niveles de prueba, ciclos de prueba, perodo del Informe.
o Estado de pruebas utilizando mtricas, por ejemplo nmero de defectos
documentados, nmero de casos de prueba ejecutados.
o Recursos utilizados, presupuesto consumido.
o Hitos alcanzados, por ejemplo aceptacin de objetos de prueba en niveles de
prueba especficos.
o Informe de defectos (nmeros de defectos descubiertos, nmero de defectos
corregidos)
o Evaluacin del riesgo (nuevos riesgos, riesgos modificados por informes previos)
o Pronstico: Actividades planificadas para el prximo perodo de informe.
o Evaluacin general, estado (semforo).
347 de 418
V Gestin de Pruebas
Informe de estado de pruebas o reporte de pruebas /2
Frecuencia de los Informes.
o Al inicio del proyecto, en la fase de preparacin los ciclos de los informes son ms
largos (quincenal o mensual).
o Las fases crticas de la ejecucin de pruebas requieren ciclos cortos (semanales,
diarios).
o El informe de cierre de pruebas al final del proyecto.
Evaluacin de los informes de pruebas.
o El desarrollo es apropiado?
o La ejecucin de las pruebas es eficaz y eficiente?
o Las actividades estn alineadas con los objetivos de pruebas?
o Estn siendo alcanzados objetivos de pruebas?
o Cul es el grado de riesgo de aquellos defectos que no han sido detectados?
o Cul es el nivel de confianza en el software basado en el estado actual de las
pruebas?
348 de 418
V Gestin de Pruebas
Control de pruebas
El control de pruebas es una tarea de gestin.
o El jefe de pruebas pertenece a las directivas del proyecto.
o Las tareas de direccin pueden Incluir otras reas del proyecto principal, tareas
ajenas al alcance de pruebas.
Medidas correctivas como respuesta a desviaciones respecto del plan.
o El control de pruebas incorpora todas las medidas ejecutadas durante el proceso de
pruebas.
o Ajuste de las actividades planificadas y cuando sea necesario, iniciar un nuevo ciclo
de planificacin en el plan de proyecto.
Evaluacin del cierre de pruebas.
o Los criterios de salida de pruebas tambin son registrados con las mtricas de
progreso de pruebas.
o Los criterios de salida de pruebas que hubieran sido alcanzados son documentados
en el informe de pruebas para su aprobacin.
349 de 418
V Gestin de Pruebas
Medidas de control de pruebas
Provisin de mayores recursos.
o Ms recursos humanos (sobe el tiempo, incrementar el tamao del equipo de
pruebas).
o Ms presupuesto (Incluir especialistas externos, consultores).
o Despliegue de herramientas para la automatizacin de tareas.
Reduccin del esfuerzo aplicado al trabajo.
o Exclusin de variaciones de casos de prueba.
o Simplificacin de objetos de prueba complejos, omisin de objetos especficos.
o Reduccin de la cantidad de datos de prueba.
o Omisin de casos de prueba, set de prueba (juego de prueba).
Las medidas de control de pruebas son documentadas con el objeto de informar a la
direccin del proyecto o el cliente, los cambios en los riesgos para el despliegue del
producto.
350 de 418
V Gestin de Pruebas
Seguimiento y control del estado de pruebas - Resumen
El seguimiento del estado de pruebas se basa en criterios medibles y aporta la
Informacin necesaria para gestionar el proceso de pruebas.
Las desviaciones respecto del plan requieren acciones correctivas.
La presentacin regular de informes aporta informacin al proyecto y a la direccin de la
compaa respecto del progreso de las pruebas.
351 de 418
V Gestin de Pruebas
Agenda

352 de 418
V Gestin de Pruebas
04 Gestin de la configuracin
Gestin de la configuracin - Motivacin
Durante el desarrollo software se genera una gran cantidad de datos, informacin,
resultados (artefactos):
o Documentos de requisitos, especificaciones, diseo del sistema.
o Componentes individuales, mdulos integrados, sistemas completos.
Un gran nmero de participantes con roles diferentes en los distintos componentes del
sistema.
La gestin de la configuracin es responsable de la asignacin explcita de una
denominacin para todos los artefactos y su administracin.
o Asignacin de nmeros de versin sucesivos.
o Es registrado el espacio (clearance) para desarrollos posteriores.
o Versiones antiguas son guardadas para un futuro control.
o Es registrado el acceso a los artefactos.
353 de 418
V Gestin de Pruebas
Gestin de la configuracin - Observaciones generales
La gestin de la configuracin presenta un rol de apoyo dentro de un proyecto. Todos los
cambios deben ser registrados en un recurso comn y comunicado haciendo uso de
procesos definidos.
Las expectativas respecto de la gestin de la configuracin pueden variar de forma
considerable dependiendo del tipo y alcance de proyecto, se debe desarrollar un plan de
gestin de la configuracin especfico.
IEEE 828 aporta un estndar para la gestin de la configuracin y el plan de gestin de la
configuracin.
La gestin de la configuracin no es una actividad particular del proceso de pruebas, es
necesaria durante todas las fases de un proyecto.
La gestin de la configuracin sin una herramienta apropiada slo es posible en proyectos
muy pequeos.
354 de 418
V Gestin de Pruebas
Gestin de la configuracin - Definiciones
Gestin de la configuracin - GC (configuration management - CM) se refiere a un
conjunto de medidas que complementan al desarrollo software:
o Gestin del cambio (change management): sigue todas las actividades, por ejemplo
cambios en el cdigo fuente para cada solicitud de cambio.
o Gestin de la construccin (build management): describe todos los pasos para
crear una versin de un producto de software con el objeto de ser suministrado
como un todo o subsistemas individuales.
o Gestin de entregas (release management): permite la definicin de versiones
aisladas para cada artefacto componente de una versin completa de un producto a
ser probado, entregado, etc.
o Gestin de versiones (versions management): como parle de GC registra todo la
informacin de acceso para cada artefacto: versin actual (nmero), ltimo cambio,
ltimo usuario, etc.
355 de 418
V Gestin de Pruebas
Problemas tratados por la gestin de la configuracin
Cul es la versin actual? La ambigedad con respecto a qu versiones se corresponden
puede resultar en actividades de desarrollo basadas en versiones antiguas (obsoletas) de
la especificacin.
Qu ha sido modificado, cuando y quien lo modific? Son posibles cambios
concurrentes de un fichero (archivo): qu cambios pueden ser sobrescritos?
Qu versin del fichero ha sido probada? Es difcil probar y extraer una conclusin de
unas pruebas cuando no se tiene conocimiento concreto d la versin de la qu se trata.
Qu artefactos se corresponden? Qu versiones han sido agrupadas para crear las
distintas entregas (release)?
356 de 418
V Gestin de Pruebas
Los requisitos sobre la GC conforman el punto de vista del proceso de pruebas
Control de versiones (versin control).
o Clasificar, guardar y recuperar diferente versiones de un objeto (V1.0, V1.1, etc.).
Gestin de la configuracin, gestin de entregas (release management).
o Determinar y administrar toda la informacin en las versiones correspondientes que
conforman un subsistema.
Protocolos, comentarios y razones para los cambios realizados.
Mantener un registro de estado.
o Trazar defectos y cambios, registrar Informes de problemas y aportar actividades de
retroalimentacin (backtracking of activities).
357 de 418
V Gestin de Pruebas
Auditoria de la configuracin (configuration audit)
Se Introduce una auditoria de la configuracin con el objeto de comprobar la efectividad
de las actividades de la gestin de la configuracin.
La auditoria de la configuracin comprobar:
o Si todos los componentes individuales de un sistema son considerados en la gestin
de la configuracin.
o Si las configuraciones individuales pueden ser identificadas correctamente.
358 de 418
V Gestin de Pruebas
Gestin de la configuracin Resumen
La gestin de la configuracin es necesaria para administrar los cambios sobre los objetos
de prueba y sus respectivas versiones.
Informacin de la construccin (build) y la entrega (release) es conservada con el objeto
de poder reconstruir versiones antiguas.
La gestin de la configuracin se aplica al proceso de desarrollo software completo, no
solamente al proceso de pruebas.
La gestin de la configuracin es posible solo con las herramientas apropiadas.
359 de 418
V Gestin de Pruebas
Agenda

360 de 418
V Gestin de Pruebas
05 Riesgo y pruebas
Riesgo - Definiciones
Riesgo
o Un riesgo es una prediccin calculada de un posible dao, la prdida en caso de un
resultado negativo, el peligro de una posible ventaja, la ganancia en el caso de un
resultado positivo (oportunidad).
o El riesgo es la probabilidad de un resultado negativo (matemtico), o la probabilidad
de la ocurrencia de un suceso negativo multiplicada por el monto del dao
econmico.
Riesgo (Waltzing With bears". Tom DeMarco, TImothy Lister)
o Un caso posible en el futuro que dar lugar a un resultado no deseado (causa), este
es un resultado no deseado en s mismo (efecto).
El riesgo asociado al proyecto y al producto deben ser tenidos en cuenta durante la
planificacin y el diseo de casos de prueba, cuando se prioricen casos de prueba, cuando
se seleccionen mtodos y durante la ejecucin de pruebas.
361 de 418
V Gestin de Pruebas
05 Riesgo y pruebas
Riesgos del proyecto /1
Riesgos asociados a la organizacin (organizational risks).
o Capacitacin y disponibilidad del personal.
o Problemas personales entre equipos, miembros del equipo.
o Cooperacin insuficiente entre departamentos, conflictos de intereses.
o Estimaciones no realistas de plazos del proyecto.
Riesgos tecnolgicos (technical risk).
o Requisitos defectuosos, incompletos o no realistas.
o Tecnologas, mtodos y herramientas nuevas que presentan incertidumbres para el
desarrollo software.
o Dficit de calidad en productos.
o Disponibilidad de un entorno de prueba complejo.
Riesgos ambientales (environmental risks).
o Deficiencias por factores externos en la provisin de componentes (plazos, calidad, coste)
o Problemas de aceptacin y otros inconvenientes contractuales con proveedores.
o Acceso concerniente a recursos externos.
o Cambios en requisitos legales.
362 de 418
V Gestin de Pruebas
05 Riesgo y pruebas
Riesgos del proyecto /2
Los riesgos asociados al proyecto afectan al xito del proyecto y deben ser gestionados.
Estimacin de la probabilidad y dao potencial.
Implementar medidas apropiadas para tratar los riesgos identificados:
o Mitigacin del riesgo: preparacin activa de medidas para reducir lo probabilidad y
dao potencial.
o Control del riesgo: preparar las medidas necesarias en el caso en el cual el riesgo se
convierte en un problema, contar con tiempo y fondos disponibles.
o Ignorancia del riesgo: esperar que el riesgo no se convierta en un problema.
o Transferencia del riesgo: mover el riesgo a otra rea, organizacin.
o Evitar el riesgo: (evitar situaciones de riesgo).
Cuando se analizan, manejan y mitigan los riesgos, el jefe de pruebas est siguiendo los
principios establecidos para la gestin del proyecto.
IEEE Std 829 plantea esquemas para planes prueba para el manejo de riesgos y contingencias.
363 de 418
V Gestin de Pruebas
05 Riesgo y pruebas
Riesgos del producto
Los riesgos asociados al producto son el resultado de problemas relacionados con el
producto suministrado.
o Funcionalidad insuficiente del producto suministrado.
o Atributos no funcionales insuficientes.
o Pobre integracin de datos y calidad.
o El producto no es idneo para su uso previsto, por lo tanto no puede ser puesto en
operacin.
o El producto provoca daos a la propiedad.
o El producto provoca lesin o muerte accidentales.
Las pruebas se ejecutan para reducir o evitar los riesgos asociados al producto.
o La probabilidad de ocurrencia de un riesgo s reduce.
o El dao potencial por la ocurrencia d un riesgo se reduce.
o Para un potencial alto de dao, mas pruebas intensivas son necesarias
364 de 418
V Gestin de Pruebas
05 Riesgo y pruebas
Gestin de riesgos de producto /1
Gestin de riesgos asociados al producto utilizando pruebas basadas en el riesgo.
o Identificar, analizar y priorizar riesgos.
o Influencia del riesgo tenido en cuenta durante la planificacin de pruebas.
Seleccionar los mtodos de pruebas para mitigar riesgos.
Asignar alcance de las pruebas (profundidad) de acuerdo al nivel de riesgo.
Adaptar el orden de ejecucin de casos de prueba. Los casos de prueba
importantes en primer lugar con el objeto de detectar defectos crticos de
forma temprana.
o Actualizar la lista de evaluacin de riesgos (risk assessment worksheet) de forma
regular.
Los riesgos pueden desaparecer (el proveedor ha entregado en el plazo
acordado).
Pueden aparecer nuevos riesgos (el cliente solicito funciones adicionales).
Los riesgos pueden cambiar (epidemia de gripe).
365 de 418
V Gestin de Pruebas
05 Riesgo y pruebas
Gestin de riesgos de producto /1
Beneficios de las pruebas basadas en el riesgo:
o Los mtodos de pruebas son seleccionados de forma particular con el objeto de
mitigar los riesgos identificados.
o El alcance de las pruebas se ocupa de los riesgos identificados.
o El alcance del proceso de pruebas tiene en cuenta los riesgos identificados. De esta
forma, el esfuerzo en el proceso de pruebas se centra en abordar la reduccin del
riesgo potencial.
o Los fallos peligrosos son detectados de forma temprana, por lo tanto se hace ms
econmica su correccin.
o Incluso en el caso de un aborto de pruebas, se asegura que los casos de prueba ms
importantes han sido ejecutados (asignacin de prioridades a pruebas basada en el
riesgo).
366 de 418
V Gestin de Pruebas
05 Riesgo y pruebas
Riesgo y pruebas - Resumen
Los riesgos asociados al proyecto y al producto ponen en peligro el xito del proyecto, los
riesgos deben ser gestionados.
Los riesgos pueden ser tecnolgicos, del entorno o estar asociados a la organizacin.
Nmero de Riesgo (valor) = Probabilidad de ocurrencia por dao potencial.
367 de 418
V Gestin de Pruebas
Agenda

368 de 418
V Gestin de Pruebas
06 Gestin de incidencias
Deteccin de errores durante las pruebas
El probador ejecuta los casos de prueba y registra los resultados.
Posteriormente analizan las desviaciones entre los resultados esperados y los obtenidos:
o Se identifican los fallos (los fallos pueden ocurrir en todo lugar: en documentos, en
el cdigo, en los datos de salida de un objeto de prueba, en un texto de ayuda).
En este punto (temporal), las tareas del probador han finalizado por el momento
o El probador espera la versin corregida del programa para ejecutar la repeticin de
pruebas (retest).
Posteriormente, el seguimiento de errores se realiza utilizando un sistema de gestin de
errores (sistema de gestin de errores / defectos).
369 de 418
V Gestin de Pruebas
Quin hace qu? /1
Probador (tester)
o Ejecuta los casos de prueba con el objeto de detectar errores.
o Registra los resultados en un protocolo de pruebas.
o Introduce los errores en un repositorio (informe de problemas).
Jefe de pruebas (test manager).
o Evala el informe de problemas.
o Asigna prioridades a los errores (de acuerdo con la direccin del proyecto, cliente,
etc.)
o Redacta el informe de estado en funcin del estado actual de las labores de
correccin.
370 de 418
V Gestin de Pruebas
Quin hace qu? /2
Comit de Control del Cambio (CCC) (Change Control Board - CCB).
o Decide con respecto a los cambios de requisitos y sus prioridades.
Desarrollador (developer).
o Analiza los fallos, localiza la causa del error.
o Corrige la causa de error de acuerdo con la prioridad asignada.
o Ejecuta todos los cambios aprobados.
Todas estas tareas son ejecutadas de forma iterativa:
o Probador (tester).
o Jefe de pruebas (test manager).
o Consejo de Control de Cambio (CCC)
o Desarrollador.
371 de 418
V Gestin de Pruebas
Estructura de un informe de incidencias (informe de errores) /1
El Informe de incidencias describe el defecto de un error, no su causa.
La estructura de un informe de incidencias puede ser encontrada en el estndar IEEE 829
(Anomaly Report).
Elementos que puede Incluir un informe de incidencias:
o Datos del error.
Nmero nico del error (puede ser generado de forma automtica).
Objeto de prueba (nombre, versin), pasos de prueba
Ambiente de pruebas.
Nombre del autor del informe de Incidencias.
Fecha de la primera ocurrencia.
o Clasificacin de errores.
Clase de error (error class), por ejemplo crtico, menor.
Estado del error (error state), por ejemplo error nuevo, repeticin de prueba,
etc.
Prioridad (priority)
372 de 418
V Gestin de Pruebas
Estructura de un informe de incidencias (informe de errores) /2
Elementos que se puede incluir un informe de incidencias:
o Descripcin.
Caso de prueba (aporta todos los detalles de las precondiciones).
Resultado errneo, modo de fallo (usando una descripcin del resultado
obtenido y el resultado esperado).
Descripcin de la desviacin para facilitar su solucin.
Severidad del error (Impacto, afectados, implicados)
Referencias cruzadas con informes relacionados.
Comentarios.
Acciones correctivas tomadas.
o Registro histrico
Tiempo y usuario de correccin
Muchos sistemas siguen automticamente los cambios en el ciclo de vida del
incidente
373 de 418
V Gestin de Pruebas
Clase de error y prioridad del error
La severidad de un error se expresa por la asignacin de una clase de error.
o Las clases de errores a utilizar pueden ser: error crtico, error mayor, error medio,
error menor. Son frecuentes tres o cuatro clases de errores.
o El criterio para la clasificacin puede ser influenciado por la usabilidad del producto.
La prioridad tiene en cuenta el efecto del error:
o Impacto sobre la funcionalidad del programa.
o Impacto sobre el proyecto, sobre el cliente.
o Posibilidad de aportar una solucin (correccin) inmediata al problema o en la
siguiente entrega.
La prioridad rige la urgencia de la correccin.
374 de 418
V Gestin de Pruebas
Estado de un error /1
El estado de un error aporta informacin relativa al progreso o evolucin del trabajo que
ha sido desarrollado para este error.
Los posibles estados de un error son, pero no estn limitados a los siguientes:
o Nuevo (new): El probador ha Introducido un error en el sistema.
o Abierto (open): El Jefe de pruebas ha confirmado el informe del problema.
o Rechazado (rejected): El Jefe de pruebas ha rechazado el informe del problema.
o Inspeccin (inspection): El desarrollador intenta Identificar el error.
o En observacin (surveillance): El error no puede ser reproducido, se encuentra bajo
vigilancia.
o Trabajo en progreso (work in progress): El error es localizado y preparado para su
correccin.
o Repeticin de pruebas (retest): El desarrollador ha corregido la causa del error.
o Finalizado (finalized): E| probador ha verificado la correccin o travs de la
repeticin de las pruebas.
o No resuello (not solved): El probador no ha podido verificar la correccin, el error
an est presente.
375 de 418
V Gestin de Pruebas
Flujo de los estados tpicos y transiciones de la gestin de incidentes.
nuevo
rechazado
abierto
en observacin
inspeccin
trabajo en progreso
No resuelto
retest
finalizado
El nmero de estados soportados

por herramientas puede variar
enormemente. Pueden ser 3 o
pueden ser 20.
376 de 418
V Gestin de Pruebas
Slo un probador puede poner un error en estado finalizado
Normalmente el jefe de pruebas decide si un error debe ser corregido o rechazado. De
forma alternativa, l comit de control del cambio puede decidir sobre la correccin de
un error teniendo en cuenta el costo de la solucin.
Todos los cambios (incluidos los comentarios) deben ser registrados en el sistema de
gestin de incidencias.
o El control continuo sobre el estado de correccin de un error est asegurado.
o Las actividades de pruebas futuras pueden ser planificadas.
o En ocasiones, pueden ser generados casos de prueba adicionales con el objeto de
localizar la causa de un fallo.
377 de 418
V Gestin de Pruebas
Anlisis del informe de incidencias
Todos los informes son analizados de manera sistemtica con el fin de evaluar el estado
de las actividades de correccin, el plan de conformidad del proyecto y la calidad del
software.
Tpicos puntos de atencin.
o Detectar una reduccin o aumento en el nmero de defectos nuevos durante el
ciclo de vida del proyecto.
o Se detecta en un objeto de pruebas un alto nmero de defectos?
o Se encuentran defectos crticos aun abiertos?
o Algn defecto lleva mucho tiempo sin ser corregido?
Los gestores de incidentes proveen una variedad de reportes de estadsticas de defectos.
378 de 418
V Gestin de Pruebas
Gestin de incidencias - Resumen
La gestin de incidentes es la gestin de los defectos encontrados durante las pruebas.
La gestin de incidentes es un proceso con un propio y particular flujo.
Para el manejo de incidentes existen herramientas, que permiten cubrir las tareas para la
gestin de cambios.
La expresin gestin de desviaciones es sinnimo de gestin de incidentes.
379 de 418
VI Herramientas de soporte de pruebas

Agenda
Captulo VI Herramientas de soporte de pruebas
VI/01 Tipos de herramientas de prueba.
VI/02 Uso efectivo de herramientas.
VI/03 Introduccin de una herramienta en una Organizacin.
380 de 418

01 Tipos de herramientas de prueba
Observaciones generales
Las herramientas de prueba se pueden utilizar para apoyar las actividades de prueba
o El soporte a la ejecucin de la prueba se conoce como automatizacin de pruebas
o Las herramientas de prueba tambin pueden apoyar otras actividades de prueba.
Las herramientas de prueba se nombran segn el tipo de soporte que proporcionan.
o Las herramientas estn disponibles para cada nivel del proceso de pruebas.
En analoga con
o CASE-Tools (Computer Aided Software Engineering), Todas las herramientas de
prueba se refieren a veces como CAST-Tools (Computer Aided Software Testing)
381 de 418

Entendiendo el significado y propsito de las herramientas de soporte de pruebas /1
Herramientas que pueden utilizarse para una o ms actividades de soporte de pruebas
o Las herramientas que se utilizan directamente en las pruebas como las herramientas
de ejecucin pruebas, herramientas de generacin de datos y herramientas de
comparacin de resultados.
o Herramientas que ayudan en la gestin del proceso de pruebas, como las utilizadas
para administrar las pruebas, resultados, requisitos de datos, incidencias, defectos,
etc. y de informacin y control de ejecucin de pruebas.
o Las herramientas que se utilizan en pruebas de reconocimiento o exploracin.
o Cualquier herramienta que ayuda en la prueba (por ejemplo, una hoja de clculo)
382 de 418

Las herramientas de apoyo de pruebas pueden tener uno o ms de los siguientes
propsitos en funcin del contexto:
o Mejorar la eficiencia de las actividades de pruebas mediante la automatizacin de
tareas repetitivas y el apoyo a las actividades manuales como la prueba de la
planificacin de controles, diseo y presentacin de informes.
o Automatizacin de las actividades que requieren recursos importantes cuando se
hace manualmente (por ejemplo, pruebas estticas).
o Automatizacin de actividades que no se puede ejecutar de forma manual (por
ejemplo, pruebas de rendimiento).
o Aumentar la fiabilidad de las pruebas (por ejemplo, mediante la automatizacin de
las comparaciones de datos de gran tamao o simulacin del comportamiento).
383 de 418

El trmino MARCO DE PRUEBAS (TEST FRAMEWORK) tambin se utiliza frecuentemente
en la industria, por lo menos con alguno de los siguientes significados:
o Bibliotecas reutilizables y extensibles de pruebas que se pueden utilizar para
construir herramientas de prueba (tambin llamadas pruebas de arns).
o Un tipo de diseo de automatizacin de pruebas .
o En general el proceso de ejecucin de las pruebas.
384 de 418

Clasificacin de herramientas de pruebas /1
Las herramientas para tareas especiales vs. Herramientas para suites de pruebas
o Herramientas individuales: Soportan una actividad de prueba particular.
o Suite de Herramientas: Cubren varias tareas e integran varias herramientas individuales.
Herramientas de prueba intrusivas vs. Herramientas de prueba que no alteran el objeto de
prueba
o Herramientas intrusivas: Pueden interferir en la ejecucin del objeto de prueba y puede
causar cambios del objeto con respecto de la ejecucin del mismo en el entorno real
(efecto de sonda)
o Depuradores introducen puntos de ruptura y alteran el manejo de interrupciones.
o Drivers de prueba proporcionan a los objetos de prueba entradas de datos simulados.
o La cobertura incluye contadores que se agregan al cdigo.
Esto no siempre es deseado
o Durante las pruebas de rendimiento, el objeto de prueba debe ejecutarse lo ms cercano
a la ejecucin en el ambiente real.
o Durante las pruebas del sistema, los objetos de prueba deben estar integrados en un
ambiente de tiempo real.
385 de 418

Clasificacin de herramientas de pruebas /2
Las herramientas de prueba se pueden clasificar segn varios criterios
o Comercial, libre, de cdigo abierto, de prueba (shareware), por la tecnologa que
usa.
o Se clasifican segn la actividad con la que estn ms estrechamente asociadas.
o Algunas herramientas soportan una actividad, otras soportan varias actividades.
o Paquetes de un solo proveedor que han sido diseados para trabajar en conjunto.
Ejemplo de herramientas que se pueden desarrollar al interior de la organizacin de
pruebas (InHouse)
o Hojas de clculo en Excel.
o SQL scripts.
o Bases de datos para el manejo de los datos de prueba.
o Herramientas de comparacin de resultados especficos de prueba.
386 de 418

Herramientas de soporte de pruebas /1
Herramientas de gestin de pruebas
o Recolecta, clasifica y administra de casos de prueba
o Evaluacin conjuntos de mtricas que describen los casos de prueba
o Controla la planificacin de tiempo, recursos y presupuesto.
o Crea informes de progreso, evaluacin y documentacin de las pruebas.
o Interconectar herramientas de ejecucin de pruebas, herramientas de seguimiento
de defectos y herramientas de gestin de requisitos.
o Realizar el seguimiento del objeto de prueba de acuerdo con la especificacin de
requisitos (consistencia).
o Gestin de versiones (gestin o administrador de la configuracin).
Herramientas de gestin de requisitos (requerimientos).
o Rene los requisitos y sus atributos asociados.
o Prioriza las necesidades.
o Referencia los requisitos para los casos de prueba para comprobaciones de
consistencia.
o Identifica los requisitos incompatibles y o que se estn perdiendo
387 de 418

Herramientas de soporte de pruebas /2
Herramientas de manejo de Incidentes (Herramientas de seguimiento de defectos)
o Registra y realiza seguimiento de incidentes (defectos, fallos, anomalas, etc.).
o Almacenar y gestionan las solicitudes de cambio.
o Priorizan, categorizan y clasifican los defectos.
o Evalan y miden el grado de avance de las pruebas.
o Muestran el flujo de trabajo para el ciclo de vida de un defecto, con el histrico de
cambios de estado y responsables.
Herramientas de gestin de la configuracin
o Realizan seguimiento de las versiones de los componentes:
o Gestin de versiones de los objetos de prueba, bases de prueba, configuraciones y
otras herramientas.
o Administra las del cdigo fuente y cdigo del objeto.
o Crea referencias a la gestin de pruebas, gestin de requisitos y a la gestin de
cambios.
388 de 418

Herramientas de soporte de pruebas estticas /1
Herramientas de revisin.
o Apoyo a los procesos de revisin (workflow), incluyendo listas de control,
directrices, comentarios de revisin.
o Permiten documentar los resultados de la revisin.
o Permiten evaluar los resultados de la revisin.
o Proporcionan listas de control o directrices para los revisores.
o Apoyan las revisiones en lnea y los equipos de pruebas ubicados en diferentes
lugares.
o Proporcionar trazabilidad entre los documentos y el cdigos fuente
389 de 418

Herramientas de soporte de pruebas estticas /2
Herramientas de anlisis esttico
o Validan el cumplimiento de estndares de codificacin y codificacin segura.
o Analizan de la estructura del cdigo.
o Anlisis de control de flujo, cdigo inalcanzable (muerto), mtricas para la
complejidad del cdigo (nmero ciclomtico).
o Informa de anomalas en el flujo de datos.
o Verificacin de cdigo HTML o XML.
Herramientas de Modelado
o Anlisis de modelos de datos, verificacin de consistencia del modelo
o Anlisis de los documentos de especificaciones, diseo de modelado de objetos,
diagramas de estado.
o Generacin de casos de prueba basados en el modelo de software (opcional)
o Prerequisito: Las especificaciones se entregan en un documento con lenguaje
formal.
o Por tener una relacin con el proceso de desarrollo de software, es considerada
comnmente una herramienta de desarrollo.
390 de 418

Herramientas de soporte de pruebas de especificacin (funcionales) /1
Herramientas de diseo de prueba: son utilizadas para generar entradas de datos de
prueba, para las interfaces grficas de usuario, modelos de diseo o en el cdigo.
Herramientas para preparacin de datos de prueba: permiten manipular bases de datos,
o archivos.
Las herramientas obtienen los datos a partir de descripciones formales o definiciones de
estructuras.
o Hacen que los datos sean annimos para garantizar la seguridad.
o Los datos generados de forma automtica a menudo tendrn que ser trabajados
nuevamente de forma manual (retest).
Las herramientas se clasifican en funcin de la fuente de los datos:
o Diseo de bases de datos.
o Cdigo fuente.
o Especificacin de interface.
o Especificacin del objeto.
o Robots de prueba.
391 de 418

Generadores de datos de prueba basados en la base de datos.
o Se generan los datos de las bases de datos o de archivos planos.
o Se obtienen los datos del reconocimiento de las estructuras y los contenidos.
Generadores de datos de prueba basados en el cdigo.
o Se generan los datos de prueba a partir del cdigo fuente
o No son capaces de proporcionar los valores esperados de resultado.
o Al igual que los mtodos de caja blanca, slo pueden generar datos de prueba sobre
la base del cdigo proporcionado.
o No pueden identificar funcionalidad faltante.
392 de 418

Generadores de datos de prueba basados en la Interfaz.
o Generacin de datos de acuerdo a los parmetros de interfaz.
o Se derivan las clases de equivalencia y valores lmite directamente de los rangos
definidos por los parmetros.
o No se puede proporcionar los valores esperados de resultado, pero bien podra ser
usado para pruebas de robustez.
Generadores de pruebas basados en las especificaciones.
o Generar datos de prueba directamente de los documentos de especificacin.
o La especificacin de documentos debe utilizar una notacin rigurosa.
o Los documentos producidos con la ayuda de las herramientas CASE (CASE-Tools)
proveen una buena base para este tipo de herramientas.
393 de 418

Robots de prueba
o Pueden direccionar interfaces externas directamente del objeto de pruebas.
o Pueden aceptar o proporcionar datos, el desarrollo de la prueba se ejecuta
automticamente.
o A menudo proporcionan una funcin de comparacin de los resultados obtenidos
con los resultados esperados.
o Frecuentemente herramientas de captura y repeticin son utilizadas como robots
de prueba. Estas herramientas registran los pasos de ejecucin de pruebas a travs
de la interfaz de usuario y los guarda como un archivo de comandos.
o Permiten la repeticin automtica de las secuencias de prueba, utilizando la
secuencia de comandos grabada.
o Muy adecuado para las pruebas de regresin y las pruebas de exploracin.
394 de 418

Herramientas para ejecucin y registro de pruebas /1
Para todos los niveles de prueba, las herramientas se pueden introducir para apoyar la
ejecucin de la pruebas.
Las herramientas de ejecucin de pruebas podrn abarcar las siguientes actividades:
o Entrega de datos.
o Recepcin de datos o registro por escrito del comportamiento de datos de salida.
o Documentacin de la ejecucin de pruebas.
Ejemplos de las herramientas de ejecucin de pruebas:
o Herramientas de ejecucin de pruebas, depurador.
o Comparadores de prueba.
o Pruebas de arns, Pruebas unitarias de Framework.
o Herramientas de medicin de cobertura.
o Herramientas de prueba de seguridad.
395 de 418

Herramientas de ejecucin de pruebas, depurador
o Herramienta para encontrar errores en el cdigo del programa.
o La secuencia de la ejecucin del programa se puede interrumpir.
o Las declaraciones individuales y las condiciones se pueden comprobar.
o Las variables pueden ser referenciadas y definidas de forma individual.
Comparadores de prueba
o Comparan los resultados previstos y reales basadas en archivos o bases de datos de
diferentes formatos.
o Los datos a comparar son seleccionados usando funcionalidades de filtrado de
datos.
o A menudo son parte de un framework, pero tambin puede ser una herramienta
independiente.
396 de 418

Pruebas de arns, Pruebas unitarias de Framework.
o Prueba los componentes o partes de un sistema.
o Simulacin del entorno en el que el objeto de prueba se ejecutar, a travs del uso
de simulacin de objetos por medio de DRIVERS y/o STUBS.
o Se trata de una rplica del entorno productivo (o una parte del mismo) y es
necesario cuando restricciones de seguridad impiden el uso del entorno productivo.
o La representacin del entorno productivo debe estar lo ms cerca posible.
o Si la prueba se centra en el anlisis de un componentes, puede ser tambin llamada
prueba unitaria de framework.
o DRIVER
Permitir el acceso al objeto de prueba cuando las interfaces no estn disponibles.
Regula la entrada y salida de datos. Registra el progreso de la prueba.
Registra los resultados en tiempo real
Proporcionan a menudo su entorno propio sistema
o STUBS
Simular la funcionalidad de un componente que no se encuentra disponible.
397 de 418

Herramientas de medicin de cobertura.
o Esta herramienta puede ser intrusiva o no intrusiva
o Mide el porcentaje de cdigo de una estructura que se han ejecutado para un
conjunto de pruebas (set).
o Cuenta las sentencias, las ramas, decisiones, los mdulos y los llamados a funciones.
Herramientas de pruebas de seguridad
o Evalan las caractersticas de seguridad de software
o Evalan la capacidad del software para proteger la confidencialidad, integridad,
autenticacin, autorizacin y disponibilidad.
o Frecuentemente se centran en una tecnologa, plataforma o propsito particular.
o Estas herramienta son muy especializadas y son usadas por expertos.
398 de 418

Herramientas de soporte de control y rendimiento /1
Apoyan o automatizan las tareas de anlisis de pruebas.
Se clasifican de acuerdo a su uso
o Herramientas de anlisis dinmico
o Herramientas de pruebas de rendimiento, carga y estrs.
o Herramientas de control
399 de 418

Herramientas de anlisis dinmico.
o Encuentran defectos que son evidentes slo cuando el software se est ejecutando.
o Encuentran dependencias de defectos.
o Encuentran prdidas de memoria.
o Encuentran defectos en la asignacin de punteros o defectos aritmticos.
o Importante para los sistemas mltiples o sistemas de sistemas.
o Normalmente se utiliza en pruebas de componentes, de integracin de
componentes y en el control y registro del estado interno del objeto de prueba.
400 de 418

Herramientas de pruebas de rendimiento, carga y estrs.
o Permiten monitoreo, medicin y reporte del comportamiento del sistema bajo una
variedad de condiciones simuladas de uso. Por ejemplo, nmero de usuarios
simultneos, frecuencia y porcentaje relativo de transacciones.
o Permiten crear usuarios virtuales para la realizacin de un conjunto seleccionado de
transacciones, propagndolas en varias maquinas de pruebas. Comnmente se
conocen como generadores de carga.
o Generan una carga artificial de transacciones de usuario paralelas o trfico de red
(esto no es posible con recursos humanos).
o Permite encontrar cuellos de botella.
Herramientas de control
o Continuamente analizan, verifican e informan sobre el uso de los recursos
especficos del sistema y advierten de los posibles problemas de un servicio.
401 de 418

Herramientas de soporte para necesidades especificas de pruebas.
Evaluacin de la Calidad de Datos
o Los datos son el centro de algunos proyectos
o Conversin de datos, migracin de proyectos
o Aplicaciones como los almacenes de datos y sus atributos.
o Se puede variar en funcin de su condicin crtica y el volumen
o Son necesarias herramientas para evaluar la calidad de los datos que se emplearn
para verificar las conversiones de datos y reglas de migracin.
o Permiten asegurarse de que los datos procesados son correctos, completos y
cumplen un estndar predefinido.
o Permite establecer la dimensin de la calidad de datos (accesibilidad, credibilidad,
integridad, relevancia, libre de errores, facilidad de interpretacin, seguridad, etc.)
o Libre de error representa que los datos son correctos. La mtrica se puede definir
como de unidades de datos con error dividido por el nmero total de unidades.
Otras herramientas de pruebas existen para las pruebas de usabilidad
o Grabadores de pantalla, es una herramienta de registro de eventos web.
402 de 418

Agenda
403 de 418

02 Tipos Uso efectivo de herramientas
Beneficios y riesgos potenciales de las herramientas de soporte de pruebas /1
El uso de herramientas de prueba ocasiona esfuerzo y costos.
o Proporciona la herramienta adecuada
o Es necesario el desarrollo de habilidades para el uso de la herramienta.
o Instalacin de la herramienta en el ambiente del sistema.
o Es necesario el ajuste de la herramienta o el ajuste de parmetros.
o Garantiza el esfuerzo de las operaciones de administracin del sistema.
o Cambios a travs del tiempo hacen necesario preparar otras pruebas.
o Tiempo y el esfuerzo durante la operacin de la herramienta.
o Un anlisis de costo/beneficio del uso de una herramienta debe realizarse antes de
su implantacin.
o En algunos casos, el beneficio total slo es evidente para el uso de herramientas en
ms de un proyecto.
404 de 418

02 Uso efectivo de herramientas
Beneficios potenciales del uso de herramientas.
o El trabajo repetitivo se reduce.
o Iteracin de actividades idnticas.
o Refuerzo de la consistencia y repeticin.
o Generacin de mtricas, por ejemplo, cobertura.
o Facilidad de acceso a la informacin sobre las pruebas.
o Gestin de datos con herramientas de prueba permite una diversidad de
evaluaciones.
o Proporcionar una mejor base de informacin para la toma de decisiones.
405 de 418

Los riesgos de utilizar herramientas incluyen:
o Funcionalidad de la herramienta de prueba no cumple las expectativas.
o La usabilidad de la herramienta de prueba no cumple las expectativas.
o Subestimar el tiempo y el esfuerzo necesario para alcanzar beneficios significativos y
continuos por el uso de la herramienta.
o Otros requisitos de calidad no se cumplen
o El beneficio se haba sobrestimado
o Los costos de compra, la introduccin o la operacin se subestimaron.
o Subestimar el esfuerzo necesario para mantener los datos de prueba generados por
la herramienta.
o La excesiva dependencia de la herramienta (las pruebas manuales seran mejor?).
o El descuido de control de versiones de los datos de prueba generados por la
herramienta.
406 de 418

Implementacin incorrecta de la herramienta
o Descuidar las relaciones y los problemas de interoperabilidad entre herramientas,
tales como herramientas de gestin de requisitos, herramientas de control de
versiones, herramientas de gestin de incidencias y las herramientas de otros
proveedores.
o Riesgo de que los proveedores de herramientas salgan del negocio, retir de la
herramienta o venta de la herramienta a un proveedor diferente.
o Mala respuesta del proveedor de soporte, actualizaciones y soluciones de defectos.
o Riesgo de suspensin de cdigo abierto para herramientas de este tipo.
o Falsa expectativa de que una herramienta va a resolver todos los problemas de las
pruebas.
o Una herramienta no puede sustituir un proceso que no existen o compensar un
procedimiento descuidado.
o Introduccin de una nueva herramienta en las fases crticas del proyecto.
o Imprevistos tales como la incapacidad para soportar una nueva plataforma.
407 de 418

Consideraciones especiales para algunos tipos de herramienta /1
Herramientas de ejecucin de pruebas
o Ejecutar los objetos de prueba utilizando automticamente scripts de prueba.
o A menudo se requiere un esfuerzo significativo para lograr importantes beneficios.
o Habilidades y conocimientos de un desarrollador para programar las secuencias de
comandos (scripts) son siempre necesarios cuando se despliegan robots de prueba.
o Los resultados esperados de las pruebas tienen que ser entregados para su
evaluacin y la comparacin automatizada, de lo contrario podra ser desperdiciado
el potencial de la herramienta.
408 de 418

Enfoque de pruebas basado en datos
o Las secuencias de comandos ejecutan las funciones del programa del objeto de
prueba. El script busca datos en un archivo externo. Por ejemplo, hoja de clculo o
base de datos.
o Probadores que deseen ejecutar casos de prueba nuevos o modificados, no deben
escribir nuevas secuencias de comandos, sino adaptar el archivo externo.
o Cambios en los datos o en la interfaz grfica de usuario puede alterar la reaccin del
objeto de prueba, pueden producirse problemas de procesamiento.
409 de 418

Otras tcnicas empleadas en las tcnicas basadas en datos
o Codificacin de datos.
Los datos son generados utilizando algoritmos basados en los parmetros configurables en
tiempo de ejecucin y se suministran a la aplicacin.
Una herramienta puede usar un algoritmo que genera una muestra aleatoria de un ID de
usuario. La repeticin est dada en un patrn que tambin controla la aleatoriedad.
o Enfoque de pruebas basadas en palabras clave
Los guiones son modulares hasta llegar al detalle de las interacciones atmicas del usuario con el
objeto de prueba. Secuencias de prueba extremadamente flexibles se pueden crear sin editar los
scripts.
Los datos de prueba y las funciones invocadas se guardan externamente. Una secuencia de
comandos de control las evala y las lleva a las funciones particulares.
En el comienzo, un programador es necesario para escribir la secuencia de comandos (script).
Probadores sern capaces de definir las pruebas sin conocer el lenguaje de programacin, slo
usan las palabras clave.
Problema: los datos externos necesarios crecern rpidamente en complejidad.
Para ambas tcnicas, los resultados esperados para cada prueba tienen que ser almacenados para su posterior
comparacin.
410 de 418

Las herramientas de pruebas de rendimiento se utilizan principalmente en aplicaciones
que se distribuyen y que se comunican a travs de redes.
En la mayora de los casos, el entorno de prueba no puede ser completamente aislado y
est sujeto a la influencia de factores que no se conocen en detalle en el momento de la
preparacin y ejecucin de pruebas.
La complejidad del medio ambiente puede hacer imposible la repeticin de pruebas
idnticas (los resultados son difcilmente comparables).
En muchos casos, el conocimiento experto detallado es necesario para analizar y
determinar las conclusiones correctamente.
411 de 418

Herramientas de anlisis esttico
o Examinan el cdigo fuente para comprobar el cumplimiento de la conformidad, por
ejemplo, normas de programacin.
o A menudo es necesario para preparar el cdigo para el anlisis esttico.
o Un problema frecuente: una cantidad relativamente grande de indicaciones, es
difcil identificar su importancia, pueden ayudar el uso de filtros.
o Una buena prctica es no slo para limpiar los defectos, sino tambin las
advertencias.
Herramientas de gestin de pruebas
o La informacin debe ser abiertamente accesible.
o Una hoja de clculo es la herramienta ms utilizada por el director de pruebas para
las evaluaciones y los informes.
o Los informes y las evaluaciones deben adaptarse a la organizacin, no al contrario.
412 de 418

Agenda
413 de 418

03 Introduccin de una herramienta en una Organizacin
Seleccin de una herramienta para una organizacin /1
Es un proceso difcil que debe ser controlado y administrado
Pasos hacia la introduccin de herramientas
o Evaluacin: Identificar las fugas o debilidades donde el proceso de prueba puede ser
soportado por una herramienta de pruebas (organizacin, debilidades, fortalezas,
etc.).
o Definicin de Requisitos: Las demandas de la herramienta deben ser claramente
definidas, ponderadas y vinculadas a criterios medibles.
o Evaluacin: Realizar una lista de herramientas. Realizar pruebas de conformidad con
la funcionalidad requerida y evaluar criterios de calidad, por ejemplo, licencias,
soporte de proveedores, etc.
o Pruebas de concepto: Identificar todos los cambios necesarios para utilizar la
herramienta de manera efectiva, como por ejemplo, infraestructura, procesos.
Probar si la herramienta ocasionar el efecto y soporte para el proceso de pruebas.
414 de 418

Seleccin de una herramienta para una organizacin /2
Pasos para la implantacin de la herramienta:
o Evaluacin del proveedor: Lista de todos los posibles candidatos con sus
caractersticas claves, verificar el resultado de la evaluacin y tomar una decisin
final.
o El uso de la herramienta: Identificar los requisitos internos para el entrenamiento y
formacin. Lo ideal es establecer un proyecto piloto para introducir la herramienta
gradualmente antes de su despliegue.
o Evaluacin de entrenamiento: Habilidades del equipo de pruebas para orientar la
formacin necesaria.
o Relacin Costo/Beneficio: Un caso de negocio concreto ser la base para
determinar la relacin Costo/Beneficio.
415 de 418

Ventajas de un proyecto piloto para la introduccin de herramientas
Conocer la herramienta en detalle con sus puntos fuertes y dbiles

Interfaz con otras herramientas en uso, la adaptacin de los procesos y flujos de trabajo.
Definicin de los informes de acuerdo con las normatividad de las organizaciones.
Evaluar si la herramienta cumple con los beneficios esperados.
Estimar si el costo de la implementacin est dentro del mbito.
No se recomienda realizar despliegue sin antes ejecutar unas pruebas piloto, de lo
contrario puede haber problemas de aceptacin.
416 de 418

Factores de xito para la implementacin de la herramienta dentro de una organizacin
Introduccin paso a paso, desarrollo de forma incremental y luego implementacin
completa en la organizacin, no slo en un proyecto o departamento.
Hacer uso de la herramienta obligatoria para los respectivos flujos de trabajo y procesos.
Directrices de usuario son necesarias para la implementacin de herramientas.
Los usuarios deben tener acceso a una formacin adecuada, un apoyo rpido debe estar
disponible para el equipo de pruebas.
Las experiencias adquiridas desde la implementacin de herramientas deben estar
disponibles para todos los usuarios.
El uso real de la herramienta debe ser objeto de seguimiento, de modo que las
intervenciones necesarias puedan mejorar su aceptacin.
Recopilar de las lecciones aprendidas de todos los equipos de pruebas.
417 de 418

Resumen
Hay una amplia gama de herramientas de prueba disponibles que abarcan diversas
tareas:
o Herramientas de gestin de pruebas.
o Herramientas de planificacin de pruebas.
o Herramientas de especificacin de pruebas.
o Herramientas de ejecucin de pruebas.
o Herramientas para el anlisis de objetos de prueba.
o Herramientas de apoyo a pruebas no funcionales.
La implementacin de herramientas debe llevarse a cabo sobre la base de un anlisis de
costo/beneficio.
La introduccin de una herramienta de prueba nueva debe ser preparada
cuidadosamente con el fin de tener xito.
Se recomienda una implementacin paso a paso, comenzando con un proyecto piloto,
para el despliegue de herramientas de prueba.
418 de 418
AGRADECEMOS SU PARTICIPACION
LES DESEAMOS UN EXAMEN EXITOSO
PARA CONVERTIRSE EN MIEMBRO DEL
ISTQB
COMO PROBADOR CERTIFICADO EN NIVEL BSICO

Curso ISTQB Español

Transféré par

Informations du document

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

Curso ISTQB Español

Transféré par

Droits d'auteur :

Formats disponibles

2 de 418

Foundation Level Syllabus (2010) Traduccin por Norman Burbano. nebroc@gmail.com

Foundation Level Syllabus (2010) Traduccin por Norman Burbano. nebroc@gmail.com

Foundation Level Syllabus (2010) Traduccin por Norman Burbano. nebroc@gmail.com

Foundation Level Syllabus (2010) Traduccin por Norman Burbano. nebroc@gmail.com

Foundation Level Syllabus (2010) Traduccin por Norman Burbano. nebroc@gmail.com

I - Fundamentos de Pruebas Software

Por qu es necesario Probar?

Foundation Level Syllabus (2010) Traduccin por Norman Burbano. nebroc@gmail.com

I - Fundamentos de Pruebas Software

Foundation Level Syllabus (2010) Traduccin por Norman Burbano. nebroc@gmail.com

I - Fundamentos de Pruebas Software

Foundation Level Syllabus (2010) Traduccin por Norman Burbano. nebroc@gmail.com

I - Fundamentos de Pruebas Software

Foundation Level Syllabus (2010) Traduccin por Norman Burbano. nebroc@gmail.com

I - Fundamentos de Pruebas Software

Foundation Level Syllabus (2010) Traduccin por Norman Burbano. nebroc@gmail.com

I - Fundamentos de Pruebas Software

El costo de los defectos

Foundation Level Syllabus (2010) Traduccin por Norman Burbano. nebroc@gmail.com

I - Fundamentos de Pruebas Software

Foundation Level Syllabus (2010) Traduccin por Norman Burbano. nebroc@gmail.com

I - Fundamentos de Pruebas Software

Foundation Level Syllabus (2010) Traduccin por Norman Burbano. nebroc@gmail.com

I - Fundamentos de Pruebas Software

Foundation Level Syllabus (2010) Traduccin por Norman Burbano. nebroc@gmail.com

I - Fundamentos de Pruebas Software

Pruebas dinmicas incluye la ejecucin

Foundation Level Syllabus (2010) Traduccin por Norman Burbano. nebroc@gmail.com

I - Fundamentos de Pruebas Software

Foundation Level Syllabus (2010) Traduccin por Norman Burbano. nebroc@gmail.com

I - Fundamentos de Pruebas Software

Foundation Level Syllabus (2010) Traduccin por Norman Burbano. nebroc@gmail.com

I - Fundamentos de Pruebas Software

Foundation Level Syllabus (2010) Traduccin por Norman Burbano. nebroc@gmail.com

I - Fundamentos de Pruebas Software

Foundation Level Syllabus (2010) Traduccin por Norman Burbano. nebroc@gmail.com

I - Fundamentos de Pruebas Software

Foundation Level Syllabus (2010) Traduccin por Norman Burbano. nebroc@gmail.com

I - Fundamentos de Pruebas Software

Foundation Level Syllabus (2010) Traduccin por Norman Burbano. nebroc@gmail.com

I - Fundamentos de Pruebas Software

Base de la prueba (test basis o test base):

Foundation Level Syllabus (2010) Traduccin por Norman Burbano. nebroc@gmail.com

I - Fundamentos de Pruebas Software

Foundation Level Syllabus (2010) Traduccin por Norman Burbano. nebroc@gmail.com

I - Fundamentos de Pruebas Software

Foundation Level Syllabus (2010) Traduccin por Norman Burbano. nebroc@gmail.com

I - Fundamentos de Pruebas Software

Por qu es necesario Probar?

Foundation Level Syllabus (2010) Traduccin por Norman Burbano. nebroc@gmail.com

I - Fundamentos de Pruebas Software

Foundation Level Syllabus (2010) Traduccin por Norman Burbano. nebroc@gmail.com

I - Fundamentos de Pruebas Software

Foundation Level Syllabus (2010) Traduccin por Norman Burbano. nebroc@gmail.com

I - Fundamentos de Pruebas Software

Foundation Level Syllabus (2010) Traduccin por Norman Burbano. nebroc@gmail.com

I - Fundamentos de Pruebas Software

Foundation Level Syllabus (2010) Traduccin por Norman Burbano. nebroc@gmail.com

I - Fundamentos de Pruebas Software

Foundation Level Syllabus (2010) Traduccin por Norman Burbano. nebroc@gmail.com

I - Fundamentos de Pruebas Software

Por qu es necesario Probar?

Foundation Level Syllabus (2010) Traduccin por Norman Burbano. nebroc@gmail.com