Iv - V - Istqb CTFL

Luis Mercadal & Asociados
Curso Oficial de ISTQB Certified Tester Foundation Level

- Probador de Software Certificado de Nivel Fundamentos -
Tcnicas de Diseo de Pruebas + Gestin de Pruebas

Captulo IV - Tcnicas de Diseo de Pruebas
IV - Tcnicas de diseo de pruebas

Contenido
Captulo IV - Tcnicas de diseo de pruebas
-
IV/01 Proceso de desarrollo de prueba

IV/02 Categoras de las tcnicas de diseo de prueba
IV/03 Tcnicas basadas en la especificacin o de caja negra
IV/04 Tcnicas basadas en la estructura o de caja blanca
IV/05 Tcnicas basadas en la experiencia
IV/06 Seleccin de las tcnicas de prueba
01 - Proceso de desarrollo de prueba

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
Trazabilidad
Las pruebas deben ser trazables
Qu casos de prueba han sido incluidos en el juego de pruebas? Basados en qu requisitos?
Caso de prueba segn el estndar IEEE 829

-
Precondiciones
Valores de entrada
Resultados esperados
Poscondiciones
Dependencias
Identificador distinguible
Requisitos
www.luismercadal.com.ar | info@luismercadal.com.ar

02 - Categoras de las tcnicas de diseo de prueba

Pruebas de caja negra (black box) y caja blanca (white box)
-
Las pruebas dinmicas se dividen en dos categoras/ grupos
Tcnica de caja negra

-
El probador observa el objeto de prueba como una caja negra

-
Los casos de prueba se obtienen a partir del anlisis de la especificacin (funcional y no funcional) de
un componente o sistema
-
La estructura interna del objeto de prueba es irrelevante o desconocida
Prueba del comportamiento entrada / salida
La funcionalidad es el foco de atencin!

-
Prueba funcional o prueba orientada a la especificacin
Tcnicas de caja blanca

-
El probador conoce la estructura interna del programa / cdigo

-
La jerarqua de los componentes, flujo de control, flujo de datos, etc.
Las casos de prueba son seleccionados en base a la estructura interna del programa / cdigo
La estructura del programa es el foco de atencin!

-
Pruebas basada en la estructura o pruebas basada en el flujo de control
Categoras de las tcnicas de diseo de pruebas

Visin general
-
Mtodos basados en la especificacin
Mtodos basados en la estructura
Mtodos basados en la experiencia

03 - Tcnicas basadas en la especificacin o de caja negra

Tcnicas basadas en la especificacin / de caja negra
-
Particin de Equivalencia (Segmentacin de Equivalencia, Clase de Equivalencia)
Anlisis de Valores Lmite
Tablas de Decisin y Grficos Causa-Efecto
Pruebas de Transicin de Estado
Pruebas de Caso de Uso
General
-
Las pruebas funcionales estn dirigidas a verificar la correccin y la completitud de una funcin
-
Estn disponibles en el mdulo todas las funciones especificadas?
Las funciones ejecutadas presentan resultados correctos?
La ejecucin de casos de prueba deberan ser ejecutados con una baja redundancia, pero sin
embargo con carcter integral / completo
-
Probar lo menos posible, pero
Probar tanto como sea necesario
1. Particin de Equivalencia / Clase de Equivalencia (CE)

-
Dividir los posibles valores en clases, mediante lo cual observan

-
Valores de entrada
Valores de salida
El rango de valores definido se agrupa en clases de equivalencia
Reglas
-
1 clase de equivalencia por valores que produzcan un comportamiento comn
No se superponen
No pueden presentar ningn salto (discontinuidad)
Rangos (por ejemplo, 0 < x < 10) o valores aislados (por ejemplo, x = Verdadero)

Particin de equivalencia vlida y no vlida

-
CE Vlida
CE No Vlida
-
Valores del formato correcto pero fuera del rango
Valores con el formato incorrecto, generalmente, forman parte de una CE separada
El mtodo de la clase de equivalencia aporta casos de prueba para los cuales an debe ser
seleccionado un representante
Las pruebas son ejecutadas utilizando un nico representante de cada CE
Particin de equivalencia - Ejemplo

-
Valores de entrada definidos para x como 0 x 100
Tres (3) clases de equivalencia:

1.
2.
3.
x<0
0 x 100
x > 100
(valores de entrada no vlidos)

(valores de entrada vlidos)
(valores de entrada no vlidos)
CE adicional:
-
Entradas no numricas
Cobertura
-
La cobertura de clases de equivalencia puede ser utilizada como criterio de salida para finalizar las
actividades del proceso de pruebas
Beneficios
-
Puede ser utilizada para lograr objetivos de cobertura de entradas y salidas
Puede ser utilizada para entradas manuales (humanas) o va interfaces de un sistema o

parmetros de interfaces en pruebas de integracin
2. Anlisis de Valores Lmite (Valores Frontera)

-
Ampla la tcnica de particin de equivalencia introduciendo una regla para seleccionar

representantes
Los valores lmite de la CE deben ser probados de forma intensiva

-
Frecuentemente los lmites del rango de valores no estn bien definidos o conducen a distintas
interpretaciones

Comprobar si los lmites han sido implementados (programados) correctamente
La experiencia demuestra que, con mucha frecuencia, los errores tienen lugar en los
lmites del rango de valores!
Asume que:
-
La CE est compuesta de un rango continuo de valores
Se pueden definir los lmites para el rango de valores
Mtodo que sugiere la seleccin de representantes
3. Tablas de Decisin y Grficos Causa-Efecto

-
Particin de Equivalencia y Anlisis de Valores Lmite tratan entradas en condiciones aisladas
Una condicin de entrada puede tener efectos slo en combinacin con otras condiciones de entrada
Los mtodos antes descritos no tienen en cuenta el efecto de dependencias y combinaciones
Explosin de casos de prueba
Con la ayuda del grfico causa-efecto y tablas de decisin obtenidas a partir de aquellos, la
cantidad de combinaciones posibles se puede reducir de forma sistemtica a un subconjunto de las
mismas
Se genera traduciendo la especificacin (normalmente informal) de un objeto de prueba a un lenguaje

formal
-
Aseveracin (assertion)
(Si causa A - entonces efecto E)
Negacin (negation)
(Si causa A - entonces no efecto E)
O (or)
(Si causa A o B - entonces efecto E)
Y (and)
(Si causa A y B - entonces efecto E)
Cada columna de la tabla representa un caso de prueba
Construccin de la tabla de decisin:

-
Seleccionar un efecto
Retroceder en el diagrama para identificar la causa
Cada combinacin de causas est representada por una columna en la tabla de decisin (un caso
de prueba)
Combinaciones de causas idnticas, conducentes a efectos distintos, se pueden fusionar para
formar un nico caso de prueba

4. Pruebas de Transicin de Estado

-
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
Las pruebas de transicin de estado con frecuencia se utilizan en la industria del software embebido
y automatizacin tcnica en general
Cada camino desde la raz a una hoja entonces representa un caso de prueba de prueba de
transicin de estado
5. Pruebas Basadas en Casos de Uso

-
Los casos de prueba se obtienen directamente a partir de los casos de uso del objeto de prueba
Los casos de uso son elementos del Lenguaje Unificado de Modelado (Unified Modeling Language,
UML)
Un diagrama de casos de uso muestra la reaccin del sistema desde el punto de vista del usuario
El objetivo principal de las pruebas de caja negra es probar la funcionalidad del sistema
04 - Tcnicas basadas en la estructura o de caja blanca

Tcnicas basadas en la estructura / de caja blanca
1. Cobertura de Sentencia
2. Cobertura de Decisin / de Rama
3. Cobertura de Condicin
4. Cobertura de Camino
-
Est basada en la estructura identificada del software o del sistema

-
Nivel de componente: la estructura de un componente software, es decir sentencias, decisiones,

ramas, distintos caminos
Nivel de integracin: la estructura puede ser un rbol de llamada (un diagrama en el cual unos
mdulos llaman a otros mdulos)
Nivel de sistema: la estructura puede ser una estructura de un men, un proceso de negocio o la
estructura de una pgina web
Las tcnicas de caja blanca requieren el apoyo de herramientas

- Por ejemplo, McCabe IQ Test Team Edition

Cobertura de Sentencia
-
Cobertura de Decisin / de Rama

-
Cada sentencia es ejecutada al menos una vez, cada decisin toma todos los resultados posibles
al menos una vez
Debemos asegurarnos de que cada rama se ejecuta al menos una vez..
Cobertura de Condicin
-
Cada sentencia / instruccin es ejecutada al menos una vez
Cada sentencia es ejecutada al menos una vez, cada condicin en una decisin toma todos los
resultados posibles al menos una vez
Cobertura de Camino
-
Cobertura exhaustiva.
Debemos garantizar que cada posible camino se ejecuta al menos una vez, lo cual, generalmente,
es impracticable
1. Cobertura de Sentencia
-
Ser detectado el cdigo muerto (cdigo constituido por sentencias que nunca se ejecutan)
No podrn ser detectadas instrucciones faltantes (cdigo que es necesario con el objeto de
cumplir con la especificacin)
1. IF cantidad < 100
2. PRINT "Compra sin descuento"
3. ENDIF
1 caso de prueba para alcanzar el 100% de cobertura de sentencia

3. ELSE
4. PRINT "Compra con descuento"
5. ENDIF
2 casos de prueba para alcanzar el 100% de cobertura de sentencia

2. Cobertura de Decisin / de Rama

-
Cada decisin es verdadera y es falsa, en ambos casos, al menos una vez
Una cobertura de decisin del 100% siempre incluye una cobertura de sentencia del 100%
3. ELSE
4. PRINT "Compra con descuento"
5. ENDIF
2 casos de prueba para alcanzar el 100% de cobertura de sentencia, y tambin 2 casos de prueba
para alcanzar el 100% de cobertura de decisin
3. Cobertura de Condicin
-
Una decisin puede estar compuesta por una o ms condiciones

- Por ejemplo, A < 10 AND B > 50
Cada combinacin de condiciones es ejecutada
1. if (x>0 and y>0) {

2. z = foo(x,y);
Podemos ver lo anterior como dos decisiones, cada una correspondiente a cada simple combinacin en
la sentencia if
1. if (x>0)
2. if (y>0)
3. z = foo(x,y);
4. Cobertura de Camino
-
La cobertura de camino se centra en la ejecucin de todos los posibles caminos a travs de un

programa
-
Un camino es una combinacin de segmentos de programa (en un grfico de flujo de control: una
secuencia de nodos y aristas alternados)
Para cobertura de decisin, un solo camino a travs de un bucle es suficiente. Para la cobertura
de camino hay casos de prueba adicionales:
-
Un caso de prueba no entrante al bucle

Un caso de prueba adicional para cada ejecucin del bucle
Esto puede conducir a un nmero muy alto de casos de prueba

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

-
Un solo bucle puede conducir a una explosin de casos de prueba dado que, toda posible
ejecucin de un bucle constituye un nuevo caso de prueba
Tericamente es posible un nmero indefinido de caminos
La cobertura de camino es ms exhaustiva que la cobertura de sentencia y de decisin

-
Cada posible camino a travs del programa es ejecutado
100% de cobertura de camino incluye 100% de cobertura de decisin, que a su vez incluye 100% de
cobertura de sentencia
05 - Tcnicas basadas en la experiencia

Tcnicas basadas en la experiencia
Prediccin de error (error guessing)
-
Comprobar lista de defectos

-
Enumerar posibles errores
Factores ponderados dependientes del riesgo y probabilidad de ocurrencia
Diseo de caso de prueba

-
Creacin de casos de prueba dirigidos a producir los defectos de la lista
Aumentar la prioridad a aquellos casos de prueba considerando el valor de su riesgo
Actualizar la lista de defectos durante las pruebas

-
Procedimiento iterativo
Es til una coleccin estructurada de experiencias cuando se repite el procedimiento en futuros

proyectos
Pruebas exploratorias (exploratory testing)

-
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
10

Procedimiento:
-
Revisar las partes constituyentes (individuales/identificables) del objeto de prueba
Ejecutar un nmero reducido de casos de prueba, exclusivamente sobre aquellas partes que
deben ser probadas, aplicando prediccin de errores
Analizar los resultados, desarrollar un modelo preliminar (rough model) de cmo funciona el
objeto de prueba
Iteracin: Disear nuevos objetos de prueba aplicando el conocimiento adquirido recientemente
Pruebas basadas en la experiencia versus basadas en la especificacin

-
El diseo intuitivo de casos de prueba es un buen complemento a los enfoques sistemticos

-
Debera ser tratado como una actividad complementaria
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 lo son los casos de prueba definidos 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 a travs de
mtodos sistemticos de prueba
06 - Seleccin de las tcnicas de prueba

Criterios para seleccionar el diseo apropiado de caso de prueba
-
Estado de la informacin respecto del objeto de prueba

-
Se pueden realizar pruebas de caja blanca de alguna manera (cdigo fuente disponible)?
Hay suficiente material de especificacin para definir pruebas de caja negra, o son necesarias
pruebas exploratorias para comenzar?
Objetivos de prueba predominantes

-
Las pruebas funcionales han sido solicitadas de forma explcita?
Qu pruebas no funcionales son necesarias?
Son necesarias pruebas estructurales para lograr los objetivos del proceso de pruebas?
11

Riesgos
-
Se espera un dao/perjuicio serio proveniente de defectos ocultos?
Es muy alta la frecuencia de uso del objeto de prueba?
Hay algn estndar legal o contractual, respecto de la ejecucin de pruebas y cobertura de

pruebas, que deba ser cumplido?
Criterios para seleccionar el diseo apropiado de caso de prueba...

-
Precondiciones del proyecto

-
Cuanto tiempo y quien est planificado/asignado para las pruebas?
Cul es el riesgo de que el proceso de pruebas no sea finalizado segn la planificacin?
Qu mtodos de desarrollo son utilizados?
Cuales son los punto dbiles del proceso asociado al proyecto?
Caractersticas del objeto de prueba

-
Que posibilidades para ser probado ofrece el objeto de prueba?
Cul es la disponibilidad del objeto de prueba?
Requisitos contractuales y del cliente

-
Ha habido algn acuerdo especfico entre el cliente / iniciador del proyecto respecto de los
procedimientos de prueba?
Qu documentos deben ser entregados en el momento del despliegue del sistema?
Mejor (buena) prctica

-
Qu enfoques han demostrado ser apropiados para estructuras similares?
Qu experiencias han sido adquiridas con qu enfoques en el pasado?
Niveles de prueba
-
En qu niveles de prueba se deben realizar pruebas?
Se deben aplicar criterios adicionales dependiendo de la situacin especfica!
12

Captulo V - Gestin de Pruebas
V - Gestin de pruebas
Contenido
Captulo V - Gestin de pruebas
-
V/01 Organizacin de prueba

V/02 Planificacin y estimacin del proceso de prueba
V/03 Seguimiento y control del estado de las pruebas
V/04 Gestin de la configuracin
V/05 Riesgo y proceso de prueba
V/06 Gestin de incidencias
01 - Organizacin de prueba
La gestin de pruebas como parte del proceso de pruebas
-
La gestin de pruebas es la gestin de proyecto de los proyectos de pruebas
El proceso de pruebas es una actividad que cubre por completo el proceso de desarrollo software
Las actividades propias de la gestin de pruebas son necesarias a lo largo de todo el proceso de
pruebas
Organizacin de pruebas e independencia

-
La efectividad de la identificacin de defectos puede mejorarse si se utilizan probadores

independientes
Desarrolladores que prueban su propio cdigo

Desarrolladores que prueban el cdigo de otros desarrolladores
Probadores pertenecientes a la misma organizacin del equipo de desarrollo
Probadores subcontratados o externos a la organizacin
Tareas del Lder de Pruebas y del Probador

Lder de Pruebas (Jefe de Pruebas, Coordinador de Pruebas)
-
Coordinar la estrategia de pruebas
Redactar o revisar una estrategia de pruebas para el proyecto, y una poltica de pruebas para la
organizacin
Contribuir a la perspectiva de pruebas de otras actividades de proyecto, tales como la planificacin de

integracin
Planificar las pruebas

13

Iniciar la especificacin, preparacin, implementacin y ejecucin de pruebas
Hacer un seguimiento de los resultados de pruebas y comprobar los criterios de salida
Tareas del Lder de Pruebas y del Probador...

Lder de Pruebas (Jefe de Pruebas, Coordinador de Pruebas)...
-
Adaptar la planificacin en base a los resultados y progreso de las pruebas
Establecer una gestin de la configuracin adecuada de los productos de soporte de las pruebas a
efectos de su trazabilidad
Introducir mtricas adecuadas para medir el progreso de las pruebas y evaluar la calidad de las
pruebas y del producto
Decidir qu debe automatizarse, hasta qu punto y cmo
Seleccionar herramientas de soporte de las pruebas y organizar cursos de formacin sobre el uso de
dichas herramientas para los probadores
Decidir sobre la implementacin del ambiente de pruebas
Redactar informes resmenes de pruebas en base a la informacin recopilada durante las pruebas
Probador
-
Revisar y contribuir a los planes de pruebas
Analizar, revisar y evaluar los requisitos de usuario, las especificaciones y los modelos para su
testeabilidad
Crear especificaciones de prueba
Configurar el ambiente de pruebas
Preparar y obtener datos de prueba
Implementar pruebas en todos los niveles de prueba, ejecutar y registrar las pruebas, evaluar los
resultados y documentar las desviaciones de los resultados esperados
Utilizar herramientas de gestin de pruebas y seguimiento de defectos
Automatizar pruebas
Medir el rendimiento de los componentes y sistemas
Revisar las pruebas desarrolladas por terceros
14

Competencias no tcnicas (soft skills)

-
Con carcter complementario a las competencias tcnicas, los miembros del equipo de pruebas
requieren de la siguientes competencias y experiencia:
-
Instinto (poltico y diplomtico)
Disposicin a preguntar sobre hechos aparentemente obvios
Persistencia, fuerte personalidad
Meticulosidad y creatividad
Capacidad para tratar situaciones complejas
Capacidad de aprender rpidamente
02 - Planificacin y estimacin del proceso de prueba

Actividades de planificacin de pruebas
-
La planificacin de pruebas es planificacin de proyectos

-
Todas las tareas y actividades deben ser planificadas con antelacin

Para las distintas tareas definidas se deben asignar recursos (personal, presupuesto,
herramientas, entornos de prueba, etc.)
Concretar las actividades de pruebas en un plan de pruebas maestro y coordinarlas con el plan
de proyecto
Definir el nivel de calidad (por ejemplo profundidad de las pruebas) para los distintos niveles de
pruebas
La planificacin de pruebas es una actividad continua, debe ser controlada de forma constante
La informacin proveniente de las actividades de pruebas podran imponer ajustes en el plan
de pruebas maestro con el objeto de afrontar riesgos sujetos a cambios
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
Plan de pruebas maestro (esttico) (master test plan)

-
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 con su fase de planificacin
El primer paso de la planificacin es la creacin de un plan de pruebas esttico

-
El plan de pruebas maestro cubre todas las fases del proceso de pruebas
Las reglas se fijan de acuerdo los objetivos de las pruebas, recursos, actividades de pruebas,
hitos, etc.
15

El plan de pruebas maestro es, posteriormente, ampliado con el objeto de cubrir los resultados a
partir de la fase de planificacin de detalle
-
Dado que durante la planificacin del proyecto se genera ms informacin, la planificacin se

puede hacer con mayor detalle
El plan de pruebas maestro cuenta con una extensin dinmica, que ser ajustada durante el ciclo
de vida del proyecto, si eso fuera necesario
El estndar IEEE 829 aporta una estructura de plan de pruebas maestro acreditada
Actividades a realizar
La planificacin de pruebas comienza al inicio de un proyecto de desarrollo y se ajusta a lo largo del
ciclo de vida del proyecto
- La planificacin de pruebas tambin cubre la creacin y actualizacin del plan de pruebas. Las
siguientes actividades se explican con mayor detalle:
-
Estrategia de pruebas (test strategy)

Planificacin de recursos (resource planning)
Prioridad de las pruebas (priority of tests)
Soporte de herramientas (tool support)
Actividades a realizar - estrategia de pruebas (test strategy)

La estrategia describe los niveles de pruebas a desarrollar y la intensidad de las pruebas en
aquellos 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 no es viable probar un sistema de forma completa.
Probar con todas las combinaciones de datos de prueba, estados internos y restricciones temporales
es prcticamente imposible
- La evaluacin del de riesgo ayuda a centrar la atencin en aquellas reas en que las actividades de
pruebas presentan un riesgo de fallo ms alto
-
Actividades a realizar - 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. Estas
estimaciones se convierten en parte del plan de pruebas (dinmico)
Este plan de pruebas maestro cuenta con un calendario (time table)detallado, incluyendo hitos,
asignacin de personal a actividades. Este plan es un instrumento para gestionar la tarea global de la
ejecucin de pruebas con todas sus actividades
Actividades a realizar - planificacin de pruebas (test planning)

-
Gestionar el tiempo: 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 o la
omisin de pruebas de forma completa
16

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
Criterios de entrada
-
Los criterios de entrada (entry criteria) definen cuando comenzar a probar, como al inicio de un nivel
de prueba o cuando un conjunto de prueba est listo para su ejecucin
Pueden ser criterios de entrada frecuentes:

-
Entorno de prueba disponible y grado de preparacin

Estado de preparacin de herramienta de prueba en el entorno de prueba
Disponibilidad de cdigo (testable)
Disponibilidad de datos de prueba
Disponibilidad de recursos humanos
Probadores preparados y en disposicin
Criterios de salida de pruebas (test exit criteria)

-
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:
Cobertura de cdigo (code coverage)

-
Cobertura de riesgo (risk coverage)

-
x% de cdigo (de un programa) que ha sido ejecutado

x% de todas las funciones / todas las opciones de men que han sido cubiertas
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
Aborto de pruebas debido a razones de tiempo, costos o calidad.

-
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
Si no ha sido alcanzado un mnimo de calidad, las pruebas pueden ser suspendidas o incluso no
ser iniciadas (muchos defectos crticos)
17

Tasa de deteccin de errores (error finding rate)

-
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
Las economas del proceso de pruebas deben ser tenidas en cuenta. Ms all de una cierta tasa
de deteccin de errores puede resultar una mejor opcin entregar/distribuir la aplicacin software
al entorno de produccin y concentrarse solamente en la correccin de fallos informados por el
cliente
Economa del proceso de pruebas

-
Un grado creciente de la calidad representa un coste ms bajo del error, pero costes ms altos en
prevencin de errores
Inicialmente, el coste de la revisin se incrementa, a continuacin se reduce (se hacen menos

revisiones en fases finales del proyecto)
Inicialmente, el coste total de la calidad se reduce, a continuacin se incrementa - los costes de la

calidad son los ms bajos donde la curva presenta su mnimo
Frecuentemente es necesario aportar un mnimo de calidad con el objeto de poder mantenerse en

el negocio, esto significa:
-
Las pruebas deben continuar a pesar de que el aumento del coste de la prevencin de errores
se incrementa ms que el decremento de costo del error
Enfoques de prueba ("test approach")/ estrategia de prueba (test strategy)

-
El enfoque de prueba es la implementacin de la estrategia de prueba para un proyecto especfico. El

enfoque de prueba es definido y redefinido en los planes de prueba y diseos de prueba.
Normalmente incluye las decisiones tomadas en funcin de los objetivos del proyecto y gestin de
riesgo.
Hay una variedad de diferentes enfoques a la pruebas

-
Enfoque preventivo (preventive approach)

-
Las pruebas son diseadas tan pronto como sea posible
Enfoque reactivo (reactive approach)

-
Los enfoques/estrategias se pueden combinar
Primero el software / sistema, luego el diseo de pruebas
Enfoque analtico (analytical approach)

-
Se realiza un anlisis previo a las pruebas, por ejemplo, pruebas basadas en riesgos (risk-based
testing)
18

Enfoque heurstico (heuristic approach)

-
Las pruebas son ms reactivas, por ejemplo pruebas exploratorias
Otros enfoques/estrategias:
-
Enfoque de reutilizacin (reuse approach): uso de juegos de pruebas y pruebas de proyectos

previos con el objeto de realizar avance rpidos
Enfoque centrado en fallo (failure focused approach): prediccin de errores (error guessing),
ataques de faltas (fault attacks)
Enfoque basado en listas de comprobacin (check list based approach): uso de listas de
comprobacin de proyectos previos o de la planificacin de pruebas
Enfoque basada en consultora (consultative based approach): expertos y tecnologa externos

guan al proceso de pruebas
Enfoque conforme a proceso o estndar (process-or standard-compliant approach):

estrategia regida por estndares de desarrollo software, por ejemplo mtodos giles, estndares
industriales
Enfoque basado en modelo (model based approach): pruebas estocsticas basadas en

informacin estadstica de tasas de fallos, etc.
Se pueden definir ms enfoques.

En la prctica se combinan varios enfoques
Estimacin de pruebas - factores (sntesis)
-
Caractersticas del producto (por ejemplo complejidad)

Calidad de la base de pruebas
Requisitos de fiabilidad y seguridad (efectos adversos) (safety) 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
-
Estimacin experta (tambin enfoque basada en tareas)

Estimacin basada en analogas
Estimacin basada en porcentajes
Estimacin experta
-
Mtodo
-
Identificar todas las tareas a ejecutar (normalmente utilizando un enfoque descendente (top
down))
Obtener estimaciones para cada tarea por los responsables (de su ejecucin) o por expertos
19

Sumar todos los valores de las tareas. Incluir los factores de correccin (si hay experiencias
respecto de la exactitud de ciertos estimadores)
Incluir elementos amortiguadores (buffers) / elementos adicionales con el objeto de cubrir tareas
omitidas o subestimadas
Ventajas
-
Las actividades de estimacin pueden estar estrechamente vinculadas a la planificacin del

proyecto
La estimacin da origen a una informacin detallada que puede ser controlada y ajustada a lo
largo del ciclo de vida del proyecto
Las tareas pueden ser asignadas a grupos (por ejemplo pequeo, mediano, grande) y los
esfuerzos slo son estimados para unos pocos representantes del grupo
Desventajas
-
Este mtodo es extensivo y caro

Este mtodo requiere un idea clara respecto de la estrategia de pruebas y actividades de pruebas
en una fase temprana del proyecto
La experiencia demuestra que las estimaciones son, en la mayora de los casos, a la baja. Esto
podra deberse a la omisin o subestimacin grosera de ciertas tareas
Los elementos amortiguadores incorporados son recortados durante la planificacin del proyecto
Los errores relativos a la planificacin de proyecto son heredados
Estimacin basada en analogas

-
Mtodo
-
Ventajas
-
Clasificar las tareas de pruebas requeridas

Buscar un proyecto que se haya desarrollado en el pasado que contenga una tarea similar a
una especfica
Utilizar el esfuerzo real de esta tarea como base para la estimacin
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
Considerar factores de correccin
El mtodo es simple y efectivo

Se pueden lograr valores muy precisos para la estimacin si se cuenta con suficiente experiencia
Desventajas
-
Se requiere personal con experiencia (estimadores) y/o base de datos detallada respecto del
proyecto actual para las tareas a estimar
Los criterios para la clasificacin de proyectos pueden no cubrir todos los aspectos de un proyecto
Frecuentemente conduce a debates con la direccin respecto de la validez de la estimacin
20

Estimacin basada en porcentajes

-
Mtodo
-
Ventajas
-
El esfuerzo para las actividades de pruebas se estiman sobre la base de la totalidad de las
actividades del proyecto
El valor del porcentaje (fraccin) requiere ser determinado basndose en la experiencia
Ejemplo: Spillner / Linz habla de un porcentaje del 50% de actividades de pruebas respecto de la
totalidad de las actividades del proyecto (vase tambin Basiswissen Softwaretest,
dpunkt.Verlag, 3. Auflage, S. 181)
Este mtodo tambin puede ser utilizado para parte del trabajo (por ejemplo estimacin para los
costes de gestin de proyecto, estimacin del esfuerzo de pruebas para las pruebas de sistema)
La estimacin basada en porcentajes no tiene en cuenta el esfuerzo de la pruebas de regresin,
que pueden ser una parte sustancial de la pruebas de mantenimiento y asociadas a cambios
Tcnica de estimacin muy simple y potente que no requiere excesiva informacin de entrada
Desventajas
No muy precisa, dado que no tiene en cuenta las hechos particulares del proyecto
Es necesaria mucha experiencia e intuicin por parte de quien realiza la estimacin (estimador)
con el objeto de obtener estimaciones vlidas
- La decisin respecto del valor del porcentaje puede conducir a debates difciles
- 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?)
- Los porcentajes varan ampliamente entre proyectos de nuevo desarrollo y proyectos de
mantenimiento
-
03 - Seguimiento y control del estado de las pruebas

Seguimiento de pruebas y control 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
-
Planificacin de pruebas, seguimiento de pruebas y control de pruebas

-
El seguimiento debe ser realizado en base consideraciones medibles

-
Mtricas en base a errores (utilizando informacin procedente del sistema de gestin de

incidentes), por ejemplo tasa de deteccin de errores, defectos detectados/corregidos, resultados
de repeticin de pruebas
21

Mtricas en base a casos de prueba (utilizando informacin procedente del sistema de gestin de
pruebas), por ejemplo cobertura de casos de prueba, cobertura de requisitos, tasa bien/mal
(good/bad) de casos de prueba, cobertura de cdigo, cobertura de riesgo
Mtricas en base a costes (utilizando informacin procedente del sistema de control del proyecto),
por ejemplo costo de deteccin de errores, costo de prueba de regresin, costo de recursos
externos
Los resultados obtenidos de la medicin deben ser informados de forma regular
Informacin de pruebas (test reporting)

-
La informacin respecto de las actividades de pruebas se consolida a los efectos de la informacin de

pruebas (test reporting )
Ejemplo del contenido de un informe de estado de pruebas (segn IEEE 829)

-
Frecuencia de los informes

-
Objeto u objetos de prueba

Nivel de prueba, ciclo de prueba, perodo del informe
Avance de pruebas (utilizando mtricas, por ejemplo nmero de defectos documentados, nmero
de casos de prueba ejecutados)
Recursos utilizados / presupuesto consumido
Hitos alcanzados (por ejemplo aceptacin de objetos de prueba en niveles de prueba especficos)
Informe de defectos (nmeros de defectos descubiertos, nmero de defectos corregidos)
Evaluacin del riesgo (nuevos riesgos / riesgos modificados respecto de informes previos)
Pronstico: Actividades planificadas para el prximo perodo de informe
Evaluacin general / estado (semforo)
Al inicio del proyecto / en la fase de preparacin los ciclos de los informes son ms largos
(quincenal o mensual)
Las fases crticas de la ejecucin de pruebas requieren ciclos cortos (semanales, o incluso
diario)
El informe de cierre de pruebas al final del proyecto
Evaluacin de los informes de pruebas

-
La evolucin es apropiada?
La ejecucin de las pruebas es eficaz y eficiente?
Las actividades estn alineadas con los objetivos de pruebas? Estn siendo alcanzados
objetivos de pruebas?
Cul es el grado de confianza respecto en el producto software basado en el estado actual de
progreso/evolucin/desarrollo?
Control de pruebas
-
El control de pruebas es una tarea de gestin

-
El jefe de pruebas pertenece a los cuadros directivos del proyecto

22

Medidas correctivas como respuesta a desviaciones respecto del plan

-
El control de pruebas incorpora a todas las medidas emprendidas durante el proceso de pruebas
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

-
Los criterios de salida de pruebas tambin son registrados con las mtricas de progreso / avance
de pruebas
Los criterios de salida de pruebas que hubieran sido alcanzados son documentados en el informe
de pruebas para su aprobacin
Medidas de control de pruebas

-
Provisin de recursos adicionales

-
Reduccin del esfuerzo aplicado al trabajo

-
Ms recursos humanos
Ms presupuesto
Despliegue de herramientas para la automatizacin de tareas
Exclusin de variaciones de casos de prueba

Simplificacin de objetos de prueba complejos / omisin de objetos especficos
Reduccin de la cantidad de datos de prueba
Omisin de casos de prueba / juegos de prueba
Las medidas de control de pruebas son documentados con el objeto de informar a la direccin del
proyecto / cliente respecto de cambios en riesgos en el despliegue del producto
04 - Gestin de la configuracin
Objetivo
-
Durante el desarrollo software se genera una gran cantidad de datos / informacin / resultados
{artefactos (artifacts)}:
-
Documentos de requisitos / especificaciones / diseo del sistema

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
-
Asignacin de nmeros de versin sucesivos

Es registrada la autorizacin (clearance) para desarrollos posteriores
Versiones antiguas son guardadas para un futuro control
Es registrado el acceso a los artefactos
23

Observaciones generales
-
La gestin de la configuracin tiene un rol de apoyo dentro de un proyecto - todos los cambios
deben ser registrados en un lugar comn y comunicados 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
El 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
Definiciones
Gestin de la configuracin GC [configuration management (CM)] se refiere a un conjunto de
medidas que complementan al desarrollo software:
Gestin del cambio (change management) sigue todas las actividades, por ejemplo cambios en
el cdigo fuente para cada solicitud de cambio
- Gestin de la construccin (build management) describe todos los pasos para crear una versin
de un producto software con el objeto de ser suministrado como un todo o subsistemas individuales
- 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.
- Gestin de versiones (versions management ) (como parte de GC) registra toda la informacin
de acceso para cada artefacto: versin actual (nmero), ltimo cambio, ltimo usuario, etc.
-
Problemas abordados 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: 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 de la versin de la que se trata
- Qu artefactos se corresponden? Qu versiones han sido agrupadas para crear las distintas
entregas (release)?
-
Los requisitos sobre GC conforman el punto de vista del proceso de pruebas

Control de versiones (version control)
- Clasificar, guardar y recuperar diferentes versiones de un objeto (V1.0, V1.1, etc.)
- Gestin de la configuracin (gestin de entregas - (release management))
- 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 del estado
- Trazar defectos y cambios, registrar informes de problemas y aportar vuelta atrs de actividades
(backtracking of activities)
-
24

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:

-
Si todos los componentes individuales de un sistema estn incluidos en la gestin de la

configuracin
Si las configuraciones individuales pueden ser identificadas correctamente
05 - Riesgo y proceso de prueba

Riesgo
Probabilidad de la ocurrencia de un suceso negativo multiplicada por el monto del dao o impacto
econmico
Frecuencia (Probabilidad) x Severidad (Impacto)
El riesgo asociado al proyecto y al producto deben ser tenidos en cuenta:
-
Durante la planificacin y el diseo de los casos de prueba,

Cuando se priorizan los casos de prueba,
Cuando se seleccionan los mtodos y
Durante la ejecucin de las pruebas.
Riesgos de proyecto
-
Riesgos asociados a la organizacin (organizational risks)

-
Capacitacin, formacin y disponibilidad del personal

Problemas personales entre equipos / miembros del equipo
Cooperacin insuficiente entre departamentos / conflictos de intereses
Estimaciones no realistas de plazos del proyecto
Riesgos tecnolgicos
-
Requisitos defectuosos, incompletos o no realistas

Tecnologas, mtodos, herramientas, etc. nuevas o que presentan incertidumbres para el
desarrollo software
Dficit de calidad en productos
Disponibilidad de un entorno de prueba complejo
25

Riesgos ambientales (environmental risks)

-
Deficiencias por parte de externos en la provisin de componentes (plazos, calidad, coste)

Problemas de aceptacin y otros inconvenientes contractuales con proveedores
Acceso concurrente a recursos externos
Cambios en requisitos legales
Los riesgos asociados al proyecto afectan al xito del proyecto y deben ser gestionados
Estimacin de la probabilidad y dao potencia
Implementar medidas apropiadas para tratar los riesgos identificados:

-
Mitigacin del riesgo (preparacin activa de medidas para reducir la probabilidad y/o el dao
potencial)
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)
Ignorancia del riesgo (esperar que el riesgo no se convierta en un problema, rezar, cruzar los
dedos, etc.)
Transferencia del riesgo (traspaso del riesgo a otra rea/organizacin)
Eludir el riesgo (evitar situaciones de riesgo)
Cuando se analizan, gestionan y mitigan los riesgos, el jefe de proyecto sigue unos principios bien
establecidos de gestin de proyecto. El esquema de la norma IEEE Std 829 para planes de prueba
requiere que se establezcan las gestiones de riesgos y contingencias.
Riesgos de producto
-
Los riesgos asociados al producto son el resultado de problemas relacionados con el producto
suministrado
-
Funcionalidad insuficiente del producto suministrado

Atributos no funcionales insuficientes
El producto no es idneo para su uso previsto, por lo tanto no puede ser puesto en operacin
(produccin)
El producto provoca daos a la propiedad
El producto provoca lesin o muerte accidentales
Las pruebas se ejecutan para reducir o evitar los riesgos asociados al producto
-
Riesgo = probabilidad de ocurrencia x dao potencial

Las pruebas reducen la probabilidad de ocurrencia de un riesgo
Son necesarias pruebas ms intensivas en caso de dao potencial alto
26

Gestin de riesgos de producto

-
Gestin de riesgos de producto utilizando pruebas basadas en el riesgo

-
Identificar, analizar y priorizar riesgos

Influencia del riesgo tenido en cuenta durante la planificacin de pruebas
-
Actualizar la lista de evaluacin de riesgos (risk assessment worksheet ) de forma regular

-
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!)
Los riesgos pueden desaparecer (el proveedor ha entregado en plazo)

Pueden aparecer nuevos riesgos (el cliente solicita funciones adicionales)
Los riesgos pueden cambiar (epidemia de gripe)
Beneficios de las pruebas basadas en el riesgo:

-
Los mtodos de pruebas son seleccionados de forma particular con el objeto de mitigar los
riesgos identificados
El alcance de las pruebas se ocupa de los riesgos identificados
El alcance del proceso de pruebas tiene en cuenta los riesgos identificados. De esta forma, el
esfuerzo en el proceso de pruebas se centra en abordar la reduccin del riesgo potencial
Los fallos de riesgo son detectados de forma temprana, por lo tanto se hace ms econmica su
correccin
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)
06 - Gestin de incidencias
Deteccin de errores* durantes las pruebas
El probador ejecuta los casos de prueba y registra los resultados
Posteriormente se analizan las desviaciones entre los resultados esperados y los obtenidos:
- 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
- El probador espera la versin corregida del programa para ejecutar la repeticin de pruebas
(retest)
- Posteriormente, el seguimiento (tracking) de errores se realiza utilizando un sistema de gestin
de incidencias (sistema gestin de defectos)
-
*Nota: En el presente captulo, defecto e incidencia se utilizan como sinnimos
27

Quien hace qu actividad?

-
Probador (tester)
-
Jefe de pruebas (test manager)

-
Decide respecto de los cambios de requisitos y sus prioridades
Desarrollador
-
Evala el informe de problemas

Asigna prioridades a los defectos (de acuerdo con la direccin del proyecto, cliente, etc.)
Redacta el informe de avance en funcin del estado actual de las labores de correccin
Consejo de Control del Cambio (CCC) (Change Control Board (CCB))

-
Ejecuta los casos de prueba con el objeto de detectar errores

Registra los resultados en un protocolo de pruebas
Introduce los defectos (incidentes) en un repositorio (informe de problemas)
Analiza los fallos, localiza la causa del defectos

Corrige la causa de error de acuerdo con la prioridad asignada
Ejecuta todos los cambios aprobados
Nota: todas estas tareas son ejecutadas de forma iterativa:

-
Probador (tester)
Jefe de pruebas (test manager)
Consejo de Control de Cambio (CCC) (Change Control Board (CCB))
Desarrollador (developer)
Probador (tester)
Estructura de un informe de incidencias (informe de errores)

-
El informe de incidencias describe un fallo, no su causa!
La plantilla / estructura de un informe de incidencias puede ser encontrada en el estndar IEEE 829
(Anomaly Report)
Detalles que puede incluir un informe de incidencia:

-
Datos de la incidencia
-
Nmero nico del defecto (normalmente generado de forma automtica)

Objeto de prueba (denominacin, versin), paso de prueba
Entorno de pruebas
Nombre del autor del informe de incidencias
Fecha de la primera ocurrencia
28

Clasificacin de errores
-
Clase de defecto (defect class) (tambin severidad del defecto)

Estado del defecto (defect state) (error nuevo, repeticin de prueba, etc.)
Prioridad (priority) (asignacin de la urgencia)
Estructura de un informe de incidencias

-
Elementos que puede incluir un informe de incidencias:

-
Descripcin
-
Caso de prueba (aporta todos los detalles respecto de las precondiciones)

Resultado del defecto / modo de fallo (usando una descripcin del resultado obtenido y el
resultado esperado)
Descripcin de la desviacin para facilitar su resolucin (incluyendo informes, capturas de
pantalla, mensajes de error de la aplicacin, etc.)
Referencias cruzadas a informes relacionados
Comentarios
Acciones correctivas tomadas
Registro histrico (history log)

-
Hora y usuario que ha realizado cambios

Muchos sistemas hacen un seguimiento automtico de cambios en el ciclo de vida del
incidente/error
Clase de defecto y prioridad del defecto

La severidad de un fallo se expresa por la asignacin de una clase de defecto {sinnimo: clase de
fallo(failure class)}
-
Las clases de defectos a utilizar pueden ser: defecto crtico, defecto mayor, defecto medio, defecto
menor. Son frecuentes tres o cuatro clases de defectos
El criterio para la clasificacin puede ser la influencia en la usablidad del producto
La prioridad tiene en cuenta el efecto del fallo:

-
Impacto sobre la funcionalidad del programa

Impacto sobre el proyecto, sobre el cliente
Posibilidad de aportar una solucin (correccin) inmediata al problema o en la siguiente entrega
La prioridad rige la urgencia de la correccin
29

Estado de un defecto
El estado de un defecto aporta informacin relativa al progreso/evolucin del trabajo que ha sido
desarrollado para este defecto
- Los posibles estados de un defecto son, pero no estn limitados a los siguientes:
-
Nuevo - El probador ha introducido un defecto en el sistema

Abierto - Informe de problema confirmado (por el jefe de pruebas o desarrollador) / Asignado
Rechazado - Rechazado el informe de problema (por el jefe de pruebas o desarrollador)
Inspeccin / En Anlisis - El desarrollador intenta identificar el defecto
En observacin - El defecto no puede ser reproducido, se encuentra bajo vigilancia
Trabajo en Proceso - El defecto es localizado y preparado/ desbloqueado para su correccin
Arreglado - El defecto ha sido corregido por el desarrollador
Repeticin de Pruebas (Retest) - El desarrollador reasigna el defecto al probador
Finalizado / Cerrado - El probador ha verificado correccin a travs de repeticin de la prueba
No resuelto - El probador no ha podido verificar la correccin, el defecto an se encuentra ah
Estado de un defecto
Slo un probador puede poner un defecto en estado Finalizado!
Normalmente el jefe de pruebas decide si un defecto debe ser corregido o rechazado - de forma
alternativa el consejo de control del cambio puede decidir sobre la correccin de un defecto teniendo
en cuenta el coste de reparacin
- Todos los cambios (incluidos los comentarios) deben ser registrados en el sistema de gestin de
incidencias
-
Se asegura el control continuo sobre el estado de correccin de un defecto

Pueden ser planificadas las actividades de pruebas futuras
En ocasiones, deben ser generados casos de prueba adicionales con el objeto de localizar la
causa de un fallo
Anlisis de informes de defectos

-
Todos los informes de defecto son analizados de forma sistemtica con el objeto de evaluar el estado
de desarrollo de las actividades de correccin de defectos, conformidad con el plan de proyecto y la
calidad software
Elementos de atencin caractersticos:

-
Es perceptible una reduccin en el nmero de detecciones de nuevos defectos? O se est

incrementando el nmero a lo largo del ciclo de vida del proyecto?
Hay objetos de prueba particulares que presenten un alto nmero de defectos? Hay algn
objeto de prueba que presente un nmero de defectos ms bajo que el nmero medio de
defectos?
Cuntos defectos de severidad alta / prioridad alta an siguen abiertos?
Cunto tiempo requiere la correccin de un defecto? Cul es el tiempo medio para la correccin
de defectos?
Las herramientas de gestin de incidencias ofrecen una amplia variedad de informes de estadsticas de
defectos.
30

Iv - V - Istqb CTFL

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Iv - V - Istqb CTFL

Încărcat de

Drepturi de autor:

Formate disponibile

Luis Mercadal & Asociados

Curso Oficial de ISTQB Certified Tester Foundation Level

Tcnicas de Diseo de Pruebas + Gestin de Pruebas

Luis Mercadal & Asociados

Captulo IV - Tcnicas de Diseo de Pruebas

IV - Tcnicas de diseo de pruebas

IV/01 Proceso de desarrollo de prueba

01 - Proceso de desarrollo de prueba

Qu casos de prueba han sido incluidos en el juego de pruebas? Basados en qu requisitos?

Caso de prueba segn el estndar IEEE 829

Luis Mercadal & Asociados

02 - Categoras de las tcnicas de diseo de prueba

Las pruebas dinmicas se dividen en dos categoras/ grupos

Tcnica de caja negra

El probador observa el objeto de prueba como una caja negra

La estructura interna del objeto de prueba es irrelevante o desconocida

Prueba del comportamiento entrada / salida

La funcionalidad es el foco de atencin!

Prueba funcional o prueba orientada a la especificacin

Tcnicas de caja blanca

El probador conoce la estructura interna del programa / cdigo

La jerarqua de los componentes, flujo de control, flujo de datos, etc.

La estructura del programa es el foco de atencin!

Pruebas basada en la estructura o pruebas basada en el flujo de control

Categoras de las tcnicas de diseo de pruebas

Mtodos basados en la especificacin

Mtodos basados en la estructura

Mtodos basados en la experiencia

Luis Mercadal & Asociados

03 - Tcnicas basadas en la especificacin o de caja negra

Particin de Equivalencia (Segmentacin de Equivalencia, Clase de Equivalencia)

Anlisis de Valores Lmite

Tablas de Decisin y Grficos Causa-Efecto

Pruebas de Transicin de Estado

Pruebas de Caso de Uso

Estn disponibles en el mdulo todas las funciones especificadas?

Las funciones ejecutadas presentan resultados correctos?

Probar lo menos posible, pero

Probar tanto como sea necesario

1. Particin de Equivalencia / Clase de Equivalencia (CE)

Dividir los posibles valores en clases, mediante lo cual observan

El rango de valores definido se agrupa en clases de equivalencia

1 clase de equivalencia por valores que produzcan un comportamiento comn

No pueden presentar ningn salto (discontinuidad)

Luis Mercadal & Asociados

Particin de equivalencia vlida y no vlida

Valores del formato correcto pero fuera del rango

Valores con el formato incorrecto, generalmente, forman parte de una CE separada

Las pruebas son ejecutadas utilizando un nico representante de cada CE

Particin de equivalencia - Ejemplo

Valores de entrada definidos para x como 0 x 100

Tres (3) clases de equivalencia:

(valores de entrada no vlidos)

Puede ser utilizada para lograr objetivos de cobertura de entradas y salidas

Puede ser utilizada para entradas manuales (humanas) o va interfaces de un sistema o

2. Anlisis de Valores Lmite (Valores Frontera)

Ampla la tcnica de particin de equivalencia introduciendo una regla para seleccionar

Los valores lmite de la CE deben ser probados de forma intensiva

Luis Mercadal & Asociados

Comprobar si los lmites han sido implementados (programados) correctamente

La CE est compuesta de un rango continuo de valores

Se pueden definir los lmites para el rango de valores

Mtodo que sugiere la seleccin de representantes