Introducción
¿Porqué es importante estudiar el programa de estudios ISTQB CTFL v3.1?
La primera respuesta es que su contenido nos permite adquirir un conocimiento teórico importante, comprender la base de nuestra práctica profesional y además reconocer el alcance de nuestra actividad como testers de software en proyectos en los que se desarrollan productos de software y requieren de un control de la calidad.
Ahora bien, en este artículo quiero ir un poco más allá y explicar una primera asociación de conceptos en este caso con una herramienta que trata justamente el análisis estático de código: SonarQube.
Por tal motivo, primero estaré contándote acerca de esta herramienta para luego analizar los términos como: Caja Blanca, Vulnerabilidad, Seguridad, Análisis Estático de Código, que tienen un común denominador y de eso trata el artículo.
Acerca de SonarQube -Introducción-
SonarQube es una herramienta open-source de las más utilizadas en el mercado para efectuar análisis estático de código y gestionar las métricas y gráficos que ofrece para mejorar la calidad del software. Escribir un código más limpio y seguro es justamente el objetivo que permite alcanzar la herramienta SonarQube.
SonarQube sirve para realizar de manera automática análisis del código fuente, sobre la base de la inspección continua del código para garantizar la calidad del software. Dicho de otra forma, sirve para implementar Clean Code, detectando errores y problemas de seguridad.
Se aplica durante la etapa de testing, tanto por el desarrollador como por el agile tester.
Sirve de guía para el desarrollador dentro del ciclo de desarrollo del software ya que por medio de la herramienta puede ir revisando su código.
Principales características
- SonarQube está desarrollado en Java.
- Puede analizar y gestionar hasta 29 lenguajes de programación, a través de conjuntos de reglas incorporados.
- Se integra con herramientas de CI/CD (Jenkins, GitHub, Azure DevOps…).
- Customizable con una gran variedad de plugins (extensiones).
- A través de SonarLint, plugin IDE libre y código abierto, ayuda a que los desarrolladores mientras escriben el código fuente puedan detectar y solucionar errores en tiempo real.
- En su versión Community (gratuita) soporta hasta 17 lenguajes de programación.
{ https://www.sonarsource.com/open-source-editions/SonarQube-community-edition/ }
El porqué de su uso
- Es una herramienta que se enfoca en analizar el código.
- Ayuda a detectar problemas de manera temprana.
- Permite una rápida solución del problema.
- Facilita el mantenimiento de un código limpio y seguro.
- Permite a quien desarrolla código, que implemente fácilmente una inspección continua, pudiendo buscar, controlar y verificar la calidad continua del código.
- A través de las métricas y gráficos que ofrece, se pueden conocer datos sobre pruebas unitarias, cobertura de código, código duplicado, estándares de codificación, complejidad del código, errores potenciales, comentarios, entre otros.
- Se puede ampliar su potencial mediante una gran variedad de extensiones.
Tipos de incidentes
- Bug
- Vulnerability
- Code Smells
Algunos de los aspectos que verifica
- Código duplicado.
- Código muerto.
- Bugs.
- Ausencia de pruebas unitarias.
- Ausencia de comentarios.
- Complejidad ciclomática (depende del número de caminos independientes del código)
- Tamaño del código.
- Estándares de calidad de codificación.[*]
- Vulnerabilidades.
[*] Por medio del «Quality Gate», podemos establecer nuestras propias condiciones de calidad y seguridad del código, configurando métricas y los respectivos umbrales.
Beneficios
- Ofrece de manera temprana un estado de situación del código previo a su pasaje a producción.
- Muestra no sólo errores sino vulnerabilidades y otros datos como reglas de codificación, cobertura de las pruebas, complejidades, duplicaciones y otros.
- Permite definir y/o re-definir estándares de calidad sobre los cuales apoyarse e ir comparando.
- Reduce tiempos y costos adicionales.
- Detecta patrones de errores y/o malas prácticas.
- Permite calcular y gestionar la deuda técnica.
Requisitos para trabajar con SonarQube
Componentes a bajar
- jdk versión 11
- SonarQube
- sonarscanner
jdk versión 11
El primer componente que necesitas tener es el jdk de Java versión 11 (alternativas para poder bajar hay varias: desde el sitio oficial de Oracle ó desde OpenLogic ó desde JetBrains). Tener en cuenta las recomendaciones en el sitio oficial de SonarQube.
{ https://docs.sonarsource.com/SonarQube/latest/requirements/prerequisites-and-overview/ }
Tener en cuenta que se puede descargar un zip o una imagen de docker
SonarQube
El segundo componente es el SonarQube (recomendación: tener la carpeta creada en tu pc). Tenemos a disposición la edición Community que es gratuita para bajar.
{ https://www.sonarsource.com/open-source-editions/SonarQube-community-edition/ }
Algunas de sus características más sobresalientes son:
- soporta los lenguajes más populares
- se integra con plataformas de devops (GitHub, GitLab, Azure, Bitbucket)
- permite hacer el check de calidad del código (pasa / no pasa)
- análisis super rápido
- configuraciones compartidas y unificadas
- integración con la extensión SonarLint
Acerca del concepto «lint»
Derivado de «linter», en programación un linter es una herramienta enfocada a la mejora del código a través del análisis del código fuente, con el propósito de detectar problemas.
SonarScanner
El tercer componente es el SonarScanner
{ https://docs.sonarsource.com/SonarQube/latest/analyzing-source-code/scanners/sonarscanner/ }
Sobre el término SAST
Static Application Security Testing (SAST) son un conjunto de tecnologías diseñadas para analizar el código de las aplicaciones con el objeto de detectar vulnerabilidades de seguridad.
El enfoque que tiene SAST es analizar de “adentro hacia afuera” y sin ejecutar código, tal y como lo define la técnica White Box testing.
SonarQube es la herramienta mediante la cual se puede aplicar SAST para una inspección continua de la seguridad y calidad del código a través de revisiones automáticas con análisis estático del código.
El testing que se lleva a cabo por medio de SonarQube se puede integrar con el pipeline CI/CD, dentro del ciclo de DevOps, y a este esquema se lo denomina “Shift to the left”.
Cuanto más temprano se detectan errores y vulnerabilidades en las aplicaciones más simple y menos costosa resulta su corrección.
Reflexiones
Reflexión #1
La expresión “análisis estático” tiene varias referencias dentro del Programa de Estudios del ISTQB CTFL v3.1.
3.1. Prueba Estática: Conceptos Básicos
Evaluación del código u otros productos de trabajo que se esté probando, mediante herramientas sin ejecutar el código.
Su utilidad aplica:
- a sistemas informáticos de seguridad crítica (p.e. aeronáutica, medicina, nuclear entre otros).
- en pruebas de seguridad (p.e. para garantizar que se apliquen los estándares de OWASP).
- en marcos de desarrollo ágil, en entrega y despliegue continuo.
3.1.1. Productos de trabajo que pueden ser evaluados por una prueba estática
El análisis estático se aplica de manera eficiente en cualquier producto de trabajo que posea una estructura formal: código fuente y/o modelos (diagramas de actividad) mediante su correspondiente herramienta de análisis estático.
5.6. Gestión de defectos
Los defectos pueden ser informados durante el análisis estático de código.
6.1.1. Clasificación de las herramientas de prueba / Soporte de Herramientas para la Prueba Estática
Hay muchos tipos de herramientas que dependiendo del contexto será su objetivo.
Un tipo de herramientas son aquellas que dan soporte y más adecuadas para los desarrolladores e identificadas en el programa de estudios con la letra “D” como es el caso para pruebas estáticas.
La misma expresión la podemos encontrar en la versión 4.0 en los siguientes apartados (más adelante estaré generando contenido detallado):
- 1.1. ¿Qué es probar?
- 2.1.4. DevOps y la Prueba
- 2.1.5. Enfoque “Desplazamiento a la izquierda”
- 3. Prueba Estática – Fundamentos
- 3.1.1. Productos de trabajo susceptibles de ser examinados mediante prueba estática
- 3.1.2. Valor de la Prueba estática
- 5.2.4. Control del riesgo de producto
- 5.5. Gestión de defectos
- 6.1. Herramientas de apoyo a la prueba.
Reflexión #2
El “análisis estático” tiene relación con la “prueba estática” y de aquí a considerar dos apartados del Programa de Estudios del ISTQB CTFL v3.1.
3.1.2. Ventajas de la Prueba Estática
3.1.3. Diferencias entre la Prueba Estática y la Prueba Dinámica.
Partiendo de la definición:
La prueba estática se basa en la evaluación manual de los productos de trabajo (denominada revisión) o en la evaluación del código u otros productos de trabajo basada en herramientas (análisis estático). En cualquier caso, sin ejecutar el producto sometido a prueba.
Habiendo planteado la definición que se encuentra en el Programa de Estudios del ISTQB CTFL v3.1, compartiré las siguientes conclusiones de los apartados arriba mencionados.
Respecto de: 3.1.2. Ventajas de la Prueba Estática
- Detección temprana de defectos antes de ejecutar pruebas dinámicas.
- Reducción del costo de desarrollo puesto que un defecto detectado antes de ser desplegado en producción y durante el uso del mismo, será menor.
- Reducción del costo de efectuar pruebas dinámicas para encontrar defectos y corregirlos aplicando técnicas de prueba estática, especialmente considerando los costos adicionales de actualización de otros productos de trabajo, pruebas de confirmación y pruebas de regresión.
- Detección de defectos que pueden no encontrarse con pruebas dinámicas.
- Prevención de defectos en la codificación (aplicando análisis de código con SonarQube).
- Reducción del costo y tiempo de desarrollo.
- Incrementar la productividad de desarrollo.
- Reducción del costo y tiempo de prueba.
- Reducción del costo total de la calidad en el ciclo de vida del desarrollo de software.
- Reducción del tiempo de análisis ya que se está revisando al código sin ejecutarlo
Respecto de: 3.1.3. Diferencias entre la Prueba Estática y la Prueba Dinámica.
- Tienen un mismo objetivo: proporcionar una evaluación de la calidad del producto de trabajo e identificar los defectos de forma temprana lo más pronto posible.
- Una de las principales diferencias es que la prueba estática detecta defectos en los productos de trabajo directamente, en lugar de identificar fallos que se originan a partir de defectos cuando se ejecuta el software.
- La prueba estática puede requerir un menor esfuerzo en encontrar un defecto que puede residir en un producto de trabajo durante mucho tiempo sin provocar fallo, frente a una prueba dinámica que tendrá un mayor costo de esfuerzo.
- La prueba estática se puede usar para mejorar la consistencia y calidad interna del producto de trabajo.
- La prueba estática puede detectar y corregir defectos de codificación, desviaciones con respecto a estándares, vulnerabilidades de seguridad.
- La prueba estática puede detectar la mayoría de los tipos de defectos de mantenibilidad:modularización inadecuadamala reutilización de los componentescódigo difícil de analizar y modificar sin introducir nuevos defectos
Reflexión #3
Las técnicas de caja blanca tienen relación con el análisis estático, y en el Programa de Estudios del ISTQB CTFL v3.1. nos encontramos con varias referencias.
2.3.3. Prueba de Caja Blanca
2.3.5. Tipos de prueba y Niveles de Prueba
Para la prueba de componente, las pruebas están diseñadas para lograr una cobertura completa de sentencia y decisión (ver sección 4.3) para todos los componentes que realizan cálculos financieros. (Nota: uno de los ejemplos de caja blanca)
4.1.2. Categorías de Técnicas de Prueba y sus Características
Las técnicas de prueba de caja blanca (también llamadas técnicas estructurales o basadas en la estructura) se basan en un análisis de la arquitectura, el diseño detallado, la estructura interna o el código del objeto de prueba. A diferencia de las técnicas de prueba de caja negra, las técnicas de prueba de caja blanca se concentran en la estructura y el procesamiento dentro del objeto de prueba.
4.1.2. Categorías de Técnicas de Prueba y sus Características
Las técnicas de prueba basadas en la experiencia aprovechan la experiencia de desarrolladores, probadores y usuarios para diseñar, implementar y ejecutar pruebas. A menudo, estas técnicas se combinan con técnicas de prueba de caja negra y caja blanca.
4.1.2. Categorías de Técnicas de Prueba y sus Características
La cobertura se mide en base a los elementos probados dentro de una estructura seleccionada (por ejemplo, el código o las interfaces). (Nota: una de las características comunes de la técnica de caja blanca)
4.3. Técnicas de Prueba de Caja Blanca
Las técnicas de prueba de caja blanca se basan en la estructura interna del objeto de prueba. Las técnicas de prueba de caja blanca se pueden utilizar en todos los niveles de prueba, pero las dos técnicas relacionadas con el código que se discuten en esta sección se utilizan con mayor frecuencia en el nivel de prueba de componente.
4.4.2. Prueba Exploratoria
La prueba exploratoria está fuertemente asociada con las estrategias de prueba reactivas (ver sección 5.2.2). La prueba exploratoria puede incorporar el uso de otras técnicas de caja negra, caja blanca y basadas en la experiencia.
Reflexión #4
El concepto de vulnerabilidades está relacionado con el análisis estático de código, y en el Programa de Estudios del ISTQB CTFL v3.1. nos encontramos con varias referencias.
Comprobación de vulnerabilidades de seguridad.
2.2.4. Prueba de Aceptación / Prueba de Aceptación Operativa
Fallos no funcionales tales como vulnerabilidades de seguridad.
2.2.4. Prueba de Aceptación / Defectos y Fallos Característicos
El diseño y la ejecución de la prueba no funcional puede implicar competencias o conocimientos especiales, como el conocimiento de las debilidades inherentes a un diseño o tecnología (por ejemplo, vulnerabilidades de seguridad asociadas con determinados lenguajes de programación).
2.3.2. Prueba No Funcional
Para la prueba de integración de componentes, las pruebas de seguridad están diseñadas para vulnerabilidades de desbordamiento de memoria intermedia debido a que los datos pasan de la interfaz de usuario a la lógica de negocio.
2.3.5. Tipos de Prueba y Niveles de Prueba
Modificaciones, tales como … parches para los defectos y las vulnerabilidades.
2.4.1. Activadores para el Mantenimiento
Vulnerabilidades de seguridad (por ejemplo, susceptibilidad a desbordamiento de la memoria intermedia).
3.1.3. Diferencias entre la Prueba Estática y la Prueba Dinámica
Reflexión #5
Aquí se puede comprender la diferencia entre los términos QA (Quality Assurance) y QC (Quality Control).
Mientras que el término QC corresponde sencillamente a testing, o sea que el software tester (tradicional o agile) lleva a cabo QC, la persona con el rol de QA cumple con las siguientes funciones:
- Define de manera individual o en conjunto con el equipo que corresponda de acuerdo con la estructura de la organización, procedimientos y estándares de calidad de software.
- Supervisa la calidad del software en cada una de las fases del proceso de desarrollo.
- Colabora con el equipo de QC en implementar los estándares definidos en cada uno de los procesos de prueba en los diferentes niveles de prueba.
- Colabora con el equipo de developers en la implementación de las mejores prácticas de desarrollo de acuerdo a los estándares de calidad definidos.
Reflexión #6
¿Que estarán buscando las empresas que solicitan QA Tester?
Sin lugar a dudas está mal expresado porque parte de la base de un desconocimiento del lado del área de reclutamiento ya que no se ha comunicado debidamente.
Referencias
https://www.youtube.com/watch?v=6pLj3KVglFA
https://www.youtube.com/watch?v=5UoygWLrBqo
https://sentrio.io/blog/que-es-sonarqube/
https://www.sonarsource.com/
