Es decir, conseguiremos controlar si el proceso de desarrollo, la arquitectura empleada o los algoritmos empleados siguen una estructura adecuada, un patrón que nos permita un fácil mantenimiento del producto.

¿Qué es SonarQube?

SonarQube es una de las herramientas más usadas para revisar código, detectar bugs, vulnerabilidades y otros problemas dentro de nuestro proyecto. Permite el análisis de código que se encuentre escrito en los principales lenguajes de programación (Java, PHP, JavaScript, C#, HTML, etc.).

SonarQube se integra como un fichero más dentro del proyecto a analizar y, si el pipeline en el que se lanzan las tareas está correctamente configurado, la inspección del código se hará automáticamente cada vez que hagamos un cambio en alguna parte de dicho proyecto.

Como se muestra en la imagen, el escenario típico en el que mejor puede entenderse su utilidad es el que contiene tres fases claras: 

• Desarrollo – El código es actualizado en el repositorio por los desarrolladores. Antes de solicitar al servicio de SonarQube que analice los cambios, ellos pueden disponer de feedback inmediato gracias a la herramienta SonarLint, que puede ser integrada en los IDEs.
• CI/CD – Al incluir los nuevos cambios en el repositorio, las herramientas de Integración Continua comprueban y construyen el código, y ejecutan las pruebas. Acto seguido se hace la llamada al escáner de SonarQube para que analice los resultados de algunas de esas pruebas y el código como tal. 
• Plataforma de SonarQube – Una vez realizado el análisis del proyecto, los resultados son almacenados en la plataforma y en función de las condiciones de calidad que se configuren, podrá informarse a los miembros del equipo si deben solventar alguna carencia.

Para los diversos proyectos que se realizan en WATA Factory, nos hemos decantado por usar la edición Community, la cuál es libre y de código abierto. Sin embargo, existen otras alternativas de pago que te facilitan la instalación y mantenimiento del servicio de SonarQube por parte de la misma compañía. Para el caso de la versión Community, ésta puede ser instalada en dos modalidades:

• Local – El desarrollador podrá montarse el servicio de SonarQube en su localhost para poder analizar su código sin necesidad de alojarlo en ningún servidor externo o remoto. 
• Remoto – El servicio de SonarQube se encontrará alojado en un servidor remoto dónde se podrá acceder a través de credenciales generadas por el administrador del servicio.  

En función de las necesidades y del tamaño del proyecto (miembros, recursos o servicios a los que acudir), podrás elegir la opción más adecuada según tus circunstancias.

Conceptos generales 

Para entender un poco más la relevancia que tiene el uso de esta herramienta, vamos a detallar los conceptos generales que van a aparecer en la plataforma: 

1. Usuarios y grupos: Al igual que en cualquier entorno, vamos a poder definir usuarios que se organicen en grupos. Cada uno de ellos con una serie de privilegios que les permitirán desde solicitar el análisis de un proyecto hasta validar o cancelar falsos positivos en los análisis realizados. 
2. Proyectos: Para poder realizar el análisis de nuestro código, tendremos que generar un proyecto en la plataforma dónde indiquemos los parámetros que van a identificar nuestro proyecto software. Dichos parámetros, en función del lenguaje que estemos usando en nuestro proyecto, se deberá indicar de una manera u otra. Dentro de estos proyectos encontraremos el análisis de cada uno de ellos, conteniendo los siguientes datos: 
3. Bugs: Errores en el código que deben ser resueltos lo antes posible. 
4. Vulnerabilidades: Puntos del código que se encuentran abiertos a ataques externos y que pueden poner en peligro la integridad y seguridad del proyecto. 
5. Hotspots: Puntos del código que deben ser revisados para evitar problemas mayores, no tienen porqué poner en peligro la seguridad del proyecto. 
6. Code smells: Elementos que hacen que el código sea poco legible o difícil de mantener. 
7. Cobertura: A partir de los reportes de los tests unitarios ejecutados, SonarQube importa los resultados y muestra la cobertura de ellos. 
8. Duplicaciones: Número de bloques, ficheros y líneas duplicadas detectadas. 
9. Total de líneas: Total de líneas de código del proyecto. 
10. Lenguajes: Lenguajes de programación que son usados en el proyecto. 
11. Estado actual: Fail/Passed, dependiendo de los valores establecidos en el perfil de calidad que se le asocien. 
12. Tags: Etiquetas que se le han asignado al proyecto. 
13. Hora del último análisis: Registro de cada uno de los análisis realizados. 
14. Perfiles de calidad: Dependen directamente de las condiciones establecidas en los Quality Gates, las cuales van a indicar cuáles son las reglas que deben seguirse en cada uno de los lenguajes disponibles en SonarQube. Las condiciones de los perfiles de calidad reflejarán límites en cuanto a mínimos de cobertura, líneas duplicadas, índice de seguridad o índice de mantenibilidad. 

Como podemos ver, el reporte y la información generada es muy amplia, lo que nos permite tener una visión muy precisa del estado de nuestro proyecto.

En WATA Factory hemos establecido SonarQube como una herramienta más y ha permitido la mejora de la calidad del código y también, un aprendizaje indirecto de los desarrolladores. Ya que con cada uno de los reportes se aprende qué malas prácticas deben evitar y cómo solventarlas con las propuestas ofrecidas por la misma herramienta, gracias a las reglas definidas en los Quality Gates. En futuros artículos, veremos cómo configurar nuestro proyecto para poder analizarlo con SonarQube de forma automática desde un pipeline. 

The post SonarQube: Cómo mantener la calidad de tu código durante un proceso de CI/CD appeared first on WATA Factory.

Como ya vimos en un artículo anterior, dentro del software testing podemos encontrar dos tipos de pruebas: pruebas manuales y pruebas automatizadas. 

En este artículo, vamos a explicar cuáles son las características, ventajas y desventajas del testing automático en un proyecto software. Para preparar el contenido de esta entrada, he complementado mi experiencia personal con la de diferentes compañeros de nuestro equipo en WATA Factory.

Recomendaremos qué aspectos son los más importantes a tener en cuenta para que el camino al éxito sea lo más fácil y rápido posible. 

Características del testing automátizado 

El testing automático es la técnica que se basa en las acciones desarrolladas por las herramientas de automatización de pruebas. Uno de sus principales objetivos es mejorar el proceso de pruebas de un proyecto software siendo el complemento de mejora de las pruebas manuales. 

A día de hoy, las pruebas automáticas nunca pueden suplir al 100% el beneficio que nos aportan las pruebas manuales. La automatización sólo mejora el proceso de testing ofreciendo ventajas como las pruebas paralelas, el reporte automático, la eliminación de tareas repetitivas para los testers manuales o la reutilización de escenarios de tests. Pero actualmente, el software testing de un proyecto no puede ser cubierto totalmente sólo por las pruebas automáticas. 

Para este tipo de pruebas, la responsabilidad del proceso recae totalmente sobre la herramienta seleccionada y los scripts diseñados por el tester para esa Application Under Test (AUT).  Al contrario que con las pruebas manuales, las automáticas no pueden ser aplicadas en cualquier ámbito. En concreto, la aplicación del testing visual y de UI de forma automática deja aún mucho que desear. Ya que existen proyectos en los cuales se están desarrollando cada día mejores herramientas basadas en la IA, pero no consiguen cumplir todos los objetivos deseados. 

Atendiendo a estos datos, podemos identificar las principales ventajas e inconvenientes del testing automático:

Ventajas

Al contrario que con las pruebas manuales, las pruebas automatizadas nos permiten paralelizar muchas rutinas de trabajo. La planificación de ellas va a ofrecer un gran abanico de posibilidades para mejorar la calidad del producto. Con un mayor nivel de detalle, podríamos decir que todo lo que nos ofrece el testing automatizado es: 

• Velocidad: el tiempo de ejecución es menor. 
• Confiable: se pueden abarcar más permutaciones y caminos en el AUT. 
• Eficiencia: se ejecutan más tests en menos tiempos y se mejora la cobertura del AUT. 
• Los tests son ejecutados automáticamente a partir de los scripts. 
• Los tests pueden ser reutilizados en diversos escenarios. 

Desventajas

Por otro lado, la aplicación de esta técnica de testing conlleva una serie de consecuencias. Entre ellas, la más destacada es la necesidad de tener un equipo de testing más formado en aspectos técnicos para el diseño de los scripts. Y como hemos comentado previamente, las limitaciones que debemos controlar en diversos ámbitos como es el testing de usuario. Si analizamos estas desventajas, podríamos obtener el siguiente listado: 

• Los testers necesitan tener conocimientos técnicos para poder implementar los scripts de tests. 
• No puede aplicarse en todos los tipos de pruebas posibles. Por ejemplo, testing visual. 
• Si los scripts no son correctamente diseñados, podemos generar falsos negativos que reduzcan la fiabilidad de los reportes. 
• No podemos automatizar aspectos como el nivel de usabilidad o cuán intuitivo es la AUT. Necesitamos del test manual para ello. 
• Recomendado para proyectos estables y de larga duración debido a la inversión técnica que debe realizarse. 

El uso del testing automatizado es cada día una tendencia más habitual entre los diversos equipos software debido a las numerosas ventajas que ofrecen. Ya que a pesar de las posibles desventajas que debemos afrontar, el resultado obtenido de su buena aplicación es siempre positivo. 

Sin embargo, partiendo de todos estos detalles que hemos analizado, es necesario que por la parte del tester automático se tengan en cuenta dos aspectos muy importantes: la selección de una buena herramienta de automatización de pruebas y el correcto diseño de los scripts de prueba. En futuras entradas analizaremos cómo podemos hacer frente a estos retos y cómo poner en práctica este tipo de testing dentro de nuestros proyectos. 

The post Automated testing: características, ventajas y desventajas appeared first on WATA Factory.

Conforman todo un ciclo paralelo dentro del desarrollo software y dicho ciclo es conocido como el Ciclo de Vida del Software Testing (CVST).  

Dentro del CVST podemos encontrar pruebas de dos naturalezas diferentes: pruebas manuales y pruebas automáticas. En el caso de las pruebas manuales, la actividad es desarrollada al 100% por el tester. Y en el caso de las pruebas automáticas, sólo un porcentaje de dichas actividades es desarrollada por dicha persona, ya que el resto es realizada por herramientas de automatización. 

Características del testing manual 

El testing manual es la técnica más utlizada a lo largo de la historia del desarrollo de software. Es la primera que permitió la aplicación de pruebas en diferentes niveles: unitario, integración de componentes, interfaz de usuario… Sin embargo, a pesar de que cualquier tipo de prueba puede ser aplicada con las pruebas manuales, esto genera ciertos inconvenientes. Veamos las características con un mayor nivel de detalle: 

Pros:

• Cualquier tipo de test puede ser realizado con pruebas manuales. De hecho, la calidad a nivel de interfaz de usuario (o user-friendly) sólo puede ser controlada por esta categoría de pruebas. 
• Permite analizar escenarios más complejos gracias a la inventiva que puede desarrollar el tester durante su aplicación. 
• El riesgo de detectar un falso negativo es muy bajo debido a la interacción directa con el sistema a probar. 
• Los testers no necesitan tener conocimientos técnicos para poder poner en prácticas las pruebas a realizar. 

Contras:

• La ejecución de las tareas es muy lenta debido a la dificultad de algunos escenarios. 
• El tester debe ser creativo, paciente y con iniciativa para poder encontrar situaciones que pongan a prueba las características del producto. 
• Consume mucho tiempo a la hora de completar las tareas. 
• Muy tedioso debido a la realización manual de todos los pasos que suponen cada una de las pruebas. 
• Es difícil cuantificar el nivel de cobertura de pruebas que tenemos con la realización de este tipo de pruebas.

Cómo ponerlo en práctica 

En WATA Factory tenemos un amplio historial de proyectos en los cuales hemos puesto en práctica las tecnicas de testing manual para poder asegurar y garantizar los niveles de calidad de nuestros productos. 

Cada proyecto tiene unas características diferentes y su puesta en práctica conlleva un análisis de los recursos y requisitos que debemos controlar. Por ello, a la hora de comenzar a aplicar el testing manual se recomienda aplicar los siguientes pasos: 

1. Análisis del sistema: definición de los requisitos funcionales y no funcionales a probar. 
2. Análisis de los recursos con los que disponemos: personas, equipos, tiempos, etc.
3. Planificación de las pruebas manuales a desarrollar: tipos y tiempos de ejecución.
4. Ejecución de las pruebas.
5. Documentación de los resultados obtenidos: reportes de bugs, informes de resultados y requisitos analizados.

Muchos de estos pasos son comunes al proceso de CVST, pero en el caso del testing manual, su aplicación y ejecución es bastante secuencial. 

Por ello, dentro de nuestros proyectos estamos comenzando a aplicar técnicas de testeo automatizado, con las cuales conseguimos reducir los inconvenientes derivados del testeo manual y así aumentar la calidad de nuestros productos. 

The post Manual Testing: aplicando pruebas manuales a un proyecto de software appeared first on WATA Factory.