02/09/2016

Taller Testing de Aplicaciones

Córdoba
2016

Agenda

DÍA 1:
 Introducción a las problemáticas de ingeniería de software
 El costo de la “no calidad”
 Control y Aseguramiento de Calidad
 Metodología de Control de Calidad
• Etapas y entregables
• Tipos de Pruebas: ¿Qué pruebas necesito para mi proyecto?
• ¿Cómo estimar las pruebas?
• ¿Qué debo tener en cuenta a la hora de planificar las pruebas?
• ¿Cómo tomar el control de mi proyecto, a través del área de test?
• ¿Cómo definir pruebas y reportar defectos en forma correcta?
• Diseño de casos de prueba – Técnicas de derivación

DÍA 2:
 Ejercitación diseño de casos de Prueba – Ejemplos Claro

1
 02/09/2016

Introducción

Algunos conceptos …

• Probar es el proceso de ejercitar el SW, de manera de encontrar diferencias

entre el comportamiento deseado y el obtenido
“Qué hace” vs. “Qué debería hacer”
• Cualquiera sean los métodos y técnicas utilizadas, no es posible garantizar que el
producto final se comporte permanentemente como es requerido. Siempre
existen Riesgos de Falla
“Todo el proceso de pruebas está orientado a disminuir los riesgos/costos
de falla del software”

2
 02/09/2016

¿Qué es el Testing?

 Es el proceso de ejercitar el SW, de manera de determinar la

diferencia entre el comportamiento deseado y el obtenido

 En resumen “Qué hace” vs. “Qué debería hacer”

 Proceso de evaluar un sistema o componente de éste,

basándose en su comportamiento durante la ejecución. Se ven
las diferencias entre su comportamiento actual y el
comportamiento deseado tal cual lo estipulado en los
requerimientos.

¿Porqué hacer testing?

 Construir software es un proceso sujeto a fallas, como toda actividad

humana.

 No importa los métodos y técnicas utilizadas, no es posible garantizar que el

producto final se comporte siempre como es requerido.

 Hacer testing en etapa temprana, baja los costos de los proyectos

3
 02/09/2016

Principios

 No es posible probar absolutamente todo.

 La prueba está basada en riesgos.
 Probar es una tarea compleja y creativa.
 La planificación y el diseño de las pruebas es fundamental.
 Es esencial medir y controlar la cobertura de las pruebas.

Introducción a las problemáticas de ingeniería de software

4
 02/09/2016

Los problemas de cada etapa

Definición del Problema

Definición de
Requerimientos

Los Arquitectura / Diseño

problemas
aparecen
en.. Construcción

Otros (ambiente, seguridad,

etc.)

El Problema
En los requerimientos

 Documentación: pobre, ambigua, poco clara u obsoleta

 Falta de priorización
 Inestabilidad, cambian con rapidez
 Usuarios poco involucrados

5
 02/09/2016

El Problema
En etapa de arquitectura / diseño

 Especificación de interfaces y áreas de riesgo escasamente

definidas

 Definiciones pobres sobre cohesión y acoplamiento

 Falta de definiciones sobre disponibilidad

 Falta de equilibrio entre costo y funcionalidad

El Problema
En etapa de construcción

Fallas en la definición de:

 Estándares de programación y/o codificación
 Criterios de mantenibilidad esperada
 Reusabilidad
 Nivel de desempeño esperado
Codificación compleja

6
 02/09/2016

Origen de defectos vs Costos de reparación

La mayor parte de los defectos son creados en las “primeras etapas” de los proyectos y son
encontrados en las “últimas etapas”

Requerimientos
Arquitectura ArquitecturaTesteo
Construcción
Pre Testeo Pre
Requerimientos
y Diseño de Sistemas Construcción
Producción
y Diseño de Sistemas Producción
60% 56%
Costo de
40%
corregir
35%
60% 56% 27%
25%
20%
7% 10%

— Fuente : Roger Pressman

40% — Fuente : Dick Bender

35%
27%
25%
20% Etapa en la que Req.
se originan 7% 10%
Arq. Mantenimiento
Dis. Construcción
Diseño
Cons. Etapa en la que
Arquitectura
se corrigen
Requerimiento
— Fuente : Roger Pressman
— Fuente : Steve McConnell
— Fuente : Dick Bender

13

Estadísticas

7
 02/09/2016

¿Dónde se originan los defectos?

60
55
50
45
40
35
30
25
20
15
10
5
0
Código Otros Diseño Reqs.

Costo relativo de corrección de los defectos en cada etapa

100
90
80
70
60
50
40
30
20
10
0
Reqs. Diseño Código Test Producción

Datos publicados con la autorización del Quality

Assurance Institute -2002

8
 02/09/2016

¿Dónde son habitualmente utilizados los recursos de test?

80

60

40

20

0
0% 0% 0% 10% 80% 10%

Propuestas Requerimientos Diseño Código Test Instalación

El costo de la “no calidad”

9
 02/09/2016

El Impacto en el negocio
 Imagen:
 Un producto defectuoso daña la reputación de la marca o empresa

• Riesgo patrimonial:

 Enfrentar demandas legales si no se alcanzan los niveles de servicio

pactados o se provocan daños

 Productividad:
 Costos adicionales para la corrección de fallos

Algunos ejemplos de la “no calidad”

Elcosto de no la calidad.avi

10
 02/09/2016

Control y Aseguramiento de Calidad

Algunas definiciones...
• Política de calidad:
– Intención y dirección de la organización respecto de la calidad, formalmente
expresados por la alta gerencia (ISO 8402).

• Control de calidad:
– Las actividades y técnicas operativas usadas para cumplir con los requerimientos
de calidad (ISO 8402).

• Aseguramiento de la calidad:
– Todas aquellas acciones planeadas y sistemáticas necesarias para proveer una
adecuada confianza de que un producto o servicio satisfará determinados
requerimientos de calidad (ISO 8402).

22

11
 02/09/2016

Calidad de Software
 Control de calidad
 Pruebas
 Revisiones (inspecciones, walktroughs, etc.)

 Aseguramiento de la calidad
 Auditorías
 Revisiones
 Análisis de datos del proceso de desarrollo
 Etc

Calidad y proceso productivo

La calidad del producto final está directamente

relacionada con la calidad del proceso de producción empleado

Mejorar el proceso facilitará la obtención

de productos de calidad

12
 02/09/2016

Movimiento de Calidad
 Departamento de Defensa (TQM)
 ISO 9000
 SW-CMM/CMMI
 TMMI

ISO 9126 – Information Tecnology

Calidad del Software Software Product Evaluation

Atributos de
Calidad del
Software

Funcionalidad Eficiencia

Completa

Tiempo

Segura

Recursos

Confiabilidad Portabilidad

Madurez

Instalable

Tolerancia a fallas

Partes

Recuperable
reemplazables
Usabilidad Mantenibilidad

Operable
Generalizable

Fácil de comprender
Fácil de probar

13
 02/09/2016

Perspectiva histórica

Demostrar Encontrar Prevenir

Control de Control de Control Calidad total.

calidad del calidad en estadístico del Administración
producto final etapas de la calidad.
proceso
intermedias
productivo. Mejora continua.

¿Qué es el test?
Un manager define el test como el proceso que le asegura:

Un producto seguro, fiable

 Que el software funcionará correctamente, tanto en condiciones

normales como adversas

 Que ese producto es lo que los usuarios necesitan

y/o quieren

14
 02/09/2016

¿Qué significa el Test para los testers?

 “Cazar” defectos

 Ser creativamente destructivos

 Perseguir defectos “no gente”

 Agregar valor

Pruebas de Software: verdadero o falso?

• El software siempre se prueba. La prueba nunca termina, cuando deja de probar el equipo de
desarrollo, lo empieza a probar el usuario.
• Un buen caso de prueba es el que demuestra que el programa no anda. Si todo anda bien, hay que
sospechar. O la cobertura de las pruebas no es buena o no se utilizó el set de datos apropiado.
• Se debe probar para condiciones válidas e inválidas. Debemos simular situaciones esperadas y forzar
las inesperadas.
• Se deben controlar todos los resultados de lo probado. Si no inspeccionamos ni verificamos
funcionamiento e integridad no podemos determinar si funciona bien o mal. Se debe controlar el
resultado inmediato y el indirecto (en otro aplicativo).
• No se debe suponer, hay que probar. No hay que inferir funcionamiento, hay que corroborar.
• Lo que no probamos es lo que seguramente va a fallar. No alcanza con probar que el proceso
funciona bien, hay que probar las excepciones. Cuanto mejor armemos los casos de prueba menor
será la probabilidad de que el proceso falle.

30

15
 02/09/2016

Organización de las pruebas - Fases

Estimar el esfuerzo, el tiempo y recursos

Estimación y Planificación
para las pruebas

Preparar casos de prueba, Ambiente y

Preparación
datos a ser utilizados

Ejecutar las pruebas y solucionar las

Ejecución incidencias

Verificar que todos los CP se ejecutaron

Cierre satisfactoriamente

31

• Planificar las pruebas, teniendo en cuenta los tipos de prueba a realizar (unitarias,
ensamblaje, sistemas, integración, técnicas, aceptación, regresiones) y los ciclos (mínimo 3
intercalando tiempos de espera de arreglos)
• Alcance de las pruebas en función de los requerimientos y de los riesgos asociados a fallas
del sistema: funciones y procesos críticos, impacto operativo, comercial, regulatorio, de
control interno, de imagen, …
• Definición de recursos, hardware y software necesarios para las pruebas
• Prever la coordinación y comunicación entre las distintas partes involucradas.
• Clasificación de defectos por severidad asociada a riesgo.
• Criterios de Fin de Pruebas

32

16
 02/09/2016

• Diseño de casos de prueba, con sus condiciones, datos de entrada y resultados

esperados.
• Priorización y distribución de las pruebas
• Armado y configuración de ambiente de pruebas
• Carga inicial de datos
• Validación

En general, no es posible verificar todos los

valores de entrada de un programa. Se
debe elegir un subconjunto representativo

33

Configuración del ambiente de prueba

• Teniendo en cuenta las entradas y las salidas y los casos a probar, se debe armar un
escenario lo más estable y parecido a PRODUCCION, pues es un riesgo probar en un
ambiente con condiciones diferentes. Algunos de los puntos a tener en cuenta:
– Los archivos y tablas de entrada: propias y de otros aplicativos, también las de uso
general, necesarios para que el programa ejecute.
– Determinación del ambiente en que se llevará a cabo la prueba: desarrollo, test,
integración.
– Perfiles de seguridad para el caso de entorno on-line
– Resguardo de información inicial y generada

34

17
 02/09/2016

Desarrollo de
Software
Producción
Ambiente de Desarrollo
Ambiente de Producción

Versiones Ciclos de Versión

a probar Prueba definitiva

Ambiente de Pruebas

35

• Ejecutar los casos de prueba

• Reporte de defectos y seguimiento de su solución
• Corregir los defectos detectados
• Verificar su solución reejecutando las pruebas
• Ajustes a los Casos de prueba

Ejecutar sin preparación previa puede

provocar falta de datos de prueba, falta de
Casos de Prueba y repeticiones de los
mismos

36

18
 02/09/2016

Cierre

• Informe de cierre de pruebas:

– Contendrá todos los casos de prueba ejecutados con los resultados obtenidos
en cada ciclo.
– La versión final debe documentar que se hayan ejecutado satisfactoriamente
los CP preparados
•Por ej.: para las pruebas unitarias todos los casos
deberán estar con el campo “Resultado Obtenido” en
estado “Satisfactorio”.

37

Cierre

• Criterios de aceptación:
– Explícitos
– Formalizados
– Consensuados
• – Ejemplo:
La aprobación de la versión de software testeada, implicará satisfacer los siguientes criterios
respectos de defectos activos:
– Bloqueantes: 0.00 % de defectos
– Alta: 2.50 % de defectos
– Media: 5.00 % de defectos
– Baja: 10.00 % de defectos

38

19
 02/09/2016

Planificación estándar

39

¿Cómo estimar los tiempos de pruebas?

No existen técnicas de estimación con la precisión y sencillez necesarias cuando se las
considera individualmente. Siempre es recomendable la aproximación por más de una
técnica.

Como técnicas de apoyo podemos mencionar:

En etapa temprana

Un 30% del tiempo estimado para diseño y programación (30%)

Un 20% del tiempo estimado para el proyecto (20%)

En etapa de análisis

Análisis de documentación, criticidad y complejidad de los requerimientos

Como control
No olvidar estimar la
obtención/preparación del
Comparación con otros proyectos similares
ambiente y datos de prueba

40

20
 02/09/2016

Técnicas de estimación – Tips a tener en cuenta

Se debe elegir muy bien qué técnica de estimación utilizar en función del tipo de
proyecto y con qué información se cuenta.

Cada persona puede tener distintos criterios a la hora de estimar (optimista,

realista o pesimista). Es aconsejable tener al menos 3 estimaciones en paralelo y
así llegar una estimación final.

Ninguna técnica es precisa en sí misma, es aconsejable utilizar técnicas de

estimación cruzadas, a fin de mejorar la exactitud de la estimación resultante.

41

Verificación y Validación

21
 02/09/2016

Modelo V&V
se valida en... Test de
Requerimientos
Aceptación

Diseño se valida en... Test del

Global Sistema

Diseño se valida en... Test de

Detallado Integración

Test
Codificación
Unitario

Se valida en…

Definiciones

Verificación
¿Estamos construyendo el producto correctamente?
 Algunos definen esta etapa como la del “test humano”, ya que consiste en trabajar
sobre documentos “en papel”, trabajo de escritorio

Validación
¿Estamos contruyendo el producto correcto?

 Consiste mayormente en la ejecución de código

22
 02/09/2016

Verificación & Validación

 Test = Verificación + Validación

 Verificación y Validación son complementarios

 Cada uno provee “filtros” orientados a “cazar” defectos de distinta índole

y en diferentes etapas

 Históricamente el test ha significado “validación”

Test Estático - Verificación

23
 02/09/2016

Objetivos

Verificar grado de adherencia a estándares

Requerimientos Verificar completitud de definiciones
Verificar prioridades ...

Especificación de interfases
Etapa de Diseño Definiciones entre cohesión y acoplamiento
Áreas de riesgo ...

Control de adherencia a estándares por

Codificación muestreo

Etapa de Requerimientos

 Seleccionar un estándar para la documentación

 Chequear el grado de adherencia del requerimiento documentado a los estándares

de la organización

 Verificar completitud de definiciones, interfases, requerimientos funcionales y no

funcionales, atributos

 Control de definición de prioridades

24
 02/09/2016

Etapa de Requerimientos

 ¿Los requerimientos están escritos en un nivel de detalle consistente y apropiado?

 ¿Proveen las bases adecuadas para el diseño?

 ¿Está incluido en cada requerimiento su prioridad de implementación?

 ¿Están definidas todas las interfaces externas de hardware, software y comunicación?

Etapa de Requerimientos

 ¿Hay algún requerimiento que esté en contraposición ó que duplique otros

requerimientos?

 ¿Cada requerimiento es verificable mediante prueba, demostración, revisión ó

análisis?

 ¿Falta alguna información necesaria del requerimiento?

 ¿Están los objetivos de performance y concurrencia apropiadamente especificados?

25
 02/09/2016

Etapa de Requerimientos

 ¿Están definidos los criterios de aceptación que se controlarán durante la última etapa
de test?

 ¿Están todas las consideraciones de seguridad apropiadamente especificadas?

 ¿Están los atributos de calidad explícitamente documentados y cuantificados?

Etapa de Requerimientos

 ¿Es necesaria la generación de documentación complementaria?

 Entregable de esta etapa: checklist de comprobación

26
 02/09/2016

Etapa de Requerimientos

 Están todas las interfaces claramente definidas?

 ¿Se pasa hasta la mínima información requerida a cada interfaz?

 ¿Está toda la información global del sistema agregada ó impactada?

Etapa de Requerimientos

 Están las especificaciones externas de cada módulo completas y las mismas

son comprobables?

 ¿Es necesaria la generación de documentación complementaria?

 Entregable de esta etapa: checklist de comprobación

27
 02/09/2016

Etapa de Diseño

Se verifica como diferentes “piezas” del sistema

Walktroughs interactúan unas con otras. Está técnica muestra
redundancias, incompatibilidades, “partes
ausentes”.

Se verifica en detalle cada parte del diseño contra

Inspecciones un check-list. Puede estar enfocada al manejo de
problemas, la conformidad con estándares, u otra
parte cualquiera del diseño.

Reuniones Técnicas Cada revisor, prepara una lista de temas puntuales

sobre los cuales se trabaja. El propósito es generar
una lista de problemas a resolver

Se generan como guía para cada una de estas

Check-lists técnicas de verificación, o bien como único control
de esta etapa

Etapa de Codificación

 ¿Los programas están escritos bajo los estándares de codificación provistos

por QA?

 ¿El código está documentado clara y adecuadamente?

 ¿Existe inconsistencia entre el código y los comentarios?

 Entregable de esta etapa: checklist de comprobación

28
 02/09/2016

Etapa de Codificación

 A partir de los estándares de programación definidos por la organización, se

verificará el grado de adherencia de los programas a los mismos.

 La selección de los programas se realizará por muestreo en función de su

criticidad.

 Se realizará un informe consolidado de “no conformidades” por aplicativo

Riesgos asociados a ausencia de Test Estático

Análisis / Diseño Diseño

Código
Requerimientos Global Detallado

(*)

1 defecto 4 defectos 8 defectos 12 defectos

Motorola: 1 U$S invertido en calidad tiene un retorno de 20 U$S

Fuente: QAI India-2002

29
 02/09/2016

Test Estático - Tendencias

Con la combinación de uno de los métodos formales de revisión, y los check-lists

es factible descubrir tempranamente el 70% de los problemas del software

Test Dinámico - Validación

30
 02/09/2016

Prueba de Software

El propósito del testing es encontrar

anomalías o fallas en el producto de software.

Modelo V&V
se valida en... Test de
Requerimientos
Aceptación

Diseño se valida en... Test del

Global Sistema

Diseño se valida en... Test de

Detallado Integración

Test
Codificación
Unitario

se valida en...
62

31
 02/09/2016

Tipos de Pruebas – Clasificación

• PRUEBAS UNITARIAS: su objetivo es probar los componentes o módulos

individuales de un sistema, para verificar que cumplen con el comportamiento
esperado.
• PRUEBAS DE ENSAMBLAJE: su objetivo es verificar el correcto ensamblaje entre los
distintos componentes una vez que han sido probados unitariamente con el fin de
comprobar que interactúan correctamente a través de sus interfaces internas y
externas.
• PRUEBAS DEL SISTEMA: su objetivo es verificar que la aplicación construida (como
un todo) cumple los requerimientos “funcionales” establecidos.

63

Tipos de Pruebas – Clasificación (cont..)

• PRUEBAS DE INTEGRACIÓN: tienen como objetivo ejercitar profundamente la
aplicación comprobando la integración del sistema de información globalmente,
verificando el funcionamiento correcto de las interfaces entre los distintos
subsistemas que lo componen y con el resto de sistemas de información con los que
se comunica.
• PRUEBAS TÉCNICAS: su objetivo es verificar que la aplicación construida cumple los
requerimientos técnicos o “no funcionales” establecidos (performance, stress,
seguridad, volumen, concurrencia,…).
• PRUEBAS DE ACEPTACIÓN: su objetivo es permitir al usuario validar que sus
requerimientos han sido contemplados correctamente y que el sistema cumple la
funcionalidad y rendimiento esperados.

64

32
 02/09/2016

Prueba de Software

 Los requerimientos son esenciales para poder realizar la

prueba.

 La prueba se hace para demostrar que el software no se

comporta de acuerdo a lo especificado.

 La prueba efectiva encontrará defectos originados en distintas

etapas del proyecto.

Principios

 No es posible probar absolutamente todo.

 La prueba está basada en riesgos.
 Probar es una tarea difícil y creativa.
 La planificación y el diseño de las pruebas es fundamental.
 La motivación es muy importante.
 Probar lleva tiempo y consume recursos.
 Es esencial medir y controlar la cobertura de las pruebas.

33
 02/09/2016

Axiomas de la Prueba de Software

 Un buen caso de prueba es aquel que tiene alta probabilidad de
mostrar un defecto no descubierto hasta entonces.
 Una prueba tiene éxito si descubre un defecto no detectado hasta
entonces.
 A medida que el número de defectos encontrados aumenta, la
probabilidad de que existan defectos aún no descubiertos aumenta.
 Un programador debe evitar probar su propio programa.
 La prueba no puede asegurar la ausencia de defectos, sólo puede
demostrar que existen defectos en el software.
 La definición del resultado esperado a la salida del programa es una
parte integrante y necesaria de un caso de prueba
 Examinar un programa para comprobar que no hace lo que se supone
que debe hacer es sólo la mitad del problema. La otra mitad consiste
en ver si el programa hace lo que no se supone que debe hacer.

Clasificación
 Las pruebas pueden clasificarse de acuerdo a:

• Alcance

• Propósito

• Técnicas empleadas

34
 02/09/2016

Clasificación
Según el alcance

 Prueba unitaria

 Prueba de integración

 Prueba del sistema

 Prueba de aceptación

Alcances de la Prueba de Software

Verifica que el software

Prueba de cumpla con las tareas y Aceptación final del Usuarios/clientes,
Aceptación funciones para las cuales fue sistema. testers.
construido

Cumplimiento de
Prueba de Verifica el funcionamiento del
requerimientos funcionales y Testers.
Sistema sistema como un todo
no funcionales.

Verifica la adecuada Interfaces, Desarrolladores,

Prueba de
Interacción entre los funcionalidad,performance, testers.
Integración elementos etc.

Verifica el flujo de control y

de datos focalizando en los
Prueba Prueba Lógica, funcionalidad,perfor-
elementos más pequeños Desarrolladores.
Unitaria Unitaria mance, etc.
(componentes, módulos, etc)

35
 02/09/2016

Clasificación
Según su propósito

 Regresión  Volumen
 Funcional  Performance o Rendimiento
 Humo  Benchmark
 Integridad  Estrés o Resistencia
 Configuración  Recuperación
 Instalación  Carga
 Seguridad  Facilidad de Uso

Clasificación
Según las técnicas

 De Caja Blanca

 Se considera la estructura interna del software.

 De Caja Negra

 No se considera la estructura interna del software.

36
 02/09/2016

Técnicas de Pruebas de Software

Clasificación de las Técnicas

 Caja Blanca:
 Tiene como propósito verificar que el diseño es válido y que el
software fue construido de acuerdo a las especificaciones.

 Caja Negra:
 Tiene como propósito validar si el software cumple o no con los
requerimientos, independientemente de su estructura interna.

37
 02/09/2016

Clasificación de las Técnicas (cont.)

Caja Blanca
 Ignora la relación entre entradas y salidas
 Focaliza en la estructura interna
 Excelente para encontrar problemas en el código

Caja Negra
 Observa la relación entre entradas y salidas
 Ignora la estructura interna
 Excelente para algunos tipos de test:
 Funcional
 Facilidad de uso

Técnicas de Caja Negra

38
 02/09/2016

Test de Caja Negra

 Está dirigido a probar los requerimientos funcionales del sistema

 Se define un input y un output esperado

 Foco en los requerimientos funcionales

 No es una alternativa en vez del test de caja blanca, sino que lo

complementa

Test de Caja Negra

Este tipo de técnica, descubre defectos en las siguientes categorías:

 Funciones incorrectas o ausentes

 Errores de interfaz

 Errores en estructuras de datos o en accesos externos a las bases de

datos

 Errores de inicialización y/o de terminación de funciones

39
 02/09/2016

Derivación de casos de Prueba

Introducción

 ¿Cuáles son los retos actuales que encontramos en los Proyectos de Testing
normalmente?
 El tiempo no alcanza para testear apropiadamente
 Demasiadas combinaciones de input para probar
 Dificultades para determinar el Resultado Esperado de cada test
 Requerimientos inexistentes, documentos pobres o cambiantes
 Falta de entrenamiento en técnicas de testing
 Management que no ha incorporado la cultura Control de Calidad y por
lo tanto el proceso de testing
 Siempre la variable de ajuste es el test

40
 02/09/2016

Axioma del testing

Tengo que
No puedo probar elegir un
un programa en subconjunto
todos sus inputs de inputs
significativos

Técnicas de Derivación

 Testing positivo y negativo

 Clases de equivalencias

 Análisis de Condiciones de Borde

 Tabla de decisión

 Vectores octogonales

 Definición jerárquica

41
 02/09/2016

TESTING POSITIVO Y NEGATIVO

83

Testing Positivo y Negativo

• Técnica muy básica

• Se basa en los valores de entrada del programa
– Un test positivo es aquel con input válido
– Un test negativo es aquel con input inválido
• La técnica consiste en testear valores positivos y negativos para los valores de
entrada del programa.
• Requiere se realice un apropiado balance entre pruebas “positivas” y “negativas”.
• Dado que en general hay más tests negativos que positivos, un balance sugerido es
del 70-80% negativos y 20-30% positivos.

84

42
 02/09/2016

Testing Positivo y Negativo - Ejemplo

• “El input debe ser un entero incluido en el rango entre 0 y 100”.

– Positivos: cualquier entero entre 0 y 100.
– Negativos:
• entero < 0
• entero > 100
• no numérico
• real con decimales

85

CLASES DE EQUIVALENCIA

86

43
 02/09/2016

Clases de Equivalencia
• Técnica que se utiliza para reducir el número de casos de prueba a una cantidad
“manejable”, manteniendo un grado de cobertura razonablemente bueno.

• Es la técnica que utilizamos intuitivamente, aunque no sepamos que se trata de

una estrategia formal.

• Una clase de equivalencia es un conjunto de datos que es tratado de la misma

manera por el sistema. Todos los valores de la clase son “equivalentes”, en
términos de testing.

87

Clases de Equivalencia (cont..)

• Particiona el dominio de entrada en un conjunto de clases de entrada (o inputs)

que tienen comportamientos similares.
Luego se selecciona un valor representativo de cada partición para ser testeado y
se define el caso. Se asume que los resultados predicen el resultado de los otros
valores en la partición, por lo cual es indistinto el valor elegido.
• El proceso incluye dos pasos:
– Identificar las clases de equivalencia
– Seleccionar datos y definir casos de test

88

44
 02/09/2016

Paso 1: Identificar las clases

• Se toma cada condición de entrada y se la divide en dos o más grupos.

• Clase válida: son aquellos inputs válidos para el programa

• Clase inválida: todos los otros posibles estados de la condición.

89

Clases de equivalencia – Heurística según las condiciones de entrada

• Rango de valores o cantidad de valores => 1 clase válida y 2 clase inválidas
– Por ejemplo para 0 <= p <= 100 se definen las siguientes clases:
• 0 <= p <= 100 (válida)
• p < 0 (inválida)
• p > 100 (inválida)
• Conjunto de valores => 1 clase por cada valor válido + 1 inválida
– Por ejemplo, listas de valores.
– Valor pertenece a la lista de valores (válido)
– Valor NO pertenece a la lista de valores (inválido)
• Valor mandatorio => 1 clase válida + 1 inválida
– Por ejemplo, “se debe ingresar una descripción”
• Se ingresa descripción
• No se ingresa descripción

90

45
 02/09/2016

Paso 2: Seleccionar datos y definir casos

• 1. Asignar un número único a cada clase de equivalencia.

• 2. Escribir un nuevo caso de test que cubra la mayor cantidad de clases de

equivalencia válidas hasta cubrir todas las clases de equivalencias válidas.

• 3. Escribir un nuevo casos de test que cubra una y sólo una de las clases de
equivalencia inválidas hasta cubrir todas las clases de equivalencias inválidas

91

Ejemplo

• Tenemos una empresa que otorga préstamos hipotecarios para personas cuyos
sueldos oscilan entre los 1.000 y los 83.333 pesos por mes (punto separador de
miles; coma separadora de decimales); si gana menos de 1.000 pesos no califica; si
gana más de 83.333 pesos mensuales, no necesita el préstamo).
• Además, la empresa sólo otorga préstamos a personas; no así a corporaciones,
sociedades u cualquier otra entidad legal.
• Por otra parte, sólo se otorgan préstamos para adquirir condominios, casa de
campo o casas de familia. No se realizará préstamos para la adquisición de dúplex,
casa rodantes, o cualquier otro tipo de propiedad.
Por último, podrán adquirirse con un sólo préstamo entre 1 a 5 casas (inclusive).

92

46
 02/09/2016

Ejemplo (cont..)

93

Análisis de Condiciones de Borde

94

47
 02/09/2016

Análisis de condiciones de borde

• Pone el foco en los bordes de los valores de entrada y salida de las clases de
equivalencias.
– Los errores tienden a estar en los bordes. Focalizando el testing en estas áreas se
incrementa la probabilidad de detectarlos.
• Esta técnica es una variación de la técnica de partición de equivalencias que se
focaliza en los bordes de cada clase de equivalencia: “Por arriba y por debajo de
cada clase”.
– En vez de seleccionar un valor de test arbitrario dentro de una clase de
equivalencia, el análisis de valores de bordes selecciona uno o más casos para
testear cada margen.

95

Análisis de condiciones de borde - Técnica

• El foco está sobre el espacio de inputs (clase de equivalencias de entrada) y sobre

el espacio de outputs (clase de equivalencias de salida).
– Es más difícil definir las clases de equivalencias de outputs, ya que no es fácil
encontrar los valores de entrada que hacen que el resultado coincida con los
bordes de los valores de output.
• Puede requerir la creación de una gran cantidad de casos de tests debido a la
gran cantidad de variaciones de entradas y salidas que pueden existir.
– Una limitación es que puede ser muy difícil definir el rango de la clase de
equivalencia si involucra cálculos muy complejos. Es por eso que los
requerimientos deben estar lo más detallados que se pueda.

96

48
 02/09/2016

Análisis de condiciones de borde – Heurística según condiciones

de input/output

• Rango de valores o cantidad de valores ⇒ escribir un caso para el máximo, otro

para el mínimo, valor siguiente al máximo, valor siguiente al mínimo.
– Ejemplo. “La cuenta puede tener a lo sumo 2 titulares”.
– Casos:
• Cuenta con 0 titulares. (No cuenta con titular)
• Cuenta con 1 titular.
• Cuenta con 2 titulares.
• Cuenta con 3 titulares.
• Conjunto ordenado ⇒ escribir un caso para el 1ro y para el último.
– Ejemplo: tablas o arreglo
• Read/Update/Insert/Delete el primer registro.
• Read/Update/Insert/Delete el último registro.

97

Ejemplo

• Para el ejemplo de la empresa de préstamos, para Sueldo y Cantidad de

Propiedades podemos crear los siguientes casos:
– Sueldo= 1.000, # Propiedades=1 (Válido).
– Sueldo= 83.333, # Propiedades=1 (Válido).
– Sueldo=1.000, # Propiedades=5 (Válido).
– Sueldo=83.333, # Propiedades=5 (Válido).
– Sueldo=1.000, # Propiedades=0 (Inválido).
– Sueldo=1.000, # Propiedades=6 (Inválido).
– Sueldo=83.333, # Propiedades=0 (Inválido).
– Sueldo=83.333, # Propiedades=6 (Inválido).
– Sueldo=999, # Propiedades=1 (Inválido).
– Sueldo=83.334, # Propiedades=1 (Inválido).
– Sueldo=999, # Propiedades=5 (Inválido).
– Sueldo=83.334, # Propiedades=5 (Inválido).

98

49
 02/09/2016

Test de robustez

• Es una técnica complementaria.

• Consiste en ingresar valores inválidos para el tipo de campo.
– Por ejemplo, un valor mucho mayor al máximo permitido.
• Sirve especialmente para detectar problemas de tipo de datos no manejados.
– Ejemplo:
• Ingresar
• 9999999999999999999999999999999999999999999999999999999999
999999999999999999999999999 es un campo char.

99

Tabla de decisión

100

50
 02/09/2016

Tabla de Decisión

• Se usan para documentar reglas del negocio que el sistema debe implementar.
Sirven como guía para diseñar casos de test.
• Las condiciones representan inputs. Las acciones son los procesos que deben
ejecutarse dependiendo de la combinación de condiciones presentes.
• Cada regla define una combinación única de condiciones que dispara las acciones
asociadas con dicha regla.

101

Tabla de Decisión - Técnica

Condiciones Regla 1 Regla 2 Regla … Regla P

Condición 1
Condición 2
Condición …

Acciones

Acción 1
Acción 2

Acción …

102

51
 02/09/2016

Tabla de Decisión – Técnica (cont.)

• Crear al menos un caso para cada regla:

– Si las condiciones son binarias se escribe un caso por cada regla o columna
(las condiciones son las entradas y las acciones las salidas).
– Si las condiciones son rangos de valores, crear casos para los bordes del rango
(complemento con Análisis de Bordes).

103

Ejemplo
Una empresa aseguradora de automóviles brinda descuentos a aquellos conductores
que estén casados y/o son buenos estudiantes. El descuento es variable.

Condiciones Regla 1 Regla 2 Regla 3 Regla 4

Casado? Si Si No No

Buen estudiante? Si No Si No

Acción

Descuento ($) 60 25 50 0

104

52
 02/09/2016

Definición Jerárquica

105

Definición Jerárquica

• Cada test es dividido en subtests con diferentes condiciones. Se arma un árbol

jerárquico, donde cada nodo indica una condición. Los tests que son especificados
y ejecutados son las hojas del árbol
• Permite minimizar la cantidad de tests “sin sentido”
• Permite organizar la derivación sin olvidarse de ninguna combinación importante

106

53
 02/09/2016

Definición Jerárquica
 Un ejemplo:

Alta de cuenta

Datos válidos Datos inválidos

Caja de ahorro Cuenta corriente

Pesos Dólares
107

Comentarios

 Mediante este tipo de técnicas se espera que ejecutando entre el 1 y

20% de las pruebas se detectan entre el 75 y 80 % de los defectos
totales.
 Debido a que las técnicas no toman en cuenta todas las combinaciones
posibles, pueden perderse combinaciones que se sabe son
frecuentemente usadas o de alto riesgo. En caso que no quedaran
cubiertos, agregar casos de prueba adicionales para dichas condiciones.

54
 02/09/2016

Otras Técnicas

Conjetura de Errores
 Consiste en la intuición sobre dónde y cómo los errores tienen alta probabilidad de
ocurrir.
 No existe una metodología particular para aplicar esta técnica pero la idea básica es
enumerar una lista de posibles errores potenciales o situaciones y escribir casos
basados en la lista.
Es una técnica complementaria especialmente útil en sistemas:
 Hecho “a las apuradas”.
 Modificado por varias personas.
 Con estructuras anidadas, condiciones compuestas.
 Complejos accesos a archivos.
 Programa “collage” formado por partes de otros programas.

55
 02/09/2016

Basado en Historia de Defectos

 Se genera un caso de test (o se reejecuta) por cada defecto encontrado en testeos

anteriores al sistema.
 Esta técnica puede ser usada en test de regresión.
 Se necesita tener la historia de defectos encontrados.
 Conviene priorizar los defectos por criticidad y probabilidad de ocurrencia.

Exception Testing
 Se identifican todos los mensajes de error y los procesos de manejos de
excepciones, incluyendo las condiciones que los disparan. Se escribe un caso de
test para cada condición de error.
 Ejemplo:
 Mensaje de error:
• “Por favor seleccione un registro”.
• “No tiene permiso para eliminar el registro”.
• “Registro duplicado”.
 Casos:
• Baja. Presionar el botón eliminar sin haber seleccionado un registro.
• Baja. Eliminar un registro con un usuario sin permiso de eliminación.
• Alta. Dar de alta un registro cuya clave primaria ya existe en la base.

56
 02/09/2016

Conclusiones

 Ninguna técnica es completa.

 Cada técnica ataca distintos problemas.
 Lo mejor en combinar varias de estas técnicas para complementar las ventajas de
cada una.
 Depende del programa a testear.

Problemas más comunes

 Perder el foco de qué es lo importante.

 Olvidarse de definir casos “normales”.
 Definir muchos casos sin importancia.
 No definir casos de integración.
 Es necesario probar que los circuitos funcionales básicos del sistema
funcionan.
 Definir demasiados casos.
 Definir demasiados pocos casos.

57
 02/09/2016

Algunos factores a observar

 El grado de cobertura que se le dio a las pruebas

 El tipo y cantidad de defectos “no resueltos” para las funcionalidades

críticas

 El criterio de tolerancia de defectos definido durante la fase de

requerimientos

 La criticidad del sistema a implementar para la organización

 Los costos de la no-calidad para la organización

Algunos factores a observar

 ¿Cuál es el costo asociado a la interrupción del servicio?
 ¿Cuánto le va a costar al negocio una interrupción parcial o total “del
proceso” por:
 un minuto?

 una hora?

 un día?

58
 02/09/2016

¿Cuál es el criterio de finalización de las pruebas?

Lo habitual

Cuando nos excedimos en tiempo

Cuando nos excedimos en presupuesto
Cuando nos excedimos en tiempo y en presupuesto

Cuándo Usarlas

59
 02/09/2016

Técnicas de Caja Blanca vs. Técnicas de Caja Negra

 Muy buena para verificación

 Focalizada en la robustez del código

Caja Blanca
 “¿Construimos el producto correctamente?”

 Excelente para validación

 Ayuda a encontrar funcionalidad faltante y

Caja Negra comportamiento insperado

 “¿Construimos el producto correcto?”

Infraestructura para la prueba

 Ambientes
 Herramientas
 Administración de la Configuración

60
 02/09/2016

Ambiente de Prueba

Desarrollo/ Testing/ Producción

Prueba Integración
Unitaria Funcional
Sistema
Performance,
etc.

Herramientas

• Casos de Prueba carga

Tracking de defectos administración

Administración de
requerimientos
Proyectos de Test
planes de prueba

Integrales
casos de prueba y defectos
informes de avance, etc

para Automatización capture y playback

Operativas
para Stress

61
 02/09/2016

Metodología

Fases del Testing

Evaluación

Ejecución Informe de Fin

de Pruebas y
estadísticas

Preparación
Reporte de
Defectos e
Informe de Avance
Estimación y Planificación Casos de Pruebas

Plan de
Inducción
Pruebas

Documentación

Herramienta de gestión de pruebas

62
 02/09/2016

Entregables

Estimación y Planificación Plan de Pruebas

Guía de Pruebas
Preparación Casos de prueba documentados
Informes de avance

Reportes de defectos
Ejecución
Informes de avance

Evaluación Informe de Fin de pruebas

Plan de Pruebas
 Introducción

 Requerimientos de la Prueba

 Estrategia de Prueba
 Tipos de Prueba

 Eventos de Prueba

 Herramientas a emplear

 Recursos
 Personal

 Equipos, ambientes e infraestructura

 Documentos a entregar

63
 02/09/2016

Planificación

Usuarios
clave

Plan
de Responsable
Test desarrollo

Area de
Tecnología

Planificación

 Diseño del plan de pruebas

 Especificación de tipos de Test a realizar y alcance

de las pruebas en función de los requerimientos

 Relevamiento funcional de la aplicación

(circuitos críticos, riesgos e impactos)

 Definición de procedimientos estándares para las pruebas

64
 02/09/2016

Planificación

 Definición de requerimientos de recursos, herramientas,

hardware y software necesario para el test

 Definición de circuitos de información entre test y desarrollo

 Definición de estándares para la clasificación de defectos

 Validación

Preparación

 Diseño de casos de prueba

 Carga inicial de datos en la herramienta de administración

 Evaluación preliminar de transacciones a automatizar

 Validación

65
 02/09/2016

Ejecución

• Ejecución de los casos de prueba

• Generación de reportes de defectos

• Seguimiento de reportes de defecto

• Generación de informes de control de avance

• Ajuste de Plan y Casos de prueba

• Validación

Ejecución

Reportes
de Area de
defectos desarrollo

Informe
de
avance Responsable
desarrollo

66
 02/09/2016

Informe de fin de prueba

 Resumen estadístico

 Casos de prueba ejecutados por ciclo

 Defectos detectados por ciclo según clasificación

 Recomendaciones

 Conclusiones

Evaluación

Jefe de
Proyecto
Informe
de fin
Usuarios
de pruebas
clave
de Test

Analista
responsable

67
 02/09/2016

Circuito de Test

Desarrollo Producción

Ciclos de Versión
Versiones Test definitiva
a probar

Casos de Prueba

68
 02/09/2016

¿Para qué sirve definir casos de prueba?

 La definición de casos de prueba es fundamental

 ¿Por qué?

Importancia de la definición
 Durante el análisis de casos se puede tener una idea genérica de la
aplicación.

 Se detectan de manera temprana problemas de inconsistencia y

completitud en la documentación del sistema a probar. Es recomendable
realizar una revisión de requerimientos previamente a las etapas de
diseño y codificación.

 Permite establecer dimensiones, prioridades y tiempos (planificar).

Evitamos olvidar áreas o funcionalidades a testear.

 Permite organizar y repartir tareas.

69
 02/09/2016

Importancia de la definición (cont.)

 Probar sin definir previamente los casos, podría ocasionar que queden
cosas sin probar (sin intención).

 Se complica definir tiempos y prioridades.

 Se dificulta generar datos previamente.

 Puede probarse varias veces lo mismo.

 Es difícil determinar cuándo parar y si se llegó a cubrir lo necesario.

 Si se recortara el tiempo de testing, no se sabría hasta dónde llegar.

Objetivo del Caso de Prueba

Verificar la condición de capacidad definida por el

usuario o cliente para un programa, sistema o
proceso

70
 02/09/2016

Casos de Prueba

Si se cuenta con tiempo, se pueden desarrollar millones

de casos de prueba, desafortunadamente, solo
contaremos con el tiempo para ejecutar algunos cientos

Debemos elegir los mejores

Casos de Prueba
Un buen caso de prueba, es aquel que satisface, al menos los
siguientes criterios:

• Alta probabilidad de “cazar” un defecto

• No es redundante

• Es el mejor de su especie

• No es ni demasiado simple ni demasiado complejo

71
 02/09/2016

Casos de Prueba

 Alta probabilidad de “cazar” un defecto

 ¿Cómo puede fallar el programa?

 Bajo qué tipo de condiciones

 Cúal es el set de datos que puede provocar el fallo

 No es redundante

 Si dos casos de prueba, pueden descubrir un mismo

 defecto, porqué ejecutar ambos?

Casos de Prueba

 Es el mejor de su especie

 En un grupo de casos de prueba “similar”, un caso

seguramente será más efectivo que otros.

72
 02/09/2016

Casos de Prueba

 No es ni demasiado simple ni demasiado complejo

 Se pueden combinar, varios casos de prueba, en un solo caso,

pero, no cree “monstruos”, son muy complicados de ejecutar o
comprender.

 Es más eficiente crear, mantener y ejecutar casos de prueba

simples.

 Al combinar casos de prueba, se deberá prestar especial

atención, a las combinaciones de datos inválidas.

Punto relevantes

 Verificación funcional.

 Verificación técnica de front-end.

 Verificación técnica de impacto.

 Verificación sobre procesos batch.

73
 02/09/2016

Verificación Funcional

 La funcionalidad verificada debería responder al requerimiento definido.

 El front-end diseñado debería responder a las reglas de negocio.

Verificación Técnica de front-end

 El tipo de dato debería validarse en cada input con mensajes claros para
el usuario.

 El ancho de campo debería restringirse de acuerdo a la estructura de la

tabla en la cual impacta.

 La performance de la aplicación no debería ser menor a la requerida.

 La aplicación debería soportar la operatoria del usuario.

74
 02/09/2016

Verificación Técnica de impacto

 Los impactos concurrentes deberían estar controlados.

 Las relaciones entre las tablas deberían responder al

requerimiento y a las reglas de negocio.

 La duplicación de registros debería estar controlada.

 La integridad no debería ser violada en ningún caso.

 Debería superar las pruebas de caída y recuperación

Verificación sobre procesos batch

 La funcionalidad de los procesos debería responder al requerimiento

 La duplicación del procesamiento debería estar controlada

 En caso de fallas el proceso debería ser capaz de realizar un rollback para

mantener la integridad

 El proceso debería generar logs con detalles de los resultados de la

ejecución

75
 02/09/2016

Casos negativos y Casos positivos

 Casos Limpios o Positivos: el objetivo de este tipo de casos es mostrar que

el producto satisface sus requerimientos, o en otras palabras, “que hace lo
que tiene que hacer”

 Casos Sucios o Negativos: el objetivo de este tipo de casos es romper el

sistema, o en otra palabras, verificar “que el sistema no hace lo que no
tiene que hacer”

 No hay que olvidarse de probar que el sistema funciona antes de

romperlo!!!

Propiedades de los Casos de Prueba

 Características deseables de un caso de prueba

 Económico: No contenga pasos innecesarios.

 Repetible, reusable: Que se pueda volver a ejecutar el mismo CP para

distintos ciclos de prueba

 Traceable: A un requerimiento o caso de uso.

 Fácilmente ejecutable: Independiente de quien lo escribió.

 Mantenible: Independiente de quien lo escribió.

76
 02/09/2016

Caso (Descripción)

• Debe ser claro y conciso de la situación representada el caso.

• En general se debe representar como acción a realizar.

Caso – Lineamientos de su descripción

 Estructurar la descripción de manera tal que quede claro el objetivo del

caso y la pantalla/funcionalidad a testear.

 Longitud: la longitud excesiva atenta contra la claridad.

 Ej: Home Banking. Transferencias

77
 02/09/2016

Caso – Condición y Datos de Entrada

 Condición:

 Longitud: la longitud excesiva atenta contra la claridad. Es necesario ser

claro y conciso a la hora de definir las condiciones de prueba

• INCORRECTO: Ingresar Caja de Ahorro como cuenta Origen, monto a

transferir menor al saldo de la cuenta y realizar la transferencia a
cuenta con la misma moneda que la Cuenta Origen.

• CORRECTO: Cuenta Origen = Caja de Ahorro. Monto < Saldo.

Moneda Cuenta Origen = Moneda Cuenta Destino.

Caso – Condición y Datos de Entrada

 Datos de Entrada:

 En este ítem, deben especificarse inicialmente todas las entidades de

datos, necesarias para la ejecución del caso y las precondiciones que
deben cumplirse previo a la ejecución.

 Ejemplo:

• Campos involucrados

• Permisos de usuario

• Precondiciones

• Datos puntuales según contexto y funcionalidad

78
 02/09/2016

Prioridad – Lineamientos
 ALTA: llevan a recorrer la aplicación a lo ancho. Por lo general salen del flujo principal
de los casos de uso. Generalmente representan el 20-30% de los casos y se ejecutan
en poco tiempo.

 MEDIA: llevar a recorrer las funcionalidades más importantes de la aplicación en

profundidad. Por lo general salen de los flujos alternativos de los casos de uso.
Suelen ser validaciones del sistema u operaciones menos frecuentes pero no por eso
menos importantes para el sistema. Su ejecución no puede posponerse hasta la
puesta en producción.

 BAJA: pueden ejecutarse luego del pasaje a producción. Por lo general son casos
negativos y/o casos de ocurrencia muy poco probables. En general suelen ser el 30-
40% de los casos.

Resultados Esperados – Lineamientos de su descripción

 Debe detallar todas las poscondiciones que deberán verificarse una vez ejecutada
las acciones con las condiciones descriptas en el “Propósito del CP” y detalladas en
“Descripción del pasos”.

 No alcanza con describir en el RE “OK”, “Lo hace bien”, “El alta se realiza
correctamente”, etc.

 Deben:

 Incluirse referencias a las tablas donde se realizan los cambios y acciones sobre las
mismas.

 Incluirse pantallas del sistema donde se puede visualizar que los cambios se
efectuaron con éxito.

 Describir todo lo que implica que una transacción, reporte o funcionalidad opere
“correctamente”.

79
 02/09/2016

Resultados Esperados – Disgregación

 No incluir muchas pruebas en un mismo caso, sino disgregarlos en casos
puntuales. De otro modo el caso puede quedar siempre como “No
Ejecutado” o “Ejecutado” sin estarlo completamente.

 Si un mismo caso tiene dos o más resultados esperados, entonces hay que
partirlo.

Diseño
• Componentes del caso de prueba

 Objetivo (descripción)

 Precondiciones (si existen)

 Paso
Acción
Resultado esperado
Resultado obtenido

 Datos de auditoria

80
 02/09/2016

Precondiciones

 Generales (se dan por sentado):

Ambiente estable

 Versión congelada

 Particulares (se detallan en el caso):

 Datos o estados iniciales requeridos

 Perfil requerido para la ejecución (roles)

Paso

 Acción:
Se describen las acciones a realizar para llevar a cabo la prueba

 Resultado esperado:
Se describe la respuesta que debería obtenerse ante la acción ejecutada

 Resultado obtenido:
Se describe el resultado obtenido como respuesta a la acción ejecutada

162

81
 02/09/2016

Datos de auditoría
 Se detallan los siguientes datos

Autor
Tester
Estado de ejecución
Resultado del caso
Fecha de ejecución
Crititicidad
Set de pruebas
Versión

Metodología de aprobación

 Puntos a considerar para la aprobación de

un caso de prueba

 Para cada paso ejecutado el resultado esperado deberá ser igual al

resultado obtenido.

 Si en al menos uno de los pasos ejecutados el resultado obtenido

fuera distinto del esperado se deberá evaluar la severidad de la
diferencia.

82
 02/09/2016

Metodología de aprobación

 Puntos a considerar para la aprobación de un caso de prueba

 Si el error resultara relevante el caso de prueba quedará en estado

“ejecutado” y resultado “failed”.

 Se deberá en tal caso generar un reporte detallando el defecto

hallado, mencionando los pasos que derivaron en él y los datos
utilizados.

Casos de Uso

 Herramienta para documentar requerimientos de un sistema

 Contienen la funcionalidad del sistema

 Es la forma de expresar como un actor utiliza el sistema

 ¿Cómo armar mi área de pruebas?
 El conjunto de casos de uso reúne toda la funcionalidad del
sistema

83
 02/09/2016

Bibliografía
 The Art Software Testing. Myers. 1979.

 Software Testing techniques. Boris Beizer, 1990.

 Black-Box Testing. Techniques for Functional Testing of Software

and Systems. Boris Beizer, 1995.

 Software Testing, A Craftsman´s Approach. Paul Jorgensen, 1995.

 Software Testing and Continuous Quality Improvement. William

Lewis, 2000.

 A Practitioner´s Guide to Software Test Design. Lee Copeland,

2003.

Fin de la presentación
Muchas gracias
consultas@liveware.com.ar
Pueyrredón 2446 Piso 3, Buenos Aires, Argentina
Tel: +54(11)48021700

84