CLASE1

De qué hablamos:
Testing de Software:
“Las pruebas intentan demostrar que un programa hace lo que se intenta que haga, así como
descubrir defectos en el programa antes de usarlo.”

Métodos formales:
“El uso de especificaciones formales y modelos que eliminan la ambigüedad y reducen las
posibilidades de introducir errores durante el proceso de desarrollo”.

1. Fundamentos de la Calidad de Software

Mezclamos 2 conceptos: “calidad” y “software”

¿Que es calidad?
¿Que es software?

1.1. Concepto de calidad

Hay muchas definiciones …
“conjunto de propiedades inherentes a un objeto que le confieren capacidad para satisfacer
Concepto de “calidad”
necesidades implícitas o explícitas” (necesidades del destinatario del objeto) [Wikipedia…]
Hay muchas definiciones …
“Calidad: grado en el quedeun
“conjunto conjunto
propiedades de características
inherentes a un objeto que leinherentes a un objeto
confieren capacidad (producto, servicio,
para satisfacer
necesidades implícitas o explícitas” (necesidades del destinatario del objeto) [Wikipedia…]
proceso, persona, organización, sistema o recurso) cumple con los requisitos” [ISO9001]
“Calidad: grado en el que un conjunto de características inherentes a un objeto (producto,
servicio, proceso, persona, organización, sistema o recurso) cumple con los requisitos” [ISO9001]
“La calidad de un“La
producto o servicio es la percepción del cliente respecto de la capacidad del mismo
calidad de un producto o servicio es la percepción del cliente respecto de la capacidad del
para satisfacer sus necesidades”
mismo para satisfacer sus necesidades”

Satisfacer
Percepción del Propiedades
necesidades/requi
cliente inherentes
sitos

Según los “Grandes” de la Calidad…

 Juran: “la administración para lograr calidad abarca tres procesos básicos: la planificación
de la calidad, el control de la calidad y el mejoramiento de la calidad”.

Se enfoca en “proceso” y “administrar”

Ishikawa: “Eliminarla causa de raíz y no los síntomas”

Se enfoca en “Actuar” y en “Herramientas”

Genichi Taguchi: “pérdida generada por el producto a la sociedad desde el momento en que
un producto es despachado hasta el final de su vida útil medido de alguna manera ($,hs…)”

Se enfoca en “medir”

Feigenbaum: “sistema eficaz para integrar los esfuerzos de mejora de la calidad de los distintos
grupos de una organización, para proporcionar productos y servicios a niveles que permitan la
satisfacción del cliente”.

Se enfoca en “sistema”

Hacemos una Nube

Entonces;
¿es solo cumplir con las expectativas del cliente?
NO, va más allá, es crear un sistema, es gestionar, es involucrar
a todos los interesados es formar un sistema (partes relacionadas
con un objetivo).
“producto bien hecho con un proceso bien hecho en una
organización bien “organizada” (coloquialmente)
Calidad, QA y Control de la Calidad
Calidad: grado en el que un conjunto de características inherentes a un objeto (producto, servicio,
proceso, persona, organización, sistema o recurso) cumple con los requisitos. [ISO 9001]

QA: conjunto de acciones planificadas y sistemáticas necesarias para dar la confianza adecuada de
que un producto o servicio satisface los requerimientos dados sobre calidad. [ISO 8402]

Control de la Calidad: conjunto de los mecanismos, acciones y herramientas realizadas para detectar
la presencia de errores.

Software: conjunto de los programas de cómputo, procedimientos, reglas, documentación y datos

asociados, que forman parte de las operaciones de un sistema de computación.

Conjugamos:

Calidad de Software: la “disciplina”, el conjunto de prácticas para lograr un software calidad. Para
“Gestionar la calidad” + “Aportar herramientas”.

Software de calidad: el que cumple los requisitos, el que produce poco impacto, el que se produce
con un proceso gestionado, el que satisface necesidades.

Aseguramiento de la Calidad. Encontrar en 3 niveles:

1. A nivel de la Organización: establecer un marco de procesos y estándares de organización

2. A nivel de los Procesos: aplicación de procesos específicos de calidad y la verificación de que

continúen en el tiempo (que se usen y se controle su uso)

3. A nivel de los Proyectos: establecer un plan de calidad para el proyecto que establezca metas
de calidad para el proyecto y defina cuáles procesos y estándares se usarán.
Resumiendo
RESUMIENDO:
Hay que:
Asegurar la calidad o QA -> definir políticas, procesos, estándares
Controlar la calidad -> usar los procesos, seguir los estándares, cumplir
las políticas, auditar el uso de los procesos

El triangulo es una organización, la

línea divide la jerarquía superior de la
inferior.

¿Y quien lo hace?
“…el equipo QA responsable de administrar el proceso de pruebas de liberación.
Se aplican las pruebas del software antes de que éste se libere a los clientes.
Equipo responsable de comprobar que las pruebas del sistema cubran los requerimientos y de
mantener los registros adecuados del proceso de pruebas”

Desmenuzamos:
existe un equipo de QA,
el equipo administra el proceso de QA ,
este proceso es para liberar un software (darle el OK),
debe asegurarse que las pruebas de sistemas cubran los requerimientos,
mantener registros  Aparece acá “Pruebas de Sistemas” … el Testing del Software

1.3. Calidad de SW y SW de Calidad

Entre las disciplinas para lograr la calidad de software está…
El TESTING de SOFTWARE es una tarea de aseguramiento de la calidad.
Testing de Software = Prueba de Sistemas = Test = Prueba de Software …

Volvamos un poco para atrás

Crosby, en 1979, traslado los conceptos de calidad de manufacturas … al software.
“desarrolló una definición de calidad, que se basa en la conformidad con una especificación de
producto detallada y la noción de tolerancia”
(tal cual viene de la industria manufacturera, implica que el producto de software podía
especificarse completamente y que teníamos un método para comprobar la adecuación a esa
especificación y que había cierta tolerancia en cumplirla)

Tolerancia

Es aceptable en software?
La tolerancia en manufactura es conocida.
En software, la cantidad de defectos es conocida?

Esto es polémico?
¿Podemos especificar completamente y sin ambigüedades un software? (así como se pueden
especificar las dimensiones y forma de un engranaje)
 Los requerimientos dependen de la interpretación/visión del analista, desarrollador, cliente
 Si el relevamiento de los requerimientos… ¿no incluyó a todos los interesados? Puede
que estos no vean alguna de sus necesidades satisfecha y opinen que el SW es “de mala
calidad” aun cuando cumplió con sus requerimientos.
 No todas las características son medibles, ni pueden tener tolerancia. EJ: “mantenibilidad”,
“reusabilidad de las clases”.
Hay mucha subjetividad por lo que la definición de Crosby no es muy aplicable.

Incertidumbre
◦ Puede que NO estén incluidos el 100% de los interesados
◦ Puede que NO sea factible relevar el 100% de los requisitos
◦ Puede que la especificación sea interpretada de diferentes maneras por las partes involucradas
en el proceso

¿Entonces?
La valoración de calidad del software es un proceso subjetivo e implica responder:
 1. ¿En el proceso de desarrollo se siguieron los estándares de programación y documentación?
2. ¿El software se verificó de manera adecuada? (según el proceso establecido)
3. ¿El software es suficientemente confiable para usarse? (no falla)
4. ¿El rendimiento del SW es aceptable para uso normal? (soporta el proceso y sus tiempos)
5. ¿El software es utilizable? (fácil de usar, de navegar, ux)
6. ¿El software está bien estructurado y es comprensible? (el código)
7. ¿El software es seguro? (ethical hacking)

1.2. Visiones de la calidad

Un proceso que NO aborde todos los ángulos de la Calidad NO tendrá chance
de satisfacer al Cliente y abrirá lagunas potenciales para la acción de los
competidores.

Al ser subjetivo, hay 5 visiones (o puntos de vistas) según a donde me paro para ver la calidad:

1. Visión Transcendental: “exceder o pasar los límites usuales”.

El cliente percibe que un producto “es de calidad” cuando recibe + de lo que espera.
Calidad es una “excelencia innata” que sólo puede ser reconocida por el Cliente con su propia
experiencia o producto.

2. Visión del Usuario: determinada por lo que el usuario

◦ Quiere
◦ Precisa
◦ Espera
La calidad está definida por la atención a las necesidades y conveniencias del cliente. Este enfoque
es subjetivo ya que las preferencias del cliente varían.

3. Visión del Productor

Calidad referida a la conformidad con la especificación y a las características del proceso de
producción que llevan a esa conformidad y a satisfacer las necesidades mismas del proceso de
producción:
◦ Condiciones del proceso (trazabilidad, tecnología, controles)
◦ Normas que cumplir (ISO)
“la calidad depende de la conformidad con los requisitos, de acuerdo a lo establecido en el proyecto
del producto”. (similar a visión del usuario, atiende a los requisitos, pero le agrega el proceso).

4. Visión del Producto

Calidad referida a las características específicas del producto:
◦ Visibles para el usuario (externas)
◦ No visibles para el usuario (internas)
◦ Medibles (evaluables) o Cilindrada o Torque máximo o RPM
“La calidad es una variable mensurable y precisa que puede ser encontrada en el conjunto de las
características y atributos de un producto”.

5. Visión Centrada en el Valor

“La calidad es función del nivel de conformidad del producto a un costo aceptable. Eso vincula las
necesidades del consumidor con los requisitos de fabricación”.
Responder a la pregunta, ¿Cuánto está el cliente dispuesto a pagar?
¿Vale la pena un producto de muy alta calidad pero extremadamente caro?
1.4. Costo de calidad y NO calidad
El hermano rico de Homero fabrica autos
Pide a Homero diseñar un auto
Relevaron los requisitos con Homero, no con los clientes
La dirección no se involucró
No hubo control
Cuando encontraron los defectos ya era tarde
La empresa de Herbert Powell => se fundió

COSTO: Algo que insume $$$...

“gasto económico que representa la fabricación de un producto o la prestación de un servicio”.
Es el valor monetario de los consumos de factores que supone el ejercicio de una actividad
económica destinada a la producción de un bien o servicio.

COSTO DE LA CALIDAD: Hacer calidad cuesta, pero los errores evitables también cuestan.
Costos en que se incurren cuando se diseña, implementa, opera y mantiene los sistemas de calidad
de una organización, costos empresariales ligados a los procesos de mejora continua.

COSTO DE LA NO-CALIDAD: costos de sistemas, productos y servicios que NO dieron frutos al ser
rechazados por el mercado.

Costo de la calidad o NO-calidad, el gasto en $$$ que representa obtener la calidad o el gasto en
$$$ que aparece por NO obtenerla.

Mas gasto en costo de la calidad

al inicio del proyecto implica
menos gastos en costo de la no-
calidad hacia el fin del proyecto

Costos de la Calidad Costos de la NO calidad

Costos de prevención Costos tangibles e intangibles (imagen de la empresa, rumores)
◦ Selección/Capacitación de personal
◦ Planeamiento del trabajo reprocesos, desperdicios, devoluciones, reparaciones,
◦ Herramientas adecuadas reemplazos, gastos por atención de quejas, exigencias de
◦ Tiempo de realización cumplimiento de garantías, ventas perdidas, clientes perdidos,
Costos de diseño costo por responsabilidad social/medioambiental,
Costos de evaluación/test Costos legales
Costos de medir Costos intangibles
Costos de testear ◦ imagen de la empresa
Costos de auditar ◦ Falta de recomendación
Costos de laboratorios
Costos de fallas internas (antes que lleguen al cliente)
 CLASE2
La Crisis del SW  dio origen a la Ingeniería de Software.
se refiere a los problemas que, desde sus inicios, ha ido experimentando el software, muchas veces
problemas de gran magnitud, debido, principalmente, a la mínima eficacia que presentan una gran
cantidad de empresas al momento de realizar un software. [wikipedia]
Edsger Dijkstra: (a fines de los ‘60) fue uno de los primeros en alertar sobre la crisis del software.
Luego en una conferencia de la OTAN se presenta una solución: “la ingeniería de SW”.
¿Solución a que???
◦ Malas estimaciones
◦ Sobrecostos
◦ Retrabajos
◦ Objetivos mal planteados
◦ Trabajos mal organizados

Ingeniería de SW Disciplina de la Ing q se interesa x TODOS los aspectos de la Producción de SW

Actividades: Especificación, Desarrollo, Validación y Evolución de SW

“control de la calidad: parte de la gestión de la calidad (3.2.8) orientada al cumplimiento de los

requisitos de la calidad” [ISO 9001:2005]

Verificación:
se enfoca más al proceso de evaluación del sistema o componentes ya que permite determinar si
los productos de una determinada fase del desarrollo satisfacen las condiciones impuestas en el
inicio de la etapa.
“¿Estamos construyendo el producto CORRECTAMENTE?”.
(trabajamos bien cumpliendo lo que pide el proceso que fijo QA y sus entregables y verificando que
paso que damos apunta a satisfacer los requisitos)

Validación:
validar el software para asegurarse de que cumple lo que el cliente quiere.
Es una evaluación del sistema o componentes solo que es en el transcurso o al final del proceso del
desarrollo para determinar si cumple con las necesidades del cliente.
“¿Estamos construyendo el producto CORRECTO?”. (hicimos lo que nos pidieron?)

Testing: 2 objetivos:
1. Demostrar al desarrollador y cliente q el SW cumple con los requerimientos (pruebas de validación)
2. Encontrar situaciones donde el comportamiento del SW sea incorrecto, indeseable o no esté de
acuerdo con su especificación. (pruebas de defecto)

DEFINICIONES “Pruebas intentan DEMOSTRAR que un programa hace lo que se intenta que haga, así
TESTING
como DESCUBRIR defectos en el programa ANTES de usarlo”. [Ian Sommerville]
“Proceso de ejecutar un programa con la intención de detectar errores”
Un test es “exitoso” cuando encuentra nuevos errores. [The Art of SW testing – Glenford Myers]

“Proceso compuesto por todas las actividades del ciclo de vida del SW, (estáticas y dinámicas),
concernientes a planificación, preparación y evaluación de productos de software y productos
relacionados para determinar si satisfacen los requerimientos especificados, para demostrar que se
adecuan al propósito y detector defectos”. [ISTQB]
La definición del ISTQB es más completa:
Proceso
Actividades en todo el ciclo de vida
Actividades estáticas (inspeccionar) y dinámicas (testear, ejecutar)
Planear (incluir dentro del proyecto)
Preparar (pensar las pruebas y armarlas)
Evaluar (chequear las pruebas)
Software y productos relacionados (soft, documentación …)

ISTQB? (International Software Testing Qualifications Board)

Organización de certificación de calificación, de personas, en pruebas de software (en testing).
Es internacional (70 y pico de países)
Ofrece varios niveles de certificación (fundamentals, advanced, expert)

Que ven distinto?

Hay 2 visiones: una solo apunta al código, la otra a todas las actividades del ciclo de vida del SW.
Algunas apuntan al “Control de la calidad” y otras al “Aseguramiento de la calidad”.

1° punto de vista: [Ian Sommerville]

El Testing de software verificación del comportamiento de un
programa sobre un conjunto finito de casos de prueba,
seleccionados a partir del dominio de ejecución que usualmente
es infinito, en relación con el comportamiento Esperado”

2° punto de vista: [ISTQB]

Más amplio, el enfoque del ISTQB:
Estático y dinámico: pruebas en las que se ejecuta el código de software para demostrar los
resultados de las pruebas en ejecución (pruebas dinámicas), y hacemos pruebas para encontrar
defectos sin ejecutar código (prueba estática), (incluye la revisión de documentos y código fuente)
y el análisis estático. Manera útil y rentable de hacer pruebas.

Planear: Las actividades tienen lugar antes y después de la ejecución de la prueba. Necesitamos
administrar las pruebas; EJ: planeamos lo que queremos hacer; Controlamos las actividades de
prueba; Informamos sobre el progreso de las pruebas y el estado del software bajo prueba; Y
finalizamos o cerramos las pruebas cuando se completa una fase.

Preparar: elegir qué pruebas harán, seleccionando condiciones de prueba y diseñando CP.

Evaluar: Ejecutar las pruebas, comprobar los resultados y evaluar el SW bajo prueba y los criterios
de finalización, para decidir si terminamos las pruebas y si el producto de SW ha superado las
pruebas.

Productos de SW y productos relacionados: Probamos código, probamos requisitos y

especificaciones de diseño, y ponemos a prueba documentos relacionados como operación, usuario
y material de capacitación. Las pruebas estáticas y dinámicas son necesarias para cubrir la gama de
productos que necesitamos probar.

Edsger Dijkstra, uno de los primeros contribuyentes al desarrollo de la ingeniería de software

“Las pruebas pueden mostrar sólo la presencia de errores, mas NO su ausencia”.
Esta expresión de Dijkstra … está completa????
Objetivo para el ISTQB
◦ Encontrar defectos, Prevenir defectos (ambos vienen de la mano)
◦ Ganar confianza sobre la calidad del producto
◦ Proveer información para la toma de decisiones
-Encontrar defectos y prevenirlos
Mientras antes mejor. + fácil y + barato. Con menos impacto.
Se puede revisar diseños y documentación. Cuando el código está escrito
es + caro corregir errores (+ para revisar y para retestear)

Si encontramos defectos en etapas tempranas … logramos prevenir la aparición de defectos en

etapas posteriores. EJ: la inspección de documentos de diseño nos ayuda a prevenir defectos que
aparezcan a posterior de la codificación.

Error: comete una persona cuando diseña o construye un software

Defecto: lo que introduce en el software, la persona al cometer un ERROR
Falla: puede producir el defecto introducido por la persona al ejecutar el software
(no solo ejecución, software es + amplio, la documentación ..)

¿Quién tiene la culpa?  la persona … todos somos falibles, el testing es la herramienta para
ayudarnos a encontrar los errores, pero no para echar la culpa… (aspecto psicológico)

Al hacer testing yo resultados o comportamientos que NO son los que debería observar, pero NO
observo el defecto, el bug, luego … es tarea de desarrollo buscar el bug.

-Ganar Confianza sobre:

La confianza del usuario en el sistema la obtiene cuando realiza el test de aceptación, cuando
confirma que funciona como quería. (Verificación)

-Proveer info sobre la toma…

La corrección de los defectos puede NO ser siempre el objetivo de la prueba o el resultado deseado.
A veces simplemente queremos recopilar información y medir el software.
Digamos obtener métricas, como el tiempo medio entre fallas para evaluar la fiabilidad, o una
evaluación de la densidad de defectos en el SW para evaluar y comprender el riesgo de liberarlo.

NIVELES DE TESTING:
Existen varios modelos de desarrollo (modelo de desarrollo en cascada, modelo de desarrollo en V,
el modelo de desarrollo Scrum).
c/u lleva incorporado el test dentro, como etapa o actividad.

ISTQB introduce el concepto 4 Niveles de Testing q encontramos dentro de los modelos de

desarrollo:

1)Testing de Componentes:
Punto de vista de Desarrollador (Son pruebas de Desarrollador)
Busca defectos, y prueba componentes de código que pueden ser separados.
Se prueba cada componente tras su construcción.
Alcance:
 ◦ Solo se prueban componentes individuales
◦ Cada componente es probado de forma independiente
Base de pruebas:
◦ Requisitos de componentes
◦ Diseño detallado
◦ Código
Objetos de prueba típicos:
◦ Componentes
◦ Programas
◦ Conversión de datos / programas de migración
◦ Módulos de bases de datos

2)Testing de Integración:
Punto de vista de Desarrollador
Prueba la interface entre distintos componentes, y las interacciones con otras partes del sistema, o
con el sistema operativo, o con el hardware o con otros sistemas.
Cuanto mayor sea el alcance de la integración, más difícil se hace para aislar las fallas de un
elemento o sistema específico, que puede conducir a un aumento del riesgo.
Las estrategias sistemáticas de integración pueden estar basadas en la arquitectura del sistema (EJ:
de arriba abajo y de abajo hacia arriba), tareas funcionales, las secuencias de procesamiento de
transacciones, o algún otro aspecto del sistema o componente.
Alcance:
◦ Se prueban grupos de componentes
◦ Se puede implementar a nivel subsistemas si se tiene un grupo de los mismos
◦ Comprueban la interacción entre componentes respecto de la especificación de
interfaces.
Base de pruebas:
◦ Diseño de software y de sistema
◦ Arquitectura
◦ Flujos de trabajo
◦ Casos de uso
Objetos de prueba típicos:
◦ Subsistemas
◦ Implementación de base de datos
◦ Infraestructura
◦ Interfaces
◦ Configuración del sistema y datos de configuración

3)Testing de Sistemas:
Punto de vista de Usuario
Se verifica contra los requerimientos.
Se usa un entorno de prueba similar al de producción. Se prueban procesos de negocio, casos de
uso, u otras descripciones de alto nivel del comportamiento del sistema.
Alcance:
Adecuación (Suitability): ¿Las funciones implementadas son adecuadas para su uso esperado?
Exactitud (Accuracy): ¿Las funciones presentan los resultados correctos (acordados)?
Interoperabilidad (Interoperability): ¿Las interacciones con el entorno del sistema presentan algun
problema?
Cumplimiento de Funcionalidad (Compliance): ¿El sistema cumple con normas y reglamentos
aplicables?
Seguridad (Security): ¿Están protegidos los datos/programas contra acceso no deseado o perdida?
Base de pruebas:
Especificación de requisitos del sistema y del software
Casos de uso
Especificaciones funcionales
Informes de análisis de riesgos
Objetos de prueba típicos:
Manuales de sistema, usuario y funcionamiento
Configuración del sistema y datos de configuración

4)Testing de Aceptación:
Punto de vista de Usuario (responsabilidad de clientes y/o usuarios de un sistema).
Objetivo establecer confianza en el sistema, las partes del sistema o características específicas y NO
funcionales del sistema.
Evalúan la disposición del sistema para el uso, aunque NO es necesariamente el nivel final de las
pruebas. Son pruebas parciales y de alto nivel.
Alcance:
Se verificará que el software satisface los requisitos del cliente
Base de pruebas:
Requisitos de usuario
Requisitos de sistema
Casos de uso
Procesos de negocio
Informes de análisis de riesgos
Objetos de prueba típicos:
Procesos de negocio en sistema completamente integrado
Procesos operativos y de mantenimiento
Procedimientos de usuario
Formularios
Informes
Datos de configuración

3 tipos de testing: (Según Sommerville)

1. Prueba de desarrollo Las personas que desarrollan el sistema ponen a prueba los
componentes que constituyen el sistema. Cada componente se prueba de manera
independiente (sin otros componentes del sistema).
2. Pruebas del sistema Los componentes del sistema se integran para crear un sistema
completo. Su finalidad, descubrir errores que resulten de interacciones no anticipadas entre
componentes y problemas de interfaz de componente, así como de mostrar que el sistema
cubre sus requerimientos funcionales y no funcionales.
3. Pruebas de aceptación Etapa final en el proceso de pruebas, antes de que el sistema se
acepte para uso operacional. El sistema se pone a prueba con datos suministrados por el
cliente del sistema, en vez de datos de prueba simulados.
Y estos niveles como encajan en los modelos de desarrollo?
Cada uno con su ciclo de vida, y el testing NO es una actividad aislada, sino integrada y depende
mucho de cada ciclo de vida (o modelo). Cada modelo influye en cuando, como y que se prueba.
Modelo
Modelo en cascada
en CASCADA:
“enfoque metodológico que ordena rigurosamente las
etapas del proceso para el desarrollo de software, de tal
forma que el inicio de cada etapa debe esperar a la
finalización de la etapa anterior”

Testing es una “etapa” … la última.

Modelo en V:
Mejora inconvenientes del modelo en cascada (Ej:
los defectos se encontraban al final del proceso).
La idea de este modelo es que el testing comience
lo antes posible.
Rama izquierda: análisis y definición del proyecto.
La base es la implementación que transcurre a lo
largo de un tiempo.
Rama derecha: es la integración y verificación de
lo desarrollado. Diferencia con modelo en cascada
en la preparación temprana de los distintos test.

Como lo Expresa Sommerville:

Modelos AGILES - SCRUM

Los 7 Principios de Testing: [ISTQB]

1. - El testing muestra la presencia de defectos
2. - El testing exhaustivo es imposible
3. - Testing temprano (en el ciclo de vida del SW)
 4. - Agrupamiento de defectos
5. - Paradoja del insecticida
6. - Testing es dependiente del contexto
7. - Falacia de la ausencia de errores
P1) El testing muestra la presencia de defectos
El testing muestra la presencia de defectos pero NO, la ausencia de los mismos. El testing reduce la
posibilidad de defectos NO descubiertos, pero NO encontrar errores durante un test no es una
prueba de la ausencia de los mismos.

P2) El testing exhaustivo es imposible

Testear todas las posibles combinaciones de entradas y precondiciones (salvo casos triviales) es
imposible. Lo conveniente es hacer análisis de riesgos y priorizar p/enfocar los esfuerzos del testing.

P3) Testing temprano

Para detectar defectos temprano (al principio del ciclo de vida del proyecto) tan pronto como sea
posible y debe tener objetivos definidos. ¿Cómo si aún no tengo código? Con testing estático.

P4) Agrupamiento de defectos

Un número pequeño de componentes contiene la mayoría de los defectos o es responsable de la
mayoría de las fallas. Los esfuerzos de testing deben ser proporcionales a los defectos esperados y
luego observados en los módulos.

P5) La paradoja del insecticida

Si el mismo set de pruebas es ejecutado una y otra vez … en algún momento van a dejar de encontrar
defectos. Los casos de pruebas deben ser revisados y ampliados para cubrir nuevas o diferentes
partes del software y así encontrar errores. El software se inmuniza contra los casos de prueba.

P6) Testing es dependiente del contexto

El testing se lleva a cabo o se enfoca en distintos aspectos en sistemas distintos, no es lo mismo una
aplicación donde la seguridad es crítica que donde no lo es. Soft de una central nuclear o un avión
vs. soft para sacar turnos a una peluquería o adquirir entradas por internet.

P7) Falacia de la ausencia de errores

Encontrar y corregir defectos … no ayuda en nada si el sistema no es usable o no satisface los
requisitos del usuario.

Aspectos Psicológicos:
La mentalidad necesaria para desarrollar es diferente de la mentalidad para testear. El testing puede
ser visto como ‘algo destructivo’ más que constructivo.
Identificar fallas durante un test pueden ser percibidas como críticas contra el producto o autor.
Si los errores son comunicados de una forma constructiva los malos sentimientos entre testeadores
y desarrolladores/analistas pueden ser evitados.
A su vez, que el mismo desarrollador pruebe su propia creación no lo libera de volver a omitir en el
test un punto que omitió en el desarrollo. O un testeador dentro del equipo puede verse presionado
por el desarrollo o por el líder del proyecto. El test es mejor si es independiente.

Dio origen a una Industria

Importancia en la sociedad:
La tecnología informática está presente en muchísimos aspectos de la vida. (EJ: teléfonos móviles)
Una aplicación sin probar puede funcionar mal y causar pérdidas, de dinero, de tiempo, de
renombre o accidentes y daños a personas.
Por lo tanto:
 Existen un proceso de pruebas de software a ser aplicado a cualquier desarrollo. Y
modelos: ITIL, TMM, CMMI, TIM …
 Este proceso se integra al ciclo de vida del software.
 Las pruebas de software son una parte importante pero muy costosa del proceso de
desarrollo de software, pero las fallas en producción pueden ser más caras.

Ética Profesional
Tener en cuenta al realizar el test:
Garantizar la confidencialidad al cliente (dado que manejaremos info privilegiada).
Cuidar la integridad/reputación del cliente.
Ser honesto.
Acordar los objetivos con el cliente.
Comunicar claramente y a tiempo los resultados y confirmar que los entendieron.
Evitar que personas ajenas alteren la información/accedan a las herramientas.
Seguir los lineamientos de seguridad laboral.

CLASE3
Depuracion Vs Test (Según ISTQB)
El proceso de depuración y el proceso de pruebas son diferentes.
Las pruebas dinámicas identifican fallos provocados por defectos.
Depuración actividad de desarrollo que localiza, analiza y elimina la causa del fallo (el defecto).

Ahora test unitarios y test de componentes como se hacen¿depurando?

ISTQB agrega: “La responsabilidad de c/u de estas actividades corresponde generalmente a los
probadores (en el caso de las pruebas), y a los desarrolladores (en el caso de la depuración)”.

Depuración (Debbuging)
Es una excelente herramienta de test.
Los programadores hacen algunas pruebas del código que desarrollaron.
Revela con frecuencia defectos del programa que deben eliminarse.
Prueba de defectos: establece la existencia de defectos
Depuración: localiza y corrige dichos defectos.
Para ser formales, las pruebas unitarias, prueba de componentes debería ir más allá de la
depuración.

Test Driven Development (TDD)

Vimos los procesos de desarrollo: cascada, “v” y scrum, nos falto mencionar TDD.

Ventajas:
- Todo el código escrito tiene al menos 1 test
- Continuamente estoy armando los casos para
hacer un test de regresión

El test se escribe antes del código, se codifica y lo que se codifico se prueba, si no pasa … no avanzo
en el desarrollo, si pasa el test me muevo a la próxima iteración.
Código se desarrolla incrementalmente, junto con una prueba para ese incremento
Proceso de Testing:

Esto es un modelo abstracto del proceso de pruebas tradicional.

Casos de prueba: son especificaciones de las entradas a la prueba, los pasos y salidas esperadas.
Datos de prueba: son las entradas, valores, que se diseñaron o escogieron para realizar la prueba.
Resultados de prueba: son las salidas que obtuvimos.
Reportes de prueba: comparación de resultados esperados vs los obtenidos. [Ian Sommerville]

Etapa de Pruebas
1. Testing de Desarrollo. El Sistema es testeado durante el desarrollo para encontrar defectos.
◦ Testing de Unidad busca defectos, prueba el funcionamiento de cada
componente, lo prueba aislado, puede automatizarse.
◦ Testing de Componentes la unidad que forman actúa según lo especificado,
Prueba interfaces entre los componentes, NO es aislado, puede automatizarse.
◦ Testing de Sistemas funcional, el sistema actúa correctamente, Prueba las
interacciones entre componentes. Es la prueba de un “todo”, puede automatizarse.
2. Testing de Release (de liberación). Un equipo de testing separado del de desarrollo, prueba
una versión complete del Sistema antes de liberarla al usuario.
3. Testing de Usuario. El usuario prueba el Sistema en su propio entorno para aceptarlo.

Etapas de Pruebas - Sommerville

1. Testing de Desarrollo. El Sistema es testeado durante el desarrollo para encontrar defectos.
Testing de Unidad.
1. Unit Testing: unidades, clases, objetos, funciones, metodos
2. Object Class Testing:
◦ Testing all operations associated with an object
◦ Setting and interrogating all object attributes
◦ Exercising the object in all possible states.
◦ Probar cuando se hereda
◦ Probar cambiar los estados
hay 2 tipos de casos de pruebas:
con datos “validos” para probar que el componente haga lo que debe
con entradas anormales para ver que el componente no falle, no se rompa.

Testing de componentes
Prueban la interface de los componentes, fallas que puedan ocurrir por defectos en las interfaces o
por supuestos inválidos en las mismas.
“Estos errores NO suelen ocurrir cuando se los prueba individualmente, porque el mismo testeador
define los valores que le pasa a cada componente, pero en la prueba de componentes son otros
“componentes” los que definen esos valores”.

Testing de sistemas
Los componentes son compatibles?
Los datos que se transfieren entre ellos están OK?
El comportamiento del Sistema esta OK?

2. Testing de Release (de liberación): Lo hace un equipo de testing separado del de desarrollo.
prueba una versión complete del Sistema antes de liberarla al usuario (o del proceso de desarrollo).
Se enfoca más en validar el software que en encontrar fallas.
Objetivo: convencer que funciona y que puede usarse
Técnicas usadas técnicas de caja negra
test de regresión
test basado en requerimientos
test de performance
test de usuario (alfa beta y de aceptación)

3. Pruebas de Aceptación (o del usuario):

Las pruebas de usuario o del cliente son una etapa en el proceso de pruebas donde los usuarios o
clientes proporcionan entrada y asesoría sobre las pruebas del sistema

1. Pruebas alfa, donde los usuarios del software trabajan con el equipo de diseño para probar el
software en el sitio del desarrollador.
2. Pruebas beta, una versión del software se pone a disposición de los usuarios, para permitirles
experimentar y descubrir problemas que encuentran con los desarrolladores del sistema.
3. Pruebas de aceptación, donde los clientes prueban un sistema para decidir si está o no listo para
ser aceptado por los desarrolladores del sistema y desplegado en el entorno del cliente.

3. Testing de Usuario. El usuario prueba el Sistema en su propio entorno.

Y en scrum cómo es? El PO introduce todo esto … dentro del mismo proceso, es el responsable

Proceso de Pruebas para ISTQB

Consta de actividades con ciertas tareas.

La parte más visible del proceso de pruebas es la ejecución de pruebas.

No obstante, para ser efectivos y eficientes, los planes de pruebas deben indicar el tiempo para
planificar las pruebas, diseñar los casos de prueba, preparar la ejecución y evaluar los resultados.
El proceso básico de pruebas tiene las siguientes actividades:
◦ Planificación y control de las pruebas
◦ Análisis y diseño de pruebas
 ◦ Implementación y ejecución de pruebas
◦ Evaluación de los criterios de salida y elaboración de informes
◦ Actividades de cierre de pruebas
A pesar de tener una secuencia lógica, las actividades del proceso pueden solaparse o realizarse a
la vez. [ISTQB Cap. 1.4]

Planificación y Control de las pruebas

Planear Actividad para:
• definir los objetivos de las pruebas
• las especificaciones de las pruebas de forma de cumplir los objetivos
• puede ser un plan maestro con un subplan por cada nivel de testing
estándar: IEEE STD 829-1998
• el plan no es estático  puede modificarse a lo largo del proyecto
porque?
depende de:
la política de pruebas de la organización
de los riesgos que se vayan identificando en el proyecto
de los recursos disponibles
de las limitaciones (de alcance, tiempo, costo)
de la criticidad del sistema bajo test o de sus componentes
Control Actividad para:
comparar el avance real contra el plan previsto
informar este avance y las posibles desviaciones
adoptar medidas para corregir desvíos
Análisis y Diseño de las Pruebas
actividad durante la cual los objetivos de las pruebas generales se transforman en condiciones de
prueba y casos de prueba tangibles.
1. Diseñar y priorizar los casos de prueba de alto nivel
2. Identificar los datos de prueba necesarios para soportar las condiciones de
prueba y los casos de prueba
3. Diseñar la configuración del entorno de pruebas e identificar cualquier
infraestructura y herramientas necesarias
4. Crear una trazabilidad bidireccional entre la base de pruebas y los casos de
prueba
Implementación y Ejecución:
actividad en la que se especifican los procedimientos de prueba o guiones de prueba mediante la
combinación de los casos de prueba en un orden determinado y la inclusión de cualquier otra
información necesaria para la ejecución de las pruebas, se configura el entorno y se ejecutan las
pruebas.
1. Crear juegos de pruebas a partir de los procedimientos de prueba para lograr una ejecución
de pruebas eficiente
2. Verificar que el entorno de pruebas ha sido correctamente configurado
3. Verificar y actualizar una trazabilidad bidireccional entre la base de pruebas y los casos de
prueba
4. Ejecutar los procedimientos de prueba manualmente o recurriendo a herramientas de
ejecución de pruebas, conforme a la secuencia prevista
5. Registrar los resultados de la ejecución de las pruebas y registrar las identidades y las
versiones del software sujeto a prueba, así como las herramientas de prueba y los productos
de prueba
 6. Comparar los resultados reales con los resultados esperados
7. Reportar las discrepancias en forma de incidencias y analizarlas con vistas a establecer sus
causas (por ejemplo, un defecto en el código o en los datos de prueba especificados o en el
documento de prueba, o un error en la forma en la que se ha ejecutado la prueba)
6. Repetir las actividades de pruebas como resultado de una medida adoptada para cada
discrepancia, por ejemplo, la repetición de una prueba que ha fallado anteriormente con
vistas a confirmar de su corrección (pruebas de confirmación), la ejecución de una prueba
corregida y/o la ejecución de pruebas con vistas a garantizar que no se han introducido
defectos en áreas no modificadas del software o que la subsanación del defecto no ha
revelado la existencia de otros defectos (pruebas de regresión).

Evaluación de los criterios de salida y generación de informes

Actividad que evalúa la ejecución de pruebas contra los objetivos definidos (en cada nivel de
pruebas)
1. Comprobar las bitácoras de las pruebas con los criterios de salida previstos en la planificación
de la prueba
2. Evaluar si se requieren más pruebas o si deberían modificarse los criterios de salida
especificados
3. Elaborar un resumen de las pruebas para los implicados (no es el reporte de lo encontrado,
sino de las pruebas llevadas a cabo, %, cantidad, modulos probados …) y por otro lado, un
reporte de las fallas observadas.

Actividades de Cierres de las Pruebas

se recopilan los datos de aquellas actividades de pruebas finalizadas con el objetivo de consolidar
la experiencia, los productos de prueba, los hechos y las cifras.
1. Comprobar cuáles de los productos entregables previstos han sido efectivamente
entregados.
2. Cerrar los informes de incidencias o aportar modificaciones a aquellos que siguen abiertos.
3. Documentar la aceptación del sistema. (si corresponde)
4. Finalizar y archivar los productos de prueba, el entorno de pruebas y la infraestructura de
pruebas para su posterior reutilización.
5. Entregar los productos de prueba a la organización de mantenimiento.
6. Analizar las lecciones aprendidas para determinar los cambios necesarios en futuras
versiones y proyectos.
7. Utilizar la información recopilada para mejorar la madurez de las pruebas.

Proceso de Pruebas y Calidad

Gracias a las pruebas, se puede medir la calidad de un software en términos de los defectos
detectados por lo que respecta a requisitos y características funcionales y no funcionales (tales
como fiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad) [ISTQB Cap. 1.1.4]

Con Cuantas Pruebas es Suficiente?: [ISTQB Cap 1.1.5]

Las pruebas deben facilitar información suficiente a los implicados, o partes interesadas para que
éstas puedan adoptar decisiones informadas sobre el lanzamiento de un software o de un sistema
probado, para pasar a la siguiente fase de desarrollo o para su entrega a los clientes.
Criterio de Salida se define al menos uno general, pero deberíamos definir uno para cada nivel de
testing.

Tipos de Pruebas: [ISTQB Cap 2.3]

Un tipo de prueba se centra en un objetivo de prueba en particular.
1. Una función a realizar por el software (pruebas funcionales)
2. Una característica de calidad no funcional, tales como la fiabilidad o la usabilidad (pruebas
no funcionales)
3. La estructura o arquitectura del software o sistema (pruebas de arquitectura)
4. Cambios asociados, es decir, confirmar que se han solucionado los defectos (pruebas de
confirmación) y localizar cambios no intencionados (pruebas de regresión)

-Pruebas de Funciones:
Las funciones son “lo que” el sistema hace. Se deja documentado en especificación de requisitos,
casos de uso o una especificación funcional, o incluso pueden no estar documentadas.
Las pruebas funcionales pueden llevarse a cabo en todos los niveles de pruebas.
Tienen en cuenta el comportamiento externo del software (pruebas de caja negra).
Se deben obtener condiciones de prueba y casos de prueba a partir de la funcionalidad requerida
de un software.
BASADAS EN ESPECIFICACION

Aparecio un concepto:

Condición de Prueba o Test Condition:

Condición de prueba es el elemento o evento de un componente o sistema que debería ser
verificado por uno o más casos de prueba, por ejemplo una función, transacción, característica,
atributo de calidad o elemento estructural.

Cuando planeo la prueba determino estas condiciones de prueba, en las etapas de análisis y diseño
(ISTQB) derivo (analizo) las condiciones de prueba de los requisitos del cliente y en base a ellas
diseño casos de prueba.

Las condiciones de prueba deben ser lo mas explicitas y taxativas posibles.

◦ Un requerimiento se convierte en 1 o mas condiciones de pruebas.

Requerimiento: “el usuario debe loguearse al sistema”

Condiciones:
1) Cuando un nombre de usuario y pass correctos son ingresados, el usuario es logueado al sistema
2) Cuando un nombre de usuario es ingresado con un password incorrecto, se muestra un mensaje de error
3) Cuando un nombre de usuario invalido es ingresado con un pass incorrecto se muestra un mensaje de error
4) Cuando un nombre de usuario correcto es ingresado todo en mayúscula o todo en minúscula o combinaciones y con
una pass correcta entonces el usuario es logueado al sistema
5) Cuando no hay conexión a internet o al servidor se muestra un mensaje de error
6) Cuando una vez ingresado el nombre de usuario y la pass, correcto o no, se demora mas de 10 segundos se debe
mostrar un mensaje de error

Es explicita y taxativa? Que es correcto? (letras, nros,

signos, una mayúscula, al menos 3 nros. ….
-Pruebas de Caracteristicas NO Funcionales:

incluyen, pero sin limitarse a ello, pruebas de rendimiento, pruebas de carga, pruebas de estrés,
pruebas de usabilidad, pruebas de mantenibilidad, pruebas de fiabilidad y pruebas de portabilidad.
pueden ejecutarse a todos los niveles de prueba
Las pruebas no funcionales tienen en cuenta el comportamiento externo del software y, en la
mayoría de los casos, para ello utiliza técnicas de diseño de pruebas de caja negra.
BASADAS EN ESPECIFICACION
Pruebas de Estructura / Arquitectura
Las pruebas estructurales (caja blanca) pueden realizarse en todos los niveles de prueba.
Utiliza técnicas de caja blanca. Se usan después de las técnicas “basadas en especificación” para
determinar la cobertura, para medir la exhaustividad de las pruebas.
“La cobertura es la medida en que un juego de pruebas ha probado una estructura, expresada
como porcentaje de los elementos cubiertos”. (código, sentencia, decisiones).
Las pruebas estructurales pueden basarse en la arquitectura del sistema, como por ejemplo una
jerarquía de llamadas.

Pruebas Asociadas a Cambios x Fallas

Una vez detectado y corregido un defecto, el software debe volver a probarse para confirmar que
el defecto original ha sido corregido con éxito.
Las pruebas de regresión son pruebas reiteradas de un programa ya probado.

Pruebas de Mantenimiento
El sistema, sus datos de configuración o su entorno son objeto de frecuentes correcciones,
modificaciones o ampliaciones.
Además de probar lo que se ha modificado, las pruebas de mantenimiento incluyen pruebas de
regresión a partes del sistema que no han sido objeto de modificaciones.

Casos de Prueba
“Un conjunto de valores de entrada, precondiciones de ejecución, resultados esperados, y
poscondiciones de ejecución, desarrollados para probar un objetivo en particular o una condición
de test así como también para verificar la conformidad con un requisito”.
[ISTQB - Glosario]
Para verificar por completo que todos los requerimientos de una aplicación se cumplan, tiene que
haber por lo menos dos Casos de Prueba para cada requerimiento: uno positivo y otro negativo

Condición de Prueba o Test Condition: Condición de prueba es el elemento o evento de un

componente o sistema que debería ser verificado por uno o más casos de prueba, por ejemplo una
función, transacción, característica, atributo de calidad o elemento estructural.

Estructura de un CASO DE PRUEBA

Formalmente, los casos de prueba escritos consisten principalmente en tres partes con
subdivisiones:
Introducción/visión general: Contiene información general acerca de los Casos de Prueba.
◦ Identificador: Es un identificador único para futuras referencias, por ejemplo,
mientras se describe un defecto encontrado.
◦ Caso de prueba dueño/creador: Es el nombre del analista o diseñador de pruebas,
quien ha desarrollado pruebas o es responsable de su desarrollo.
◦ Versión: La actual definición del caso de prueba.
◦ Nombre: El caso de prueba debe ser un título entendible por personas, para la fácil
comprensión del propósito del caso de prueba y su campo de aplicación.
◦ Identificador de requerimientos: el cuál está incluido por el caso de prueba.
También aquí puede ser un identificador de casos de uso o de especificación
funcional.
◦ Propósito: Contiene una breve descripción del propósito de la prueba, y la
funcionalidad que chequea.
◦ Dependencias: Indica qué otros subsistemas están involucrados y en qué grado.
Actividades de los casos de prueba
◦ Ambiente de prueba/configuración: Contiene información acerca de la
configuración del hardware o software en el cuál se ejecutará el caso de prueba.
◦ Inicialización: Describe acciones, que deben ser ejecutadas antes de que los casos de
prueba se hayan inicializado. Por ejemplo, debemos abrir algún archivo.
◦ Finalización: Describe acciones, que deben ser ejecutadas después de realizado el
caso de prueba. Por ejemplo si el caso de prueba estropea la base de datos, el analista
debe restaurarla antes de que otro caso de prueba sea ejecutado.
◦ Acciones: Pasos a realizar para completar la prueba.
◦ Descripción de los datos de entrada

Resultados
◦ Salida esperada: Contiene una descripción de lo que el analista debería ver tras
haber completado todos los pasos de la prueba.
◦ Salida obtenida: Contiene una breve descripción de lo que el analista encuentra
después de que los pasos de prueba se hayan completado.
◦ Resultado: Indica el resultado cualitativo de la ejecución del caso de prueba, a
menudo con un Correcto/Fallido.
◦ Severidad: Indica el impacto del defecto en el sistema: Grave, Mayor, Normal,
Menor.
◦ Evidencia: En los casos que aplica, contiene información, bien un link al print de
pantalla (screenshot), bien una consulta a una base de datos, bien el contenido de
un fichero de trazas, donde se evidencia la salida obtenida.
◦ Seguimiento: Si un caso de prueba falla, frecuentemente la referencia al defecto
implicado se debe enumerar en esta columna. Contiene el código correlativo del
defecto, a menudo corresponde al código del sistema de tracking de bugs que se esté
usando.
◦ Estado: Indica si el caso de prueba está: No iniciado, En curso, o terminado.

Diseño de un Caso de Pruebas

Consejos:
◦ Verificar sólo una acción o una funcionalidad por vez
◦ Pruebas demasiado complicadas.
Pruebas que son difíciles de entender.
◦ Pruebas que se superponen. Diferentes
Pruebas verificando la misma
funcionalidad, pueden traer un gran
dolor de cabeza a la hora de realizar un
mantenimiento.
◦ Cobertura baja o escasa del código. Es
más fácil tener mayor cobertura del
código si se escriben Casos de Prueba
simples para todos los elementos del
código.
◦ Dificultad para rastrear un error.
Cuando un Caso de Prueba falla, debería
ser bien simple determinar dónde falló.
Cuando se verifican varias cosas a la vez
 en todos los Casos de Prueba, suele ser
difícil determinar la fuente del error.
◦ Estructurar y almacenar los casos de prueba
◦ Escribir un caso de prueba para cada condición

EJEMPLOS DE CASOS DE PRUEBAS

Aspectos Psicologicos:
La mentalidad necesaria para desarrollar es diferente de la mentalidad necesaria para testear. El
testing puede ser visto como ‘algo destructivo’ mas que constructivo.

Identificar fallas durante un test pueden ser percibidas como críticas contra el producto o contra su
autor. Por lo que suele verse como “algo destructivo” (algo malo). Cuando en realidad es una
poderosa herramienta.
Si los errores son comunicados de una forma constructiva los malos sentimientos entre testeadores
y desarrolladores/analistas pueden ser evitados.
A su vez, que el mismo desarrollador pruebe su propia creación no lo libera de volver a omitir en el
test un punto que omitió en el desarrollo. O un testeador dentro del equipo puede verse presionado
por el desarrollo o por el líder del proyecto. El test es mejor si es independiente.

Dio origen a una industria

Importancia en la sociedad:
La tecnología informática está presente en muchísimos aspectos de la vida. (EJ: teléfonos móviles).
Una aplicación sin probar puede funcionar mal y causar pérdidas, de dinero, de tiempo, de
renombre o accidentes y daños a personas.
Por lo tanto:
◦ Existen un proceso de pruebas de software que puede ser aplicado a cualquier
desarrollo. Y modelos: ITIL, TMM, CMMI, TIM …
◦ Este proceso se integra al ciclo de vida del software.
◦ Las pruebas de software son una parte importante pero muy costosa del proceso de
desarrollo de software, pero las fallas en producción pueden ser mas caras.

Etica Profesional
Tener en cuenta al realizar el test:
◦ Garantizar la confidencialidad al cliente (dado que manejaremos info privilegiada).
◦ Cuidar la integridad/reputación del cliente.
◦ Ser honesto.
◦ Acordar los objetivos con el cliente.
◦ Comunicar claramente y a tiempo los resultados y confirmar que los entendieron.
◦ Evitar que personas ajenas alteren la información/accedan a las herramientas.
◦ Seguir los lineamientos de seguridad laboral.

CLASE4 Clasificación de las pruebas

Clasificación de las pruebas:

Estáticas Dinámicas

Análisis Estático con Revisiones y sus Estructurales Funcionales

Herramientas versiones De caja blanca De caja negra

Pruebas Estáticas: se realizan examinando los productos de software pero sin ejecutar el código,
por ejemplo, revisando ‘requerimientos’, ‘diseños’, ‘un plan de test’ o ‘un manual de usuario’.
Pruebas Dinámicas: se realizan ejecutando código. Son técnicas para detectar defectos (fallas
observables).
Pruebas Estructurales: de caja blanca o basada en el código. Revisamos los caminos que sigue el
Soft, el algoritmo. Toma el punto de vista del desarrollador. Verificar que cada componente es
operativo.
Pruebas Funcionales: de caja negra o basado en la especificación del usuario o de caja negra. La
idea es verificar que el comportamiento observado del software cumple o no con sus
especificaciones. La prueba funcional toma el punto de vista del usuario.

Prueba no incremental:
◦ Primero se efectúa la prueba de componentes separados. Luego se integran para
formar el programa completo.
 ◦ La prueba de cada módulo requiere de otro, que lo llame y llamados.
Prueba incremental:
◦ El siguiente componente en ser probado se combina con los ya probados.
◦ La prueba puedes ser BottomUp o Top Down.

Pruebas Bottom Up: desde abajo (componentes) integrando hacia arriba (subsistema, sistema)
Hasta que tenemos cierta cantidad de componentes desarrollados … la aplicación no es “visible”.
Pruebas Top Down: desde arriba, el sistema, y profundizando en cada componente.
Requiere dummies para los componentes aun no desarrollados.
Requiere regresión.
Puede demorarse la prueba de una funcionalidad completa (porque no está desarrollada en su
totalidad).

Técnicas de Testing

1. Técnicas Estáticas: (revisión y/o inspección)

I. Busca defectos en los requisitos y modelos se traducirán en defectos en el sistema
final
II. inspeccionan artefactos tempranos del desarrollo (o no… pero lo mejor es empezar
temprano)
2. Técnicas Dinámicas: (prueba o test de software)
I. Prueba un sistema o uno de sus componentes se ejecuta en circunstancias
previamente especificadas
II. Busca evalar los resultados contra requerimientos o contra resultados previamente
especificados

Técnicas Estáticas:
El objetivo fundamental de las pruebas estáticas es mejorar la calidad de los productos de software
ayudando a los ingenieros a reconocer y corregir sus propios defectos a principios del proceso de
desarrollo de software.
Mientras que las técnicas de prueba estática no resolverán todos los problemas, son enormemente
eficaces.
Las pruebas estáticas no deben considerarse un reemplazo para las pruebas dinámicas, pero todas
las organizaciones de software deben considerar el uso de revisiones en todos los aspectos
principales de su trabajo, incluyendo requisitos, diseño, implementación, pruebas y mantenimiento.

Son métodos complementarios a las técnicas dinámicas.

Hay 2 puntos de vistas  Las revisiones e inspecciones son actividades QA
 Las revisiones e inspecciones son actividades de testing
[Ian Sommerville – Ing. de Soft 9° edición Cap. 24]

Lo mas usado es la revisión o inspección por pares. Buscando posibles errores u omisiones.
La revisión debe comprobar la coherencia e integridad de los documentos o el código objeto de
prueba, y asegurarse de que se han seguido las normas de calidad.
No sólo es acerca de la comprobación de conformidad con las normas, sino también se utiliza para
ayudar a descubrir problemas y omisiones en la documentación del software o proyecto.

También… ayuda a que los participantes aprendan acerca del Proyecto en el que están
involucrados.
Y… nos ayuda a determinar donde están los productos mas riesgosos. Testing dinámico sobre todo
y con todos los casos de prueba posibles es muy improbable, priorizamos por riesgo o criticidad, las
revisión nos da una idea de riesgos (donde encontramos mas problema durante la inspección? y
que parte vimos mas compleja?)

¿Cuáles son las técnicas?

• Revisiones e Inspecciones de código: Informales no dejan de ser un intercambio de
opiniones entre los participantes. Formales: generan un informe que refleja el acto de la
revisión. Es una actividad para comprobar la calidad de los entregables, no para evaluar a la
gente que lo hizo, con el propósito de mejorar el software. Es una ‘revisión entre pares’.
• Walkthrough: se recorre el programa imitando lo que haría la computadora y con la guía de
quien lo desarrolló.
Pero también sirven como técnicas estáticas: (no
• Creación de prototipos:
• Generación de casos de prueba:
Cada organización decide que técnicas emplear y sobre que artefactos.
¿Qué productos?
Procedimientos: como se lleva a cabo la tarea respecto del procedimiento
Documentos: documentos y registros que se generan en el proceso, requerimientos, casos
de prueba, planes, diseños, requerimientos.
Productos: códigos (antes de ejecutarlos), prototipos, manual de uso y/o configuración.

¿Que podemos buscar/encontrar? [ISTQB Cap. 3.1]

• desviación de estándares
• requerimientos que falten
• defectos de diseños
• código no mantenible
• especificaciones de interfaces inconsistentes
En contraste con el testing dinámico … busca DEFECTOS no FALLAS!
Defecto -> es lo mal hecho por haber cometido un error al hacerlo
Falla -> es la manifestación del defecto

Revisiones e Inspecciones
Digamos, las inspecciones son las revisiones mas formales. En la práctica las revisiones informales
son las mas utilizadas. El grado de formalidad depende mucho de factores como la madurez del
proceso de desarrollo, de regulaciones legales, o de algún requerimiento para una auditoria.
Pueden participar dos o mas personas.
En las primeras etapas del desarrollo una persona puede solicitar a un colega … que revise un
documento, un diseño, un relevamiento.
En etapas mas avanzadas pueden ser grupos de personas reunidos cumpliendo una formalidad y
dejando asentado el resultado.
El objetivo es … ayudar al quien lo solicito a mejorar la calidad de su trabajo.

FASES
Fase: PLANEAR

1. Planificación:
◦ Definir los criterios de revisión (¿Qué vamos a buscar dentro de los entregables?)
◦ Seleccionar al personal
◦ Asignar funciones (al menos un moderador, un líder, y un “secretario”; que tipos de
defectos busca cada uno)
◦ Definir los criterios de entrada y salida para tipos de revisión más formales (EJ: las
inspecciones)
◦ Seleccionar qué partes de los documentos deben revisarse

Fase: kick Off

2. Inicio: (previo a la reunión! Es para que lo vayan viendo de antemano y no vayan crudos!)
◦ Repartir los documentos
◦ Explicar los objetivos, procesos y documentos a los participantes

Fase: Preparación
3. Preparación individual
◦ Prepararse para la reunión de revisión repasando los documentos
◦ Anotar posibles defectos, preguntas y comentarios
Fase: reunión de revisión
4. Examen/evaluación/registro de los resultados (reunión de revisión)
◦ Debatir o registrar, mediante resultados documentados o actas (para tipos de
revisión más formales)
◦ Anotar defectos, hacer recomendaciones sobre cómo manejar los defectos, tomar
decisiones de los defectos
◦ Examinar/evaluar y registrar problemas durante reuniones físicas o registrar
cualquier comunicación electrónica del grupo
◦ • Critical: defects will cause downstream damage; the scope and impact of
the defect is beyond the document under inspection.
◦ • Major, defects could cause a downstream effect (e.g. a fault in a design can
result in an error in the implementation).
◦ • Minor, defects are not likely to cause downstream damage (e.g. non-compli
ance with the standards and templates).
Fase: retrabajo o reconstrucción
5. Reconstrucción (del producto que inspeccionamos)
◦ Corregir los defectos detectados (normalmente a cargo del autor)
◦ Registrar el estado actualizado de los defectos (en revisiones formales)
Fase: Seguimiento
 6. Seguimiento
◦ Comprobar que los defectos han sido tratados
◦ Recopilar métricas
◦ Comprobar los criterios de salida (para tipos de revisión más formales)
Tipos de Revisiones
* Informal
* Guiada (Walkthrough)
* Técnica
* Inspección
[ISTQB Foundation Level Syllabus Cap. 3 - 3.2.3]
Revisión Informal
1. Ausencia de un proceso formalizado por la organización
2. Puede adoptar la forma de programación en pareja o una revisión por parte de un líder
3. técnico de los diseños y el código
4. Los resultados pueden estar documentados
5. Su utilidad varía en función de los revisores
6. Objetivo principal: forma barata de obtener beneficios

Revisión Guiada – Walkthrough

1. Reunión liderada por el autor del trabajo a revisar
2. Puede adoptar la forma de escenarios, ejecución simulada o participación en grupo de pares
3. Sesiones abiertas (significa que puede ir gente de fuera del equipo de desarrollo).
4. Preparación opcional de revisores previa a la reunión
5. Preparación opcional de un informe de revisión en el que se incluya la lista de hallazgos
6. Escriba opcional (distinto del autor)
7. Puede variar en la práctica desde bastante informal hasta muy formal
8. Objetivos principales: aprender, ampliar conocimientos, encontrar defectos

Revisión Técnica
1. Proceso documentado y definido para la detección de defectos que incluye la participación
de pares y expertos técnicos, siendo la participación de la dirección opcional
2. Puede llevarse a cabo como una revisión entre pares sin la participación de la dirección
3. Idealmente está dirigida por un moderador formado (distinto del autor)
4. Preparación previa a la reunión por parte de los revisores
5. Uso opcional de listas de comprobación
6. Elaboración de un informe de revisión en el que se incluya la lista de hallazgos, el veredicto
de si el producto de software cumple los requisitos y, si procede, recomendaciones en base
a los hallazgos
7. Puede variar en la práctica desde bastante informal hasta muy formal
8. Objetivos principales: debatir, tomar decisiones, evaluar alternativas, encontrar defectos,
resolver problemas técnicos y comprobar la conformidad con las especificaciones, los planes,
la normativa y los estándares

Inspección
1. Dirigida por un moderador formado (distinto del autor)
2. Generalmente celebrada como una examinación entre pares
3. Funciones definidas
4. Incluye recopilación de métricas
5. Proceso formal basado en normas y listas de comprobación
 6. Criterios de entrada y salida especificados para la aceptación del producto de software
7. Preparación previa a la reunión
8. Informe de inspección en el que se incluye una lista de hallazgos
9. Proceso de seguimiento formal (con proceso de mejora de componentes opcional)
10. Lector opcional
11. Objetivo principal: identificar defectos

Usamos un checklist
Con frecuencia se usa una lista de verificación de errores comunes de programación para enfocar la
búsqueda de bugs.
Esta lista de verificación se basa en ejemplos de libros, o bien, en el conocimiento de defectos
normales en un dominio de aplicación común.
Para diferentes lenguajes de programación se usan distintas listas de verificación, puesto que cada
lenguaje tiene sus errores característicos.

Peer Review – Revisión de Pares

La revisión entre pares es una técnica para evaluar anónimamente un programa en términos de
calidad, mantenibilidad, extensibilidad, usabilidad y claridad. El propósito de esta técnica es proveer
una evaluación al programador
• Was the program easy to understand?
• Was the high-level design visible and reasonable?
• Was the low-level design visible and reasonable?
• Would it be easy for you to modify this program?
• Would you be proud to have written this program?
[The Art of Software testing –Glanford Myers]

Desk Checking – Prueba de Escritorio

Una prueba de escritorio puede ser vista como una inspección o wlakthrough realizado por una sola
persona: una persona lee el programa, lo controla contra una lista de posibles errores, y va
probando los datos a través de el. Quien mejor lo puede hacer… es el autor.
Ahora, que es mejor? Walkthrough o Prueba de escritorio? La razón es la sinergia
[The Art of Software testing –Glanford Myers]

Análisis estático con Herramientas

El objetivo del análisis estático es detectar defectos en el código fuente del software y en los
modelos de software.
El análisis estático se realiza sin ejecutar el software objeto de la revisión; en las pruebas dinámicas
sí se ejecuta el código de software.
El análisis estático permite identificar defectos difíciles de encontrar mediante pruebas dinámicas.
Al igual que sucede con las revisiones, el análisis estático encuentra defectos en lugar de fallos.
Las herramientas de análisis estático analizan el código del programa.
Se usan herramientas.

Análisis estático con Herramientas

Ejemplos de herramientas:
◦ Para JAVA: FindBugs http://findbugs.sourceforge.net/findbugs2.html
◦ Para JavaScript: JSHint http://jshint.com/about/

METRICAS
Complejidad Ciclomática
Es una métrica cuantitativa de la complejidad lógica de un código.
Se basa en el cálculo de la cantidad de caminos independientes dentro del programa.
Un camino es independiente cuando se introduce una nueva sentencia o una nueva condición
respecto de los anteriores.
Los caminos se identifican a partir de las estructuras de control (condiciones, bucles, …) y a partir
del diagrama de flujo de cada uno de nuestros métodos.
Al calcular la complejidad ciclomática obtenemos el número máximo de casos a probar, por lo que
es importante para el testing.
Propuesta por Thomas McCabe en 1976 (si, en 1976)

Se calcula:
1- Sumando la cantidad de decisiones binarias en el código (if, while, for …) y agregándole 1
2- Por detección y recuento de caminos independientes.
3- En el diagrama de flujo, visualmente:
◦ CC = nro. de regiones cerradas + 1
◦ CC = nro. de decisiones simples + 1 (if+1)
4- Con fórmula:
◦ CC = A –N + 2 donde A es el nro. de aristas y N el nro. de nodos
◦ CC = A –N + 2*S donde S es el nro. de nodos de salida
A partir de un grafo

A partir del Grafo o Código

¿Para que sirve?

Thomas McCabe, establece una relación con el riesgo:
“… cuanto más compleja sea la lógica de un código, más difícil será de entender, mantener y
probar…”
◦ <= 10, códigos sencillos, sin mucho riesgo.
 ◦ > 10, <= 20, códigos medianamente complejos, con riesgo moderado.
◦ > 20, <= 50, códigos complejos, con alto riesgo.
◦ > 50, códigos inestables, de altísimo riesgo.
◦ También nos permite darnos una idea del esfuerzo necesario para poder probar
todos sus caminos.

◦ Los códigos con alta complejidad ciclomática pueden ser refactorizados, o

rediseñados, o puede que requiera la incorporación de un patrón de diseño.
◦ Nos da el número de casos de prueba unitarios básicos para obtener una cobertura
del 100%.
◦ Es una aproximación al grado de comprensibilidad del diseño.

¿Con que seguimos?

Con las técnicas dinámicas:

Caja Blanca: o basada en el código. Revisamos los caminos que sigue el Soft, el algoritmo. Toma el
punto de vista del desarrollador. Verificar que cada componente es operativo. §Se enfoca en
verificar Comportamiento interno y Estructura.

Caja Negra: o basado en la especificación del usuario o de caja negra. La idea es verificar que el
comportamiento observado del software cumple o no con sus especificaciones. La prueba funcional
toma el punto de vista del usuario. §Se enfoca en verificar el Comportamiento en función de sus
entradas y salidas.

TECNICAS DE TESTING
Prueba de Caja Blanca
◦ Prueba de camino básico
◦ Prueba de bucles
◦ Prueba de bucles no estructurados
Prueba de Caja Negra
◦ Partición equivalente
◦ Valores límites
◦ Tablas de decisión
◦ Transición de estados
Prueba de Carga y Stress
Prueba de Humo
Prueba de Regresión
Prueba de UI
Prueba de Ayuda
 Ethical Hacking

CLASE 5
Para testear tenemos que diseñar

Diseñar la prueba que vamos a realizar.

La “herramienta” para diseñar la prueba y especificarla… es el caso de prueba o test case.

¿Qué es un Caso de Prueba?

Es un conjunto de valores de entrada, precondiciones de ejecución, resultados esperados y
postcondiciones de ejecución desarrollados para un objetivo en partículas o condición de test con
el fin ejercitar un camino particular del programa o verificar el cumplimiento de requerimiento
específico”. [ISTQB Foundation Level Glossary]

Es muy importante la creación de los casos de prueba, dado que no se puede probar el 100%,
entonces:
¿Qué conjunto de casos de prueba tiene la máxima probabilidad de encontrar la mayor cantidad de
errores?
1. Al menos uno que pruebe el escenario básico, que sea positivo, el curso normal, que
demuestre que el requerimiento ha sido satisfecho.
2. Otro para reflejar que es inaceptable, anormal o inesperada la condición o dato, algo
negativo.
3. La idea es cubrir la mayor parte con técnicas de caja negra y, si es necesario, cubrir algunos
aspectos con técnicas de caja blanca.
4. Debemos seguir criterios que nos permitan mediante métricas … establecer la cobertura.

Que deben incluir:

• Precondiciones
• Conjunto de valores de entradas
• Procedimiento
• Conjunto de resultados esperados
• Postcondiciones
• Identificador único del caso
• Descripción para su comprensión, propósito
• Dependencia de otros casos de prueba
• Referencia al requisito/funcionalidades que implementa (trazabilidad)

Descripción
Precondiciones
condiciones necesarias para ejecutar el caso de prueba.
◦ Si no se cumplen no se puede iniciar el caso.
◦ Lo que se representa es un estado y no la ejecución de una serie de acciones.
Ejemplos:
◦ [Tabla / Parámetro/ Variable / Atributo, Campo, etc] debe estar configurada/o con el
valor…
◦ Se debe estar en la pantalla …
◦ La sesión debe estar iniciada …
◦ Se debe haber ejecutado el proceso …

Datos de Entrada
Conjunto de valores de entradas y salidas esperadas: especificamos los valores “correctos” y los
“incorrectos”.

Pasos del Caso de Prueba

Cada paso tiene un resultado esperado. El formato para la respuesta esperada será el siguiente:
◦ Que se + suceda algo
◦ Que algo sea…
Ejemplos:
◦ Que se visualice por pantalla…
◦ Que se genere el archivo…
◦ Que el valor por defecto del campo sea…

Post Condiciones
“Condiciones de entorno y estado, del software, que deben ser satisfechas tras la ejecución de una
prueba o un procedimiento de pruebas”.
Lo que se representa es un estado y no la ejecución de una serie de acciones (previas o posteriores
al caso de uso)

Resultado
Del caso de pruebas:
Salida esperada: Contiene una descripción de lo que el analista debería ver tras haber
completado todos los pasos de la prueba. El estado esperado del sistema, el valor esperado
de las variables o los datos que se espera que devuelva.
Salida obtenida: Contiene una breve descripción de lo que el analista encuentra después de
que los pasos de prueba se hayan completado. El estado real del sistema, el valor real de las
variables o los datos que devolvió.
Resultado: Indica el resultado cualitativo de la ejecución del caso de prueba, a menudo con
un Correcto/Fallido.
Estado: Indica si el caso de prueba está: No iniciado, En curso, o terminado.

¿Que puedo encontrar?

Según Pressman, los tipos de defecto (en realidad “fallas”) que se pueden encontrar son:
• Defectos del comportamiento.
• Defectos en la interfaz.
• Defectos en las estructuras de datos o acceso a la base de datos.
• Defectos en las funciones que desempeña el sistema (no tengo la salida correcta).
• Funciones que están faltando(defecto del relevamiento, del diseño o de la implementación).
• Defectos de rendimiento.

Por cada defecto encontrado:

Severidad: Indica el impacto del defecto en el sistema: Grave, Mayor, Normal, Menor,
Invalidante.
Evidencia: En los casos que aplica, contiene un link al printde pantalla (screenshot) donde se
evidencia la salida obtenida. Con la referencia al caso de prueba en si mismo.
Seguimiento: Contiene el código correlativo del defecto, a menudocorresponde al código
del sistema de tracking de bugs que se esté usando

Tipos de Test Case

-Basados en requerimientos: se derivan de las especificaciones o del entendimiento de lo que el
sistema debe hacer. Los vamos a derivar, por ejemplo, de casos de usos.
-Basado en el código: se derivan de la lógica del software. Por ejemplo, de cobertura.
Extremos: son aquellos que se derivan del esfuerzo por hacer fallar al sistema, por llevarlo a sus
límites.
Aleatorios: son casos creados al azar.

Derivar Test Case de Casos de Uso

1. Representar gráficamente los flujos, el básico y los alternativos, del caso de uso.
2. Comenzar con el flujo básico, el normal, el que no tiene excepciones.
3. Luego los otros escenarios, caminos, siguiendo los flujos alternativos y excepciones.
4. Identificamos los valores de entrada y salida para cada escenario.
5. Reconocemos las variables en juego.
6. Identificamos los valores de salida esperados.
7. Cada escenario es un posible caso de prueba.
8. Decidimos cuales caso de prueba incluir, siguiendo algún criterio de cubertura.
Escenarios

Derivar Test Case de Casos de Uso

Ejemplos:

Entonces son 3 pasos:

Por cada caso de Uso:
1. generar los escenarios
2. identificar los casos de pruebas
3. identificar los valores de entrada

Métricas
“Cuando se puede medir aquello de lo cual se está hablando y se puede expresar en números, se
sabe realmente acerca de ello; pero cuando no puede medirse, y no puede expresarse en números,
el conocimiento que se tiene de ello es escaso e insatisfactorio, o puramente subjetivo.”
Lord Kelvin [1890]  no es sommerville, y fue en 1890!
 “Una métrica de software es una característica de un sistema de software, documentación
de sistema o proceso de desarrollo que puede medirse de manera objetiva”.
[Ian Sommerville – Ing. de Soft. 9° ed. Cap. 24.4]

◦ De control o del proceso

necesitamos hacer cambios al proceso?
◦ Métricas
◦ De predicción o del producto
cuanto nos llevara hacer un trabajo
sobre tal código?
◦ Estáticas
◦ Dinámicas
◦ Las métricas de software pueden ser métricas de control o de predicción.
◦ Como el nombre lo dice, las métricas de control apoyan la gestión del proceso, y las
métricas de predicción ayudan a predecir las características del software.
◦ Las métricas de control se asocian por lo general con procesos de software. Ejemplos de las
métricas de control o de proceso son el esfuerzo promedio y el tiempo requerido para
reparar los defectos reportados.
◦ Las métricas de predicción se asocian con el software en sí y a veces se conocen como
métricas de producto. Ejemplos de métricas de predicción son la complejidad ciclomática
de un módulo, la longitud promedio de los identificadores de un programa, y el número de
atributos y operaciones asociados con las clases de objetos en un diseño.
[Ian Sommerville Cap 24]

Ejemplos:
De control:
esfuerzo promedio
el tiempo requerido para reparar los defectos reportados
De predicción:
complejidad ciclomática
longitud de los indicadores
cantidad de atributos y métodos de una clase
Objetivo
Objetivo

Ventajas de usar métricas:

• Las métricas evitan juzgar de manera subjetiva al software.
• Las métricas sirven para planear.
• Las métricas cuentan como funciona nuestro proceso de test de manera objetiva.
• Las métricas permiten darnos una idea del cumplimiento de los atributos de calidad de un
SW.
• Las métricas nos permiten mejorar las estimaciones futuras.
• La meta a largo plazo de la medición del software es usar la medición en lugar de revisiones
para realizar juicios de la calidad del software.
[Ian Sommerville Cap 24.4]

Metricas y Calidad
“Atributo de la calidad” … es una propiedad del producto, que cuando es asociada con la calidad se
relaciona con los elementos que considera el cliente para aceptar o rechazar el producto.
• Las métricas se basan en atributos del producto.
• Los atributos del producto pueden clasificarse en internos y externos.
• Los atributos internos describen al producto basado en el producto mismo.
Se miden de manera estática basado en tamaño, funcionalidad, complejidad y reusabilidad.
• Los atributos externos describen al producto de la manera como funciona en el ambiente.
• El cliente define usualmente estos atributos.
• Algunos atributos externos son adaptabilidad del producto para el problema definido,
conformidad con las especificaciones, grado de excelencia, puntualidad.

Los atributos de calidad, como:

◦ mantenibilidad,
◦ comprensibilidad
◦ Usabilidad
son atributos externos que se refieren a cómo los desarrolladores y usuarios experimentan el
software.
Se ven afectados por factores subjetivos, como la experiencia y educación del usuario, y, por lo
tanto, no pueden medirse de manera objetiva.
Para hacer un juicio sobre estos atributos, hay que medir algunos atributos internos del software
(como tamaño, complejidad, etcétera) y suponer que éstos se relacionan con las características de
calidad por las que uno se interesa.
Pero no tienen una relación clara.. No es 100% seguro que la métrica interna nos indique algo
100% sobre el atributo externo de calidad.

Metricas

¿Qué métricas importan más en testing?

Las métricas de producto se dividen en 2:

1. Métricas dinámicas, que se recopilan mediante mediciones hechas de un programa en ejecución.
Dichas métricas pueden recopilarse durante las pruebas del sistema o después de que el sistema
está en uso. EJ: número de reportes de bugs o el tiempo necesario para completar un cálculo.

Comprender “como quedó” lo que hicimos

2. Métricas estáticas, las cuales se recopilan mediante mediciones hechas de representaciones del
sistema, como el diseño, el programa o la documentación. Ejemplos de mediciones
estáticas son el tamaño del código y la longitud promedio de los identificadores que se
usaron.
Predecir

Estáticas:
Valorar el riesgo de un producto
Para planear el testing
O a donde enfocar los esfuerzos
Dinámicas
El objetivo de la monitorización de las pruebas es facilitar información de retorno y visibilidad sobre
las actividades de pruebas.
◦ * Porcentaje de trabajo realizado durante la preparación del caso de prueba (o
porcentaje
◦ de casos de prueba planificados preparados)
◦ * Porcentaje de trabajo realizado durante la preparación del entorno de pruebas
◦ * Ejecución de casos de prueba (por ejemplo, número de casos de prueba
ejecutados/no
◦ ejecutados, y casos de prueba pasados/fallados)
◦ * Información sobre defectos (por ejemplo, densidad de los defectos, defectos
detectados y
◦ corregidos, tasa de fallos y resultados de la repetición de pruebas)
◦ * Cobertura de las pruebas de los requisitos, riesgos o código

Cobertura
Es un concepto importantísimo del testing.
¿Cuánto de xxxx cubrí con las pruebas?

Donde xxxx = código o funcionalidad (básicamente).

Es más usado en pruebas unitarias, nivel de testing =
Que es cobertura entonces: “el grado, expresado en porcentaje, en el cual un ítem a sido ejercitado
por una suite de casos de prueba” [ISTQB] Foundations Level Glossary

Cobertura de Código
En un código de 1000 líneas pruebo 700 líneas, la cobertura es del 70%.
¿Para qué sirve?
Aumenta la calidad del código, al revisar más % de mi código minimizo la cantidad de errores. Lo
mejor es tener una alta cobertura, que tienda al 100%.
¿Una cobertura del 100% implica que el programa no tiene errores? NO, solo que probé el 100%
del código. (puedo no haber probado todas las condiciones …)
Cobertura de Sentencias: se escriben casos de prueba suficientes para que cada sentencia (o un
cierto %) en el programa se ejecute, al menos, una vez. Los bucles solo se consideran una vez (al
contrario que la cobertura de caminos).

Cobertura de Decisiones: lograr la cobertura de un porcentaje específico de todas las decisiones.

Tiene dos variantes:
◦ Se escriben casos de prueba suficientes para que cada condición sea evaluada al
menos una vez.
◦ Se escriben casos de prueba suficientes para que cada condición en una decisión
tenga una vez resultado verdadero y otra vez falso.

Cobertura de Condiciones: se escriben casos de prueba suficientes para que cada condición en una
decisión tenga una vez resultado verdadero y otra falso. No solo considero el resultado final de una
condición, ya que puede estar constituida por múltiples condiciones atómicas (SI a>0 y b>100
ENTONCES…)
Cobertura de Caminos: se escriben casos de prueba suficientes para que se ejecuten todos los
caminos de un programa. Entendiendo camino como una secuencia de sentencias encadenadas
desde la entrada del programa hasta su salida. Un solo camino a través de un bucle es suficiente.
Se podría agregaría un caso de prueba adicional para cada ejecución del bucle. Cada incremento en
el contador del bucle añade un nuevo caso de prueba pero no es práctico… es una locura.
Cobertura de Métodos de Objetos: se escriben casos de prueba suficientes para que se ejecuten
todos los métodos de todos los objetos.

Cobertura Funcional: medimos la cobertura de las funcionalidades probadas. Se derivan de los

requerimientos funcionales (los no-funcionales quedan fuera).
Digamos, mido el % de funcionalidades que cubrió mi prueba.

CLASE 6
Vimos la clase pasada:
- Derivación de Casos de Prueba de Casos de Uso (no es caja blanca)
- Cobertura de Código pensado como métrica (acá empezamos caja blanca)
pensado como técnica para diseñar casos de prueba
* cobertura de sentencias
* cobertura de decisiones
* cobertura de condiciones
 * cobertura de bucles (0, 1, + de 1, antes, cond, desp cond)
-> se llaman coberturas lógicas
-> caja blanca / nivel componentes
- Cobertura funcional (no es caja blanca)
- Cobertura de requerimientos (no es caja blanca)

Oráculo
En testing se presupone la existencia de lo que se llama un oráculo, que es algún tipo de método
para determinar que una salida dada, luego de un testing, es la salida esperada.
◦ Este oráculo puede ser un humano; por ejemplo, el futuro usuario del sistema.
◦ En general, el oráculo más confiable lo constituirá una especificación formal del
sistema a testear.

Driver: es un módulo de software que se usa para invocar el modulo bajo test y por lo general
proveerle de entradas, controlar y monitorear su ejecución y reporter los resultados.
Dummy/Stub: es un programa de computadora que sustituye a otro o parte de otro que está siendo
definido o lo será más adelante, y que debe simular su comportamiento real hasta que se lo
desarrolle.
Se usan en pruebas de caja blanca, donde ejecutamos códigos, que de alguna manera debemos
llamar y que probablemente no tenga los demás componentes con los cuales se relacionan
terminados.

Método de Mc Cabe – Caminos Básicos

Los métodos de caja blanca descansan sobre el código y la forma en que este se ejecuta instrucción
por instrucción, esto se relaciona con el control de la ejecución del software, que puede expresarse
como un grafo de control, sobre el cual se aplican luego los diversos métodos.

Las pruebas estructuradas de McCabe se basan en un conjunto de caminos básicos que deducimos
del grafo de control. O dicho de otra manera, el grafo de control es una herramienta para
determinar los caminos y los casos de prueba.

Veámos el método, que requiere:

◦ Convertir el código en un grafo de control equivalente al que vamos a testear.
◦ Calcular la complejidad ciclomática y obtener el # de caminos bases.
◦ Prepara un caso de prueba para cada camino base.
Empecemos primero con la construcción del grafo.
-> Método McCabe [Watson y McCabe, 1996]

Se construye un grafo equivalente al entregable de código bajo testing. Con las siguientes reglas:
◦ Existen solo un nodo inicial y solo uno final.
◦ Cada nodo representa una secuencia de instrucciones (o ninguna).
◦ La relación entre los nodos es “… el control pasa a...”.
◦ De cada nodo se desprenden uno o dos nodos hijos. Máximo DOS.
 ◦ Un nodo tendrá dos sucesores si dada una condición se desprenden dos caminos
posibles.
◦ For, While, Until, Case, Switch se reducen a grupos de nodos con dos sucesores (con
un máximo de DOS).
◦ Un nodo puede tener 1…n antecesores.

La ejecución de los programas es secuencial … a menos que haya un salto, o bifurcación, o vuelta
atrás por un bucle … estos cambios es lo que se modela en el grafo.

Método de McCabe
Esto significa que las secuencias de instrucciones donde no haya bifurcaciones las podemos modelar
como un solo nodo.
int a = 10; 1
int b = 10;

int x = a + b;
2
if (x > 21) {
writeln(‘mayor a 21’); 3
} else { 4
writeln(‘menor a 21’);

}
5
writeln(‘fin’);
Método de McCabe
Como sigo después:
- Cálculo la complejidad ciclomática:
CC = Aristas -Nodos + 2
1. cc = a -n + 2, siendo a el número de arcos o aristas del grafo y n el número de nodos.
2. cc = r, siendo r el número de regiones cerradas del grafo.
3. cc = c + 1, siendo c el número de nodos de condición.
Y ahora … calculo los caminos básicos.

* Buscar los caminos básicos:

Cada camino puede convertirse en un vector de n elementos, donde n es la
cantidad de arcos del grafo. Cada elemento del vector toma un valor 1 o 0 si
participa dicho arco del camino o no.
Si se reúnen todos los vectores de todos los caminos se obtiene una matriz de la
cual por un procedimiento algebraico se obtiene la base. (La base son todos los
vectores independientes que combinados por medio de una operación permiten
conformar los restantes).
La base es el conjunto de todos los caminos independientes, un camino
independiente es aquel que introduce un conjunto nuevo de sentencias o una
condición respecto de los anteriores. (Un arco que no ha sido recorrido
anteriormente).
.
Hay 2 métodos: el simplificado y el general

Método simplificado:
Se comienza seleccionando el camino más corto(el vector con menor cantidad de ‘1’).
Buscar un segmento no de una decisión recorrido, tomarlo y regresar al camino base lo más pronto
posible.
Se finaliza al llegar a tener tantos caminos como la complejidad ciclomática.
Este método tiende a recorrer primero los errores, las excepciones y las salidas de emergencias.

Método general.
Se elige el camino que funcionalmente es el correcto, el que representa la operación normal del
software.
Se va variando en cada paso, agregando un arco no recorrido y volviendo tan pronto como sea
posible al camino básico.
Se finaliza al llegar a tener tantos caminos como la complejidad ciclomática.

Ahora, se generan los casos de prueba (¿Qué contienen mínimamente un caso de prueba?)
• Se selecciona un camino.
• Se avanza hasta la primera condición.
• Se identifican las variables, si son externas se deduce el valor que deben tener para tomar el
arco siguiente del camino.
• Si son internas hay que retroceder hasta encontrar las variables externas de las cuales
provienen.
• Avanzar a la próxima decisión y repetir el proceso.

Seleccionamos los caminos de prueba… en función de la cobertura que deseamos utilizar (y por
supuesto medir):
• Que se ejecuten todos los nodos. Cobertura de sentencias.
• Que se ejecuten los nodos de decisión. Cobertura de decisiones.
• Que se ejecuten los bucles. Cobertura de bucles.
• Que se ejecuten los caminos básicos. Cobertura de caminos.

Prueba de las decisiones.

Hay que asegurarse de revisar todas las decisiones, o mejor dicho que los caminos seleccionados
pasen por todas las condiciones. Ahora por cada camino … armamos muchos casos de prueba:
Para que cada condición sea una vez verdadera, una vez falsa.

Prueba de las condiciones.

 Si la decisión es compuesta, para que cada condición atómica que forma la compuesta
asuma una vez un valor falso y otra vez verdadero.

Prueba de bucles simple.

◦ Pasar por alto el bucle
◦ Pasar solo una vez por el bucle
◦ Pasar dos veces por el bucle
◦ Pasar n veces por el bucle
◦ Pasar n-1 y n+1 veces (¿valores límites?)
Prueba de bucles anidados.
◦ Repetir la prueba con los bucles anidados.
◦ Se puede producir una explosión de casos de pruebas al aumentar el nivel de
anidamiento.
Prueba de bucles concatenados.
◦ Se prueban como bucles simples (siempre que sean independientes, sino son
anidados).
◦ Prueba de bucles no estructurados (goto… todavía lo usamos? Si hay … rediseñar).

Flujo de Datos
¿Que pretendo probar con la prueba de flujo de datos?
◦ Una variable que es declarada pero nunca usada dentro del programa.
◦ Una variable que es usada pero nunca declarada.
◦ Una variable que es definida varias veces antes de usarse.
◦ Destrucción de variables antes de usarlas.
Prueba de flujos de datos.
Seleccionar las rutas de pruebas de acuerdo con las ubicaciones de las definiciones, uso y
destrucción de los datos del programa. La ruta sería la secuencia de cambios de estados de los datos.

Debemos elegir la suficiente cantidad de rutas de forma de asegurar que:

◦ Todas las variables son inicializadas
◦ Todas las variables son usadas al menos una vez
◦ Todas las variables son destruidas

Tenemos que aprender 2 ítems:

◦ Anomalías del flujo de datos
◦ Estrategias del flujo de datos

1. Se determinan potenciales errores examinando los “patrones” de uso de los datos (de las
variables).
2. Con uso se refiere a: la creación, el uso en predicados (IF), el uso en cálculos, y la destrucción.
(respectivamente: d, p-use, c-use, k).
3. Partimos del flujo del programa, lo convertimos en un gráfico de flujo de datos de los datos.
4. Posibles anomalías:
5. Anomalías de flujo de datos representa patrones de uso de datos que pueden generar una
incorrecta ejecución del código.
6. Buscamos los patrones como pares (entre dos nodos) de uso, de fin, o desasignación de la
variable.

Hasta aquí hicimos una prueba estática.

También podemos hacer pruebas dinámicas, los casos de prueba deben armarse definiendo c/u,
un camino desde la definición de una variable c/u de sus usos, y consignando el resultado esperado.
Existen distintas estrategias, a las que por experiencia se les ha asignado una cierta fortaleza.

• ADUP(alldu paths) probar cada camino du, desde la definición de la variable hasta el uso de
esta definición.
• AU(alluses) probar al menos un camino desde cada definición de cada variable a cada uso
que puede ser alcanzado por dicha definición.
• APU+C(allp-uses/somec-uses) para cada variable y cada definición de esa variable incluir al
menos un camino desde la definición hasta cada predicado que lo usa. Si existe una
definición de la variable sin un uso en un predicado agregar el camino desde dicha definición
hasta un uso en un calculo.
• ACU(allc-uses) para cada variable y cada definición de esa variable incluir al menos un
camino desde la definición hasta cada calculo que lo usa. Si existe una definición sin un
calculo … se la quita de los casos de prueba-

• ACU+P(allc-uses/somep-use) para cada variable y cada definición de esa variable incluir al

menos un camino desde la definición hasta un predicado que la usa. Si existe una definición
sin un predicado agregamos el camino desde la definición hasta algún calculo.
• AD(alldefinition) para cada definición de cada variable debemos considerar al menos un uso
de la misma, sea en un calculo o en un predicado