Diseño de Experimentos:

Tipos de Prueba de Rendimiento:

https://cl.abstracta.us/blog/tipos-pruebas-performance/

SCRUM:

Validación: ¿Provee al sistema las funciones que mejor soporten las necesidades del cliente?

Consistencia: ¿Existe cualquier conflicto en los Requisitos?

Completo: ¿Están incluidas todas las funciones requeridas por el cliente?

Realismo: ¿Pueden los Requisitos ser implementados con la tecnología y el presupuesto disponible?

Criterios de aceptación: Un criterio de aceptación es el criterio por el cual se define si una historia de
usuario fue desarrollada según la expectativa del Product Manager/Owner (como representante de los
criterios del cliente) y se si puede dar como hecha. 

Revisión de Requisitos:

Demostración de que los Requisitos que definen el sistema son lo que el cliente realmente quiere.

Los costos de errores en los Requisitos son altos, por lo cual, la validación es muy importante.

reparar un error de Requisito después del desarrollo puede resultar en un coste 100 veces mayor que
reparar un error en la implementación.
El Prototipado es una técnica importante de la validación de Requisitos.

Validación. ¿Provee al sistema las funciones que mejor soporten las necesidades del cliente?

Consistencia. ¿Existe cualquier conflicto en los Requisitos?

Completo. ¿Están incluidas todas las funciones requeridas por el cliente?

Realismo. ¿Pueden los Requisitos ser implementados con la tecnología y el presupuesto disponible?

Una revisión regular puede ayudar mientras la definición de Requisitos está siendo hecha.

Tanto el cliente como el personal de contratistas deben estar involucrados en la revisión.

La revisión debe ser formal (con los documentos completos) o informal. Una buena comunicación entre
desarrolladores, clientes y usuarios puede resolver problemas en las primeras etapas.

Términos:

• RUP: Es un proceso de ingeniería de software que suministra un enfoque para asignar tareas y
responsabilidades dentro de una organización de desarrollo

• XP: Es una metodología de desarrollo que pertenece a las conocidas como metodologías ágiles
(otras son Scrum, Kanban…), cuyo objetivo es el desarrollo y gestión de proyectos con eficacia,
flexibilidad y control. Ambos conceptos, relacionados estrechamente, son distintos.

• SCRUM: Es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas

para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto

• Fase: Iniciación. Identificar el alcance inicial del proyecto.

 Elaboración. Identificar y validar la arquitectura del sistema.

 Construcción. Esta fase consiste en construir software desde un punto de vista

incremental

 Transición. En esta fase se valida y despliega el sistema en el entorno de producción.

• Disciplina:

 Modelado.

 Implementación.

 Pruebas.

 Despliegue.

 Gestión de la configuración.

 Gestión del proyecto.

 Entorno.
 • Iteración: En un desarrollo iterativo e incremental el proyecto se planifica en diversos bloques
temporales (en el caso de Scrum de un mes natural o hasta de dos semanas, si así se necesita)
llamados iteraciones. Las iteraciones se pueden entender como miniproyectos.

• Requisito: requisito es 'circunstancia o condición necesaria para algo'

• Requerimiento: requerimiento es la acción de requerir

• Error (error): Es una decisión incorrecta tomada durante el desarrollo de un sistema de software
(usualmente una suposición incorrecta).

• Defecto (defect, fault, «bug»): Es una propiedad del software que puede hacer que se comporte
de una manera no deseada, por ejemplo, un proceso, una definición de datos o un paso de
procesamiento incorrectos en un programa.

• Fallo (failure): es la situación en la cual un software en ejecución efectivamente se comporta de

una manera no deseada.

Los fallos son producidos por defectos, que son el resultado de errores. Los fallos existen en la ejecución
del programa, los defectos en el software, y los errores en las personas.

¿Cómo medimos la Calidad entregado?

¿De donde vienen los defectos?

 Plan Análisis Diseño Construcción Implantación

¿En qué etapa se inyecta más defectos?

¿Cuánto cuesta corregir un defecto?

Costo de las Pruebas
Factores de calidad:

Corre
cción
Compa
Robustez
tibilidad

Facilida Calidad
Eficien
d de
cia
Uso
Integri Portabil
dad idad
Corrección:
Es la capacidad de los productos software para realizar con exactitud las tareas expresadas en su
especificación.

Uno de los problemas de la corrección es que se presupone la confianza en los distintos componentes
involucrados en la producción del sistema; compilador, bibliotecas, módulos, Sistema operativo, etc.

Robustez:

Es la capacidad de los productos software de reaccionar apropiadamente ante condiciones

excepcionales.

La robustez viene a ser el complemento de la corrección. En implementación se cuenta con el

mecanismo de excepciones el cual garantiza el correcto flujo de ejecución del código. (Programación por
contrato)

Eficiencia:

Es la capacidad del software para hacer buen uso de los recursos que manipula.

Una práctica muy común en los desarrolladores es la optimización excesiva, lo importante es mantener
un balance adecuado entre eficiencia y corrección.

Portabilidad:

Es la facilidad con que un sistema software puede ser migrado entre diferentes plataformas hardware o
software.

La portabilidad es un factor que tomó gran importancia en la década de los 90 debido a la gran
proliferación de los sistemas basados en Internet y su basta heterogeneidad.

Integridad:

Es la característica de un sistema de ser capaz de proteger sus diferentes componentes contra los
procesos o elementos que no tengan derecho de acceso a los mismos.

La integridad es un factor muy importante en sistemas contables, administrativos y gerenciales ya que de

ellos depende el capital de la empresa.

Facilidad de Uso:

Es la facilidad con la que un usuario puede interactuar con un sistema software.

La facilidad de uso es un factor determinante en términos de mercadeo y venta, ya que es el principal

elemento que afecta al usuario final. La facilidad de uso incluye prestancia en instalación, operación y
supervisión.

Compatibilidad:

Es la facilidad de combinar diferentes elementos software con el fin de ejecutar una labor en conjunto.

La mayoría de los sistemas son abiertos (interactúan con otros sistemas), y el dinamismo inherente a la
realidad hace muy probable que los sistemas software tengan que intercambiar información entre sí.
Esto hace que la compatibilidad sea un factor muy serio al momento de modelar el sistema.
Validación:

Conjunto de actividades que aseguran que el software construido se ajusta a los requisitos del cliente.

La validación involucra las pruebas de aceptación y se realiza después de la verificación.

Verificación:

Conjunto de actividades que aseguran que el software implementa correctamente una función
específica.

La verificación permite evaluar planes, código, requisitos y especificaciones.

Verificación y Validación:
¿Qué evitamos con las pruebas?

 Pérdidas de productividad

 Frustración del usuario

 Incremento de llamadas a Help Desk – Caso : cambio de versión

 Sistema fuera de servicio – Caso : Envío de tramas

 Pérdida y corrupción de datos – Caso : cambio de fórmula

¿Para qué sirven las pruebas?

Es una de las barreras para evitar que software de baja calidad llegue a los usuarios finales.
V&V Estática = REVISIONES

V&V Dinámica = PRUEBAS

Informales:

 No hay proceso definido

 No existen Roles
 Usualmente no son Planeadas
Formales:

 Objetivos Definidos
 Procesos Documentados
 Roles definidos y Personas entrenadas en ellos
 Checklist, reglas y métodos para encontrar defectos
 Reporte de resultado
 Recolección de datos para el control de proceso

Técnicas de Prueba:
Documentos:
V&V Estática

Analizar la representación Estática del Sistema

Ventajas:

 No requiere de código ejecutable, por lo que puede ser realizada desde el inicio

 Se encuentran varios defectos a la vez

 Encuentra hasta un 85% de los defectos

 Se localiza la posición exacta del defecto

 Refuerza el uso de estándares

 Mejora la capacitación

Desventajas:

x Requiere de tiempo de Expertos

x No se verifican características no-funcionales como: Rendimiento

x Validan cumplimiento de lo que se especificó, en vez de lo que realmente quiere el cliente

x Es vista como improductiva por algunos ingenieros

V&V Dinámica

Ejercitar y Observar el comportamiento del producto

Ventajas:
  Pueden no ser exhaustivas (Principio de Pareto – 80 / 20)

 Existen varios tipos, dependiendo del aspecto que se quiera probar

Desventajas:

x No asegura ausencia de defectos

x Requieren Planificación y Seguimiento

Tipos de Prueba:

Pruebas de Unidad

 Caja Blanca: Usa la estructura de control del diseño procedimental para obtener los casos de

prueba. Tratan de analizar la estructura interna del componente/sistema. Es decir, el diseño de

los casos de prueba se enfoca en la estructura del componente o sistema.

 Caja Negra: Se centran en los requisitos funcionales del software. Se llevan a cabo sobre la
interfaz del sistema.

Pruebas Funcionales
Comprueban si los sistemas cumplen con las funciones específicas para los que han sido
creados.
Pruebas no Funcionales
Prueban la calidad de las características del producto (Usabilidad, Mantenibilidad, Fiabilidad,
rendimiento, etc)

Pruebas de Integración

Se comprueba la compatibilidad y funcionalidad de los interfaces entre las distintas ‘partes’ que
componen un sistema, estas ‘partes’ pueden ser módulos, aplicaciones individuales, aplicaciones
cliente/servidor, etc.

Pruebas de Validación

La validación del software se consigue mediante una serie de pruebas de caja negra que demuestran la
conformidad con los requisitos.

 Prueba Alfa: Las pruebas alfa se llevan a cabo en un entorno controlado, pero por un cliente.
Realizadas por el usuario con el desarrollador como observador en un entorno controlado
(simulación de un entorno de producción).
  Prueba Beta: Es una aplicación en vivo del software en un entorno que no puede ser controlado

por el desarrollador. Realizadas por el usuario en su entorno de trabajo y sin observadores

Pruebas de Sistema

 Pruebas de Recuperación: Fuerza el fallo del software de muchas formas y verifica que la
recuperación se lleva a cabo apropiadamente.
 Pruebas de Seguridad: Intenta verificar que los mecanismos de protección incorporados en el
sistema lo protegerán de accesos impropios por parte de piratas informáticos.
 Pruebas de Resistencia: Ejecuta un sistema de forma que demande recursos en cantidad,
frecuencia o volúmenes anormales.
 Pruebas de Rendimiento: Consisten en determinar que los tiempos de respuesta están dentro
de los intervalos establecidos en las especificaciones del sistema.

Niveles de Pruebas:

Medición:

Es el acto de determinar una medida

Por ejemplo:

El tester recopila la cantidad de defectos hallados en un módulo.

El programado recopila la cantidad de líneas de código de cada módulo del sistema.

Medida:

Proporciona una indicación cuantitativa de la extensión, cantidad, dimensiones, capacidad o tamaño de

algunos atributos de un proceso o producto.

Por ejemplo:

Número de defectos encontrados en un módulo.

Cantidad de líneas de código en un módulo.

Métrica:

Una medida cuantitativa del grado en que un sistema, componente o proceso posee un atributo dado
(IEEE Estándar Glossary of Software Engineering Terms)

Por ejemplo:

La productividad por tester fue de 3 errores/hora.

La productividad del proyecto fue de 500 LOC/persona-mes.

Indicador:

Un indicador es una métrica o una combinación de métricas que proporcionan una visión profunda del
proceso del software, del proyecto de software o del producto en sí.

Un ingeniero de software recopila mediadas y desarrolla métricas para obtener indicadores.

Métricas para mejora:

Reporte de pruebas:
 • Pruebas De Software: Realizo la Medición

• Recopilación de Datos: Obtengo Medidas

• Cálculo de las Métricas: Obtengo Métricas

• Evaluación de las Métricas: Obtengo Indicadores

Tiempo Medio entre Fallos (TMEF):

TMEF = TMDF +TMDR

Donde:

TMDF: Tiempo Medio de Fallo (Tiempo medio que le demora a una persona encontrar el origen del fallo)

TMDR: Tiempo Medio de Reparación (Tiempo medio que le demora una persona en arreglar el fallo)

Eficacia de la Eliminación de Defectos (EED):

EED = (DE) / (DE+ DV)

Donde:

DE: Defectos Eliminados

DV: Defectos Evadidos

Madurez de las Pruebas (MP):

MP = CPS / CPR

Donde:

CPS: Número de casos de pruebas que han obtenido un resultado satisfactorio.

CPR: Número de casos de pruebas a ejecutar requeridos para cubrir los requisitos.

Modelo V
Organización del Equipo

Gerente de
Proyecto

Gestor de
Calidad

Jefe de QA/QC

Analista de
Analista de Analista de
Control de
Aseguramiento Control
Cambios
SCRUM:

RUP:
Escenarios de Negocio:
Caso de Prueba:

Test Case (Caso de Prueba)

La definición de un caso de prueba incluye la siguiente información (IEEE Std 610):

 Precondiciones
 Conjunto de valores de entrada
 Conjunto de resultados esperados
 Forma en la cual se debe ejecutar el caso de prueba y verificación de resultados
 Postcondiciones
Test Base o Test Basis (Fundamentos de pruebas)

Conjunto de documentos que definen los requisitos de un componente o sistema utilizado como
referencia para el desarrollo de casos de prueba.

Code o Source Code (código fuente)

Programa de computadora escrito en un lenguaje de programación que puede ser

leído por una persona.

Debugging (Depuración)

Localización y corrección de defectos en el código fuente.

Software Development (Desarrollo de Software)

Es un proceso / secuencia de actividades cuyo objetivo es desarrollar un sistema basado en un

computador (ordenador).

Code o Source Code (código fuente)

Programa de computadora escrito en un lenguaje de programación que puede ser

leído por una persona.

Debugging (Depuración)
Localización y corrección de defectos en el código fuente.

Software Development (Desarrollo de Software)

Es un proceso / secuencia de actividades cuyo objetivo es desarrollar un sistema basado en un

computador (ordenador).

Requirement (Requisito)

Un requisito describe un atributo funcional o no funcional deseado o considerado

obligatorio.

Review (Revisión)

Evaluación de un producto o estado de un proyecto con el objeto de detectar discrepancias con

respecto a los resultados esperados (planificados) y para recomendar mejoras (lEEEStd 1028).

Test strategy (Estrategia de pruebas)

Descripción sucinta de los niveles de pruebas a realizar y las pruebas

asociadas a una organización o programa (uno o más proyectos).

Conformidad con el enfoque global, los esfuerzos requeridos para las pruebas se distribuyen entre los
deferentes objetos de prueba y objetivos de las pruebas:

• elección del método de prueba

• cómo y cuándo se ejecutarán las actividades asociadas a las pruebas

• cuándo se debe detener el proceso de pruebas (exit criteria).

Exit criteria (Criterio de salida) [Gilb and Graham]

Conjunto de condiciones genéricas y específicas, acordadas con los stakeholders, para permitir que un
proceso sea considerado formalmente finalizado. El propósito de los criterios de salida es evitar que una
tarea se considere finalizada habiendo partes importantes de la misma sin completar. Los criterios de
salida son utilizados como fuente para elaborar informes y planificar
le suspensión de las pruebas.

Test condition (Condición de Pruebas)

Un objeto u evento de un componente o sistema que debe verificado por uno o más casos de prueba.
Ejemplos: una función, transacción, característica, atributo de calidad o elemento estructural

Test Suite/ Test sequence

Conjunto de casos de prueba para un componente o sistema, donde la post condición de un caso de
prueba es utilizada como precondición pare el caso de
prueba siguiente.

Test procedure specification (especificación del procedimiento de pruebas) /

Test scenario (escenario de pruebas)
Documento en el cual se específica une secuencia de acciones para la ejecución
de una prueba. También es conocido como test script o manual test script [IEEE
Std 829].

Test execution (Ejecución de pruebas)

Es el proceso de ejecutar una prueba en un sistema o componente a probar, para

producir el resultado actual.

Test plan (Plan de pruebas)

Documento que describe el alcance, el enfoque, recursos y planificación de las

actividades previstas en el proceso de pruebas. Identifica, entre otros objetos de
prueba, las características a ser probadas, las tareas de pruebas, quién realizará
cada tarea, grado de independencia del tester, el ambiente de pruebas, las
técnicas de diseño de pruebas y los criterios de salida (exit criteria), y la
justificación racional de la elección. [IEEE 829]

Test data (Datos de prueba)

Datos que existen en el sistema antes de que una prueba sea ejecutada, y que
afecta o es afectado por los componentes o sistema sujeto a pruebas.

Input data (Datos de entrada)

Variable que es leída por un componente del sistema.

Inspección:

Las Inspecciones son un proceso bien definido y disciplinado donde un equipo de personas cualificadas
analiza un producto software usando una técnica de lectura con el propósito de detectar defectos.

• Escrutinio Sistemático por Colegas

 Verifica que el producto

 Cumpla con los requerimientos

 Cumpla con los atributos de calidad

 Se ajuste a las regulaciones, estándares y procedimientos definidos

 Identifica desviaciones con estándares y requerimientos

 Recolecta datos para mejorar el proceso

• Su propósito es detectar anomalías

• También se le conoce como “Revisión por Colegas” (Peer Review)

Proceso de Inspección:
 DETECCION DE CORRECCION Y
Preparar la LecturaDEFECTOS
Individual Compilado de SEGUIMIENTO
Corrección por el
Inspección Detección de faltas Autor
Proporcionar Faltas Discusión de Informe de
Información Grupo cambios

COLECCIÓN DE
INICIO
DEFECTOS

INICIO:

Planificación:

Se asignan roles a los participantes (máximo 5 participantes, mínimo 2)

Se preparan calendarios para reuniones

Se distribuye el Material a Inspeccionar

Lanzamiento (Opcional):

Primera reunión de explicación

DETENCIÓN DE DEFECTOS:

Es el corazón de la inspección.

Cada participante examina y entiende a solas el producto y busca defectos, documentándolos

COLECCIÓN DE DEFECTOS:

Compilación

La recolección de defectos debe ayudar a tomar la decisión sobre si es necesaria una reinspección.

Inspección en grupo

Análisis de flujo de datos

C-USE: Asignación

P-USE: Sentencia Condicional

d: definida

u: usada

k: destruida

~: no existe la variable

U: indefinida

D: definida pero no referenciada

R: definida y referenciada

dk: definida y luego destruida

~u: variable no existe y después se utiliza

Este es el estudio de las variables del programa

variable definida donde se almacena un valor en ella

variable utilizada en donde el valor almacenado se accede

variable no está definida antes de que sea definido o cuando se encuentra fuera de alcance
COMPLEJIDAD CICLOMATICA

Complejidad Ciclomatica(La complejidad de McCabe V (G))

La métrica de McCabe ha sido muy popular en el diseño de pruebas.

Es un indicador del número de caminos independientes que existen en un grafo.

• V (G) = a – n + 2 -> sentencia

• V (G) = r -> decisión

• V (G) = c + 1 -> camino

Donde

• a : # de arcos o aristas del grafo.

 • n : # de nodos.

• r : # de regiones cerradas del grafo.

• c : # de nodos de condición.

Beneficios:

 V (G) marca el límite mínimo de casos de prueba para un programa.

 Cuando V (G) >10 la probabilidad de defectos en el módulo o programa crece mucho entonces
quizás sea interesante dividir el módulo.

V&V ESTÁTICA

Es un conjunto de técnicas que buscan defectos sobre el sistema en reposo. Esto es, estudian los
distintos modelos que componen el sistema software buscando posibles defectos en los mismos. Así
pues, estas técnicas se pueden aplicar, tanto a requisitos como a modelos de análisis, diseño y
pseudocódigo.

Las técnicas de evaluación estática se aplican en el mismo orden en que se van generando los distintos
productos del desarrollo siguiendo una filosofía top- down.

La evaluación estática es el único modo

disponible de evaluación de artefactos para
las primeras fases del proceso de desarrollo
(análisis y diseño), cuando no existe código.
Las actividades de revisión marcan el punto de decisión para el paso a la siguiente actividad de
desarrollo.

Ventajas y Desventajas

 Efectivas en la detección temprana de defectos.

 Sirven para validar cualquier artefacto (requerimientos, diseño, pseudocódigo, casos de

prueba, etc).

 Potencia las capacidades de los participantes.

 Mejoran la comunicación entre los equipos.

x Sujeto a los errores de nuestro razonamiento.

x Normalmente basadas en un modelo del producto y no en el producto.

x Dependen de la especificación.

x No consideran el hardware o el software de base.

x Requieren más presupuesto por el tipo de recurso.

 La experiencia
demuestra que
entre el 30% y el
70% de los defectos,
de diseño y código
son

detectados por las

técnicas estáticas.

Cuando se esté evaluando estáticamente un producto de software, es importante que el evaluador tenga
en mente qué tipo de defectos está buscando y cuál sería el mejor “tipo de calidad” para ese producto.
Tipos de Defectos

Corrección: Los requerimientos especifican correctamente lo que el sistema debe hacer.

Compleción: Especificación completa del problema. Está especificado todo lo que tiene que hacer el
sistema. En dos palabras: no falta nada; no sobra nada

Consistencia: No hay requerimientos contradictorios.

Ambigüedad: Los requerimientos no pueden estar sujetos a interpretación.

claridad: Se entiende claramente lo que está especificado.

Corrección: Defectos de “escritura”, es decir, defectos en el uso de la notación de diseño empleada

Defectos con respecto a los requerimientos: el diseño no realiza lo que el requerimiento establece

Compleción: El diseño debe estar completo.

Consistencia: Al igual que en los requerimientos, el diseño debe ser consistente entre todas sus partes.

Factibilidad: El diseño debe ser realizable. Debe poderse implementar.

Trazabilidad: Se debe poder navegar desde un requerimiento hasta el fragmento de

diseño donde éste se encuentra representado.

Corrección: El código no debe contener errores.

Defectos de “escritura”:

Lo que habitualmente se conoce por “programa que no funciona”.

Por ejemplo, bucles infinitos, variable definida de un tipo, pero utilizada de otro, contador que se
sale de las dimensiones de un array, etc.

Defectos con respecto al diseño:

No realiza lo que el diseño establece.

Revisiones

 A las técnicas de Evaluación estática se las conoce de modo genérico por Revisiones.
 Las revisiones pretenden detectar manualmente defectos en cualquier producto del desarrollo.
 Manualmente significa que el producto en cuestión (sea requisito, diseño,
 código, etc.) está impreso en papel y los revisores están analizando ese artefacto mediante
técnicas de lectura, sin ejecutarlo.

 Las técnicas estáticas de pruebas comprenden varios métodos que no ejecutan el componente o
sistema objeto de la prueba.

 Las pruebas estáticas incluyen:

 Revisiones (“reviews”) ( actividad manual ).

  Análisis estático

 Las técnicas estáticas complementan los métodos dinámicos.

 Las pruebas estáticas detectan defectos en lugar de fallos.

 Los conceptos también son analizados, no sólo el código ejecutable.

 Los defectos / desviaciones son detectados en una fase temprana antes de que sean
implementadas en el código.

 Documentos de alta calidad conducen a productos de alta calidad.

 Incluso si una especificación revisada no contiene ningún defecto, la interpretación de la

especificación y creación del diseño pueden ser defectuosos

Objetivos de las revisiones:

 Las revisiones se realizan con el objeto de mejorar la calidad del producto.

 Las Revisiones se utilizan para verificar la correcta transición de una fase a la siguiente,
según está definido en el lado izquierdo del modelo “V”
 La detección temprana de errores ahorra costos.
 En el transcurso de las revisiones se podrían detectar los siguientes defectos:
 Defectos de las especificaciones
 Defectos en el diseño y en la arquitectura del software.
 Desviaciones con respecto a estándares acordados por ejemplo guías de programación).
 Defectos en las especificaciones de interfaces.
 Mantenibilidad insuficiente

Ventajas:

 Costos más bajos y un potencial de ahorro relativamente alto.

 Defectos en la documentación son detectados y corregidos temprano.
 Los documentos de alta calidad mejoran el proceso de desarrollo.
 Mejora el índice de comunicación / intercambio de conocimiento (“Know-how”)

Desventajas:

 Se podrían presentar situaciones de tensión en el caso de enfrentamientos directos con el autor.

 Los expertos involucrados en las revisiones deben adquirir conocimientos específicos del
producto, es necesario una buena preparación.
 Inversión considerable de tiempo (del 10% - 15% del presupuesto total)
 Moderador y participantes influyen directamente en la calidad de la revisión.

Fases de una Revisión:

 Fase de planificación
 Organización de la revisión, selección de los miembros de la revisión.
 Preparación de la organización e inicio (KICK-OFF”).
  Distribución de los objetivos de la revisión e información adicional.
 Preparación individual.
 Los evaluadores inspeccionarán los objetos, comentan los elementos en caso de
necesidad de aclaraciones.
 Reunión de revisión.
 Reunión de los miembros de la revisión, los evaluadores presentan sus resultados.
 Seguimiento (“follow up”)
 El resultado de la revisión es distribuido al responsable de la revisión estableciendo:
 Objeto sujeto a pruebas, participantes y roles.
 Recomendaciones realizadas por los evaluadores.

Roles:

Director – Responsable – Jefe de proyecto: Inicia la revisión, decide respecto de los participantes y
asigna recursos.

Moderador: Dirige la reunión / discusión, hace de mediador, concluye resultados.

Autor: Expone su trabajo a la crítica, lleva a cabo los cambios recomendados.

Evaluador (también: Inspector o revisor): Reunión de los miembros de la revisión, los evaluadores
presentan sus resultados.

Escriba (también escribano): Documenta todos los asuntos, problemas y putos que hubieran sido
identificados.

Tipos de revisión

Revisiones Formales: Los participantes son responsables de la fiabilidad de la evaluación, y generan un

informe que refleja el acto de la revisión. Por tanto, sólo consideramos aquí como técnica de evaluación
las revisiones formales, puesto que las informales podemos considerarlas un antepasado poco
evolucionado de esta misma técnica.

Ventajas y desventajas

 Sesiones formales y organizadas con roles claramente definidos.

 Requiere actividades intensivas de preparación y seguimiento.
 Son necesarios el moderador y el escriba.
 Propósito principal: detección de defectos utilizando un método estructurado.

Revisiones Informales

También llamadas inadecuadamente sólo Revisiones.

Las Revisiones Informales no dejan de ser un intercambio de opiniones entre los participantes.

Ventajas y desventajas

 Rentable
 No requiere protocolo
 Desventaja: No tiene un procedimiento formal
Walkthrough:

Es una revisión que consiste en simular la ejecución de casos de prueba para el programa que se está
evaluando. No existe traducción exacta en español y a menudo se usa el término en inglés. Quizás la
mejor traducción porque ilustra muy bien la idea es Recorrido. De hecho, con los walkthrough se recorre
el programa imitando lo que haría la computadora.

Ventajas y Desventajas

 Esfuerzo producido en la preparación de la sesión de revisión, pero es una sesión cuyo resultado
queda abierto.
 Una sesión puede ser iniciada a través de notificaciones realizadas con poca antelación.
 El autor tiene una gran influencia sobre el resultado dado que el mismo modera la revisión, hay
un riesgo de dominación por su parte.
 Posibilidad limitada de control, dado que el autor también se encuentra a cargo de cualquier
actividad de seguimiento

Auditorias

Las auditorias contrastan los artefactos generados durante el desarrollo con estándares, generales o de
la organización. Típicamente pretenden comprobar formatos de documentos, inclusión de toda la
información necesaria, etc. Es decir, no se tratan de comprobaciones técnicas, sino de gestión o
administración del proyecto.

Factores de Éxito

 Las revisiones se deben desarrollar orientados al logro de objetivos, es decir, las desviaciones en
el objeto revisado deben ser establecidos de forma imparcial.
 El autor del objeto revisado deberá ser motivado de una forma positiva por la revisión (“su
documento será aún mejor” en lugar de “su documento es de baja calidad”).
 Uso sistemático entre otros de las técnicas y plantillas implantadas.
 El uso de listas de comprobación mejorará la eficiencia de la revisión.
 Para la ejecución apropiada de las revisiones será necesario un presupuesto suficiente (10% al
15% del costo total del desarrollo)
 Hacer uso del efecto de las lecciones aprendidas, utilizar la retroalimentación para implementar
un proceso de mejora continua.
 Duración de una reunión de revisión: 2 horas máximo.

Partición equivalente
  dividir (partición) de las entradas, salidas, etc en zonas que son iguales (equivalentes)
 hipótesis: si un valor funciona, todo funciona
 una de cada partición mejor que todas de una

Ejemplo:

Aplicación toma números enteros de dos dígitos (A y B)

Suma el resultado de A + B

Posibles valores de A y B de -99 a 99.

Posibles combinaciones de pruebas son 199 x 199 = 39601.

No es posible ejecutar todas las pruebas posibles.

Debemos encontrar pruebas efectivas que representen al resto.

Variabl Partición Partición Casos límite y especiales Notas

e Equivalente Equivalente
- - Caso
Inválido
Caso Válido

A -99 a 99 > 99 99, 100

< -99 -99, -100

B -99 a 99 > 99 99, 100

< -99 -99, -100

Suma -198 a 198 > 198 (-99,-99) No se conoce como probar

partición de caso inválido
< -198 (-99,99)

(99,-99)

(99,99)
• fallas tienden a esconderse cerca de las fronteras

• buen lugar para buscar las faltas

• los valores de prueba en ambos lados de los límites