Testing de Aplicaciones

Módulo 1 - Conceptos Elementales de Testing

LA PIEDRA Y EL HOMBRE

El distraído tropezó con ella;

el violento la utilizó como proyectil;
el emprendedor construyó con ella;
el campesino, cansado, la utilizó como asiento;
Drummond de Andrade, la poetizó;
David, la utilizó para derrotar a Goliat;
Michelangelo le sacó la más bella de las esculturas.

En todos los casos la diferencia no estuvo en la

piedra, sino en el hombre

Este curso es el mismo para todos.

Depende de nosotros que hagamos con él… En Breve Empezamos…
PRESENTACION DEL DOCENTE
 Nombre: Marcelo Fabián Sívori - LinkedIn: /marcelo-f-sivori-90945415
Email: masivori@uade.edu.ar - Móvil: +54 9 11 6336 9482

 Licenciado en Sistemas con Posgrado en Calidad de Software e IA, 35 años de experiencia.

Especializaciones en Metodologías y Marcos Metodológicos (PMI, Hibrido, Ágil,).

 Puestos: Programador, Analista Funcional, Analista de Procesos y Negocios, Jefe de Centro de Cómputos,
Jefe de Área IT, Project Manager, Analista QA-Tester, QA Manager, Gerente de IT, Asesor. Consultor. Entrenador.
Docente y Generador de Contendido de carrera QA Management, Analista Funcional,
PEPM, Gestión de Proyectos, Lean@Kanban, Producto Owner, Transformación Digital, ISO 20000-ITIL
 Consultoras:

 Empresas Clientes:

IMA
 Países:
España EEUU Colombia Paraguay Venezuela México Argentina

 Propuesta de valor: Trascender a través de la enseñanza, brindando conocimientos y experiencias de una manera
simple y concreta.
Guía de Actividades
Hora Puntos a trabajar .

00:00 Presentación de los alumnos (expectativas), y del docente

Presentación de la Materia

00:15 Desarrollo de la Clase – parte 1

02:00 Break

02:20 Desarrollo Clase – parte 2

03:45 Repaso de lo visto.

04:00 Cierre
Conceptos de Calidad

Módulo 01 – Principios y Fundamentos

Contenido
 Que es Calidad
 Como Hacemos Calidad
 Donde Aplica
 QA/QC
 Atributos de QA/QC
 Circuito Virtuoso de Deming
 Normas y Estándares

Fuente: Google
Que es Calidad

Es el grado en el cual un sistema, componente, o proceso

satisface los requerimientos especificados (descripto por el
Analista Funcional) y las expectativas o necesidades del
cliente
Glosario de Ingeniería de Software del IEEE

Criterios de Aceptación del SW  75 % esta ok

Los Criterios de Aceptación surgen de Necesidades del Cliente (describe a través de

Requerimientos de Usuario)
Los requerimientos describen los atributos que debe cumplir el sistema (analista funcional).
Atributos deben cumplir con un criterio cuantitativo
Como Hacemos Calidad
Validamos si cumple el propósito del Producto
Ejercicio:
Enumeramos sus atributos Aplicamos estos pasos con
algún producto.
Cuantificamos sus atributos Por ejemplo un marcador, una
lamparita de luz, un celular.

Definimos sus Patrones de Medición o métricas Ej: birome

Cartucho 20ml con variación de
Medimos el producto o una muestra de él 0,2 ml (Mínimo 19,8 ml y
máximo 2,2 ml)
Comparamos medición contra métrica Subjetivos  Objetivos

Aprobamos o confirmamos desvíos

 Hablado de PROCESOS El CLIENTE no sabe lo que quiere
(Para que) pero lo quiere ‘YA’ !!!
Necesidades del
Negocio

Un requerimiento puede atravesar

Relevar
1 o mas procesos.
1 proceso puede tener mas de 1
requerimiento
Requerimientos de los (Qué a nivel
Usuarios (funcionales) funcional)

Analizar
Atributos a nivel
cuantitativos

Requerimientos Técnicos (analista funcional) (Qué y como técnico

Diseños de bbdd, pantallas, Casos de uso, /funcional en detalle)
interelaciones, DER, DTS
Hablado de PROCESOS

Front-end Back-end
Entrada

$$$ Co
mer
cial
EMPRESA
IT y
otras
$$$
Salida
(Costos)
Vista del proyecto (a medida que avanzamos)

Inicio Fin
Tiempo
Licitación o Business
Contratación Case
directa (Caso del Duración
(RFP) Negocio) del proyecto

Cronograma
Presupuesto
Alcance y fuera del alcance
Recursos Humanos y Técnico….
Marco metodológico
Donde Aplica la Calidad

• Se aplica en procesos
• Debe estar orientada al cliente
• Es mejora continua “siempre” Circuito de mejora de calidad
Mal  bien
• Debe ser medible Bien  mejoremos
Mejorado  optimizado
• Nos involucra a todos a todo Optimizado  Excelencia
Excelente  World Class
• Incorpora activos a la compañía World Class  Estado del arte
Estado del ARTE  cambio el
paradigma y empiezo de nuevo

Todo aquello que no es medible no tiene calidad!!

Quality Assurance – Quality Control

QC QA
- Detecta problemas en los productos - Asegura que los desarrollos cumplan con
los procesos y estándares definidos
- Verifica que los productos cumplan con
- Asegura que los procesos, planes y
los estándares de calidad especificados en
estándares utilizados en el proyecto
el Plan de Proyecto tanto funcionales como
cumplan con los estándares
técnicos organizacionales
- Revisa el producto - Revisa Procesos
Características de Calidad

QC QA
Usable Definido
Correcto Documentado
Confiable Practicado
Disponible Medido
Performance
Mantenible
 Ciclo Virtuoso de Deming
Requerimiento
del usuario

Espiral ascendente de mejora

continua de la calidad
Normas y Estándares

Standard

Metodología

Aplicación Templates
Conceptos de Testing

Módulo 01 – Principios y Fundamentos

En Breve Continuamos…
Contenido
 Que es Testing
 Visión del Testing
 Para que Testeamos
 Actividades del Analista QA/Tester
 Validación vs Verificación
 Error, Falla, Defecto
 Trazabilidad

Fuente: Google
Que es Testing

Es el proceso que consiste en todas las actividades del ciclo de

vida, tanto estáticas como dinámicas relacionadas con la
planificación, preparación y evaluación de productos de software y
productos relacionados con el trabajo para determinar que cumplen
los requisitos especificados, para demostrar que son aptos para el
propósito y para detectar defectos.

ISTQB
Visión del Testing

Proceso de correr aplicativos con el

objeto de encontrar defectos

Proceso inmerso en la mejora continua

de la calidad
Para que testeamos

Para detectar y resolver problemas tan pronto como sea posible

Para verificar que las pruebas cumplan con el requerimiento

Para generar compromiso en los usuarios

Para trabajar con (orientación al) cero defecto desde el principio

Nivel de compromiso o interrelación del Usuario / Cliente

Alto

Bajo
Análisis Plan de Análisis de Diseño de Construc. Test Test de Test de UAT
de Req. Pruebas Escenar&CP CPs de CPs Unitario Integración Sistemas
Tiempo
(meses)
SW V3.1

Ejecución de
Pruebas
Actividades del Analista QA / Tester

1. Confeccionar estrategias y planes de prueba

2. Analizar requisitos y/o requerimientos
3. Diseñar de escenarios y casos de prueba
4. Establecer ambientes de prueba
5. Generar set de datos de prueba
6. Ejecutar casos de prueba
Actividades del Analista QA/Tester

1. Confeccionar estrategias y planes de prueba

2. Analizar requisitos y/o requerimientos
7. Administrar, Registrar e Informar las pruebas
3. Diseñar de casos de prueba
8. Realizar reportes y seguimiento de defectos
4. Establecer ambientes de prueba
9. Confeccionar avances de prueba e informes final
5. Generar set de datos de prueba
10. Llevar indicadores de gestión
6. Ejecutar casos de prueba
11. Asistir a usuarios en el UAT
Validación vs Verificación
Responde a las siguientes preguntas:

Apunta a VALIDACION Apunta a VERIFICACION

ISTQB: International Software Testing Qualifications Board

Error, Falla, Defecto

• Equivocación Humana (del programador)

Error

• Desperfecto que puede causar que un

Defecto componente o sistema falle (en el Software)

• Diferencia entre el resultado esperado y el

Falla obtenido (incumplimiento del requerimiento)

ISTQB: International Software Testing Qualifications Board

Trazabilidad = CALIDAD

Capacidad de identificar elementos relacionados en la

documentación y el software, tales como requisitos con
las pruebas asociadas
ISTQB

Defecto 87 – CP12
Caso Prueba 12 SW ver 3.04
Requerimiento
34.02 Caso Prueba 15
SW ver 4.01
Caso Prueba 27
ISTQB: International Software Testing Qualifications Board
Fundamentos del Testing

Módulo 01 – Principios y Fundamentos

Contenido - Los 7 Fundamentos o Principios del Testing
 Principio 1 – La Prueba Muestra la Presencia de Defectos
 Principio 2 – La exhaustividad es imposible
 Principio 3 – Detección Temprana de Defectos
 Principio 4 – Agrupamiento de Defectos
 Principio 5 – Paradoja del Pesticida
 Principio 6 – Es Dependiente del Contexto
 Principio 7 – La Ausencia de Defectos es una Falacia

Fuente: Google
Fundamento 1 – Muestra la Presencia de Defectos,
no su ausencia

La prueba puede mostrar la presencia de defectos, pero no que no haya defectos. La prueba
reduce la probabilidad de que queden defectos no descubiertos en el software pero, incluso
si no se encuentran defectos, el proceso de prueba no es una demostración de la corrección.

ISTQB
Fundamento 2 – La Exhaustividad No Es Posible

CADA CP esta ASOCIADO A un

DETERMINADO DATO
Fundamento 3 – La Detección Temprana (de Errores)
Análisis Diseño Construcción Test de Comp Test integ Test Sistema UAT PRODUCCION
Sin control en Origen del defecto
etapas
zona de caos HOTFIX
Descubrimiento
Análisis Diseño Construcción Test de Comp Test integ Test Sistema

Análisis Diseño Construcción Test de Comp Test integ Test Sistema UAT
Con control en Origen del defecto
etapas

Descubrimiento
Análisis Diseño Construcción Test de Comp Test integ Test Sistema
Fundamento 3 – Detección Temprana
Fundamento 4 – Agrupamiento de Defectos

Asociado complejidad del requerimientos, del proceso de negocio o a la complejidad

ciclomática del software. Es común ver que a mayor complejidad mayor nivel de defectos
hallados.

ISTQB
Complejidad Ciclomática
Prod
Imp?
Tipo de IVA
(A, B C)
Sumar (X,Y) Calcular IVA En T del
F?

Periodo
(FI,FF)
Fundamento 5 – Paradoja del Pesticida

Si las pruebas se repiten una y otra vez, eventualmente estas pruebas no encontraran
nuevos defectos. Para detectar nuevos defectos es posible que sea necesario cambiar a
nuevas pruebas y a nuevos datos de pruebas.
Las pruebas ya no son efectivas del mismo modo que los pesticidas ya no son efectivos
para matar insectos después de un tiempo.

ISTQB
Fundamento 6 – Depende del Contexto

Las pruebas se realizan de manera diferente según el contexto (ambiente de desarrollo,

pruebas, pre-producción, etc.).
Por ejemplo, la prueba se desarrollan de manera diferente en marcos predecibles
(metodología tradicional) que en framework agile (scrum).

ISTQB
Fundamento 7 – La Ausencia de Defectos es una
Falacia

La ausencia de errores es una falacia (es decir, una creencia equivocada) conforme a que
las pruebas contribuyen a minimizar los defectos en un gran numero, pero eso no indica que
se realice al 100 %.

ISTQB
Tipos y Técnicas de Pruebas

Módulo 01 – Principios y Fundamentos

Contenido
 Tipos de Prueba
 Pruebas Funcionales
 Niveles de Prueba
 Pruebas No Funcionales
 Pruebas estructurales y Pruebas Asociadas al Cambio
 Enfoque, Tipos y Técnicas de Pruebas

Fuente: Google
Tipos de Prueba

Funcionales No Funcionales Estructurales Asociadas al

Cambio
Pruebas Funcionales

Verifican que el sistema, módulo o componente realice lo que está

establecido en los requerimientos funcionales o casos de uso (UML).

• componentes
• integración
Funcionales Se pueden llevar a cabo en todos los niveles
• sistemas
• aceptación

ISTQB: International Software Testing Qualifications Board

Niveles de SQA Team
Users
Pruebas Pruebas de E2E
Aceptación Nuestro
(Alfa/Beta) SQA Team ambiente
tecnológico
Pruebas de Sistema de pruebas
Incluye casos de uso*
SQA Team
Pruebas de Integración Pruebas
(Incremental/Big Bang) automatizadas
Objetos: referidas a
Clases, Métodos pequeñas
Developers piezas de
Pruebas de Componentes/UNITARIAS código

*El Caso de Uso es uno de los tipos de diagramas utilizado por el Lenguaje Unificado de Modelado (UML).
Describe el comportamiento del sistema y muestra la reacción del sistema desde el punto de vista del usuario.
Hablando de Caja Blanca y Caja Negra
Sistema (big-bang)

Datos Paquete 2
SW Resultados

Paquete 1
Datos
Set a =1;
If (s) then
dfd() Resultados
Else etc.
…
..
…

Paquete 3
Estructura Cliente-Servidor de 3 capas
FRONT-END BACK-END

INTERNET

Nombre (20 Char)

AP!1 Marcelo Fabian Pedro

AP!4
Nombre (40 Char) AP!2
Marcelo Fabian Pedro Alberto
AP!3
Pruebas No Funcionales

Verifica los aspectos necesarios para el normal funcionamiento

del sistema en cuanto a los requerimientos técnicos o de IT

• Performance, Carga, Stress

• Usabilidad
No
Funcionales • Mantenabilidad
Las más típicas son: • Fiabilidad
• Portabilidad
• Preparación Operacional
• Deployment
• Seguridad Informática
Pruebas Estructurales y Asociadas al Cambio

Estructurales Asociadas al Verifican el sistema luego de la resolución de

Cambio defectos. Son:
• Test de Regresión
• Re-Test

• Smoke Test o Test de Humo

Verifican la arquitectura del sistema
(comúnmente se aplica luego
de ingresar una nueva
versión de SW)
Enfoques y Tipos
Enfoque Estático, Tipos y Técnicas
Enfoque Dinámico, Técnicas de Caja Blanca
Ejercicio: Requerimiento: Hace cumplir la siguiente regla de negocio

Edad: > 15 y < 65 años (mayor a 15 y menor a 65)

¿Con qué datos probamos?

…
…
…
…
Edad: ___
…
…. …
…
GRABAR …
…
Ejercicio: Requerimiento: Hace cumplir la siguiente regla de negocio

Edad: > 15 y < 65 años (mayor a 15 y menor a 65)

Incorporar FUERA DEL ALCANCE y/o SUPUESTOS:

-El valor 15 y 65 no son valores válidos
Valores con los que pruebo:

13 mensaje de error  Casos no válido, caso no feliz,

caso negativo
14 mensaje de error
15 mensaje de error
17  dato es válido  Caso válido, caso feliz, caso
… positivo
Edad: ____ 18  dato es válido
…. 25  dato es válido
30  dato es válido
GRABAR
45  dato es válido
65 mensaje de error
67 mensaje de error
70 mensaje de error
72 mensaje de error
Ejercicio: Requerimiento: Hace cumplir la siguiente regla de negocio

Edad: > 15 y < 65 años (mayor a 15 y menor a 65)

Esquema: CP1(10) CP2(15) CP3(34) CP4(65) CP5(78)

T (años)

15 65
0
No valido
No valido No valido válido No valido
Técnica
CP6 : Otro CP no válido más: Símbolos, letras, Reales SCYC
CP7: Null (presionar Enter sin cargas dato)

Cuando las reglas están en la capa cliente entonces las

…
pruebas se unifican….
Edad: 89____ Pruebo ordenadamente los casos negativos y luego los
…. casos positivos.
Marce… y otros Por ejemplo: 10, 15, 65, 78, NULL (resultado esperado es no
GRABAR pasar) 34 (resultado esperado es progresar al siguiente
campo)
Ejercicio: Requerimiento: Hace cumplir la siguiente regla de negocio

Fecha: condiciones habituales

¿Con qué datos probamos?

…
…
… …
Fecha: 99/99/9999
…. …
…
GRABAR …
…
…
Enfoque Dinámico, Técnicas de Caja Negra

Partición de equivalencias

Análisis de valores límites

Transición de estados

Tablas de decisión

Casos de uso
 Testing de Aplicaciones
Clase 3 – El Proceso del Testing

En Breve Empezamos…
Enfoque Dinámico, Técnicas Basado en experiencia

Pruebas Exploratorias

• Exploratory Testing

Predicción de Errores

• Error Guessing
Hagamos memoria…

¿Qué es QA y QC?

¿Para qué se realiza testing?

¿Cuáles son sus fundamentos?

Validar vs Verificar. ¿Cuándo se aplica?

¿Qué es error, falla, defecto?

¿Qué es detección temprana de errores?

¿Qué niveles del testing conoce?

¿Cuáles son los tipos y técnicas de testing?

Revisión
Repase
• Los puntos visto en la clase

Realice
 Las preguntas necesarias al o la docente antes de continuar
 Realice los ejercicios de la práctica
Continuación del ejercicio Edad (> 15 y < 65 años) se agrega el campo email

Edad: > 15 y < 65 años

Email con formato normal
Solo un @, un o dos puntos, primer parte del email sea solo con alfabéticos y números, incluye ‘_’ o ‘-’
Ejemplo válido: marcelo_f-sivori@uade.com.ar

Cualitativos (tipificación de datos)

TODO OK Solo un @, ninguna @, mas de @, posicionar @ antes, después, en
… el medio.
Edad: 10_ un o dos puntos: ., .. , …., posiciones del punto
…
Email: _______
….
Datos (cuantitativo)
Confirmar pepe@etc.com, pepeetc.com, pepep@@@.com, @pepe.com,
pepep.com@
pepe@fff.com.ar, pepefffcom.ar.Er.err, pepe@.., pepe@....,
pepe..@com,
pepe113@.., pepe p12@..., AAA$#%, nulo @sddfds…., ‘ ‘@ddd…
mar_123@web.com... ----@..., ____@web.com
Continuación del ejercicio Edad (> 15 y < 65 años) se agrega el campo email

Esquema:
Campo Edad

CP1 CP2 CP3 CP4 CP5 CP6

TODO OK (10) (15) (20) (65) (78) ($%)
…
Edad: 10_

Email: _______
CP3-9
…. CP1-7 CP2-8

Confirmar
Campo email

CP7 CP8 CP9

(maria@emp.com) (maria@@emp.com) (maria Julia@emp.com)
La combinatoria de los casos son: 6 x 3 = 18

1. Probar el caso Edad = 10 y email = maria@emp.com

2. Probar el caso Edad = 15 y email = maria@@emp.com La combinatoria optimizada da que tengo
3. Probar el caso Edad = 20 y email = maria julia@emp.com solo casos 6 casos por hacer.
4. Probar el caso Edad = 65 y email = maria@emp.com
Como extensión proponemos mas campos

Cantidad de CP
Campos: Edad, Email, Nombre, DNI

…
Edad: --------------#CP= 6 Cantidad combinada de casos de prueba:
Email: --------------#CP= 3 6 x 3 x 5 x 8 = 720
Nombre:------------#CP= 5
DNI: -----------------#CP= 8
….

¿Cuántos Casos de Prueba tengo?

Al combinar optimizadamente voy a tener  8 CP

Ejercicio para realizar en casa

Alta del Cliente: Reglas:

DNI: numérico, máximo 8 dígitos (arriba de 999999)
Sexo F , M, O (1 carácter),
Nombre: Apellido: 14224dd Nombre : a-z , A-Z, blanco, ñ, vocales con acento, apóstrofe,
(max char (20) según BBDD. Se excluye: cedillas, dieresis,
DNI: Apellido: ídem nombre
Email: Email: no puede ocurrir @@, con dominio: ej correcto:
Sexo: juan@comercio.com
Dirección:
Nota: No aceptan campo vacío o en blanco
ENTER
Control se realiza en el cliente

Comúnmente el control
combinado se realiza en el NOMBRE?
servidor
CP1.1 CP1.2 CP1.3

Maria 123 NULL

Casos Combinado toma

en un mismo momento
las pruebas: CP1.1 +
CP2.1 APELLIDO?

CP2.1 CP2.2 CP2.3

Garcia 123 NULL

Caso Uso
ID: CU456
Titulo:: Solicitar Vacaciones

Descripción (paso a paso del proceso)

1.-El solicitante ingresa en el sistema la Solicitud.
2.- El sistema toma los datos requeridos y confirma
el ingreso
3.- Ej jefe revisa y aprueba la solicitud
4.- El sistema toma los datos de la aprobación
4.1.- Si el jefe aprueba el sistema envía a RRHH el
tramite administrativo
4.2.- Si el jefe rechaza, el sistema Notifica el
rechazo a Solicitante.
 Diagrama Transacción Estado
DTE

Tipo de Solicitud : Vacaciones Status: SV Status: SV

Datos: Ingresado Rechazada
- Fecha de Inicio de
vacaciones (dd/mm/aaaa)
- Fecha Final de Vacaciones
(dd/mm/aaaa)
- Cantidad de días solicitados
(surge de la diferencia entre Status: SV
fecha final y fecha inicio) Revisado
- ID del Empleado
- Nombre y Apellido del
Empleado
- Fecha de Solicitud
Status: SV
(dd/mm/aaaa) Aprobada
Diagrama Transacción Estado
DTE

C
Ingresar solicitud

Status: SV
Ingresado Status: SV Status: SV
Ingresado Rechazada

Status: SV
Revisado

Status: SV
Revisado
Status: SV
Rechazada

Status: SV Status: SV
Aprobada Aprobada

F
Ejemplo Diagrama de Transición y Estado
(DTS)

E2E End-to-End (visión del usuario) y pruebas integrales

Ejemplo Diagrama de Transición y Estado
C
(DTS)
Buscar /Seleccionar producto TV por menú vertical
(Sansung 40´´)
Requerimiento: Comprar un Prod.
producto por e-commerce Encontrado

Seleccionar forma de Pago (TC Visa, Francés, 18 c)

y Envío (Retiro en sucursal)

Forma de P
realizada

Ingresar datos TC/TD (1234, etc)

TC ingresada

Confirmar Compra de Producto

Pago
Confirmado

T
Ejemplo de Tablas de Decisión

Requerimiento: Realizar la comprobación del ingreso de Credenciales (Usuario / clave) en un

sistema xxxx

Completitud:
FUERA DEL ALCANCE: pruebas cuyos datos no se encuentran disponibles en la base de datos
SUPUESTO: El usuario existe en la base de datos y sus datos son válido

Condición
Válido
 Usuario Usuario V V F F
No es válido
Clave F V F V

Válido Respuesta NI I NI NI
 / clave
CP CP neg CP pos CP neg CP neg
No es válido
Ejemplo de Tablas de Decisión

Requerimiento: Realizar la comprobación del ingreso de Credenciales (Usuario / clave) en un

sistema xxxx

Completitud:
FUERA DEL ALCANCE: pruebas cuyos datos no se encuentran disponibles en la base de datos
SUPUESTO: El usuario existe en la base de datos y sus datos son válido

Cajero
Válido Perfil
Asistente
Válido  / clave
 Usuario No es válido Tesorero
No es válido

No es un caso de prueba si
No es válido el control se ejerce primero
por el campo Login
Ejemplo de Tablas de Decisión
Ingresar usuario y clave para acceder al sistema (si existe o no en la bbdd, o sea si está registrado).

Campos Posibilidad
OK
Usuario
Campos Cond1 Cond2 Cond3 Cond4
Erróneo
Usuario F F V V
CONDICION
Clave F V F V
OK
Perfil
Clave
Resultado Error Error Error OK
ACCIONES
Erróneo
CP1 (-) CP2(-) CP3(-) CP4(+)

Cajero
Campos Cond1.1 Cond1.2 Cond1.3
Perfil Combinatoria 4x 3  12
Asistente Usuario V V V

Tesorero Optimizada: 6 Clave V V V

Perfil Cajero Asistente Tesorero

CP4.1 (+) CP4.2(+) CP4.3(+)
Ejemplo de Arbol de Decisión
Ingresar usuario y clave, y perfil para acceder al sistema (si existe o no en la bbdd, o sea si está registrado)

CONDICIONES ACCIONES
OK Ingrese al Sitio
OK Clave

Erróneo
Usuario

No ingrese al Sitio
OK
Erróneo Clave

Erróneo
Cajero
Perfil
Asistente

Tesorero

No existe
Caso de Uso
• Un diagrama de caso de uso es una descripción de las actividades que deberá realizar alguien o algo para
llevar a cabo algún proceso.
• En el contexto de ingeniería del software, representa a un sistema como un conjunto de interacciones.
Sirven para especificar la comunicación y el comportamiento
Ejemplos de Descripción Caso de Uso
Ejemplos de Descripción Caso de Uso
Ejemplos de Descripción Caso de Uso
Caso de Uso y Caso de Prueba
Necesidad del Negocio (idea de usuario)

Requerimiento del usuario (Historia de Usuario)

Analista Funcional

Especificación en Detalle del Requerimiento (IEEE 830) o

Caso de Uso (UML)

Análisis de ERS/HU/Req
Analista QA (Tester)
Descripción de los Escenarios / Casos de Pruebas
¡Muchas gracias!
¡Sigamos trabajando!