Fundamentos de Pruebas de Software - Capítulo 3

  • 828 views
Uploaded on

Las Pruebas de Software son todavía una de las áreas más desatendidas del desarrollo y espliegue de los productos de software. Las Pruebas de Software son predominantemente vistas como una actividad …

Las Pruebas de Software son todavía una de las áreas más desatendidas del desarrollo y espliegue de los productos de software. Las Pruebas de Software son predominantemente vistas como una actividad periférica, casi una formalidad, antes del espliegue del software. Un cambio de actitud y un buen programa de estudios como fundamento hacia las Pruebas de Software pueden reducir tremendamente los problemas normalmente asociados con el lanzamiento del nuevo software y minimizar el riesgo implicado. El programa de estudio del ISTQB (International Software Testing Qualifications Board) Probador Certificado (Certified Tester) ofrece el mejor
entrenamiento estandarizado del mundo para los probadores de software.

Este libro le proporcionará el conocimiento esencial para ser un profesional en Pruebas, que incluye:

Fundamentos de Pruebas
Pruebas a través del Ciclo de Vida de Software
Técnicas Estáticas
Técnicas de Diseño de Pruebas
Gestión de Pruebas
Soporte de las Herramientas de Pruebas
Adquisición de Herramientas y Software en General en una Organización
Más de 200 preguntas de examen de muestra con soluciones
Ejercicios prácticos y soluciones por cada tema cubierto
Caso real, resuelto, como ejemplo a lo largo de los temas
Dos exámenes de simulación del examen real
Estándares de Pruebas
Excelente Bibliografía

Cabe señalar que este libro no es sólo para los probadores sino también para quienes están encargados de la adquisición de software en general, gerentes de tecnología, gerentes del Aseguramiento de la Calidad/Control de la Calidad (QA/QC), gerentes de sistemas, jefes de proyectos de software, analistas, arquitectos, desarrolladores, estudiantes y profesores de TI.

Asimismo este libro está diseñado para el autoestudio. El contenido comprende el programa de estudios necesario para aprobar el examen de certificación nivel básico definido por el ISTQB versión 2011 (Syllabus 2011).

More in: Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
828
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
121
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. 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
  • 2. 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
  • 3. 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
  • 4. 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
  • 5. 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 Objetivos del Aprendizaje LO-3.2.1 Recordar las actividades, los roles y las responsabilidades de una revisión formal típica. (K1)
  • 6. 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
  • 7. 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
  • 8. 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.
  • 9. 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.
  • 10. 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
  • 11. 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
  • 12. 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
  • 13. 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
  • 14. 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.
  • 15. 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. 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 en el Documento de los Requisitos de Marketing. Encontramos más de veinte cuando realizamos este ejercicio por nosotros mismos (véase
  • 16. 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.
  • 17. 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 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)
  • 18. 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.
  • 19. 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
  • 20. 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:
  • 21. 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. Solución del Ejercicio 1 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
  • 22. 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.
  • 23. 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.
  • 24. 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.
  • 25. Capítulo 3 Pregunta a través de las secciones Preguntas del Examen de Simulación 1
  • 26. Preguntas del Examen de Simulación 2
  • 27. _____________________________ 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.