La importancia de anticipar los aspectos de seguridad en los sistemas

En un mundo cada vez más interconectado, donde la automatización de procesos rutinarios aumenta cada día gracias a la tecnología actual (entre la que destacan la robótica, la inteligencia artificial y el internet de las cosas) es de vital importancia anticipar el mayor número de riesgos en las fases tempranas de los procesos de construcción de sistemas.

La anticipación de dichos riesgos, práctica conocida como shift left en ambientes técnicos, es una práctica “obligatoria” hoy en día para reducir los fallos de los sistemas, en especial todos aquellos aspectos relacionados con la seguridad, tanto de las personas que interaccionan con los sistemas (safety), como de la protección de los datos y sistemas de la información empleados (security). Ejemplos como el vehículo autónomo o los robots que emplea Amazon en sus almacenes, pasando por dispositivos wearables, aspiradoras inteligentes y asistentes personales como Alexa, Siri o google home, cada vez más empleadas en la vida cotidiana, son un claro indicativo. ¿Imagináis el impacto y la desconfianza que podría generar que de forma sistemática se produjeran accidentes en los almacenes de Amazon, producidos por sus robots? ¿O que un mal funcionamiento de un sensor de un coche autónomo causa un accidente? ¿O que alguien fuera capaz de hackear el asistente de voz de tu casa y espiarte, o de hackear tu aspirador y pudiera tener una imagen completa del plano de tu casa o cualquier edificio oficial donde se hace uso de esta tecnología?

Desde el punto de vista del usuario estos aspectos son críticos, pero si nos situamos en el punto de vista de la empresa, ¿cuál es el coste de un fallo en un sistema? Es de absoluto sentido común pensar que cuanto más tarde se detecte, mayor será el coste del mismo, siendo crítico cuando el sistema ya está implantado, donde no solo se debe tener en cuenta el coste operacional derivado de su resolución y/o sustitución, sino que también habrá que tener en cuenta el impacto en la reputación de la compañía que probablemente genere más daño en la cuenta de resultados.

Para reducir el impacto de dichos fallos es importante implantar mecanismos que anticipen los riesgos , como es el ejemplo de la cultura devops que, además de automatizar procesos de integración, testing, despliegue y entrega continua, disponga también de un flujo de información continuo que retroalimente las iteraciones de los distintos procesos de la construcción de sistemas.

Estas prácticas de ingeniería requieren la aplicación de técnicas, metodologías, herramientas y estándares que en aspectos como la seguridad no están al alcance de toda la comunidad dedicada a la construcción de sistemas. Con el objetivo de facilitar el acceso a esta información nacen las conferencias QA&TEST Safety and Security, un punto de encuentro internacional, multidisciplinar y multisectorial, donde los asistentes podrán conocer experiencias y prácticas  empleadas por otros profesionales del sector donde estos aspectos son críticos en el éxito de sus productos.

Desde el comité técnico hemos intentado que el contenido de la conferencia cubra una parte muy demandada actualmente, que a día de hoy no tenía cobertura en otros eventos, desde un punto de vista didáctico, práctico, y sobre todo que aporte valor y visión a los asistentes.

QA&Test Safety and Security tendrá lugar en Madrid entre el 27 y 28 de marzo. Desde QA Lovers, puedes conseguir tu entrada con un 20% de descuento, usando el código: QALOVERS20.

Dos días llenos de experiencia, información y sinergias con gente diferente pero con inquietudes similares, donde esperamos que los asistentes adquieran nuevos conocimientos y contactos que les permitan recorrer el camino hacia un ámbito Safety and Security, algo que sin duda será uno de los aspectos fundamentales de la cuarta revolución industrial.

Santiago García Nieto

Software Development Manager en Confirma Sistemas

Miembro del Comité Técnico de QA&TEST Safety and Security

Estrategia de pruebas para dispositivos móviles y navegadores

La necesidad que tenemos de realizar validaciones en dispositivos móviles es ya una realidad. Todas las empresas tienen ya presencia en ellos ya sea por tener apps nativas como portales responsive.

Ahora mismo, una mala app en un dispositivo, es el detonante perfecto para que una empresa pierda mucho dinero y tenga menor presencia en relación a sus competidores.

Esto, lo sabemos todos nosotros, ya que, si instalamos una app en nuestro dispositivo y esta tiene un mal funcionamiento, es lenta o falla, directamente buscaremos una alternativa y la desinstalaremos. El usuario medio, es realmente exigente y eso se demuestra cada día en que, los smartphone actuales tienen unos procesadores muy potentes.

La demanda actual de dispositivos y aplicaciones móviles, nos hace tener estrategias de validación para dispositivos, teniendo en cuenta que debemos obtener un nivel de exigencia aún más alto. 

Lo primero que debemos de hacer es estudiar el mercado, y herramientas como NET Marketshare, nos da exactamente eso: que dispositivos, navegadores y sistemas operativos son los más utilizados. Así vamos cubriendo, poco a poco, la demanda y utilización actual.

Este portal, nos ofrece diferentes gráficas, datos y detalles actualizados, que nos dan una idea global de por donde se mueve el mercado y donde tenemos que atacar. Evidentemente, no podemos tener todos los móviles ni creo que desembolsar grandes cantidades de dinero, sea eficiente, ya que, en muy poco tiempo, ese parque de dispositivos se habrá quedado anticuado.

Cuando realicemos las búsquedas necesarias o que nos ayuden y tengamos un número que consideremos adecuado de dispositivos, que vendrá dado por el tipo de proyecto y los usuarios potenciales que van a usar la aplicación, en concreto, debemos de ver que sistemas operativos son los más utilizados. Habitualmente, estaremos hablando de Android e iOS en diferentes versiones, donde iOS tiene un nivel de actualización y utilización de la última versión, muy superior a Android.

En este último, la actualización del sistema operativo suele ir de la mano de los últimos modelos de dispositivos del mercado, que no todo el mundo tiene o compra. Son dispositivos más longevos, pero menos actualizados.

Una vez hemos obtenido los datos adecuados para nuestra aplicación, procedemos a realizar una tabla, donde mezclaremos los dispositivos con las versiones y seleccionando tablet y smartphone entre ellos, posibilitando que todas las versiones estén probadas en diferentes dispositivos con tamaños, también, diferentes.

Mi recomendación es que solo repitáis tamaño de pantalla en dispositivos diferentes, por ejemplo, un Samsung Galaxy y un iPhone, no dos iPhone con distintos sistemas operativos. 

De esta manera, obtendremos alrededor de 15 dispositivos distintos, con tamaños, resoluciones y pantallas diferentes con todos los sistemas operativos seleccionados, sin repetir ninguno.

Por ejemplo, una versión bastante eficiente de dispositivos y sistemas operativos utilizados a día de hoy, sería la siguiente:

Con esta tabla, a expensas de algún modelo más novedoso que aparezca en breve, podemos comenzar a trabajar sin ningún problema, sabiendo que cubrimos mucha cuota de mercado con un abanico relativamente pequeño de dispositivo. Esto lo hacemos, ya que estamos trabajando con modelos muy nuevos y algunos más antiguos, que estén más afianzados en los hogares, como por ejemplo la Tab E que data del 2015 aproximadamente.

Para el tema de navegadores, hacemos lo mismo, cubriendo tantos sistemas operativos y dispositivos como existan en el mercado. Aquí, la tasa de actualización es altamente superior y además, jugamos con que, los navegadores suelen actualizarse directamente, sin preguntar.

Podemos comenzar con una tabla similar a esta:

Lo bueno que tiene este tipo de pruebas de compatibilidad, es que podemos utilizar máquinas virtuales, Amazon Workspace o alguna otra herramienta similar que nos permitirá tener una buena batería sin tener la necesidad de comprar o adquirir muchos dispositivos físicos.

Si ya queremos comenzar a automatizar, no os olvideis de herramientas como Appium. Hay un artículo muy completo, que escribío nuestra compañera Estefanía Fernandez Muñoz, que habla sobre todos estos temas. Lo podéis leer aquí.

Podéis tener más ideas de como comenzar las validaciones de dispositivos móviles, que herramientas existen y cómo utilizarlas, adquiriendo uno de mis libros, en los que trato más en profundidad todos estos temas: El arte de asegurar la calidad en proyectos software.

QA&TEST Safety and Security: Un evento multisectorial

Uno de los principales objetivos en los que se basó el diseño del programa de la primera edición de QA&TEST Safety y Security (Madrid 27-28 de marzo) fue dotar a la conferencia de un carácter multisectorial y multidisciplinar. 

En el sector de la seguridad, teniendo en cuenta su doble vertiente de Safety y Security, se están desarrollando numerosas iniciativas a nivel sectorial y es muy importante que sean compartidas por otros dominios. El intercambio de experiencias e iniciativas sin duda ofrece muchísimos beneficios y, así, el objetivo de la empresa organizadora, SQS, es crear el entorno adecuado para la discusión, el intercambio de ideas y el aprendizaje. Además, no podemos olvidarnos de que la transferencia de conocimiento entre sectores nos permite evolucionar más rápido y con pasos más firmes, aprendiendo, no sólo de las experiencias positivas y exitosas sino también de todas aquellas fallidas.

En este sentido, en la conferencia hay ponentes y asistentes que pertenecen a los sectores del ferrocarril, automóvil, espacio, energía, desarrollo de componentes electrónicos, banca o la propia administración. Desde un punto de vista de dominio, la conferencia es de interés para cualquier sector de actividad.

y recuerda que a través de QA Lovers, puedes conseguir un 20% de descuento si al comprar tu entrada, introduces el código: QALOVERS20

Pruebas de accesibilidad web

A día de hoy, uno de los temas candentes es la accesibilidad web. Es muy importante cubrir una serie de puntos y reglas que nos permitan ofrecer un portal o una web accesible para todo el mundo y que se pueda usar por personas con un tipo de discapacidad de cualquier tipo.

Habitualmente, cuando hablamos de revisiones de accesibilidad, tenemos dos variantes:

• Revisión automática: en la que con una aplicación informática analizamos el código y se devuelven de manera automática una serie de informes que anotan o agrupan los fallos encontrados. Uno de los portales más conocidos que aportan este tipo de pruebas es este: http://www.tawdis.net
• También existe una revisión manual: en la que entrarían una serie de pruebas de accesibilidad que se hacen con diferentes escenarios con diferentes circunstancias que agrupan ayudas específicas para diferentes discapacidades e interactúan con distintos navegadores.

Lo ideal para la realización de unas buenas pruebas de accesibilidad es la combinación de ambos, ya que se tiene que contar con la experiencia de los usuarios que pueden observar dificultades que se encuentran algunos usuarios (edad avanzada, discapacidad visual, auditiva…) y lo que ofrecen estos portales que revisan la aplicación desde el código para facilitar una serie de reglas a cumplir.

Lo ideal es que contemos con grupos de personas con diferentes discapacidades y nos puedan apoyar en las necesidades que buscan ellos y las que no cumple nuestra página web, pero como esto suele ser complicado, lo más sencillo es simular escenarios que nos ayuden a comprender esas necesidades.

El último paso que deberíamos de cumplir es la realización de una revisión de código HTML y CSS que evitará muchos errores relacionados con la accesibilidad.

Una vez que hemos realizado estas pruebas, debemos de ponernos como meta el cumplir las pautas de accesibilidad al contenido web (WCAG) que nos guiará a la hora de optimizar nuestro diseño a uno accesible y que reducirá las barreras a la información.

Estas pautas tienen tres niveles, que son los siguientes:

• Prioridad 1: Son aquellos puntos que se tienen que cumplir para que ciertos grupos de usuarios no podrían acceder a la información del sitio web
• Prioridad 2: Puntos a cumplir ya que si no sería muy difícil acceder a la información para ciertos grupos de usuarios
• Prioridad 3: Aquellos puntos a cumplir para que algunos usuarios no experimenten ciertas dificultades de acceso. 

Una vez que tenemos cumplimentados estos tres niveles, aparecen ciertas conformidades:

• Conformidad A: los puntos del nivel 1 están satisfechos.
• Conformidad AA: Los puntos de prioridad 1 y 2 están cubiertos.
• Conformidad AAA: Están cubiertos los tres niveles de prioridad.

Cumpliendo estos niveles y estas conformidades, la guía de pautas nos explica que puntos realizar para que la accesibilidad y el diseño vayan a la par. La idea es que la accesibilidad sea cubierta desde diferentes situaciones.

Cada día más, este tipo de pruebas, pautas y conformidades a cumplir son más importantes y sí que es cierto que, navegadores, sistemas operativos y demás aplicaciones que utilizamos, desde hace muchos años, tienen muchas reglas y opciones de accesibilidad, pero aún tenemos mucho terreno por andar en este nivel, sobre todo en aplicaciones móviles y en páginas web. Es un punto que creo, debería de explotarse más y poder eliminar todo tipo de barreras para distribuir y alcanzar la información por y para todas las personas.

SonarQube es una herramienta para desarrolladores - Excentia

Antes de iniciar la parte gruesa de este artículo y la razón por la que escribimos hoy aquí, queremos destacar que es un placer para excentia poder colaborar con el proyecto QA Lovers. Muchas gracias Víctor por tu invitación y sobre todo, por tu predisposición, energía y ganas por seguir mejorando la calidad del software de las aplicaciones. Estamos seguros que personas con tu conocimiento, experiencia y humildad lograrán que la calidad reine en el mundo tecnológico.

Para aquellos que no nos conozcan y con tal de ponernos en contexto, en Excentia somos QA Lovers :) Nuestro ámbito de especialización es la calidad desde dos grandes campos o perspectivas: la gestión de procesos y la calidad propia del producto software. Con esa filosofía nacimos hace 10 años, y con esa misma visión seguimos ahora tratando, tanto de  mejorar nosotros, como de ayudar a nuestros clientes a hacerlo.

Para conseguirlo, trabajamos como partners codo con codo con dos grandes players en el mercado: Atlassian y SonarSource. Nuestro conocimiento experto en SonarQube es lo que nos permitió conocer a Víctor, y estar hoy aquí aportando nuestro granito de arena y tratar de generar una comunidad de amantes de la calidad software.

El título de este artículo es bastante explicativo de lo que a continuación nos disponemos a exponer: SonarQube es una herramienta para desarrolladores sí, no es una herramienta para fiscalizar los proyectos, medir la rentabilidad de un producto software o espiar a los equipos de desarrollo. Sin embargo, durante nuestros años de experiencia nos hemos encontrado con que esa era la realidad en muchas organizaciones.

Son multitud de situaciones a las que, o bien nos hemos enfrentado directamente, o bien, escuchamos en redes, blogs y foros de opinión.

SonarQube provoca frustración en muchos equipos de desarrollo. Tras haber estado trabajando en un nuevo código, añadiendo funcionalidades, habiendo echado humo el teclado… SonarQube detecta que algo no va bien. Además, los desarrolladores tienen en muchas ocasiones la sensación de que SonarQube fiscaliza erróneamente su esfuerzo (pista en algunas organizaciones sí ocurre, pero eso ¿es culpa de la herramienta? ¿Tiene culpa la espada o el caballero que la blande?). Incluso hemos sido testigos de quejas y negación de resultados hacia la herramienta, que no funciona correctamente… Amigos desarrolladores, SonarQube detecta falsos positivos, tenedlo en cuenta.

Pero lo interesante en todo esto es preguntarse por qué esta animadversión de los desarrolladores hacia SonarQube.

Son varios los motivos que en excentia hemos detectado:

1.     Una interpretación errónea de los datos: tenemos que entender que SonarQube es una herramienta de mejora continua que mide código estático y por tanto, cambios constantes. Es vital entender el concepto del “leak period” así como la filosofía “Fix the leak” (https://www.excentia.es/una-fuga-de-agua-cambia-el-juego-en-la) en la que SonarQube se basa.

2.     Introducción de alguna evidencia bloqueante o crítica que hace que la calificación del proyecto caiga. ¿No se ha mejorado? Por supuesto que sí, en el momento se corrige esa evidencia, seremos capaces de observar que el cómputo global es mejor.

3.     El peso de las calificaciones del código antiguo es mayor que el del código nuevo. Suele pasar cuando los equipos de desarrollo se enfrentan a proyectos que no han escrito ellos mismos, cuando tratan con legacy code, o cuando manejan proyectos muy grandes en los que hay que trabajar poco a poco.

4.     Actualización de la plataforma: actualizamos a la última versión de SonarQube y… ¡oh sorpresa!, se detectan más evidencias. ¿Está peor el código? No, la herramienta lo mide mejor y te permitirá mejorar la calidad todavía más.

Teniendo en cuenta estos escenarios, desde excentia proponemos una serie de iniciativas y actividades que permitan a los equipos de desarrollo  combatir esa desafección.  Una vez esa “fase de negación” haya sido superada, los desarrolladores serán capaces de aprovechar todas las ventajas que SonarQube, SonarCloud o SonarLint ofrecen.

Nuestro objetivo, y esperamos que el vuestro, sea conseguir una comunidad feliz.

Volviendo a las “soluciones” o a como remediar la desafección de desarrolladores hacia SonarQube, las propuestas son varias:

1.     Formación: ¿sabes usar realmente SonarQube?, ¿sabes interpretar adecuadamente los datos? Pero sobre todo: ¿conoces el nuevo paradigma de calidad?, ¿sabes aplicarlo al día a día de tu equipo de desarrollo? No hace falta que digamos que la formación no es una cosa puntual. Provee a tus equipos de una fuente de información en la que puedan conocer detalladamente nuevas métricas, novedades en la herramienta, etc.

2.     Pide al equipo de sistemas (o al equipo encargado) que documente los cambios en las actualizaciones, para que los desarrolladores entiendan por qué sus métricas han cambiado. Comunicar es clave.

3.     Usa SonarLint (https://www.sonarlint.org/). Corrige defectos en tu propio IDE, pero sobre todo, entiende el contexto y la razón por la que se producen. Edúcate como desarrollador haciendo lo que mejor sabes, desarrollar. ¡Ah! Y no te olvides de sincronizar tu SonarQube con tu SonarLint para mantener siempre actualizados y en la misma posición a todos los colaboradores, estén estos dispersos, sean proveedores distintos, etc.

Y con estos consejos y buenas prácticas llegamos al fin de nuestro artículo. Esperamos que haya sido de utilidad, que podáis aplicar nuevas prácticas y principios y que todos desarrollemos un código más seguro y de mayor calidad.

¡No dudéis en consultar cualquier duda con nosotros (https://www.excentia.es/)!

Pautas para aprender y ampliar el conocimiento de negocio de un producto

Muchas veces, quizá demasiadas, he escuchado que probar puede cualquiera, que nuestro trabajo lo puede realizar cualquier persona en cualquier momento, sin formación y se puede poner al instante, sin conocimiento del negocio ni similar. Esto, además de ser totalmente erróneo, es algo que desprende bastante desconocimiento sobre nuestro gremio.

Además de todo esto, nos encontramos con algunas situaciones que suceden muy a menudo. Una empresa decide contratar a una persona para probar, una empresa que lleva mucho tiempo en el mercado, pero no tienen un conocimiento claro de lo que es nuestro trabajo ni lo que supone un control de calidad completo. Aquí, hay dos caminos que labrar, el de explicar que haces y el de explicar que tienen que hacer los demás para que tus pruebas aporten y sean efectivas.