Capítulo 3Té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 porlas diferentes técnicas estáticas. (K1)

LO-3.1.2 Describir la importancia y el valor de considerar las técnicas estáticas para laevaluació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, considerandolos objetivos, los tipos de defectos que deben ser identificados y el rol de estas técnicas enel ciclo de vida del software. (K2)

Esta sección, Técnicas Estáticas y el Proceso de Pruebas, cubrirá los siguientes conceptosclave:

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 deprueba— 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 osistema.

Pruebas estáticas: Pruebas de un componente o sistema en un nivel de la especificación oimplementació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ódigollevados a cabo sin la ejecución de estos artefactos del desarrollo de software. El análisisestático es usualmente llevado a cabo por una herramienta.

Esto puede involucrar la utilización de las revisiones y las herramientas. Ahora, lasrevisiones, las cuales pueden ir de informales a muy formales, serán cubiertas en detalle enbreve. Hay también varias herramientas que pueden realizar algunos tipos de pruebasestá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 esbastante típico. También se pueden—y se deberían— utilizar para el código, los esquemasde las bases de datos, la documentación, las pruebas y cualquier otro producto de trabajoque haya sido escrito.

Una forma de pruebas estáticas es la utilización de modelos y prototipos. Un diagrama deun sistema complejo puede revelar con frecuencia problemas de diseño que puedenesconderse en las palabras. Un diagrama de diseño deforme significa a menudo muchosdefectos.

En un proyecto de hace algunos años, utilizamos las pruebas estáticas de los modelos deldiseño para comprobar si habían problemas potenciales de rendimiento. Las pruebasestáticas incluían un modelo descrito en una hoja de cálculo acerca de la utilización de losrecursos en distintos niveles de carga. También incluían un modelo de simulaciónejecutable de la utilización de de los recursos del sistema. Esto previno una gran cantidadde 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 comouna forma de pruebas estáticas.

El análisis y el diseño de las pruebas basados en las especificaciones de los requisitos y eldiseño son una forma de revisión estructurada, y estos procesos de análisis y diseño depruebas 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 formasdel análisis estático que podemos realizar. Una de estas formas es la comprobación de laortografía, la gramática y la dificultad de lectura que se pueden realizar contra losdocumentos. Por ejemplo, Word incluye la capacidad para detectar los errores deortografía, los problemas de gramática y los pasajes de lectura difíciles, los cuales puedenser útiles para las especificaciones de los requisitos y el diseño.

Al observar el código fuente, podemos utilizar herramientas para comprobar losconstructos peligrosos de programación. Estas herramientas son por ejemplo J-Test, SaferC, lint y otras. También podemos utilizar las herramientas de código abierto y lascomerciales para medir el código en cuanto a los asuntos del análisis de la complejidad, lacual 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 estructurainterna que es difícil de entender, mantener y verificar. Véase también la complejidadciclomática.

Las herramientas de análisis estático también contienen las simulaciones de sistemas. Hayun programa llamado General Purpose System Simulator, el cual ha estado en uso durantedécadas que puede simular componentes básicos de un sistema, como las colas y losrecursos. Como se mencionó antes, existen herramientas de modelado de rendimiento einvestigación de operaciones que pueden predecir el comportamiento del sistema sometidoa carga. Incluso podemos utilizar herramientas simples como las hojas de cálculo parasimular el comportamiento del sistema, especialmente para el rendimiento, pero tambiénpara la funcionalidad.

Empecemos con la técnica manual de las revisiones. Las revisiones deberían ser utilizadaspara cada producto valioso del trabajo del proyecto, en un algún nivel de formalidad uotro.

Lamentablemente, las revisiones no se aproximan a la clase de utilización y atención que semerecen. 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 unarevisión, se necesita el tiempo necesario para realizar las revisiones. Con frecuencia, lapreocupación aquí no es tanto el esfuerzo como la duración. Segundo, si estamosrealizando una revisión formal, necesitamos el esfuerzo necesario para recopilar y analizarlas 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 elproceso. 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 requisitosdocumentados, 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 antescon 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íamosobservar 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 defectoses más fácil cuando encontramos los defectos, en lugar de los síntomas, como es el casodurante las revisiones — deberíamos observar la productividad mejorada deldesarrollador. Finalmente, como se mostró nuevamente en un capítulo anterior, deberíamosver la calidad mejorada del producto, lo cual reducirá los costos indirectos, tanto en eldesarrollo como después de las versiones.

En definitiva, las revisiones de todos los tipos son técnicas probadas, de alto retorno paramejorar la calidad. David Rico, en sus estudios acerca de las organizaciones delDepartamento de Defensa de los Estados Unidos, encontró que las revisiones tienen unretorno 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—elobjeto de pruebas— no es ejecutado, mientras que las pruebas dinámicas son las pruebasdonde 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 deinteresados del negocio están involucrados. Recuerde nuestra descripción anterior acercade las pruebas dominantes. Y también, ambas ahorran tiempo y dinero a la compañía, comofue demostrado en un capítulo anterior cuando hablamos acerca de s los beneficios de laspruebas tempranas y el aseguramiento temprano de la calidad.

Entonces ¿Cuáles son las diferencias? Bueno, por un lado cada técnica puede encontrardiferentes tipos de defectos de manera más efectiva y eficiente. Por ejemplo, ciertos tiposde cuestiones de la mantenibilidad son más fáciles de encontrar en las revisiones y losanálisis estáticos. Por otra parte, las técnicas estáticas encuentran más bien defectos quefallas. En otras palabras, si realizamos una revisión y encontramos una suposición

equivocada acerca del comportamiento sometido a carga, estamos examinandodirectamente 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áticolocalizarí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énel análisis de las pruebas, los casos de prueba, el plan de pruebas y los resultados de laspruebas. Impondríamos los análisis estáticos en el código de Omninet. En el caso deOmninet, el código no solo incluye programas acerca de los servidores del centro de datosy el centro de llamadas, sino también HTML y otros entregables acerca de los clientes delcentro de llamadas y los quioscos.

Las revisiones encuentran típicamente las ambigüedades, las incompletitudes y losconflictos. Los análisis estáticos encuentran código descuidado, no estándar, peligroso einalcanzable. Sin embargo, las revisiones y el análisis estático, mientras son bastanteefectivos, eliminan típicamente el 65% o menos de los defectos presentes en el ítemrevisado o analizado.20 Dado que cientos o incluso miles de defectos podrían existir en unsistema tan complejo como Omninet, las revisiones y los análisis estáticos deben serampliados con las pruebas dinámicas en los niveles de componente, integración, sistema yaceptación.

3.2 Proceso de Revisión

Objetivos del Aprendizaje

LO-3.2.1 Recordar las actividades, los roles y las responsabilidades de una revisiónformal 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 documentospara detectar defectos, p.ej., las violaciones de los estándares de desarrollo y ladisconformidad con la documentación de nivel superior. La técnica de revisión más formaly además basada siempre en un procedimiento documentado. Véase también la revisión porpares.

Revisión técnica: Una actividad de debate de grupo por pares que se enfoca en lograr unconsenso acerca del método técnico que deba tomarse. Véase también la revisión porpares.

Revisión guiada (“Walkthrough”): Una presentación paso a paso por el autor de undocumento con el fin de reunir información y establecer un entendimiento común de sucontenido. 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 elcódigo. Éstas pueden que tengan los resultados documentados, pero el nivel de detalle enel documento es típicamente bajo. Tienen una efectividad limitada en la eliminación de losdefectos, pero son útiles, económicas y populares.

La efectividad depende mucho del empleo de revisores idóneos. El propósito principal esde 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 enel producto o proyecto sometido a revisión. Los revisores pueden ser elegidos pararepresentar 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ónde los defectos. Debería involucrar a sus compañeros y técnicos expertos. Si el proceso noinvolucra jefes, entonces es una revisión entre pares. Típicamente los jefes no asistirían sino pueden contribuir técnicamente. Si el jefe puede contribuir técnicamente, entonces elproceso debería ser establecido de manera que el jefe no utilice los hallazgos de larevisión para premiar o sancionar al autor o los participantes de la revisión. Las revisionesté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ónpor los revisores es normalmente necesaria. Las listas de comprobación, las cuales sonespecíficas para el tipo del ítem que está siendo revisado, son recomendadas pero nonecesarias durante la preparación y la revisión misma. La revisión debería resultar en uninforme de revisión que incluye la lista de los hallazgos, el veredicto si el producto desoftware cumple con sus requisitos y si es apropiado, y sus recomendaciones relacionadascon los hallazgos. En la práctica, éstas varían de bastante informal a muy formal. Lospropósitos principales de una revisión técnica son el debate, la toma de decisiones, laevaluación de alternativas, el hallazgo de defectos, la solución de problemas técnicos y lacomprobación de la conformidad con las especificaciones, los planes, las regulaciones ylos estándares. Una revisión guiada es un tipo especial de revisión técnica donde el ordendel 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ónde la pre-reunión de los revisores como la entrega de un informe de la revisión incluyendolos hallazgos, son opcionales para las revisiones guiadas. Si un informe tiene que serentregado, entonces debería haber un escribano o un registrador, quien no es el autoridealmente.

Como con las revisiones técnicas, en la práctica, éstas varían de bastante informal a muyformal. Los propósitos principales de una revisión guiada son aprender, ganar lacomprensió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 unainspección u otro proceso de revisión. Tenga en cuenta que el término “líder de lainspección” no está definido en el Glosario ISTQB, pero su utilización en El Programa deEstudios 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. Ejemplosson 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 lamejora del proceso durante una reunión de revisión, en un formulario de registro. Elescribano 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, quienno puede ser el autor, lidera el equipo de inspección. Los compañeros son seleccionadoscuidadosamente para formar el equipo de revisión. Cada miembro del equipo de revisióntiene roles definidos, basados en su experticia particular. Un proceso formal de inspecciónes utilizado, el cual tiene reglas, listas de comprobación, criterios de entrada y salida. Elproceso 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óntécnica, pero para las inspecciones esta preparación es obligatoria. Hay un proceso deseguimiento formal, incluyendo los elementos opcionales del mejoramiento del proceso. Aveces se da el caso de que un lector especialmente entrenado es incorporado. El propósitoprincipal de una inspección es de encontrar defectos—de hecho encontrar a casi todos deellos.

Note que un método informal valora más la velocidad que la efectividad en la eliminaciónde los defectos, mientras que una revisión formal valora la efectividad de la eliminaciónde defectos. De acuerdo a los estudios de Capers Jones, las técnicas informales tienden aalcanzar una efectividad de la eliminación de los defectos cerca del 25%, mientras que lasinspecciones formales pueden alcanzar una efectividad de la eliminación de los defectosde hasta un 90%.

Ahora, cuando las revisiones guiadas, las revisiones técnicas o las inspecciones sonrealizadas 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 reglasimple: Dos pares de ojos. Esto significa que, para cualquier producto del trabajo que seaimportante, más de una persona lo examina antes de que se considere como terminado. Estopodría implicar una revisión informal para los informes de los defectos o una revisiónformal 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 softwareo producto relacionado con el trabajo puede ser revisado. No sólo revise el código, losrequisitos y las especificaciones del diseño. Revise todos los productos importantes deltrabajo. Segundo, note que cualquier ítem el cual es revisado puede estar sujeto a más deuna 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ñoantes de una revisión técnica de la especificación del diseño. Usted puede realizar unainspección de una especificación de requisitos antes de una revisión guiada con losclientes.

Figura 3.1: Consenso y Entendimiento

Además de encontrar y eliminar los defectos, las revisiones pueden ayudar en el consensoy el entendimiento. La incompletitud y la ambigüedad pueden ocultar el verdaderosignificado de las especificaciones y una revisión puede revelar el significado. Podemosutilizar una revisión para alcanzar un acuerdo y entendimiento uniforme de lasespecificaciones.

Por ello, todos deben entender este objetivo. Una vez hicimos una evaluación donde lagente mencionó que si bien todos los requisitos del trabajo y las especificaciones deldiseño pasaron por una revisión, algunas veces fueron realizadas después de que el códigohabí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, lagente necesita entender que las revisiones ayudan a crear un acuerdo acerca de lo que seestá construyendo”.

Les contestamos: “Sí, eso tiene sentido, pero si los participantes no saben que éste es unobjetivo 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 queatienda 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 suexperiencia con las revisiones que se remontan a la década de los sesenta. “Mucho antesque cualquier código exista, la especificación debe ser entregada a un grupo de pruebasexterno para que la completitud y claridad sean revisadas. Como dice V.A. Vyssotsky delproyecto Safeguard Project del Laboratorio Bell, los desarrolladores mismos no puedenrealizar esto: “No te dirán que no lo entienden, inventarán felizmente su camino a través delas 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 seispasos:

1. Planificación, que incluye la definición de los criterios de la revisión, laselección del personal, la asignación de los roles, la definición de los criteriosde entrada y salida para los tipos de revisión más formales (p.ej. lasinspecciones), la selección de las partes de los documentos que deben serrevisadas y la comprobación de los criterios de entrada (para los tipos derevisión más formales).

2. Inicio, que incluye la distribución de los documentos, la explicación a losparticipantes de los objetivos, el proceso y los documentos.

3. Preparación individual, la cual incluye la preparación para la reunión de larevisión mediante la comprobación de los documentos y la observación de losdefectos, las preguntas y los comentarios potenciales.

4. La reunión misma de la revisión, la cual incluye las actividades relacionadas conlas pruebas, la evaluación y la protocolización de los resultados. Estasactividades incluyen los resultados o los minutos de las argumentaciones y losregistros (para los tipos de revisión más formales), la observación de losdefectos, 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 ylas cuestiones de protocolización durante cualquier reunión física o elseguimiento de cualquiera de las comunicaciones electrónicas de grupo.

5. Reproceso, el cual incluye la corrección de los defectos encontrados (realizadostípicamente por el autor) y la protocolización de las actualizaciones del estadode 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 lostipos de revisiones más formales).

La planificación, la definición de los criterios de entrada y salida y las actividades deinicio incluyen el trabajo para el proyecto entero y para cada ítem que tiene que serrevisado.

La comprobación de los criterios de salida, la preparación individual, la observación delos hallazgos, la reunión de revisión, el análisis de la reunión, el reproceso, la correcciónde los defectos y el seguimiento de las actividades se repiten por cada ítem revisado. Eltrabajo de la preparación es usualmente de una a dos horas solamente. La reunión es de unaa dos horas en total. El reproceso y la corrección de los defectos son realizados por elautor.

Sin embargo, el seguimiento no solo incluye el trabajo en los ítems individuales. Elseguimiento incluye también el análisis del mejoramiento del proceso general, laevaluación de la eliminación de los defectos (o “bugs”) en las revisiones de la salida deuna fase (reuniones de salida), y etc.

Observe que los detalles del proceso de revisión dependen del tipo específico de revisiónutilizado en el proyecto, así como también del tipo de revisión utilizado para cada claseparticular del ítem.

Las revisiones implican que las personas desempeñen varios roles y asuman variasresponsabilidades.

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 dela 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 lasmé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, losautores actúan a veces como moderadores, como en la revisión guiada. Uno de losrevisores puede actuar como secretario. Estos detalles son determinados por el tipo derevisió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 manteneruna buena revisión. Para tener reuniones de revisión exitosas, podemos ofrecer lassiguientes sugerencias:

Por un lado, proporcione capacitación para los participantes de la revisión. Esto nonecesita ser extenso—una hora podría ser suficiente para las revisiones informales, aunquelas técnicas formales como las inspecciones necesitarían mucho más—pero deberíaenseñ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íanconvertirse en un foro para ataques personales de ningún tipo.

Como con cualquier reunión, usted debería establecer y seguir una agenda, y tenerobjetivos claros y formulados.

La mayoría de los métodos para las revisiones son acerca de la búsqueda de losproblemas, 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 queciertos tipos de revisiones técnicas pueden incluir sesiones de lluvia de ideas para lasolución de los problemas, las cuales deben tener períodos bien identificados dentro de larevisión.

Tenga un secretario o escribano cuyo trabajo sea de anotar, especialmente acerca de losproblemas identificados. Usted debería tener algún tipo de proceso de ciclo cerrado paragarantizar que todos los problemas sean resueltos, incluso si es algo tan sencillo comopedir al autor que retorne una copia de la lista de los problemas con una marca decomprobació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 derealizar el aseguramiento temprano de calidad y las pruebas tempranas, mencionamos quemuy pocas organizaciones saben cuántos defectos son introducidos, detectados yeliminados en las primeras etapas del ciclo de vida. Si desea recopilar métricas acerca delas revisiones, tendrá que pensar en la forma adecuada de incorporar eso en este proceso.Algunas personas asumen que los mismos procesos, relativamente pesados, utilizados parahacer el seguimiento de los defectos durante los niveles de pruebas de etapas finales comolas 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étricasesenciales 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 defectosle 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 serclaros 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 lareunión.

Diferentes tipos de ítems tienen diferentes tipos de problemas y los diferentes ítemstendrán diferentes objetivos de la revisión. Por lo tanto, desarrolle una lista decomprobación para cada tipo de ítem que es revisado.

Revise las revisiones y sus resultados de forma periódica, para asegurarse de que elproceso 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 cadainforme de defectos y cada caso de pruebas son revisados. Sin embargo, para los informesde 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, contres o cuatro personas.

Es muy útil de hacer participar a los probadores—si el probador puede leerlo— en lasrevisiones de los productos del trabajo así como los requisitos, los casos de uso, lasespecificaciones del diseño e incluso el código. Primero, el probador tiene una buenamentalidad para la revisión, especialmente encontrando los defectos. Segundo, losprobadores pueden aprender más acerca del producto, durante el desarrollo temprano yutilizar 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 genteobserva los resultados de la revisión utilizados para las evaluaciones del personal, laentrega de bonos, la determinación de aumentos de pagos o salarios, la asignación deculpabilidad y responsabilidad para los problemas del proyecto, o la entrega de cualquierrecompensa o sanción relacionada con la gestión, la confianza será perdida y el proceso derevisió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 luegosabe 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 eldiseño, aquí tiene algunos problemas comunes que ellos encontrarán.

Es bastante común encontrar ambigüedades, donde no es exactamente claro lo que significauna declaración o sección. Por ejemplo, considere una declaración como “El sistemadebería permitir al usuario leer el correo electrónico de su Proveedor de Servicios deInternet”. 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 ytienen problemas de completitud que lo dejan a usted pensando, “Bueno, ¿Y qué pasadespués?” Por ejemplo, considere una declaración como esta, “Al ingresar trescontraseñas inválidas, el sistema debería bloquear la cuenta del usuario”. Esto parece unabuena idea en un principio, desde el punto de vista de seguridad, pero pregúntese ustedmismo algunas de las preguntas obvias. ¿Durante cuánto tiempo estará bloqueada lacuenta? ¿Cómo podemos desbloquearla antes si es necesario? ¿Quién está autorizado paradesbloquearla? Esta declaración, aparentemente una mejora de la seguridad, en realidadpodría permitir un pequeño e ingenioso ataque de la denegación del servicio. En primerlugar, el hacker ingresa tres contraseñas al azar para las cuentas administrativas o delsúper usuario, bloqueando aquellas y luego procede a introducir las contraseñas al azarpara 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 serprobada. Pregúntese: “¿Cómo puedo comprobar este requisito?” Si no hay manera deconfirmar o negar el requisito, no es comprobable. Por ejemplo, considere la declaración,“El sistema debería proporcionar una disponibilidad del 100%”. Bueno, es posiblerealizar una prueba que cause una caída, para desaprobar esto, pero ¿Cómo podríaconfirmarlo? No existe una técnica de pruebas conocida para demostrar una disponibilidadperfecta del 100%. 99,999%, sí, pero no el 100%.

Por último, mantenga los ojos abiertos para las dependencias, el acoplamiento y lacomplejidad excesivos. Busque diagramas de diseño deformes y requisitos confusos. Si sele 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, laorganizació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 salidasde los datos, los criterios de entrada y salida y los procedimientos para las revisiones degestión. Tenga en cuenta que las revisiones de gestión no son parte del Programa deEstudios Nivel Básico.

Sección 5, Revisiones técnicas, también llamadas revisiones de pares, que cubren lasresponsabilidades, las entradas y salidas de datos, los criterios de entrada y salida y losprocedimientos 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 lainformación acerca de las responsabilidades, las entradas y las salidas de los datos, loscriterios de entrada y salida y los procedimientos. Porque esta técnica es más formal queuna revisión técnica, el estándar cubre también la recopilación de los datos y la mejora delproceso a través de las inspecciones.

Sección 7, Revisiones guiadas, que cubren las responsabilidades, las entradas y las salidasde los datos, los criterios de entrada y salida y los procedimientos. Las revisiones guiadasson 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 losdatos 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 elmoderador 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 lassalidas de los datos, los criterios de entrada y salida y los procedimientos para este tipo derevisiones, 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, loscuales fueron presentados anteriormente, se espera que recuerde este estándar en elexamen. 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 seleccionadainvolucra roles específicos, asigne los roles.

Revise el Documento de Requisitos de Marketing de Omninet.

Argumente acerca de los hallazgos de su equipo.

Solución del Ejercicio 1

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 enel 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 estedocumento, pero la limitación del tiempo nos cortó. También encontré un número dedefectos o defectos potenciales que necesiten probablemente ser resueltos en un documentode 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 cursodijo que el Documento de los Requisitos de Marketing de Omninet es tan bueno o mejorque los típicos documentos de requisitos que ellos reciben. Eso es verdad sin importardónde en el mundo se ha presentado el curso. Si observa a través de los defectos que ustedy nosotros encontramos en el Documento de los Requisitos de Marketing de Omninet, sepuede imaginar cómo estos problemas podrían conducir después a problemas serios delsistema 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

Objetivos del Aprendizaje

LO-3.3.1 Recordar los defectos y los errores típicos identificados por el análisis estático ycompararlos 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 seridentificados por las herramientas de análisis estático. (K1)

Esta sección, Análisis estático por medio de herramientas, cubrirá los siguientes conceptosclave:

Defectos típicos y errores identificados por el análisis estático en comparacióncon 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 deaná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 softwaremismo, pero también puede buscar defectos en los modelos del software como losrequisitos o los modelos ejecutables así como los modelos de rendimiento del sistema quemencionamos anteriormente.

En un contraste adicional, a diferencia de las pruebas dinámicas, el análisis estático serealiza sin realmente ejecutar el sistema, más bien, se ejecuta una herramienta que verificael 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. Laspruebas dinámicas no siempre involucran herramientas

El análisis estático puede encontrar defectos que son difíciles de encontrar o aislar en laspruebas dinámicas.

Los ejemplos incluyen cuestiones de mantenibilidad con el código, que podría ejecutarsebien, pero podría ser difícil de entender (y modificar), así como también la utilizacióninsegura de punteros, que podrían causar una caída o un comportamiento extraño sólo encircunstancias especiales.

Por último, tenga presente que el aislamiento del defecto es más fácil porque ustedencuentra el defecto, no el síntoma o la falla.

¿Qué puede ser objeto del análisis estático? Bueno, muchas cosas pueden, por lo generalmás de lo esperado.

Generalmente, las personas piensan sólo en el código del programa, examinando los flujosde control y el flujo de datos, examinando las violaciones de los estándares decodificació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 uncomponente o sistema.

Flujo de datos: Una representación abstracta de la secuencia y los cambios posibles delestado de los objetos de datos, donde el estado de un objeto puede ser cualquiera de lossiguientes: creación, uso o destrucción.

Hay simuladores que nos permiten analizar los modelos del programa, así como losmodelos de rendimiento.

Podemos comprobar las salidas generadas como HTML y XML acerca de la conformidadcon una sintaxis correcta, los enlaces rotos, y así sucesivamente.

Por último, incluso los análisis usuales, como la ortografía, la gramática, lascomprobaciones de los requisitos acerca de la dificultad de su lectura y la legibilidad y laclaridad de los documentos del diseño.

Las herramientas de análisis estático no son necesariamente económicas, e incluso cuandolo son, las personas no siempre se toman el tiempo para usarlas, porque no entienden losbeneficios del análisis estático.

Al igual que con las revisiones, el análisis estático proporciona una detección temprana ymás económica de los defectos, a menudo mucho antes que la ejecución de las pruebascomience.

Esto significa que los defectos pueden ser encontrados y eliminados en muchos casos fuerade la ruta crítica para la versión, a diferencia de los defectos encontrados y eliminadosdurante los niveles de pruebas en las últimas etapas, como ser las pruebas de sistema y laspruebas de aceptación.

Los análisis estáticos pueden proporcionar advertencias acerca de dónde podrían existiragrupaciones 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íanencontrar, 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 delsoftware. Por ejemplo, enlaces rotos en las páginas Web.

Estos beneficios se combinan para ayudarnos a mejorar la mantenibilidad del código y losdiseñ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 lavariable es un puntero o un resultado erróneo, si es que son utilizados valores aleatorios enun cálculo.

Interfaces inconsistentes entre los módulos y componentes, así como el paso de un enterodonde se requiere un número real.

Variables que nunca son utilizadas, así perdiendo espacio de memoria y códigoinalcanzable (o muerto), lo cual no sólo desperdicia espacio, sino podría crear riesgos deseguridad.

Lógica faltante o incorrecta, así como la utilización del operador de asignación en lugardel 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 lacomplejidad 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álisisestático, y muchas herramientas comerciales de análisis estático incluyen bibliotecasenteras de estándares de codificación.

Algunas herramientas de análisis estático ayudarán también a encontrar especialmentevulnerabilidades de seguridad, las cuales son tipos particulares de violaciones de losestándares de codificación.

Por último, el análisis estático puede localizar las violaciones de sintaxis de código y delos 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, confrecuencia durante las pruebas de componente e integración, aunque ellos comenzaríanidealmente durante la codificación.

Si hablamos de diseño, entonces los usuarios típicos son los diseñadores y los arquitectosdurante el período del diseño. El modelado del rendimiento que hemos mencionado unascuantas veces suele ocurrir en ese punto.

Ahora, una cosa que hemos encontrado con nuestros clientes es que durante la presentacióninicial de las herramientas de análisis del código en una base de código existente, estasherramientas pueden producir un gran número de mensajes de advertencia. Por lo tanto, lerecomendamos el siguiente proceso:

Determine cuáles reglas hará valer y cuáles no son importantes. Desactive las que noson importantes.Exija la utilización de las herramientas de análisis estático, pero sólo en funciones oclases 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 antesde declarar el código como terminado y exíjale que presente los resultados delanálisis estático y las pruebas de unidad, junto con las pruebas unitarias mismas, parauna 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 delcódigo existente—siendo las más propensas que necesitan mantenimiento—se pondrángradualmente en conformidad con los estándares de codificación. En cuanto al resto delcódigo, oiga, si no está causando problemas, creo que las violaciones de los estándares decodificación que existen no están creando demasiados problemas.

Algunas personas utilizan los compiladores para hacer su análisis estático, pero haymuchas herramientas sofisticadas. Sin embargo, algunos compiladores y entornos dedesarrollo 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 delISTQB es que los términos no definidos en el glosario no pueden ser incluidos en elexamen.

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.

Solución del Ejercicio 1 En Omninet, utilizaríamos el análisis estático para el código Java, C++ u otro lenguaje deprogramación utilizado para crear las aplicaciones en los servidores y el procesamiento delos pagos y los períodos de tiempos de los quioscos. También utilizaríamos el análisisestá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 lareacción a la carga. Utilizaríamos ambos, los modelos estáticos como una hoja de cálculo ylos modelos dinámicos como un simulador del rendimiento del sistema de redes. ParaOmninet, los problemas del rendimiento que indicaron cuestiones de arquitectura seríadesastroso si aparecen durante la prueba de sistema. Por cierto, trabajamos en un proyectoque falló debido al descubrimiento tardío de cuestiones de rendimiento básico. Tambiéntrabajamos en un proyecto donde utilizamos modelos estáticos y dinámicos para evitarcualquier descubrimiento tardío de esas cuestiones de rendimiento.

Incluso utilizaríamos comprobadores de ortografía y gramática en las especificaciones delos prototipos de la interfaz del usuario, los requisitos y el diseño y los planes de pruebasy los proyectos. Usted podría preguntar “¿Cuáles problemas importantes podría encontrarun comprobador de gramática?” Si el plan de pruebas incluye demasiadas oraciones converbos pasivos como, “Tantos defectos como sea posible deberían ser detectados”, sinespecificar quién debe hacer qué para detectar esos defectos, es un plan deficiente, uno queno puede ser puesto en acción.

Mientras que somos grandes partidarios del análisis estático, también probaríamos cadauno de los ítems que pasaron por el análisis estático. Asuma que el análisis estático es65% efectivo en promedio y que ha encontrado y eliminado 650 defectos a través delanálisis estático de cada parte de Omninet. Esto significa que 350 defectos han escapado ydeben 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 examende muestra para reforzar su conocimiento y comprensión del material y prepararse para elexamen 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 deSoftware].

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ónguiada.

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

_____________________________

20 Véase el libro de Capers Jones, Estimating Software Costs, para las cifras acerca de laefectividad típica de varias actividades del aseguramiento de calidad y las pruebas.

21 Este ejercicio y su solución han sido adaptados del capítulo 9 del libro de Rex BlackPragmatic Software Testing

22 El libro Estimating Software Costs de Capers Jones cita el 65% como la efectividad delas revisiones de diseño y código, entonces estamos utilizando ese cálculo como unaestimación aproximada de la efectividad del análisis estático solo para ilustrar este punto.