Pruebas Estáticas Parte 2

  • Autor de la entrada:
  • Categoría de la entrada:Agile / ISTQB

Partiendo de los Conceptos Básicos de las Pruebas Estáticas, en este artículo sigo explorando el tema y me enfoco en plantear ciertos aspectos considerados en esta sección y que no debemos dejarlos de lado para seguir logrando la totalidad del concepto y un mayor entendimiento del  alcance de las pruebas estáticas como:

  • los beneficios
  • las técnicas
  • la integración en el ciclo ágil
  • y finalmente, algunos ejemplos asociados con un proyecto modelo

Momento de reflexionar: ¿Te imaginas poder ir acordando con el equipo que en cada sprint se pueda aplicar parte de estas técnicas para mejorar el código del producto que se esté desarrollando? En mi opinión aquí aplicaría perfectamente los OKRs.

Beneficios de las Pruebas Estáticas para Agile Testers

Para los testers ágiles, y en definitiva para todo el equipo, las pruebas estáticas ofrecen varias ventajas:

  • Detección temprana de defectos: Podemos encontrar errores en los requisitos (historias de usuario), diseños o código fuente antes de integrarlo en el producto final. Todo esto aplica muy bien en el marco Scrum, donde los ciclos de desarrollo son cortos y rápidos.
  • Reducción de costos: Al detectar errores antes de la fase de ejecución podemos reducir el costo de corregirlos, ya que evita que estos defectos se propaguen y afecten a múltiples partes del software.
  • Mejora de la calidad del código: Al utilizar técnicas como la revisión de código y el análisis estático, podemos identificar problemas de calidad del código, como complejidad excesiva, duplicación de código, o incumplimiento de estándares de codificación.
  • Aumento de la eficiencia de las pruebas dinámicas: Las pruebas estáticas ayudan a preparar mejor el terreno para las pruebas dinámicas, de esa forma aseguramos a todo el equipo que se ejecuten sobre una base sólida, libre de errores o problemas básicos de diseño.

Técnicas de Pruebas Estáticas

Existen varias técnicas de pruebas estáticas que son esenciales para los testers ágiles:

  • Revisión de documentos: Implica revisr de manera manual de documentos relacionados con el desarrollo del software, como requisitos, especificaciones de diseño, y casos de prueba. Esto puede incluir revisiones informales, revisiones por pares (tanto entre programadores como entre testers como incluso entre POs), y revisiones técnicas formales (inspecciones). El objetivo es asegurar que todos los documentos sean claros, consistentes y completos.

  • Revisión de código: Esta técnica se centra en la revisión manual del código fuente para identificar defectos, errores de lógica, o incumplimientos de las mejores prácticas de codificación. Las revisiones de código suelen realizarse en equipos, lo que fomenta la colaboración y el intercambio de conocimientos entre desarrolladores y testers.

  • Análisis estático de código: Utiliza herramientas automatizadas para analizar el código fuente en busca de errores, problemas de seguridad, o incumplimientos de estándares de codificación. Herramientas como SonarQube (Nota: tengo publicado algunos artículos), Checkstyle, y ESLint son comunes en este contexto. Este enfoque es eficiente y puede integrarse fácilmente en el pipeline de CI/CD.

  • Análisis de métricas: Este análisis incluye la evaluación de métricas de calidad del código, como la complejidad ciclomática, cobertura de código, y la cantidad de líneas de código. Estas métricas proporcionan una visión cuantitativa de la calidad del software y ayudan a identificar áreas de riesgo potencial.

Momento para reflexionar: ¿Cuánto trabajo en conjunto con los desarrolladores merecen cada una de las tareas mencionadas aquí?

Integración de Pruebas Estáticas en el Ciclo Ágil

En un entorno ágil como el marco Scrum, las pruebas estáticas deben integrarse en el proceso de desarrollo desde el principio. 

  • Incorporación en sprints: Deberíamos pensar en planificar sesiones de revisión de código y documentos al final de cada sprint, de esa forma estaríamos asegurando que los errores se identifiquen rápidamente y se resuelvan antes del siguiente incremento de software.
  • Automatización en CI/CD: Deberíamos pensar en integrar herramientas de análisis estático en el pipeline de CI/CD, de esa manera podemos detectar problemas en cada commit y así darle feedback instantáneo a los desarrolladores.
  • Revisiones continuas: Deberíamos pensar e promover una cultura de revisiones continuas de código y documentos. En lugar de esperar a una revisión formal, fomentamos revisiones rápidas y frecuentes entre los desarrolladores y nosotros, los testers ágiles.

Momento para reflexionar: ¿Cuánto conocimiento hay que adquirir para llegar a este nivel de madurez con el equipo?

Ejemplos de Pruebas Estáticas en un Proyecto de Aplicación Web para Vender Paquetes Turísticos

Supongamos que estamos trabajando en un proyecto para desarrollar una aplicación web responsive que vende paquetes turísticos. Aquí hay algunos ejemplos de cómo se podrían aplicar las pruebas estáticas:

Revisión de requisitos y documentación:

Antes de comenzar a codificar la funcionalidad «Buscar paquete», el equipo revisa el documento de requisitos para asegurarse de que los campos obligatorios («¿Adónde quieres viajar?», «¿En qué mes quieres ir?», «¿Desde dónde quieres salir?») estén claramente definidos y no haya ambigüedades. Identificar cualquier inconsistencia en esta fase evita confusiones durante el desarrollo y asegura que los criterios de aceptación sean claros.

Revisión de código:

Durante el desarrollo de la funcionalidad «Buscar paquete», los desarrolladores realizan revisiones de código por pares para verificar que la lógica de validación del formulario es correcta. Se asegura que el botón «Buscar» solo se habilite cuando todos los campos obligatorios estén completados correctamente. Esta revisión ayuda a identificar posibles errores de lógica o malentendidos sobre los requisitos antes de que se integren en el código base.

Análisis estático de código:

Una herramienta de análisis estático como SonarQube se integra en el pipeline de CI/CD para verificar el código fuente de la aplicación en cada commit. Esto permite detectar problemas como el uso incorrecto de variables, problemas de seguridad, o incumplimientos de las mejores prácticas de codificación, como la falta de manejo de errores en la lógica del formulario de «Buscar paquete».

Análisis de métricas de código:

El equipo utiliza SonarQube para evaluar la complejidad ciclomática del código de la funcionalidad «Buscar paquete». Una alta complejidad puede indicar que el código es difícil de mantener o probar. Si se detecta un valor alto, el equipo puede refactorizar el código para simplificarlo, mejorando así la calidad y mantenibilidad del software.

Revisiones técnicas formales (Inspecciones):

Antes de cada lanzamiento, el equipo organiza una sesión de inspección formal para revisar los artefactos de prueba y el código crítico. Para la funcionalidad «Buscar paquete», esto incluiría revisar la implementación del formulario y la lógica de backend que maneja las consultas de búsqueda. Esta revisión formal ayuda a garantizar que todo el equipo esté alineado y que no se pasen por alto defectos importantes.

Momento para reflexionar: ¿Podrías hacer el ejercicio de imaginar aplicar cada una de estas técnicas en tu proyecto actual? ¿Qué te impide hacerlo? ¿Cuánto conocimiento debes adquirir? ¿Tienes algún mentor o referente que te pueda ayudar? ¿Los desarrolladores de tu equipo están al tanto de estas prácticas? ¿Tu proyecto lo requiere a corto / mediano plazo? ¿Qué valor le aportaría al negocio en cada sprint? ¿Cuánta calidad impulsarías en el producto que se está desarrollando?

Comentario final

Si te ha servido este contenido basado en el programa de estudios del ISTQB CTFL v4.0, me alegro y mucho. También te cuento que me puedes seguir en LinkedIn e interactuar con otros colegas testers que me siguen y que están interesados en contenidos relacionados con agile testinginteligencia artificial y OKRs aplicado a testing. Muchas gracias

Gus Terrera

Apasionado por el agile testing y la ia.