ANEXO U.T.

N°2
PRUEBAS ESTÁTICAS
 CONTROL DE CALIDAD DE VIDEOJUEGOS
ANEXO U.T. N°2: PRUEBAS ESTÁTICAS

Contenido
Pruebas estáticas .......................................................................................................................... 2
Introducción.............................................................................................................................. 2
Ventajas de una prueba estática.............................................................................................. 3
Desventajas de una prueba estática ........................................................................................ 4
¿En qué se diferencian con las pruebas dinámicas? ............................................................... 4
Defectos típicos en las pruebas estáticas ................................................................................ 4
Productos de trabajo .................................................................................................................... 5
Concepto ................................................................................................................................... 5
Productos de trabajo en las diferentes etapas ........................................................................ 5
De la planificación ................................................................................................................. 5
Del control y monitoreo ........................................................................................................ 5
Del diseño de pruebas ........................................................................................................... 6
De la implementación de pruebas ........................................................................................ 6
De la ejecución de pruebas ................................................................................................... 6
De la compleción de pruebas ................................................................................................ 6 1
Importancia de la trazabilidad entre las bases de prueba y los productos de trabajo .......... 6
Productos de trabajo que pueden ser evaluados por una prueba estática ........................... 7
Proceso de revisión....................................................................................................................... 7
Proceso de revisión de productos de trabajo .......................................................................... 7
Tipos de revisión ....................................................................................................................... 8
Revisiones formales de software .......................................................................................... 8
Revisiones informales de software ....................................................................................... 9
Otras revisiones de software ................................................................................................ 9
Aplicación de técnicas de revisión ......................................................................................... 10
Ad hoc.................................................................................................................................. 10
Basadas en listas de comprobación .................................................................................... 10
Basadas en escenarios y ensayos ........................................................................................ 10
Factores de éxito para las revisiones ..................................................................................... 11

DESARROLLO DE VIDEOJUEGOS
 CONTROL DE CALIDAD DE VIDEOJUEGOS
ANEXO U.T. N°2: PRUEBAS ESTÁTICAS

Pruebas estáticas
Introducción

A diferencia de las pruebas dinámicas, estas no requieren de la ejecución de software

para ser realizadas. Parte del objetivo de las pruebas estáticas es la revisión de productos de
trabajo como documentos de requerimientos, casos de prueba, planes de prueba, código, guías
de usuario.

Este tipo de pruebas se enfoca en la prevención de defectos y en la detección temprana

de dichos defectos, ya que se pueden efectuar en cualquier etapa del ciclo de vida del software,
dependiendo de la información que se tenga disponible. El objetivo de las pruebas estáticas es
verificar la calidad y estabilidad del código antes de pasar a las pruebas dinámicas.

Para el análisis estático hay muchas herramientas, y la mayoría de ellas se centran en el

código del software, suelen ser utilizadas por los desarrolladores antes y durante las pruebas de
componente e integración; y por los diseñadores durante el modelado de software.

Las herramientas de análisis estático muestran:

 Profundidad de anidamiento.
 Complejidad ciclomática: Número de caminos independientes que pueden ocurrir en
la ejecución, entre el inicio y el fin del software.
 Estándares de codificación.
 Flujos de control. 2
 Relaciones de datos.
 Número de rutas entre líneas de código.

El análisis estático es de vital importancia para softwares de seguridad crítica, como ser:
sistemas aeronáuticos, médicos, nucleares y bancarios.

Un análisis estático es aplicable mediante herramientas que evalúan los productos de

trabajo escritos en lenguaje natural (ej.: un corrector ortográfico). Algunas de las herramientas
más comunes en el análisis estático son la revisión de estándares de código, la revisión de las
métricas y de la estructura de código.

Los estándares de código hacen referencia a las formas de escribir el código dentro de un
marco de lenguaje común a todos los desarrolladores. Las métricas proporcionan información
sobre la cantidad de líneas de código, frecuencia de comentarios, complejidad de anidamiento
en las estructuras de control (condicionales o estructuras repetitivas). Esto se realiza tanto para
un sistema nuevo como para tareas de mantenimiento ya que permite entender si el sistema está
creciendo en tamaño, complejidad o ambos.

Respecto a la estructura de código, existen diferentes mediciones relacionadas al código

que indican qué tan complejo fue escribirlo, comprenderlo para modificarlo a futuro o probarlo.

 Flujo de control: Muestra el orden en que las instrucciones son ejecutadas. Mediante
este tipo de análisis se pueden ubicar defectos relacionados con secciones del código
muerto o inalcanzable.
 Flujo de datos: Permite analiza cómo mutan valores a lo largo de la vida de la
aplicación, como se acceden y se alteran a través del código las distintas variables;

DESARROLLO DE VIDEOJUEGOS
 CONTROL DE CALIDAD DE VIDEOJUEGOS
ANEXO U.T. N°2: PRUEBAS ESTÁTICAS

esto permite ubicar defectos relacionados a variables con valores indefinidos y

variables que nunca se usan.
 Estructura de datos: Muestra cómo se organizan los datos en sí mismos; no suele
tener relación con la estructura del código o con el flujo de control.

Una vez identificados los mecanismos para administrar los datos (colas, pilas, listas o
estructuras más complejas), se puede identificar la complejidad de los algoritmos necesarios para
lidiar con esas estructuras a nivel de programación, y así establecer su complejidad para
probarlas.

Ventajas de una prueba estática

La mayoría de los productos de software pueden ser evaluados por las pruebas
estáticas (revisiones), como por ejemplo las especificaciones de requerimientos del software
(funcionales, no funcionales), historias de usuario, criterios de aceptación, especificaciones de
diseño del software o el código. En resumen, se puede revisar cualquier producto de trabajo que
los interesados puedan leer y comprender para poder encontrar defectos.

Las ventajas de las pruebas estáticas son muy variadas, pero se puede destacar que no
solo el costo del desarrollo y las pruebas va a ser menor, también el costo de todo el proceso de
calidad del producto durante toda la vida útil, ya que se reduce la frecuencia de los fallos en
momentos posteriores a la entrada en producción, pero una ventaja que también es muy
importante y aunque suene simple permite encontrar defectos que no se pueden identificar
fácilmente con las pruebas dinámicas.

 Detección precoz de defectos: Detectar los defectos lo antes posible ahorra tiempo y 3
dinero. De hecho, cuando los errores de diseño, requisitos o codificación se dejan sin
comprobar, se propagan a etapas posteriores del SDLC y pueden llegar a ser muy
incómodos y caros de eliminar. Las pruebas estáticas ayudan a los equipos a detectar
errores en una fase temprana y evitar nuevos defectos.
 Reducción del tiempo y coste de las pruebas: Las pruebas estáticas ayudan a reducir
el tiempo y los costes de las pruebas. Al tener lugar antes de las pruebas dinámicas,
los problemas pueden descubrirse pronto, lo que reduce el tiempo y el dinero que
conlleva la reelaboración.
 Mejora de la calidad del código: Consiste en realizar revisiones del código. Al
centrarse en las normas y las mejores prácticas - no sólo en el rendimiento funcional
-, el código se vuelve más ágil, más inteligible y mucho más fácil de mantener. Este
enfoque fomenta un código coherente y bien estructurado, mucho más fácil de
modificar y editar en el futuro.
 Mejor comunicación: Las pruebas estáticas consisten en organizar revisiones y
debates para garantizar que el software está a un buen nivel. En estas reuniones
participan probadores, desarrolladores y partes interesadas, y son una oportunidad
para compartir conocimientos e información, lo que conduce a un equipo mejor
informado.
 Desarrollo más rápido: Dado que las pruebas estáticas promueven un enfoque más
proactivo tanto para la detección de defectos como para su corrección, los equipos
pueden ahorrar un tiempo valioso en la resolución de problemas, la reelaboración y
las pruebas de regresión. Puede dedicar este tiempo ahorrado a otras tareas, como
el desarrollo de nuevas características y funciones.

DESARROLLO DE VIDEOJUEGOS
 CONTROL DE CALIDAD DE VIDEOJUEGOS
ANEXO U.T. N°2: PRUEBAS ESTÁTICAS

Desventajas de una prueba estática

 Inversión de tiempo: Cuando se realizan correctamente, las pruebas estáticas pueden

ahorrar mucho tiempo a los equipos. Sin embargo, requiere una inversión de tiempo,
que puede ser especialmente onerosa cuando se hace manualmente para
construcciones de software complejas.
 Organización: Las pruebas estáticas son profundamente colaborativas. Programar
este tipo de pruebas requiere mucha coordinación, lo que puede resultar una tarea
ardua para equipos dispersos por todo el mundo y trabajadores muy ocupados.
 Alcance limitado: Hay un límite claro al número de defectos que se pueden detectar
mediante revisiones del código. Las pruebas estáticas se centran principalmente en
el código y la documentación, por lo que no descubrirán todos los errores que existen
en la aplicación. Además, no puede tener en cuenta factores externos, como
dependencias externas, problemas del entorno o comportamientos inesperados de
los usuarios.
 Dependencia de la intervención humana: Las pruebas estáticas manuales dependen
en gran medida de las habilidades y la experiencia de los probadores humanos. A
menos que el revisor humano tenga las habilidades, la experiencia y los
conocimientos adecuados, puede pasar por alto fácilmente defectos y errores, lo que
mitiga algunos de los beneficios de las pruebas estáticas.
 Calidad de la herramienta de análisis estático: La calidad de las herramientas de
pruebas estáticas es desigual. Algunos son muy buenos, mientras que otros generan
falsos positivos y negativos, lo que significa que es necesaria la intervención humana
para interpretar los resultados. 4
¿En qué se diferencian con las pruebas dinámicas?

Las pruebas dinámicas y estáticas pueden tener el mismo objetivo donde la meta es
asegurar la calidad del producto; si bien cada uno de estos tipos de prueba tiene un momento de
aplicación diferente, no se trata de tipos de prueba contrarios sino complementarios. Mientras
que la prueba estática se utiliza para mejorar la consistencia y calidad interna de los productos
de trabajo, la prueba dinámica se centra en los comportamientos visibles desde el exterior.

Una de las principales diferencias es que la prueba estática detecta defectos

directamente, en lugar de identificar fallos causados por defectos. Mientras que para sacar a la
luz un defecto mediante pruebas dinámicas puede implicar un proceso complejo para desarrollar
aquella prueba que lo provoque, la prueba estática puede ser capaz de encontrarlo con un
esfuerzo mucho menor.

PRUEBAS DINÁMICAS PRUEBAS ESTÁTICAS

En ejecución: Se realizan mientras el código
se ejecuta.
Detección: Se enfocan en encontrar defectos.
Pruebas tardías: Se realizan cuando el código
se lleva a un entorno de pruebas.
Técnicas: Funcionales y no funcionales.
Defectos típicos en las pruebas estáticas
No ejecución: Se realizan sobre productos de
trabajo.
Prevención: Se enfocan en evitar defectos.
Pruebas tempranas: Se pueden desarrollar
desde las primeras etapas del ciclo de vida.
Técnicas: Revisión técnica, inspección,
revisión de código.

DESARROLLO DE VIDEOJUEGOS
 CONTROL DE CALIDAD DE VIDEOJUEGOS
ANEXO U.T. N°2: PRUEBAS ESTÁTICAS

Hay ciertos defectos comunes dentro del desarrollo de un software que son mucho más
fáciles y económicos de detectar y corregir a través de este tipo de pruebas. A saber:

 Defectos en los requisitos en términos de inconsistencia o redundancia, entre otras

cosas.
 Defectos de diseño como algoritmos y estructuras de bases de datos ineficientes; alto
acoplamiento o baja cohesión.
o Acoplamiento: Concepto que se refiere a que cada módulo o funcionalidad
conoce poco o nada de los otros módulos o funciones.
o Cohesión: Hace referencia a que las funciones de un módulo guardan relación
entre ellas y mantienen un único enfoque.
 Defectos de codificación que pueden incluir variables mal consideradas o no
consideraras.
 Especificaciones de interfaz incorrecta como diferencias de unidad de medida entre
el sistema que realiza la llamada al sistema que la recibe.
 Vulnerabilidades de seguridad.
 Deficiencias o inexactitudes en la trazabilidad o cobertura de la base de prueba.

Adicionalmente, la mayoría de defectos de mantenibilidad sólo pueden detectarse

mediante pruebas estáticas (ejemplo: código difícil de analizar y modificar sin introducir nuevos
defectos).

Productos de trabajo
Concepto
5
Se denomina así a los diferentes elementos que pueden examinarse durante la ejecución
de pruebas estáticas.

Los productos de trabajo se crean como parte del proceso de prueba, y cada organización
varía la implementación del proceso de prueba por lo que también lo hace con los tipos de
productos de trabajo que se crean durante este proceso, cómo se organizan y gestionan.

Productos de trabajo en las diferentes etapas

De la planificación

En esta etapa se reciben las bases de prueba que serán la guía del proceso de pruebas y
permitirán definir los objetivos y la definición de hecho, y el producto de trabajo generado será
el plan de pruebas que se deberá seguir.

El plan de pruebas incluye información sobre la base de prueba con la que se relacionarán
los demás productos de trabajo de prueba, mediante la información de trazabilidad, así como los
criterios de salida que se utilizarán durante el monitoreo y control de prueba.

Del control y monitoreo

DESARROLLO DE VIDEOJUEGOS
 CONTROL DE CALIDAD DE VIDEOJUEGOS
ANEXO U.T. N°2: PRUEBAS ESTÁTICAS

Durante el monitoreo se compara el avance real con el plan, generando el reporte de

progreso o resumen de pruebas dependiendo de la etapa donde se encuentren las pruebas.

Se ejecutan reportes de progreso de manera regular y los de informes de resumen que se

producen durante hitos de compleción. Independientemente del tipo de informe deben contener
información relevante. Los productos de trabajo de esta etapa deben abordar inquietudes de la
gestión del proyecto como la compleción de tareas, asignación y uso de recursos y esfuerzo
requerido.

Del diseño de pruebas

Al momento del diseño, los productos de trabajo (documentos de requerimientos que

contienen las condiciones de prueba) sirven como base para generar escenarios o casos de
prueba de alto nivel, así como los conjuntos de casos de pruebas, para la creación de escenarios.

Los escenarios contienen la descripción del evento y el comportamiento esperado en el

software. También se los llama casos de prueba de alto nivel porque, aunque contienen la
descripción del evento y el resultado esperado, no contienen valores concretos para los datos de
entrada.

El diseño de pruebas también da lugar a la identificación de datos de prueba necesarios,

el diseño del entorno de pruebas, la infraestructura y las herramientas necesarias.

De la implementación de pruebas

Durante la implementación, los escenarios y casos de pruebas de alto nivel se

6
transforman en casos de prueba de bajo nivel llamados casos de prueba o procedimientos.

Un procedimiento define el elemento específico que afecta, la descripción de la acción,

el resultado esperado, y además indica el dato que se usará para afectar al elemento.

De la ejecución de pruebas

En esta etapa se pueden generar documentos sobre el estado individual de las pruebas:
casos listos, por ejecutar, rechazados, bloqueados, etc., defectos encontrados y herramientas
usadas durante la ejecución.

Los reportes permiten conocer el estado de los requisitos a partir de la trazabilidad

bidireccional con la base de prueba ya que cada documento generado tiene una huella que
permite encontrar su base de prueba. Así se pueden conocer los requisitos que han sido
probados, cuáles han fallado y qué defectos tienen asociados.

De la compleción de pruebas

Durante el cierre de pruebas se generan los reportes a los interesados en la prueba, que
permitirán tomar decisiones sobre si el producto está listo o no para su liberación, o las acciones
a tomar para mejorar el proyecto.

Importancia de la trazabilidad entre las bases de prueba y los productos de trabajo

DESARROLLO DE VIDEOJUEGOS
 CONTROL DE CALIDAD DE VIDEOJUEGOS
ANEXO U.T. N°2: PRUEBAS ESTÁTICAS

La trazabilidad es la posibilidad de rastrear la huella desde las bases de prueba hasta los
resultados de la ejecución del software; es decir, que cada requerimiento entregado siga su huella
hasta la solicitud que lo originó, y los productos de trabajo que se fueron generando en el
proceso. Esto permite evaluar la cobertura de la prueba.

Además de esto, una buena trazabilidad admite:

 Analizar el impacto de los cambios, qué secciones de la solución en desarrollo se

verán afectadas por el ajuste propuesto.
 Pruebas auditables: Significa poder comparar lo esperado con lo obtenido.
 Cumplir con los criterios estándar ya que, si bien todas las compañías tienen
parámetros particulares, apegarse a ellos genera confianza y credibilidad en el
trabajo realizado.
 Mejorar la comprensión de los informes de progreso de la prueba y los informes
resumidos de la prueba para incluir el estado de los elementos de base de prueba.
 Relacionar lo técnico de las pruebas con los interesados para que lo puedan
entender.
 Proporcionar información para evaluar la calidad del producto, la capacidad del
proceso y el progreso del proyecto contra objetivos de negocio.

Productos de trabajo que pueden ser evaluados por una prueba estática

 Especificaciones y requisitos: de negocio, funcionales, de seguridad.

 Épicas, historias de usuarios.
 Especificaciones de arquitectura y diseño.
7
 Código.
 Planes y casos de prueba.
 Guías de usuario.
 Páginas web.
 Contratos, calendarios, presupuestos.

Proceso de revisión
Las revisiones de software son exámenes sistemáticos de artefactos de software, como
código, diseño, documentación, casos de prueba o comentarios de los usuarios, para identificar
y resolver defectos, mejorar el rendimiento, mejorar la usabilidad y verificar el cumplimiento de
estándares y especificaciones. Las revisiones de software se pueden realizar en cualquier etapa
de SDLC, pero son especialmente importantes en las fases de prueba e implementación, donde
los errores y defectos pueden tener graves consecuencias

Proceso de revisión de productos de trabajo

 Planificar: Incluye la definición del alcance, del objetivo de la revisión, estimación de

esfuerzos, elección de recursos.
 Iniciar revisión: Distribución del producto de trabajo, explicar el alcance a los
colaboradores y responder consultas para que se pueda llevar a cabo la tarea.
 Revisión individual: Revisión del producto de trabajo y notificar posibles defectos o
mejoras.

DESARROLLO DE VIDEOJUEGOS
 CONTROL DE CALIDAD DE VIDEOJUEGOS
ANEXO U.T. N°2: PRUEBAS ESTÁTICAS

 Comunicar y analizar cuestiones: Comunicar defectos potenciales, analizar los defectos,

evaluar y documentar las características de calidad y evaluar esos resultados respecto al
objetivo para determinar si se acepta o rechaza dicho resultado.
 Corregir e informar: Elaboración de informes, corrección de defectos en el producto de
trabajo, registrar el estado actualizado de defectos y recopilación de métricas (en
procesos más formales), comprobar el cumplimiento de los criterios de salida y aceptar
el producto de trabajo cuando alcanza el objetivo.

Tipos de revisión

Las revisiones de software se pueden clasificar en dos categorías principales: formales e

informales.

Revisiones formales de software

Las revisiones formales de software son procesos estructurados y documentados que

siguen reglas, procedimientos y roles predefinidos. Involucran a un equipo de revisores que
inspeccionan, analizan y evalúan los artefactos de software según criterios y objetivos específicos.
Este tipo de revisión se puede dividir en dos tipos:

 Inspecciones: Revisiones rigurosas y detalladas que se centran en encontrar y corregir

defectos en los artefactos de software.
 Tutoriales: Revisiones menos formales y más colaborativas que tienen como objetivo
mejorar la comprensión y la comunicación de los artefactos de software entre los
miembros del equipo y las partes interesadas.
8
La inspección es la técnica de revisión más formal; se basa en el examen visual de
documentos para detectar defectos como ser el no cumplimiento de estándares.

El propósito de la inspección es detectar e identificar anomalías en el producto de

software, incluyendo errores y desviaciones de estándares y especificaciones. Es un proceso
formal en el cual se definen los roles de cada uno de los participantes en donde un moderador
entrenado se encarga de llevar la sesión presencial.

En general, el tamaño del producto que se revisa es pequeño y el equipo de revisión debe
usar estándares y/o listas de chequeo para verificar el producto. La inspección tiene tres etapas,
pre-revisión, revisión, post-revisión.

En la etapa de pre-revisión, los revisores analizan de forma individual el producto, durante

la revisión, moderador, autor del producto y revisores se reúnen para discutir los hallazgos de
cada uno de los revisores. El valor de esta reunión es encontrar otros defectos por el efecto
sinérgico de las interacciones que se establecen entre los revisores. Al final de la reunión se
obtiene una lista de errores que deberían ser atendidos por el autor del producto bajo revisión.
En la etapa de post-revisión, el moderador verifica que el autor haya corregido el producto.

Roles y responsabilidades en una revisión formal

En una revisión formal, se incluyen los siguientes roles, cuyas responsabilidades varían
dependiendo del rol:
 Autor: Crea y corrige los defectos del producto bajo revisión.

DESARROLLO DE VIDEOJUEGOS
 CONTROL DE CALIDAD DE VIDEOJUEGOS
ANEXO U.T. N°2: PRUEBAS ESTÁTICAS

 Dirección: Planifica, decide acerca de la ejecución de revisiones, asigna recursos y

tiempo, supervisa la rentabilidad y ejecuta las decisiones.
 Facilitador: Asegura el funcionamiento efectivo de las reuniones, media entre los
puntos de vista y de él depende el éxito de la revisión.
 Líder de revisión: Tiene la responsabilidad de la revisión, decide los implicados, el
cómo y el cuándo.
 Revisores: Identifican los defectos en los productos de trabajo bajo revisión. Pueden
tener distintos perfiles y perspectivas.
 Escriba: Recopila los defectos encontrados durante la revisión individual y registra los
puntos revisados en la reunión (nuevos defectos, puntos abiertos y decisiones).

Revisiones informales de software

Las revisiones informales se caracterizan por no tener documentado un proceso, el

objetivo de la reunión no está centrado en la detección de faltas y en general, se realizan de
manera improvisada. Por tanto, es difícil determinar su efectividad, en términos de la cantidad
de defectos encontrados. Normalmente este tipo de revisiones se lleva a cabo por parte del líder
técnico de los diseños y del código. El objetivo principal es obtener defectos de forma económica.

Son procesos menos rígidos y más flexibles que no siguen un protocolo o documentación
estrictos. Involucran a un grupo más pequeño de revisores que verifican, prueban y discuten los
artefactos de software sin una agenda o resultado predefinido. Las revisiones informales de
software se pueden dividir en dos tipos:

 Revisiones por pares: Revisiones informales y voluntarias que implican el intercambio de

comentarios y sugerencias entre los pares que trabajan en los mismos artefactos de 9
software o en artefactos de software relacionados.
 Revisiones de usuarios: Revisiones informales y espontáneas que implican la recopilación
y el análisis de comentarios y opiniones de los usuarios finales o clientes que utilizan el
software.

Otras revisiones de software

Revisión técnica

Estas revisiones pueden variar desde muy formal a muy informal. Los objetivos son
debatir, tomar decisiones, evaluar alternativas, resolver problemas técnicos, comprobar la
conformidad con las especificaciones, estándares y normativas, y se centrarán en alcanzar un
consenso. Es un proceso documentado donde se realizará un informe de revisión.

Revisión guiada

También van de lo muy formal a lo muy informal, y son llevadas a cabo por el autor del
documento del proyecto; el objetivo principal es encontrar defectos y establecer un
entendimiento común.

Revisión de código

Es una medida de garantía de calidad en el desarrollo de software. El código fuente es el

medio básico del trabajo de desarrollo y el producto principal de la programación. El código recién

DESARROLLO DE VIDEOJUEGOS
 CONTROL DE CALIDAD DE VIDEOJUEGOS
ANEXO U.T. N°2: PRUEBAS ESTÁTICAS

creado o modificado se somete a una revisión del código. En este proceso, uno o varios miembros
del equipo repasan el trabajo de un programador.

Los revisores leen el código e identifican posibles errores y desviaciones de las

convenciones establecidas en el equipo. Los revisores mejoran el código a posteriori o transmiten
sus conclusiones a los autores originales que incorporan los cambios.

Aplicación de técnicas de revisión

Ad hoc

En la técnica de lectura Ad-hoc, el producto software se entrega a los inspectores sin

ninguna indicación o guía sobre cómo proceder con el producto ni qué buscar. Por eso se
denomina también cómo “Lectura sin Checklists”. Sin embargo, que los participantes no cuenten
con guías de qué buscar no significa que no escudriñen sistemáticamente el producto
inspeccionado, ni tampoco que no tengan en mente el tipo de defecto que están buscando.

El término "ad-hoc" sólo se refiere al hecho de no proporcionar apoyo a los inspectores.

En este caso la detección de los defectos depende completamente de las habilidades,
conocimientos y experiencia del inspector. Típicamente, el inspector deberá buscar
secuencialmente los defectos típicos del producto que esté leyendo (y que hemos indicado más
arriba). Por ejemplo, si se está inspeccionando unos requisitos, el inspector, buscará sistemática
y secuencialmente defectos de corrección, de completitud, de ambigüedad, etc.

Basadas en listas de comprobación

10
Proporciona un apoyo mayor mediante preguntas que los inspectores deben de
responder mientras leen el artefacto. Es decir, esta técnica proporciona listas que ayudan al
inspector a saber qué tipo de faltas buscar. Aunque una lista supone más ayuda que nada, esta
técnica presenta la debilidad de que las preguntas proporcionan poco apoyo para ayudar a un
inspector a entender el artefacto inspeccionado. Además, las preguntas son a menudo generales
y no suficientemente adaptadas a un entorno de desarrollo particular. Finalmente, las preguntas
en una lista de comprobación están limitadas a la detección de defectos de un tipo determinado,
típicamente de corrección, puesto que las listas establecen errores universales (independientes
del contexto y el problema).

Basadas en escenarios y ensayos

La Lectura basada en escenarios proporciona guías al inspector (escenarios que pueden

ser preguntas, pero también alguna descripción más detallada) sobre cómo realizar el examen
del artefacto. Principalmente, un escenario limita la atención de un inspector en la detección de
defectos particulares definidos por la guía. Dado que inspectores diferentes pueden usar
escenarios distintos, y como cada escenario se centra en diferentes tipos de defectos, se espera
que el equipo de inspección resulte más efectivo en su globalidad. Existen dos técnicas de lectura
basada en escenarios:

 Lectura basada en defectos: Focaliza cada inspector en una clase distinta de defecto
mientras inspecciona un documento de requisitos. Contestar a las preguntas planteadas
en el escenario ayuda al inspector a encontrar defectos de determinado tipo.

DESARROLLO DE VIDEOJUEGOS
 CONTROL DE CALIDAD DE VIDEOJUEGOS
ANEXO U.T. N°2: PRUEBAS ESTÁTICAS

 Lectura basada en perspectiva: Establece que un producto software debería

inspeccionarse bajo las perspectivas de los distintos participantes en un proyecto de
desarrollo. Las perspectivas dependen del papel que los distintos participantes tienen en
el proyecto. Para cada perspectiva se definen uno o varios escenarios consistentes en
actividades repetibles que un inspector debe realizar y preguntas que el inspector debe
responder.

Factores de éxito para las revisiones

Algunos consejos útiles para realizar un proceso de prueba estático son:

 Concentrarse sólo en los asuntos que importan, los problemas secundarios ralentizan el
proceso.
 Planificar y evaluar las actividades de revisión de forma explícita. El código del programa
y las inspecciones de entregables generalmente se componen de revisiones por pares.
 Capacitar a los participantes para sus tareas.
 Mantener el proceso tan formal como la cultura del proyecto.
 Mejorar el proceso de revisión y las herramientas constantemente.
 Eliminar los retrasos importantes en la ejecución de la prueba para reducir los costos de
prueba y el tiempo de prueba.

11

DESARROLLO DE VIDEOJUEGOS