Este documento describe los conceptos clave del testing de software. Explica los objetivos del testing como verificar la interacción entre componentes e identificar defectos. También describe los tipos de pruebas como pruebas de unidad, integración y aceptación. Además, explica conceptos como el ciclo de vida de pruebas, métricas de cobertura y calidad, y tácticas como inspecciones y pruebas dinámicas.

1. El Testing

2. Contexto

3. Agenda
 Objetivos e Introducción
 La Calidad
 Tipos de Prueba.
 Ciclo de Vida y Mediciones.
 Escenarios en las Pruebas.
 Tácticas de Prueba
 Técnicas de Prueba

4. Objetivos del Testing
 Verificar la correcta interacción entre los
objetos
 Verificar la apropiada integración de los
componentes del software.
 Verificar que todos los requerimientos se han
implantado correctamente.
 Identificar y asegurar que los defectos y su
tratamiento se han priorizado sobre el
desarrollo del software.

5. Introducción
 En muchas organizaciones la prueba del
software significa el 30 o 50 % de los costos
de desarrollo del software, no obstante
mucha gente sostiene que la mayoría del
software no se prueba lo suficiente antes de
ser distribuido.

6. Introducción
 Factores:
 La prueba del software es tremendamente
difícil. Las interrelaciones son tantas que
probar todo el comportamiento es
incuantificable.
 La pruebas no se hacen con una clara
metodología y sin la automatización
requerida.

7. Introducción
 Pruebas bien hechas y planificadas desde el
comienzo del ciclo de vida del software
reducen significativamente los costos de
terminar y mantener el software.
 También reducen los riesgos asociados con
una pobre calidad del software: productividad
deficiente, errores de ingreso y cálculo de
datos, comportamiento funcional inaceptable,
entre otros.

8. Calidad
 Alcanzar la calidad no consiste solamente en
lograr conformidad en la “satisfacción de
requerimientos” o de cumplir con las
expectativas de los usuarios....
 ...Radica en identificar las medidas y criterios
que demuestren que se ha alcanzado en
implantar un proceso que asegure que
cualquier producto realizado siempre alcance el
mismo nivel de calidad.

9. Calidad del producto.
 Es la calidad del resultado tangible o producto
del proceso que lo llevó a cabo.
 En el desarrollo del software el producto es la
suma de muchos artefactos, como:
 El ejecutable y su código (sistemas de
aplicación) que es el producto primario objeto o
motivo de un proyecto de desarrollo.
 Artefactos no ejecutables como manuales de
usuario y materiales de curso.

10. Calidad del producto.
 .....
 Ejecutables no implementados
como la especificación de pruebas y
herramientas de desarrollo.
 Artefactos no ejecutables ni
implementados como los planes de
implementación, de prueba y
modelos.

11. Calidad del producto.
 Como muchos artefactos se basan en
otros, la calidad de los mismos está
relacionada en cierto grado.
 Por esta razón todos los artefactos
deben ser sometidos a métricas de
calidad.

12. Dimensiones de la Calidad
Dimensiones propuestas por el RUP:
 Confiabilidad: Consiste en la
fiabilidad y robustez del software
(resistencia a fallas, interrupciones,
caidas y falta de memoria) uso
adecuado de recursos e integridad del
código.

13. Dimensiones de la Calidad
 Funcionalidad: Es la habilidad de
implementar los casos de uso tal
como se han requerido.

14. Dimensiones de la Calidad
(cont.)
 Rendimiento: Es el perfil de
tiempo de operación del software y
sus características operacionales.
 El perfil incluye el flujo de ejecución del
código, el acceso a los datos, las llamadas
a funciones y las llamadas del sistema.
 Las características operacionales incluyen:
el tiempo de respuesta, la recuperación y
límites en horas pico y estrés.

15. Niveles de Calidad
 Existen 4 niveles de calidad: prueba,
verificación, validación y certificación:
 Prueba
 Las pruebas se llevan a cabo para
demostrar que no hay errores en un
programa. Esto es prácticamente imposible
cuando se ejecuta por primera vez.
 Las pruebas involucran la ejecución de
procesos con la intención explícita de
hallar errores, hacer que el proceso falle.

16. Niveles de Calidad
 Verificación (Alpha test)
 La verificación (alpha test) involucra la
ejecución de partes o todo el sistema en
ambientes simulados, con el fin de
encontrar errores.
 La retroalimentación de esta fase produce
cambios en el software para resolver los
errores y fallas que se descubren.
 Los Alpha test se llevan a cabo en un
ambiente controlado, en el cual el
desarrollador está presente.

17. Niveles de Calidad
 Validación (Beta Test)
 La validación (beta test) involucra el uso
del software en un ambiente real.
 Las transacciones y personas que usan el
sistema son reales y trabajan en su área
de trabajo real.
 El desarrollador no está presente.
 Los usuarios están advertidos de que
están usando un sistema que puede fallar.

18. Niveles de Calidad
 Certificación
 Es una garantía de un programa o
sistema.
 La garantía identifica que el software
hace apropiadamente lo que el
vendedor afirma que realiza.

19. Tipos de Prueba.
 Como ya se mencionó antes hay mucho mas
en la prueba del software que solamente
probar las funciones, interfaces y tiempos de
respuesta. Algunos criterios adicionales de
prueba son:
 Integridad (resistencia a fallas)
 Habilidad para ser instalado / ejecutado en
diferentes plataformas.
 Habilidad de manejar diferentes requerimientos de
manera simultánea (concurrencia)
 Y otros mas....

20. Tipos de Prueba (cont.)
 Para cada dimensión existe un
conjunto de pruebas.......
 Confiabilidad
 Prueba de Integridad: Se concentra
en determinar la robustez del sistema
(resistencia a fallas) y las facilidades
técnicas del lenguaje, sintaxis y uso de
recursos.

21. Tipos de Prueba (cont.)
 Confiabilidad
 Prueba de Estructura : Se enfoca en
asegurar la adherencia del objeto de
prueba a su diseño y concepción.
Típicamente se realiza para aplicaciones
WEB enable asegurando que todos los
enlaces estén conectados, el contenido
sea apropiado y no existan contenidos
huérfanos.

22. Tipos de Prueba (cont.)
 Funcionalidad
 Prueba de Configuración: Pruebas
enfocadas a asegurar la calidad de resolución
de las funciones del sistema. Están
encaminadas a probar diferentes
configuraciones de hardware y software.

23. Tipos de Prueba (cont.)
 Funcionalidad
 Pruebas de Función: Se concentran
en la funcionalidad propiamente dicha; si
tiene los servicios requeridos, métodos o
casos de uso. Se implementan y
ejecutan en diferentes objetos de prueba
como: unidades funcionales, unidades
integradas, subsistemas, aplicaciones y
sistemas completos.

24. Tipos de Prueba (cont.)
 Funcionalidad
 Pruebas de instalación:
Concentradas en las diferentes
instalaciones del hardware y software en
distintas configuraciones y condiciones
tales como: espacio de disco insuficiente
o cortes de energía.

25. Tipos de Prueba (cont.)
 Funcionalidad
 Pruebas de Seguridad: Focalizadas
en asegurar que la disponibilidad de los
datos esté solamente para aquellas
personas o usuarios autorizados.

26. Tipos de Prueba (cont.)
 Funcionalidad
 Pruebas de Volumen: Focalizadas en
verificar el comportamiento del sistema en la
administración de grandes volúmenes de
datos, tanto en la entrada, salida como en la
comunicación con la base de datos. Estas
pruebas se concentran en la elaboración de
queries que recuperen el contenido completo
de la base de datos o manejen variadas
restricciones.

27. Tipos de Prueba (cont.)
 Rendimiento
 Prueba de Benchmark: Compara el
comportamiento de una nueva
funcionalidad u objeto de prueba versus
otro que se comporta de manera óptima.

28. Tipos de Prueba (cont.)
 Rendimiento
 Prueba de Contención:
Concentrada en verificar la
concurrencia esto es muchas
demandas a un mismo recurso
(registros de datos, memoria, etc.)

29. Tipos de Prueba (cont.)
 Rendimiento
 Prueba de Carga: Es un tipo de prueba que
verifica y asegura los límites aceptables de
operación del sistema bajo variadas cargas de
trabajo. Las métricas incluyen las
características de la carga de trabajo y los
tiempos de respuesta. Cuando los sistemas
incluyen arquitecturas distribuidas o balance de
carga, se deben hacer pruebas especiales que
aseguren que los métodos de distribución y
carga balanceada funcionen apropiadamente.

30. Tipos de Prueba (cont.)
 Rendimiento
 Perfil de Rendimiento: Es una prueba en
donde el rendimiento es probado y
monitoreado en la ejecución de flujos de
trabajo, acceso a los datos, llamadas a
funciones y al sistema con el propósito de
encontrar cuellos de botella y procesos
ineficientes.

31. Tipos de Prueba (cont.)
 Rendimiento
 Pruebas de Estrés: Es un tipo de prueba
que se efectúa como consecuencia de haber
encontrado un comportamiento anormal en el
sistema. Se concentra en probar las funciones
implicadas en situaciones extremas como
sobrecarga del sistema, memoria insuficiente,
no disponibilidad de servicios de software y/o
hardware o disminución de los recursos
compartidos.

32. El ciclo de Vida de la Prueba.
 Durante su Ciclo de Vida, el Software se
refina en cada iteración. Bajo este contexto el
ciclo de vida de la prueba debe tener la
misma aproximación.
 Este ciclo de vida debe ser integrado con el
enfoque iterativo, lo que significa que cada
iteración va a tener un ciclo de pruebas
siguiendo ese mismo patrón.

33. El ciclo de Vida de la Prueba.

34. El ciclo de Vida de la Prueba.
 Este enfoque iterativo permite las
pruebas de regresión. Muchas de las
pruebas efectuadas en la iteración X se
usan como pruebas de regresión en la
iteración X +1 y así sucesivamente.
 Debido a que la misma prueba se repite
varias veces es necesario un esfuerzo
adicional para automatizarla.

35. El ciclo de Vida de la Prueba.

36. Mediciones clave en las
Pruebas.
 Las mediciones clave en la
prueba incluyen: cobertura y
calidad.

37. Mediciones clave en las
Pruebas.
 La cobertura es la medición de
cuan completo está el software en
su funcionalidad.

38. Mediciones clave en las
Pruebas.
 La calidad es la medición de la
confiabilidad, estabilidad y
rendimiento del objeto de prueba.
La calidad se basa en los
resultados de las pruebas de
evaluación y el análisis de los
defectos identificados durante la
prueba.

39. Mediciones clave en las
Pruebas.
 La métricas de Cobertura
responden a la pregunta: ¿Cuan
completa está la prueba? Estas
pruebas se miden respecto a los
requerimientos y casos de uso, o al
código desarrollado versus el
diseñado (ejecución del código).

40. Mediciones clave en las
Pruebas.
 Calidad es un indicativo de que el
software también cumple con los
requerimientos. Aquí los defectos son
identificados como requerimientos de
cambio.

41. Escenarios en las Pruebas.
Unidad de Prueba
 Las unidades de prueba se deben
definir en la fase inicial de una iteración
y se debe concentrar en probar
elementos pequeños. Usualmente
estos elementos son componentes y
como estos participan en la ejecución
de un caso de uso.

42. Escenarios en las Pruebas.
Prueba de Integración o Integral
 Esta prueba está orientada a asegurar
que los componentes implementados
operan apropiadamente cuando
combinan esfuerzos en la ejecución de
un use case.

43. Escenarios en las Pruebas.
Prueba del Sistema
 Se realiza cuando el software está
funcionando como un todo o cuando se
esta probando todo un subsistema
completo.

44. Escenarios en las Pruebas.
Prueba de Aceptación
 Esta prueba es el test final antes de
distribuir el software para su operación
y uso.

45. Tácticas en las Pruebas.
 Una Táctica busca reducir la
posibilidad de que un riesgo
específico tenga lugar.
 Se enfatizará en dos tipos de
tácticas:
 Inspecciones.
 Pruebas dinámicas.

46. Inspección
 Las inspecciones son aplicables en
todas las etapas de desarrollo del
producto (no sólo para código).
 No requieren herramientas
sofisticadas.

47. Inspección
 Inspecciones: Roles y
responsabilidades
 Autor: Desarrollador del producto que será
inspeccionado.
 Inspectores:
 Colegas del autor.
 Uno de otro proyecto.
 Moderador: Miembro del grupo de
aseguramiento de calidad.

48. Inspección
 Preparación de la Inspección: Proceso
 Autor prepara el producto para revisar,
lista de chequeo y material de soporte.
 Moderador selecciona 2 inspectores y
elabora cronograma.
 Autor distribuye material.
 Autor presenta el producto a los
participantes en la inspección.

49. Inspección
 Revisión individual: Proceso:
 Inspectores y moderador revisan
individualmente, según lista de
chequeo.
 Inspectores registran defectos.
 Inspectores registran tiempo invertido
en revisión.

50. Inspección
Preparación Rev. Individual Reunión de Ins.
Cambios Corr. De errs.
?
Verif. De corr. Congelar versión
An. Causal de
errs.

51. Pruebas dinámicas
 Consiste en la ejecución de programas para
detectar errores.
 Son menos efectivas que inspecciones.
 Los defectos se manifiestan como
discrepancias en el comportamiento
esperado.
 La corrección de un error puede ser difícil,
porque:
 Puede ser difícil aislar errores.
 Los problemas pueden ser intermitentes, difíciles
de repetir.

52. Técnicas de Prueba
 Caja blanca o Pruebas estructurales
 El conocimiento del diseño interno del software se
usa para construir casos de prueba.
 Caja negra o Pruebas funcionales
 Casos de prueba basados en la especificación del
software.
 Pruebas basadas en escenarios o casos de
uso
 Actuar como usuario final.
 Crear escenarios para detección de errores.

53. Técnicas de Prueba
 Pruebas selectivas
 Más casos de prueba para componentes
más usados.
 Más rigor en prueba de componentes
críticos.
 Más casos de prueba para componentes
más complejos.

54. Técnicas de Prueba