Fundamentos de Pruebas de Software - Capítulo 3

Capítulo 3
Técnicas Estáticas
“Nada ocurre porque si. Todo en la vida es una sucesión de hechos que, bajo la lupa del análisis,
responden perfectamente a causa y efecto”
Richard Feynmann, premio nobel de física acerca de la electrodinámica cuántica.

El capítulo 3, Técnicas Estáticas, contiene las siguientes 3 secciones:

1. Técnicas estáticas y el proceso de pruebas.
2. Proceso de revisión.
3. Análisis estático por medio de herramientas.

Cada una de las secciones estará desglosada en dos o más partes.

3.1 Técnicas Estáticas y el Proceso de Pruebas
Objetivos del Aprendizaje
LO-3.1.1 Reconocer los productos del trabajo del software que pueden ser examinados por
las diferentes técnicas estáticas. (K1)
LO-3.1.2 Describir la importancia y el valor de considerar las técnicas estáticas para la
evaluación de los productos del trabajo del software. (K2)
LO-3.1.3 Explicar las diferencias entre las técnicas estáticas y dinámicas, considerando
los objetivos, los tipos de defectos que deben ser identificados y el rol de estas técnicas en
el ciclo de vida del software. (K2)
Esta sección, Técnicas Estáticas y el Proceso de Pruebas, cubrirá los siguientes conceptos
clave:

Productos del trabajo del software y técnicas estáticas.
Importancia y valor de las técnicas estáticas.
Diferencia entre las técnicas estáticas y dinámicas.
Objetivos del análisis estático y las revisiones y la comparación del objetivo

con las pruebas dinámicas.
Las pruebas estáticas son aquellas pruebas donde el ítem sometido a pruebas—el objeto de
prueba— no tiene que ser ejecutado (o debe funcionar).

Glosario del ISTQB
Pruebas dinámicas: Pruebas que involucran la ejecución del software de un componente o
sistema.
Pruebas estáticas: Pruebas de un componente o sistema en un nivel de la especificación o
implementación sin la ejecución de ese software, p.ej. las revisiones o el análisis estático.
Análisis estático: Análisis de los artefactos del software, p.ej., los requisitos o el código
llevados a cabo sin la ejecución de estos artefactos del desarrollo de software. El análisis
estático es usualmente llevado a cabo por una herramienta.
Esto puede involucrar la utilización de las revisiones y las herramientas. Ahora, las
revisiones, las cuales pueden ir de informales a muy formales, serán cubiertas en detalle en
breve. Hay también varias herramientas que pueden realizar algunos tipos de pruebas
estáticas, así como la comprobación de la conformidad con los estándares de codificación.
Se pueden utilizar las pruebas estáticas para los requisitos y los diseños, lo cual es
bastante típico. También se pueden—y se deberían— utilizar para el código, los esquemas
de las bases de datos, la documentación, las pruebas y cualquier otro producto de trabajo
que haya sido escrito.
Una forma de pruebas estáticas es la utilización de modelos y prototipos. Un diagrama de
un sistema complejo puede revelar con frecuencia problemas de diseño que pueden
esconderse en las palabras. Un diagrama de diseño deforme significa a menudo muchos
defectos.
En un proyecto de hace algunos años, utilizamos las pruebas estáticas de los modelos del
diseño para comprobar si habían problemas potenciales de rendimiento. Las pruebas
estáticas incluían un modelo descrito en una hoja de cálculo acerca de la utilización de los
recursos en distintos niveles de carga. También incluían un modelo de simulación
ejecutable de la utilización de de los recursos del sistema. Esto previno una gran cantidad
de defectos que de otro modo se habrían descubierto durante la prueba de sistema.
Usted también debería considerar a la creación de casos de prueba y datos de prueba como
una forma de pruebas estáticas.
El análisis y el diseño de las pruebas basados en las especificaciones de los requisitos y el
diseño son una forma de revisión estructurada, y estos procesos de análisis y diseño de
pruebas revelan a menudo el problema. Este ejemplo de las pruebas es considerado como

una actividad de la prevención de defectos.
Hablando acerca de las herramientas para las pruebas estáticas, tenemos diversas formas
del análisis estático que podemos realizar. Una de estas formas es la comprobación de la
ortografía, la gramática y la dificultad de lectura que se pueden realizar contra los
documentos. Por ejemplo, Word incluye la capacidad para detectar los errores de
ortografía, los problemas de gramática y los pasajes de lectura difíciles, los cuales pueden
ser útiles para las especificaciones de los requisitos y el diseño.
Al observar el código fuente, podemos utilizar herramientas para comprobar los
constructos peligrosos de programación. Estas herramientas son por ejemplo J-Test, Safer
C, lint y otras. También podemos utilizar las herramientas de código abierto y las
comerciales para medir el código en cuanto a los asuntos del análisis de la complejidad, la
cual será explicada más adelante en este libro.

Glosario del ISTQB
Complejidad: El grado en que un componente o sistema tiene un diseño y/o una estructura
interna que es difícil de entender, mantener y verificar. Véase también la complejidad
ciclomática.
Las herramientas de análisis estático también contienen las simulaciones de sistemas. Hay
un programa llamado General Purpose System Simulator, el cual ha estado en uso durante
décadas que puede simular componentes básicos de un sistema, como las colas y los
recursos. Como se mencionó antes, existen herramientas de modelado de rendimiento e
investigación de operaciones que pueden predecir el comportamiento del sistema sometido
a carga. Incluso podemos utilizar herramientas simples como las hojas de cálculo para
simular el comportamiento del sistema, especialmente para el rendimiento, pero también
para la funcionalidad.
Empecemos con la técnica manual de las revisiones. Las revisiones deberían ser utilizadas
para cada producto valioso del trabajo del proyecto, en un algún nivel de formalidad u
otro.
Lamentablemente, las revisiones no se aproximan a la clase de utilización y atención que se
merecen. Esto es debido a la separación de los costos de las revisiones y sus beneficios.
El costo de las revisiones consiste en tres tipos principales. Primero, si vamos a tener una
revisión, se necesita el tiempo necesario para realizar las revisiones. Con frecuencia, la
preocupación aquí no es tanto el esfuerzo como la duración. Segundo, si estamos
realizando una revisión formal, necesitamos el esfuerzo necesario para recopilar y analizar
las métricas. Tercero, cuando las revisiones son utilizadas para producir valiosas métricas,
esas métricas deberán ser analizadas— con algún esfuerzo — para realizar mejoras en el
proceso. Estos costos no son insignificantes, pero estos producen beneficios serios más

tarde en el proyecto.

Glosario del ISTQB
Revisión formal: Una revisión caracterizada por procedimientos y requisitos
documentados, p.ej. La inspección.
Métrica: Una escala de medición y el método utilizado para la medición.
Estos beneficios incluyen cuatro tipos principales. El primero y quizás el más convincente,
es el beneficio de cronogramas más cortos. Dado que los defectos serán eliminados antes
con un menor esfuerzo (como se mostró en un capítulo anterior, debemos ahorrar tiempo).
Segundo, debido a que menos defectos entrarán en las fases de pruebas, deberíamos
observar períodos de pruebas más cortos y menos costosos en las pruebas. Tercero,
porque el reproceso es siempre una forma de pérdida— y porque la corrección de defectos
es más fácil cuando encontramos los defectos, en lugar de los síntomas, como es el caso
durante las revisiones — deberíamos observar la productividad mejorada del
desarrollador. Finalmente, como se mostró nuevamente en un capítulo anterior, deberíamos
ver la calidad mejorada del producto, lo cual reducirá los costos indirectos, tanto en el
desarrollo como después de las versiones.
En definitiva, las revisiones de todos los tipos son técnicas probadas, de alto retorno para
mejorar la calidad. David Rico, en sus estudios acerca de las organizaciones del
Departamento de Defensa de los Estados Unidos, encontró que las revisiones tienen un
retorno de la inversión que está siempre por encima de 10-a-1; es decir, 1.000%.
Observemos ahora las similitudes y las diferencias entre las pruebas estáticas y dinámicas.
Recuerde que las pruebas estáticas son las pruebas donde el ítem sometido a pruebas—el
objeto de pruebas— no es ejecutado, mientras que las pruebas dinámicas son las pruebas
donde el ítem sometido a pruebas—el objeto de pruebas—es ejecutado.
Generalmente, tanto las pruebas dinámicas como las estáticas buscan identificar defectos,
como uno de los principales objetivos. Ambas funcionan mejor cuando una amplia gama de
interesados del negocio están involucrados. Recuerde nuestra descripción anterior acerca
de las pruebas dominantes. Y también, ambas ahorran tiempo y dinero a la compañía, como
fue demostrado en un capítulo anterior cuando hablamos acerca de s los beneficios de las
pruebas tempranas y el aseguramiento temprano de la calidad.
Entonces ¿Cuáles son las diferencias? Bueno, por un lado cada técnica puede encontrar
diferentes tipos de defectos de manera más efectiva y eficiente. Por ejemplo, ciertos tipos
de cuestiones de la mantenibilidad son más fáciles de encontrar en las revisiones y los
análisis estáticos. Por otra parte, las técnicas estáticas encuentran más bien defectos que
fallas. En otras palabras, si realizamos una revisión y encontramos una suposición

equivocada acerca del comportamiento sometido a carga, estamos examinando
directamente la suposición equivocada, no el comportamiento incorrecto que ocurriría.

3.1.1 Ejercicios
Ejercicio 1
¿Considera usted las revisiones y el análisis estático útiles en el proyecto Omninet?
Si es así, ¿Cuáles tipos de problemas cree usted que estas revisiones y el análisis estático
localizarían?
¿Cuáles tipos de problemas no podrían localizar?
Argumente.

Solución del Ejercicio 1
Definitivamente utilizaríamos las revisiones y el análisis estático en el proyecto Omninet.
Quisiéramos ver las revisiones de los requisitos, el diseño y el código, así como también
el análisis de las pruebas, los casos de prueba, el plan de pruebas y los resultados de las
pruebas. Impondríamos los análisis estáticos en el código de Omninet. En el caso de
Omninet, el código no solo incluye programas acerca de los servidores del centro de datos
y el centro de llamadas, sino también HTML y otros entregables acerca de los clientes del
centro de llamadas y los quioscos.
Las revisiones encuentran típicamente las ambigüedades, las incompletitudes y los
conflictos. Los análisis estáticos encuentran código descuidado, no estándar, peligroso e
inalcanzable. Sin embargo, las revisiones y el análisis estático, mientras son bastante
efectivos, eliminan típicamente el 65% o menos de los defectos presentes en el ítem
revisado o analizado.20 Dado que cientos o incluso miles de defectos podrían existir en un
sistema tan complejo como Omninet, las revisiones y los análisis estáticos deben ser
ampliados con las pruebas dinámicas en los niveles de componente, integración, sistema y
aceptación.

3.2 Proceso de Revisión
LO-3.2.1 Recordar las actividades, los roles y las responsabilidades de una revisión
formal típica. (K1)

LO-3.2.2 Explicar las diferencias entre los diferentes tipos de revisión: revisión informal,
revisión técnica, revisión guiada (“Walkthrough”) e inspección. (K2)
LO-3.2.3 Explicar los factores para el desempeño exitoso de las revisiones. (K2)

Glosario del ISTQB
Revisión informal: Una revisión que no se basa en un procedimiento formal
(documentado).
Inspección: Un tipo de revisión por pares que se basa en la revisión visual de documentos
para detectar defectos, p.ej., las violaciones de los estándares de desarrollo y la
disconformidad con la documentación de nivel superior. La técnica de revisión más formal
y además basada siempre en un procedimiento documentado. Véase también la revisión por
pares.
Revisión técnica: Una actividad de debate de grupo por pares que se enfoca en lograr un
consenso acerca del método técnico que deba tomarse. Véase también la revisión por
pares.
Revisión guiada (“Walkthrough”): Una presentación paso a paso por el autor de un
documento con el fin de reunir información y establecer un entendimiento común de su
contenido. Véase también revisión por pares.
Esta sección, Proceso de revisión, cubrirá los siguientes conceptos clave.

Fases, roles y responsabilidades de una revisión formal típica.
Diferencias entre los diferentes tipos de revisiones.
Factores para las revisiones exitosas.
Hay varios tipos de revisiones de diversos niveles de formalidad.
Hay revisiones informales. Éstas no siguen un proceso real e incluyen charlas de pasillos,
pruebas de pares, programación de pares y líderes técnicos que revisan los diseños y el
código. Éstas pueden que tengan los resultados documentados, pero el nivel de detalle en
el documento es típicamente bajo. Tienen una efectividad limitada en la eliminación de los
defectos, pero son útiles, económicas y populares.
La efectividad depende mucho del empleo de revisores idóneos. El propósito principal es
de proporcionar una forma económica para conseguir algún beneficio.

Glosario del ISTQB

Revisor: La persona involucrada en la revisión que identifica y describe las anomalías en
el producto o proyecto sometido a revisión. Los revisores pueden ser elegidos para
representar los diferentes puntos de vista y los roles en el proceso de revisión.
Hay revisiones técnicas. Éstas tienen un proceso documentado y definido de la eliminación
de los defectos. Debería involucrar a sus compañeros y técnicos expertos. Si el proceso no
involucra jefes, entonces es una revisión entre pares. Típicamente los jefes no asistirían si
no pueden contribuir técnicamente. Si el jefe puede contribuir técnicamente, entonces el
proceso debería ser establecido de manera que el jefe no utilice los hallazgos de la
revisión para premiar o sancionar al autor o los participantes de la revisión. Las revisiones
técnicas son idealmente conducidas por un moderador entrenado quien no es el autor,
aunque esto no es necesario para una revisión técnica. La preparación de una pre-reunión
por los revisores es normalmente necesaria. Las listas de comprobación, las cuales son
específicas para el tipo del ítem que está siendo revisado, son recomendadas pero no
necesarias durante la preparación y la revisión misma. La revisión debería resultar en un
informe de revisión que incluye la lista de los hallazgos, el veredicto si el producto de
software cumple con sus requisitos y si es apropiado, y sus recomendaciones relacionadas
con los hallazgos. En la práctica, éstas varían de bastante informal a muy formal. Los
propósitos principales de una revisión técnica son el debate, la toma de decisiones, la
evaluación de alternativas, el hallazgo de defectos, la solución de problemas técnicos y la
comprobación de la conformidad con las especificaciones, los planes, las regulaciones y
los estándares. Una revisión guiada es un tipo especial de revisión técnica donde el orden
del día es el ítem sometido a la revisión. El autor guía la revisión del ítem de revisión.
Esto puede incluir los escenarios, los ensayos y la participación de grupos de compañeros.
Las revisiones guiadas pueden ser abiertas sin límites determinados. Tanto la preparación
de la pre-reunión de los revisores como la entrega de un informe de la revisión incluyendo
los hallazgos, son opcionales para las revisiones guiadas. Si un informe tiene que ser
entregado, entonces debería haber un escribano o un registrador, quien no es el autor
idealmente.
Como con las revisiones técnicas, en la práctica, éstas varían de bastante informal a muy
formal. Los propósitos principales de una revisión guiada son aprender, ganar la
comprensión y encontrar los defectos.

Glosario del ISTQB
Moderador o líder de la inspección: El líder y la persona principal responsable para una
inspección u otro proceso de revisión. Tenga en cuenta que el término “líder de la
inspección” no está definido en el Glosario ISTQB, pero su utilización en El Programa de
Estudios del ISTQB Nivel Básico implica que es un sinónimo.
Revisión por pares: Una revisión de un producto del trabajo del software por colegas del

productor del producto con el propósito de identificar los defectos y las mejoras. Ejemplos
son la inspección, la revisión técnica y la revisión guiada (“Walkthrough”).
Escribano: La persona quien registra cada defecto mencionado y alguna sugerencia para la
mejora del proceso durante una reunión de revisión, en un formulario de registro. El
escribano debería que garantizar que el formulario de registro sea legible y comprensible.
Una inspección es el método más formal. En este método, un moderador entrenado, quien
no puede ser el autor, lidera el equipo de inspección. Los compañeros son seleccionados
cuidadosamente para formar el equipo de revisión. Cada miembro del equipo de revisión
tiene roles definidos, basados en su experticia particular. Un proceso formal de inspección
es utilizado, el cual tiene reglas, listas de comprobación, criterios de entrada y salida. El
proceso incluye también la recopilación de las métricas de la eliminación de los defectos.
La preparación de la pre-reunión puede ser llevada a cabo, como descrita para la revisión
técnica, pero para las inspecciones esta preparación es obligatoria. Hay un proceso de
seguimiento formal, incluyendo los elementos opcionales del mejoramiento del proceso. A
veces se da el caso de que un lector especialmente entrenado es incorporado. El propósito
principal de una inspección es de encontrar defectos—de hecho encontrar a casi todos de
ellos.
Note que un método informal valora más la velocidad que la efectividad en la eliminación
de los defectos, mientras que una revisión formal valora la efectividad de la eliminación
de defectos. De acuerdo a los estudios de Capers Jones, las técnicas informales tienden a
alcanzar una efectividad de la eliminación de los defectos cerca del 25%, mientras que las
inspecciones formales pueden alcanzar una efectividad de la eliminación de los defectos
de hasta un 90%.
Ahora, cuando las revisiones guiadas, las revisiones técnicas o las inspecciones son
realizadas por un grupo de pares, la revisión puede llamarse una revisión por pares.
En nuestros proyectos, los consultores de RBCS/Business Innovations tienen una regla
simple: Dos pares de ojos. Esto significa que, para cualquier producto del trabajo que sea
importante, más de una persona lo examina antes de que se considere como terminado. Esto
podría implicar una revisión informal para los informes de los defectos o una revisión
formal para los casos de prueba, pero confiamos en el método de revisión para todo.
Un par de puntos tienen que ser adicionados aquí. Primero, cualquier producto de software
o producto relacionado con el trabajo puede ser revisado. No sólo revise el código, los
requisitos y las especificaciones del diseño. Revise todos los productos importantes del
trabajo. Segundo, note que cualquier ítem el cual es revisado puede estar sujeto a más de
una revisión. Usted puede realizar estas revisiones en cualquier orden que tenga sentido.
Por ejemplo, usted puede realizar una revisión informal de una especificación del diseño
antes de una revisión técnica de la especificación del diseño. Usted puede realizar una
inspección de una especificación de requisitos antes de una revisión guiada con los
clientes.

Figura 3.1: Consenso y Entendimiento
Además de encontrar y eliminar los defectos, las revisiones pueden ayudar en el consenso
y el entendimiento. La incompletitud y la ambigüedad pueden ocultar el verdadero
significado de las especificaciones y una revisión puede revelar el significado. Podemos
utilizar una revisión para alcanzar un acuerdo y entendimiento uniforme de las
especificaciones.
Por ello, todos deben entender este objetivo. Una vez hicimos una evaluación donde la
gente mencionó que si bien todos los requisitos del trabajo y las especificaciones del
diseño pasaron por una revisión, algunas veces fueron realizadas después de que el código
había sido escrito. Algunos participantes de la evaluación dudaron del valor de la revisión.
Cuando mencionamos esto a los interesados de la evaluación, ellos dijeron, “Bueno, la
gente necesita entender que las revisiones ayudan a crear un acuerdo acerca de lo que se
está construyendo”.
Les contestamos: “Sí, eso tiene sentido, pero si los participantes no saben que éste es un
objetivo de la revisión, ¿Pondrán ellos atención durante las revisiones?”.
También es importante contar con personal de pruebas y aseguramiento de la calidad que
atienda las revisiones cuando ellos puedan comprender el ítem sometido a revisión.
Revise esta cita del libro de Fred Brooks, The Mythical Man Month, el cual documenta su
experiencia con las revisiones que se remontan a la década de los sesenta. “Mucho antes
que cualquier código exista, la especificación debe ser entregada a un grupo de pruebas
externo para que la completitud y claridad sean revisadas. Como dice V.A. Vyssotsky del
proyecto Safeguard Project del Laboratorio Bell, los desarrolladores mismos no pueden
realizar esto: “No te dirán que no lo entienden, inventarán felizmente su camino a través de
las omisiones y oscuridades”.
Los buenos probadores tienen la habilidad especial de reconocer las partes ambiguas,
oscuras y faltantes de los requisitos y señalarlas en las revisiones.

Figura 3.2: Un Proceso Genérico de Revisión
En esta figura, podemos observar un proceso genérico de la revisión. Consiste en seis
pasos:

1. Planificación, que incluye la definición de los criterios de la revisión, la
selección del personal, la asignación de los roles, la definición de los criterios
de entrada y salida para los tipos de revisión más formales (p.ej. las
inspecciones), la selección de las partes de los documentos que deben ser
revisadas y la comprobación de los criterios de entrada (para los tipos de
revisión más formales).
2. Inicio, que incluye la distribución de los documentos, la explicación a los
participantes de los objetivos, el proceso y los documentos.
3. Preparación individual, la cual incluye la preparación para la reunión de la
revisión mediante la comprobación de los documentos y la observación de los
defectos, las preguntas y los comentarios potenciales.
4. La reunión misma de la revisión, la cual incluye las actividades relacionadas con
las pruebas, la evaluación y la protocolización de los resultados. Estas
actividades incluyen los resultados o los minutos de las argumentaciones y los
registros (para los tipos de revisión más formales), la observación de los
defectos, la creación de recomendaciones acerca del tratamiento de los defectos,
la toma de decisiones en relación con los defectos, y las pruebas, la evaluación y
las cuestiones de protocolización durante cualquier reunión física o el
seguimiento de cualquiera de las comunicaciones electrónicas de grupo.
5. Reproceso, el cual incluye la corrección de los defectos encontrados (realizados
típicamente por el autor) y la protocolización de las actualizaciones del estado
de los defectos (en revisiones formales).
6. Seguimiento, que incluye la comprobación si los defectos han sido abordados, la

recopilación de las métricas y la verificación de los criterios de salida (para los
tipos de revisiones más formales).

La planificación, la definición de los criterios de entrada y salida y las actividades de
inicio incluyen el trabajo para el proyecto entero y para cada ítem que tiene que ser
revisado.
La comprobación de los criterios de salida, la preparación individual, la observación de
los hallazgos, la reunión de revisión, el análisis de la reunión, el reproceso, la corrección
de los defectos y el seguimiento de las actividades se repiten por cada ítem revisado. El
trabajo de la preparación es usualmente de una a dos horas solamente. La reunión es de una
a dos horas en total. El reproceso y la corrección de los defectos son realizados por el
autor.
Sin embargo, el seguimiento no solo incluye el trabajo en los ítems individuales. El
seguimiento incluye también el análisis del mejoramiento del proceso general, la
evaluación de la eliminación de los defectos (o “bugs”) en las revisiones de la salida de
una fase (reuniones de salida), y etc.
Observe que los detalles del proceso de revisión dependen del tipo específico de revisión
utilizado en el proyecto, así como también del tipo de revisión utilizado para cada clase
particular del ítem.
Las revisiones implican que las personas desempeñen varios roles y asuman varias
responsabilidades.
El moderador dirige las reuniones de revisión.
El escribano o secretario es la persona que reúne la información acerca de los hallazgos de
la revisión.
El autor describe, explica y responde a preguntas acerca del ítem.
Los revisores o inspectores encuentran los defectos(o “bugs”) en el ítem.
El jefe de proyecto planifica, organiza los recursos y la capacitación, apoya y analiza las
métricas del proceso, pero, en algunos procesos, él no participa en la revisión.
Ahora, en algunos casos, una persona puede desempeñar múltiples roles. Por ejemplo, los
autores actúan a veces como moderadores, como en la revisión guiada. Uno de los
revisores puede actuar como secretario. Estos detalles son determinados por el tipo de
revisión.
Si bien las revisiones son una forma muy eficiente de encontrar defectos, así como también

una buena herramienta para la educación y la creación de consenso, no es trivial mantener
una buena revisión. Para tener reuniones de revisión exitosas, podemos ofrecer las
siguientes sugerencias:
Por un lado, proporcione capacitación para los participantes de la revisión. Esto no
necesita ser extenso—una hora podría ser suficiente para las revisiones informales, aunque
las técnicas formales como las inspecciones necesitarían mucho más—pero debería
enseñar a la gente el proceso y las reglas básicas.
Asegúrese de revisar el producto, no el productor. Las reuniones de revisión no deberían
convertirse en un foro para ataques personales de ningún tipo.
Como con cualquier reunión, usted debería establecer y seguir una agenda, y tener
objetivos claros y formulados.
La mayoría de los métodos para las revisiones son acerca de la búsqueda de los
problemas, en lugar de la identificación de las correcciones para ellas. En esos casos,
debería limitar el debate acerca de los hallazgos de las personas. La excepción es que
ciertos tipos de revisiones técnicas pueden incluir sesiones de lluvia de ideas para la
solución de los problemas, las cuales deben tener períodos bien identificados dentro de la
revisión.
Tenga un secretario o escribano cuyo trabajo sea de anotar, especialmente acerca de los
problemas identificados. Usted debería tener algún tipo de proceso de ciclo cerrado para
garantizar que todos los problemas sean resueltos, incluso si es algo tan sencillo como
pedir al autor que retorne una copia de la lista de los problemas con una marca de
comprobación junto a cada uno cuando la corrección es realizada.
Ahora bien, podría recordar que en el capítulo 1, cuando hablamos de los beneficios de
realizar el aseguramiento temprano de calidad y las pruebas tempranas, mencionamos que
muy pocas organizaciones saben cuántos defectos son introducidos, detectados y
eliminados en las primeras etapas del ciclo de vida. Si desea recopilar métricas acerca de
las revisiones, tendrá que pensar en la forma adecuada de incorporar eso en este proceso.
Algunas personas asumen que los mismos procesos, relativamente pesados, utilizados para
hacer el seguimiento de los defectos durante los niveles de pruebas de etapas finales como
las pruebas de sistema son los únicos métodos posibles. Usted puede utilizar esos métodos,
pero a la mayoría de nuestros clientes no les agrada. Se recomienda identificar las métricas
esenciales que desea recopilar de las revisiones y hacer el seguimiento sólo a éstas.
Comprendiendo la manera de incluirlas en su base de datos del seguimiento de los defectos
le permitirá extraer un conjunto unificado de las métricas de ese repositorio.
Debería limitar el número de personas allí y seleccionar cuidadosamente los participantes.
Piense acerca de los objetivos de la revisión—recuerde, aquellos objetivos deberían ser
claros y señalados— y pregúntese a usted mismo cómo cada participante contribuirá.
Todos deberían participar en la reunión de revisión preparada, lo que significa que han

leído la revisión del ítem sometido a pruebas y han recopilado algunas notas preliminares.
Usted puede asegurarse de la preparación, haciendo que la gente presente notas antes de la
reunión.
Diferentes tipos de ítems tienen diferentes tipos de problemas y los diferentes ítems
tendrán diferentes objetivos de la revisión. Por lo tanto, desarrolle una lista de
comprobación para cada tipo de ítem que es revisado.
Revise las revisiones y sus resultados de forma periódica, para asegurarse de que el
proceso está funcionando.
Utilice la técnica adecuada para cada tipo de ítem. Más antes mencionamos nuestra regla
“dos pares de ojos” para los productos del trabajo de las pruebas. Esto significa que cada
informe de defectos y cada caso de pruebas son revisados. Sin embargo, para los informes
de los defectos, utilizamos una revisión rápida, muy informal, con sólo dos personas,
mientras que para los casos de prueba utilizamos una revisión de pares más formal, con
tres o cuatro personas.
Es muy útil de hacer participar a los probadores—si el probador puede leerlo— en las
revisiones de los productos del trabajo así como los requisitos, los casos de uso, las
especificaciones del diseño e incluso el código. Primero, el probador tiene una buena
mentalidad para la revisión, especialmente encontrando los defectos. Segundo, los
probadores pueden aprender más acerca del producto, durante el desarrollo temprano y
utilizar ese conocimiento para crear los casos de prueba con más anticipación.
Evitar el uso indebido de los hallazgos y los resultados de las revisiones. Si la gente
observa los resultados de la revisión utilizados para las evaluaciones del personal, la
entrega de bonos, la determinación de aumentos de pagos o salarios, la asignación de
culpabilidad y responsabilidad para los problemas del proyecto, o la entrega de cualquier
recompensa o sanción relacionada con la gestión, la confianza será perdida y el proceso de
revisión fallará—o se volverá tan desagradable o político que usted deseará que falle.
Como cualquier cambio del proceso lleva tiempo y requiere de recursos comprometidos,
necesitará asegurarse del apoyo de la gerencia.
Por último, tenga en cuenta que las revisiones no son algo que aprende una vez y luego
sabe perfectamente. El proceso de revisión debería ser mejorado continuamente.
Porque la mayoría de los probadores participarán en las revisiones de los requisitos y el
diseño, aquí tiene algunos problemas comunes que ellos encontrarán.
Es bastante común encontrar ambigüedades, donde no es exactamente claro lo que significa
una declaración o sección. Por ejemplo, considere una declaración como “El sistema
debería permitir al usuario leer el correo electrónico de su Proveedor de Servicios de
Internet”. Está bien, de acuerdo, pero ¿Cuáles Proveedores de Servicios de Internet?
¿Todos? ¿Algunos de ellos? ¿Cuáles? ¿Qué tamaño de e-mails se permiten? ¿Cuáles tipos y

tamaños de los archivos adjuntos se permiten?
También es común encontrar que los escenarios no han sido pensados cuidadosamente y
tienen problemas de completitud que lo dejan a usted pensando, “Bueno, ¿Y qué pasa
después?” Por ejemplo, considere una declaración como esta, “Al ingresar tres
contraseñas inválidas, el sistema debería bloquear la cuenta del usuario”. Esto parece una
buena idea en un principio, desde el punto de vista de seguridad, pero pregúntese usted
mismo algunas de las preguntas obvias. ¿Durante cuánto tiempo estará bloqueada la
cuenta? ¿Cómo podemos desbloquearla antes si es necesario? ¿Quién está autorizado para
desbloquearla? Esta declaración, aparentemente una mejora de la seguridad, en realidad
podría permitir un pequeño e ingenioso ataque de la denegación del servicio. En primer
lugar, el hacker ingresa tres contraseñas al azar para las cuentas administrativas o del
súper usuario, bloqueando aquellas y luego procede a introducir las contraseñas al azar
para todas las otras cuentas. ¡Tantán! El software es inutilizable.
Un tercer problema común de los requisitos y el diseño es que la declaración no puede ser
probada. Pregúntese: “¿Cómo puedo comprobar este requisito?” Si no hay manera de
confirmar o negar el requisito, no es comprobable. Por ejemplo, considere la declaración,
“El sistema debería proporcionar una disponibilidad del 100%”. Bueno, es posible
realizar una prueba que cause una caída, para desaprobar esto, pero ¿Cómo podría
confirmarlo? No existe una técnica de pruebas conocida para demostrar una disponibilidad
perfecta del 100%. 99,999%, sí, pero no el 100%.
Por último, mantenga los ojos abiertos para las dependencias, el acoplamiento y la
complejidad excesivos. Busque diagramas de diseño deformes y requisitos confusos. Si se
le hace difícil de descubrirlos, es también probable que les sea difícil a los demás.
Ahora, examinemos el estándar que se aplica en las revisiones, el estándar IEEE 1028.
Este estándar consiste en ocho secciones, de las cuales veremos las primeras cinco:
Sección 1, Descripción general, que abarca el propósito, el alcance, la conformidad, la
organización y la aplicación del estándar.
Sección 2, Referencias
Sección 3, Definiciones
Sección 4, Revisiones de gestión, aborda las responsabilidades, las entradas y las salidas
de los datos, los criterios de entrada y salida y los procedimientos para las revisiones de
gestión. Tenga en cuenta que las revisiones de gestión no son parte del Programa de
Estudios Nivel Básico.
Sección 5, Revisiones técnicas, también llamadas revisiones de pares, que cubren las
responsabilidades, las entradas y salidas de datos, los criterios de entrada y salida y los
procedimientos para estas revisiones.

Las tres secciones restantes del estándar IEEE 1028 son:
Sección 6, Inspecciones, las más formales de las revisiones, son cubiertas, con la
información acerca de las responsabilidades, las entradas y las salidas de los datos, los
criterios de entrada y salida y los procedimientos. Porque esta técnica es más formal que
una revisión técnica, el estándar cubre también la recopilación de los datos y la mejora del
proceso a través de las inspecciones.
Sección 7, Revisiones guiadas, que cubren las responsabilidades, las entradas y las salidas
de los datos, los criterios de entrada y salida y los procedimientos. Las revisiones guiadas
son menos formales que las inspecciones, pero, de acuerdo con el estándar IEEE 1028,
más formales que las revisiones técnicas, así el estándar cubre también la colección de los
datos y la mejora del proceso a través de las revisiones guiadas. En la práctica común,
aunque una revisión guiada no es más que una revisión técnica, donde el autor es el
moderador y el ítem sometido a revisión es la agenda.
Por último, la sección 8, las auditorías, abordan las responsabilidades, las entradas y las
salidas de los datos, los criterios de entrada y salida y los procedimientos para este tipo de
revisiones, los cuales están fuera del alcance del Programa de Estudios Nivel Básico.
Al igual que con el estándar IEEE 12207, el estándar CMMI y el estándar ISO 9126, los
cuales fueron presentados anteriormente, se espera que recuerde este estándar en el
examen. Le recomendamos que estudie este estándar cuidadosamente.

3.2.1 Ejercicios
Ejercicio 1
Forme equipos de 3 a 5 personas.21
Seleccione una técnica de revisión de las que ya hemos hablado. Si su técnica seleccionada
involucra roles específicos, asigne los roles.
Revise el Documento de Requisitos de Marketing de Omninet.
Argumente acerca de los hallazgos de su equipo.

Hemos resuelto este ejercicio en cursos en vivo en todo el mundo con cientos de personas.
Típicamente, los equipos de revisión encuentran cerca de diez defectos de varios tipos en
el Documento de los Requisitos de Marketing.
Encontramos más de veinte cuando realizamos este ejercicio por nosotros mismos (véase

la tabla 3.1). Pudimos haber encontrado otros defectos—o defectos posibles— con este
documento, pero la limitación del tiempo nos cortó. También encontré un número de
defectos o defectos potenciales que necesiten probablemente ser resueltos en un documento
de más bajo nivel, como el Documento de Requisitos del Sistema Omninet.
Una observación interesante, para lo que sirva, es que la mayoría de la gente en cada curso
dijo que el Documento de los Requisitos de Marketing de Omninet es tan bueno o mejor
que los típicos documentos de requisitos que ellos reciben. Eso es verdad sin importar
dónde en el mundo se ha presentado el curso. Si observa a través de los defectos que usted
y nosotros encontramos en el Documento de los Requisitos de Marketing de Omninet, se
puede imaginar cómo estos problemas podrían conducir después a problemas serios del
sistema si es que no son corregidos antes de la implementación.

Tabla 3.1: Problemas con el Documento de los Requisitos de Marketing de Omninet

3.3 Análisis Estático por medio de Herramientas
LO-3.3.1 Recordar los defectos y los errores típicos identificados por el análisis estático y
compararlos con las revisiones y las pruebas dinámicas. (K1)
LO-3.3.2 Describir, utilizando ejemplos, los beneficios típicos del análisis estático. (K2)

LO-3.3.3 Hacer una lista de los defectos típicos del código y el diseño que pueden ser
identificados por las herramientas de análisis estático. (K1)
Esta sección, Análisis estático por medio de herramientas, cubrirá los siguientes conceptos
clave:

Defectos típicos y errores identificados por el análisis estático en comparación
con las revisiones y las pruebas dinámicas.
Beneficios típicos del análisis estático.
Los típicos defectos de código y diseño identificados por las herramientas de
análisis estático.
Empecemos a comparar y contrastar el análisis estático con las pruebas dinámicas.
Al igual que las pruebas dinámicas, el análisis estático busca defectos en el software
mismo, pero también puede buscar defectos en los modelos del software como los
requisitos o los modelos ejecutables así como los modelos de rendimiento del sistema que
mencionamos anteriormente.
En un contraste adicional, a diferencia de las pruebas dinámicas, el análisis estático se
realiza sin realmente ejecutar el sistema, más bien, se ejecuta una herramienta que verifica
el sistema o un modelo de éste.
Análisis estático implica el análisis del sistema o sus componentes por una herramienta—
eso es lo que hace diferente al análisis estático de una revisión, la cual es manual. Las
pruebas dinámicas no siempre involucran herramientas
El análisis estático puede encontrar defectos que son difíciles de encontrar o aislar en las
pruebas dinámicas.
Los ejemplos incluyen cuestiones de mantenibilidad con el código, que podría ejecutarse
bien, pero podría ser difícil de entender (y modificar), así como también la utilización
insegura de punteros, que podrían causar una caída o un comportamiento extraño sólo en
circunstancias especiales.
Por último, tenga presente que el aislamiento del defecto es más fácil porque usted
encuentra el defecto, no el síntoma o la falla.
¿Qué puede ser objeto del análisis estático? Bueno, muchas cosas pueden, por lo general
más de lo esperado.
Generalmente, las personas piensan sólo en el código del programa, examinando los flujos
de control y el flujo de datos, examinando las violaciones de los estándares de
codificación. Sí, ése es un uso común del análisis estático, pero no el único.

Glosario del ISTQB
Flujo de control: Una secuencia de eventos (caminos) en la ejecución a través de un
componente o sistema.
Flujo de datos: Una representación abstracta de la secuencia y los cambios posibles del
estado de los objetos de datos, donde el estado de un objeto puede ser cualquiera de los
siguientes: creación, uso o destrucción.
Hay simuladores que nos permiten analizar los modelos del programa, así como los
modelos de rendimiento.
Podemos comprobar las salidas generadas como HTML y XML acerca de la conformidad
con una sintaxis correcta, los enlaces rotos, y así sucesivamente.
Por último, incluso los análisis usuales, como la ortografía, la gramática, las
comprobaciones de los requisitos acerca de la dificultad de su lectura y la legibilidad y la
claridad de los documentos del diseño.
Las herramientas de análisis estático no son necesariamente económicas, e incluso cuando
lo son, las personas no siempre se toman el tiempo para usarlas, porque no entienden los
beneficios del análisis estático.
Al igual que con las revisiones, el análisis estático proporciona una detección temprana y
más económica de los defectos, a menudo mucho antes que la ejecución de las pruebas
comience.
Esto significa que los defectos pueden ser encontrados y eliminados en muchos casos fuera
de la ruta crítica para la versión, a diferencia de los defectos encontrados y eliminados
durante los niveles de pruebas en las últimas etapas, como ser las pruebas de sistema y las
pruebas de aceptación.
Los análisis estáticos pueden proporcionar advertencias acerca de dónde podrían existir
agrupaciones de defectos, debido a la programación peligrosa, la alta complejidad y así
sucesivamente.
Los análisis estáticos pueden localizar defectos que las pruebas dinámicas no podrían
encontrar, así como el código difícil de mantener, complejo o ilegible.
El análisis estático puede detectar dependencias e inconsistencias en los modelos del
software. Por ejemplo, enlaces rotos en las páginas Web.
Estos beneficios se combinan para ayudarnos a mejorar la mantenibilidad del código y los
diseños, y, si recolectamos las métricas y estudiamos las lecciones aprendidas del análisis

estático, nos puede ayudar a prevenir defectos.
Los problemas típicos encontrados durante el análisis estático incluyen:
Referencia a una variable con un valor no definido, que puede hacer caer al sistema si la
variable es un puntero o un resultado erróneo, si es que son utilizados valores aleatorios en
un cálculo.
Interfaces inconsistentes entre los módulos y componentes, así como el paso de un entero
donde se requiere un número real.
Variables que nunca son utilizadas, así perdiendo espacio de memoria y código
inalcanzable (o muerto), lo cual no sólo desperdicia espacio, sino podría crear riesgos de
seguridad.
Lógica faltante o incorrecta, así como la utilización del operador de asignación en lugar
del operador de igualdad lógica en la condición de una sentencia if.
Complejidad excesiva del código, tal vez utilizando una métrica como por ejemplo la
complejidad ciclomática, acerca de la cual hablaremos más adelante en este libro.
Las violaciones de los estándares de programación son otro defecto común del análisis
estático, y muchas herramientas comerciales de análisis estático incluyen bibliotecas
enteras de estándares de codificación.
Algunas herramientas de análisis estático ayudarán también a encontrar especialmente
vulnerabilidades de seguridad, las cuales son tipos particulares de violaciones de los
estándares de codificación.
Por último, el análisis estático puede localizar las violaciones de sintaxis de código y de
los modelos del software.
¿Cómo y quién utiliza las herramientas de análisis estático?
Si estamos hablando del código, entonces los usuarios típicos son los programadores, con
frecuencia durante las pruebas de componente e integración, aunque ellos comenzarían
idealmente durante la codificación.
Si hablamos de diseño, entonces los usuarios típicos son los diseñadores y los arquitectos
durante el período del diseño. El modelado del rendimiento que hemos mencionado unas
cuantas veces suele ocurrir en ese punto.
Ahora, una cosa que hemos encontrado con nuestros clientes es que durante la presentación
inicial de las herramientas de análisis del código en una base de código existente, estas
herramientas pueden producir un gran número de mensajes de advertencia. Por lo tanto, le
recomendamos el siguiente proceso:

Determine cuáles reglas hará valer y cuáles no son importantes. Desactive las que no
son importantes.
Exija la utilización de las herramientas de análisis estático, pero sólo en funciones o
clases nuevas o aquellas funciones o clases que están siendo modificadas.
Haga que el programador ejecute el análisis estático y sus pruebas de unidad antes
de declarar el código como terminado y exíjale que presente los resultados del
análisis estático y las pruebas de unidad, junto con las pruebas unitarias mismas, para
una revisión del código antes de aceptar el código como terminado.
Si este proceso se aplica con diligencia en el tiempo, las partes más defectuosas del
código existente—siendo las más propensas que necesitan mantenimiento—se pondrán
gradualmente en conformidad con los estándares de codificación. En cuanto al resto del
código, oiga, si no está causando problemas, creo que las violaciones de los estándares de
codificación que existen no están creando demasiados problemas.
Algunas personas utilizan los compiladores para hacer su análisis estático, pero hay
muchas herramientas sofisticadas. Sin embargo, algunos compiladores y entornos de
desarrollo integrados son también cada vez más sofisticados en este sentido.

Glosario del ISTQB
Compilador: Este término no está definido en el glosario del ISTQB. La política del
ISTQB es que los términos no definidos en el glosario no pueden ser incluidos en el
examen.

3.3.1 Ejercicios
Ejercicio 1
¿Cuál tipo de análisis estático sugeriría para Omninet?
¿Utilizaría el análisis estático en áreas que estarían sujetas a pruebas posteriores?
Argumente.

En Omninet, utilizaríamos el análisis estático para el código Java, C++ u otro lenguaje de
programación utilizado para crear las aplicaciones en los servidores y el procesamiento de
los pagos y los períodos de tiempos de los quioscos. También utilizaríamos el análisis
estático en HTML en las interfaces del usuario, los repositorios de datos XML y las bases

de datos SQL.
Además, utilizaríamos modelos temprano en el proyecto para predecir el rendimiento y la
reacción a la carga. Utilizaríamos ambos, los modelos estáticos como una hoja de cálculo y
los modelos dinámicos como un simulador del rendimiento del sistema de redes. Para
Omninet, los problemas del rendimiento que indicaron cuestiones de arquitectura sería
desastroso si aparecen durante la prueba de sistema. Por cierto, trabajamos en un proyecto
que falló debido al descubrimiento tardío de cuestiones de rendimiento básico. También
trabajamos en un proyecto donde utilizamos modelos estáticos y dinámicos para evitar
cualquier descubrimiento tardío de esas cuestiones de rendimiento.
Incluso utilizaríamos comprobadores de ortografía y gramática en las especificaciones de
los prototipos de la interfaz del usuario, los requisitos y el diseño y los planes de pruebas
y los proyectos. Usted podría preguntar “¿Cuáles problemas importantes podría encontrar
un comprobador de gramática?” Si el plan de pruebas incluye demasiadas oraciones con
verbos pasivos como, “Tantos defectos como sea posible deberían ser detectados”, sin
especificar quién debe hacer qué para detectar esos defectos, es un plan deficiente, uno que
no puede ser puesto en acción.
Mientras que somos grandes partidarios del análisis estático, también probaríamos cada
uno de los ítems que pasaron por el análisis estático. Asuma que el análisis estático es
65% efectivo en promedio y que ha encontrado y eliminado 650 defectos a través del
análisis estático de cada parte de Omninet. Esto significa que 350 defectos han escapado y
deben ser detectados y eliminados durante las pruebas.22

Preguntas de Examen de Muestra y Simulación
Para finalizar cada capítulo, usted puede tratar de resolver una o más preguntas de examen
de muestra para reforzar su conocimiento y comprensión del material y prepararse para el
examen del Probador ISTQB Nivel Básico.

Sección 3.1 Técnicas estáticas y el proceso de pruebas (K2)
Términos
Pruebas dinámicas y pruebas estáticas.

Sección 3.2 Proceso de revisión (K2)
Estándares
• [IEEE 1028] Estándar IEEE 1028™ (1997) Estándar IEEE para las Revisiones de
Software].
Términos
Criterios de entrada, revisión formal, revisión informal, inspección, métrica,
moderador/líder de la inspección, revisión por pares, revisor, revisión técnica y revisión
guiada.

Sección 3.3: Análisis estáticos por herramientas (K2)
Términos
Compilador, complejidad, flujo de control, flujo de datos y análisis estático.

Capítulo 3 Pregunta a través de las secciones

Preguntas del Examen de Simulación 1

Preguntas del Examen de Simulación 2

_____________________________
Véase el libro de Capers Jones, Estimating Software Costs, para las cifras acerca de la
20
efectividad típica de varias actividades del aseguramiento de calidad y las pruebas.
Este ejercicio y su solución han sido adaptados del capítulo 9 del libro de Rex Black
21
Pragmatic Software Testing
El libro Estimating Software Costs de Capers Jones cita el 65% como la efectividad de
22 las revisiones de diseño y código, entonces estamos utilizando ese cálculo como una
estimación aproximada de la efectividad del análisis estático solo para ilustrar este punto.

Fundamentos de Pruebas de Software - Capítulo 3

Más contenido relacionado

La actualidad más candente

Destacado

Similar a Fundamentos de Pruebas de Software - Capítulo 3

Más de Professional Testing

Último

Fundamentos de Pruebas de Software - Capítulo 3