Blog

En esta sección 3.1. Conceptos Básicos de las Pruebas Estáticas del Capítulo 3. Pruebas Estáticas del programa de estudios del ISTQB CTFL v4.0, adelanta varios aspectos que debemos tener en cuenta para comprender su alcance:

• explica la diferencia entre las pruebas estáticas con las pruebas dinámica, 
• los objetos de trabajo que son evaluables,
• la manera de evaluar: manual o mediante herramientas
• sus objetivos,
• su aplicación tanto para la verificación como para la validación,
• los usuarios involucrados,
• las ventajas que proporcionan y garantizan las técnicas de revisión,
• los beneficios que ofrece aplicar análisis estático,

En esta sección (3.1.) el programa de estudios indica la vinculación que tiene el análisis estático con:

• el capítulo 5 Gestión de las actividades de prueba, sección 5.1.3. Criterios de entrada y de salida (Definición de preparado),
• el capítulo 6 Herramientas de Prueba,
• el capítulo 2 Pruebas en el contexto de un SDLC, sección 2.1.4. (Integración Continua),

Muy bien, hasta aquí una síntesis de la sección y a continuación estaré profundizando el tema.

Conceptos básicos sobre las pruebas estáticas

Las pruebas estáticas son un tipo de pruebas de software que se realizan sin ejecutar el código de la aplicación. 

Las pruebas dinámicas requieren la ejecución del software para validar su comportamiento.

Los objetos de trabajo evaluables pueden ser: 

• el código
• la especificación del proceso
• la especificación de la arquitectura del sistema

Momento para reflexionar: ¿Qué otros objetos de trabajo incluirías en esta lista y que te hagan sentido para tu proyecto?

La manera de evaluar dichos productos de trabajo puede ser:

• de manera manual, aplicando revisiones,
• ayudados con herramientas, aplicando análisis estático (p.e. sonarqube),

Momento para reflexionar: ¿Hay algún equipo que esté utilizando alguna herramienta como la mencionada o alguien que esté aplicando la técnica de revisión?

Los objetivos de las pruebas estáticas incluyen

• mejorar la calidad,
• detectar defectos
• evaluar la legibilidad, completitud, corrección, comprobabilidad, consistencia

Momento para reflexionar: ¿De que forma podemos ayudar para cumplir con alguno de estos objetivos? ¿Acaso interviniendo de forma más activa o si se quiere, proactiva en la Planificación del Sprint o será que en la Retrospectiva o en el Refinamiento es más apropiado?

Una manera de acercarnos a impulsar acciones para que podamos cumplir con los objetivos pudiera ser que juntos con el Product Owner y Developers trabajemos en el mapeo del Backlog, ayudándolo al Product Owner desde el aspecto técnico claro está.

¿Cómo? Podemos compartir todo lo que sepamos acerca de los desarrollos que se deben encarar para garantizar que las historias de usuario y todos los componentes relacionados cumplan con sus criterios de aceptación y podamos así contar con los escenarios de prueba que necesitamos.

Momento para reflexionar: Aquí habría que saltar hasta el capítulo 5 / 5.1.3. en el que se menciona el concepto de Definición de Preparado/Listo y que tiene que ver con los criterios de entrada que toda historia de usuario debe cumplimentar para iniciar las actividades de desarrollo y prueba. Hay varias situaciones que te pueden dar idea y aterrizar estos conceptos al plano práctico.

Técnicas de revisión

El objetivo que buscamos aquí es garantizar que las historias de usuario estén completas y sean comprensibles, poniendo mucho foco en que los criterios de aceptación sean comprensibles, tanto para los desarrolladores como para nosotros, los testers.

¿Cómo? Haciendo las preguntas correctas, para lo cual habrá que saber no sólo del negocio sino de nuestra práctica como para aportar valor. Debemos explorar y desafiarnos a nosotros mismos incluso para ayudar a mejorar el alcance de las historias de usuario. 

En este sentido y con todas las recomendaciones relacionadas con la seguridad y la confidencialidad de los datos, entre otras cuestiones que vengo recomendando en mis diferentes artículos a partir de lo que vengo estudiando y aplicando, la GenAI nos puede comenzar a ayudar mucho ofreciéndonos alternativas que hasta ese momento no las teníamos para aumentar y/o automatizar algunas de nuestras tareas como agile testers.

Pero bueno, volvamos al Syllabus y a las pruebas estáticas.

Análisis estático

El objetivo que buscamos aquí es detectar problemas antes de realizar las pruebas dinámicas, y es tan importante el concepto que en el programa de estudios, encontraremos referencias en distintos capítulos como ser:

• 2.1.4 DevOps y pruebas
• 2.1.5. Enfoque del desplazamiento hacia la izquierda
• 3.1.2. Valor de las pruebas estáticas
• 5.2.4. Control de riesgos del producto
• 5.5. Gestión de defectos
• 6.1. Soporte de herramientas para las pruebas

Así que fijate si no es importante el concepto y todo el contenido que hay por explorar y estudiar!

No sólo sirve para detectar defectos de código sino además para evaluar la capacidad de mantenimiento y seguridad, aspectos que están considerados por ejemplo en la herramienta SonarQube (tengo algunos artículos publicados al respecto e incluso hay un webinar). 

Un tema interesante para profundizar cuando tengas tiempo, es todo lo vinculado con OWASP que si bien no está considerado en el programa de estudios, hace a todo ésto ya que por ejemplo SonarQube tiene embebido en sus prácticas, varias de las recomendaciones planteadas en OWASP.