0. Introducción 

La gestión de la calidad del software se lleva a cabo durante el desarrollo del proyecto, no es una tarea que se realiza a posteriori, por lo que irán asociadas a las diferentes releases de nuestro proyecto. No obstante no todos los controles de calidad deben hacerse siempre o en el mismo punto del desarrollo, por lo que en este documento describiremos cómo y cuándo realizar los diferentes controles de calidad de nuestros proyectos.

• Accesibilidad: De imperativo legal, deben asegurar y documentar que nuestras aplicaciones cumplen la normativa vigente en lo que a accesibilidad se refiere.

• Pruebas sobre el código fuente: Test unitarios y de integración implementados en el código y que serán lanzado por el servidor de integración continua antes de cada despliegue.

• Pruebas de carga: Necesarias para el paso a producción de nuestros proyectos, deben asegurar la estabilidad del mismo.

• Pruebas funcionales: Prueba que nuestro proyecto funciona correctamente, depurando los fallos que se pudieran producir.

• Pruebas de seguridad: Realizar las pruebas necesarias para garantizar la seguridad de las aplicaciones.

• Pruebas de usabilidad: Mejoran la experiencia del usuario final, reduciendo las incidencias que no son errores de aplicación, sino dificultad para encontrar funcionalidad o rellenar datos.

• Pruebas de aceptación: Aseguran que el proyecto realizado cubre los requisitos indicados por el cliente final.

1. Tarea para la gestión de la calidad

1.1. Pruebas de accesibilidad

Se trata de 3 tareas consecutivas:

1. Tarea 1 - Las Pruebas de Accesibilidad; analizar la accesibilidad de las pantallas que tiene la aplicación web, tanto de forma automática (herramientas) como manual (donde no lleguen las herramientas).
2. Tarea 2 - El Informe de Accesibilidad de la aplicación; rellenar el Informe de Revisión de la Accesibilidad (IRA) de la aplicación web, usando la plantilla del OAW (Observatorio de Accesibilidad Web) que proporciona MNCS pre-rellena.
3. Tarea 3 - La Declaración de Accesibilidad: finalmente, crear una página con la Declaración de Accesibilidad de la aplicación web, con el resultado del Informe de Accesibilidad.

Vamos viendo cada una de estas 3 tareas de forma secuencial, empezando por la primera.

Las Pruebas de Accesibilidad (tarea 1) deben realizarse siempre que se cree o modifique algún elemento que afecte a la interfaz de usuario de nuestro proyecto, e idealmente durante la implementación de cada pantalla, de modo que cada pantalla terminada tenga su test de accesibilidad. Por lo tanto en cada release del desarrollo se deberán crear los Jiras pertinentes para realizar las comprobaciones de accesibilidad correspondientes, para ello por cada prueba o conjunto de pruebas (a discreción del Responsable del proyecto) se creará una o varias tareas de la siguiente forma (idealmente una tarea/subtarea para cada pantalla):

Para poder reflejar este trabajo dentro de nuestro proyecto en Confluence, deberemos ir a la release en la que nos encontremos y editar la página correspondiente a la Accesibilidad en el Control de Calidad de tu proyecto en Confluence, que será similar al modelo de la plantilla "YYYY - PRnn - Accesibilidad". En esa sección deberemos registrar unos datos básicos, explicar el motivo de las no conformidades de cara a justificar una posible reclamación y modificar la macro que muestra los jiras, para que muestre los asociados a esta release:

• URL Declaración Accesibilidad: La URL de la página con la Declaración de Accesibilidad (tarea 3) de nuestro proyecto. 

  • Una vez verificada la Accesibilidad en TODAS las pantallas de tu aplicación, debes crear una página con la Declaración de Accesibilidad, explicando las no conformidades encontradas, y qué alternativas accesibles has habilitado.
  • En Jira, esta será una tarea del tipo Test (o Subtarea Test) con la etiqueta sdaym_accesibilidad_declaracion.

• Método de validación: Herramienta que se ha usado para realizar la revisión de accesibilidad de todas las pantallas.

• Realizada validación manual: Indicar si se ha repasado manualmente los items de accesibilidad indicados en la normativa o si se ha limitado a lanzar la validación automática proporcionada por alguna de las herramientas incluidas en los métodos de validación.

• Informe de Accesibilidad: indicar la url donde está el Informe de Accesibilidad de la aplicación (tarea 2)
  • Finalmente, debes hacer un informe sobre la Accesibilidad de tu aplicación, antes del 20 de Septiembre del 2020.
  • En Jira, esta será una tarea del tipo Test (o Subtarea Test) con la etiqueta sdaym_accesibilidad_informe.

Para que las tareas realizadas con el control de accesibilidad se vean reflejadas en esta ficha deberemos editar la macro correspondiente

Poniendo en el campo del filtro el siguiente contenido: 

↑ Ir a menu

1.2. Pruebas sobre el código fuente

Las pruebas sobre el código fuente son las que engloban tanto los test unitarios como los test de integración (ver advertencia más abajo). Éstas pruebas se deben desarrollar a la par que el código del proyecto evoluciona con la finalidad que los diferentes cambios e integraciones de módulos no causan problemas colaterales en nuestro proyecto. Las pruebas unitarias están enfocadas a probar clases mientras que las de integración prueban interacciones entre diferentes clases y EJB's de nuestro proyecto.

El código fuente de los test deberá estar incluido en el proyecto, en el módulo de test de cara a que los test sean lanzados de manera automática por el servidor de integración continua abortando la integración en caso de que algún test falle.

Por cada test o conjunto de test (a discreción del Responsable del proyecto) se creará una o varias tareas de la siguiente forma

Para poder reflejar este trabajo dentro de nuestro proyecto en Confluence, deberemos ir a la release en la que nos encontremos y editar el apartado Plan de Release > Control de calidad > Test de código. En esta sección registraremos el repositorio donde está el código fuente de nuestro proyecto y el enlace al gestor de calidad del mismo.

Para poder ver los test reflejados deberemos editar la macro correspondiente

Poniendo en el campo del filtro el siguiente contenido: 

De igual forma, la calidad del código deberá ser controlada en el servidor de análisis estático SonarQube, en el cual se deberán contar con 0 bugs y 0 vulnerabilidades para garantizar un mínimo de calidad. A su vez se deben reducir al máximo los CodeSmell y evitar en nuevas subidas de código aumentar la deuda técnica.

En el caso de que se detecten falsos positivos se deberá contactar con MNCS para que lo valide y anote dicha alerta como tal.

↑ Ir

Ir a menu

1.3. Pruebas de carga

Las pruebas de carga son obligatorias antes de que un proyecto se pase al entorno de producción y se deben hacer cuando la funcionalidad de los módulos esté completa (o mayoritariamente completa), por lo que estas tareas se realizarán al final de una (o varias) releases, pero no necesariamente en todas. Para registrar el trabajo realizado en lo referente a las pruebas de carga  por cada prueba o conjunto de pruebas (a discreción del Responsable del proyecto) se creará una o varias tareas de la siguiente forma:

Para poder reflejar este trabajo dentro de nuestro proyecto en Confluence, deberemos ir a la release en la que nos encontremos y editar el apartado Plan de Release > Control de calidad > Pruebas de carga. En esta sección registraremos los datos básicos de los test y las justificaciones oportunas sobre los resultados obtenidos, para ello deberemos rellenar

• Resumen: Breve resumen de las pruebas que se han realizado, para conocer las pantallas que se han cubierto y la carga media estimada de usuarios.

• Justificaciones: En el caso de que algún test tenga un resultado más alto de lo normal, pero se considere aceptable, indicar el por qué de dicho valor (muchos usuarios concurrentes, operaciones pesadas en base de datos, etc.). En estas justificaciones también se deberán registrar las medidas tomadas para paliar estos resultados.

Las pruebas de carga se realizarán siguiendo las instrucciones descritas en 1. Cómo abordar un test de carga y tanto el test como las evidencias que se generen deberán anexarse a los jiras de trabajo correspondientes. Para que las tareas realizadas se vean reflejadas en esta ficha deberemos editar la macro correspondiente

Poniendo en el campo del filtro el siguiente contenido: 

↑ Ir a menu

1.4. Pruebas funcionales

Las pruebas funcionales se deben realizar para garantizar que el desarrollo llevado a cabo durante un Sprint o Relase funciona de manera adecuada. Estas pruebas las realizará el equipo de desarrollo del proyecto intentando que la persona que desarrolló una funcionalidad no sea la responsable de probarla. A su vez, también las realizará el personal del CAU, pero su participación requiere que previamente se hayan realizado las pruebas de usabilidad o bien las realice un miembro diferente ya que las pruebas de usabilidad requieren que no se conozca la aplicación.

Para realizarlas el Responsable del proyecto creará las correspondientes tareas en Jira para que el equipo de desarrollo realice las pruebas correspondientes. 

Cada tarea que se cree tendrá como objetivo cubrir una funcionalidad concreta, de manera que cuando el desarrollador del equipo a aborde pueda comentar los problemas que ha encontrado o si ha funcionado de manera exitosa. Para ello deberá indicar el conjunto de datos / o acciones llevadas a cabo. Tras probar que todo funciona correctamente finalizará la tarea.

Para poder reflejar este trabajo dentro de nuestro proyecto en Confluence, deberemos ir a la release en la que nos encontremos y editar el apartado Plan de Release > Control de calidad > Pruebas funcionales. Esta sección solo posee del listado de jiras relacionados con la tareas, el estado de dichos jiras nos indicará si la prueba se ha resuelto satisfactoriamente o no.

Para poder mostrar los jiras en nuestro proyecto, deberemos editar la macro correspondiente:

Poniendo en el campo del filtro el siguiente contenido: 

Realización de pruebas por parte del CAU

Una vez realizadas las pruebas por el personal del equipo de trabajo, se podrá proceder a realizar las pruebas por parte del CAU. Para ello se les debe impartir un curso de formación sobre el desarrollo realizado y dar acceso al apartado de pruebas funcionales en Confluence que previamente ha realizado el equipo. Para coordinar el trabajo se reservará el tiempo del CAU mediante la aplicación cita previa, apartado FORMACIÓN para reservar tiempo para la impartición del curso y apartado PRUEBAS FUNCIONALES para reservar tiempo para que el CAU realice las pruebas funcionales indicadas. Tras ello el personal del CAU repetirá las pruebas creando un Bug al proyecto con la etiqueta sdaym_test_funcional en caso de encontrar un error e indicando en el apartado Test plan cómo poder reproducirlo. Esta información también se verá reflejada en la lista anteriormente mencionada.

↑ Ir a menu

1.5. Pruebas de seguridad

Las pruebas de seguridad son obligatorias antes de que un proyecto se pase al entorno de producción y se deben hacer cuando la funcionalidad de los módulos esté completa (o mayoritariamente completa), estas pruebas deberán hacerse cada vez que se publique una nueva release ya que garantizar la seguridad de las aplicaciones es crítico. Para registrar el trabajo realizado en lo referente a las pruebas de seguridad el Responsable del proyecto creará una o varias tareas de la siguiente forma:

Esta tarea está muy relacionada con "1.2. Pruebas sobre el código fuente" (revisión de bugs y vulnerabilidades).

Para poder reflejar este trabajo dentro de nuestro proyecto en Confluence, deberemos ir a la release en la que nos encontremos y editar el apartado Plan de Release > Control de calidad > Pruebas de seguridad. En esta sección registraremos el resumen de las pruebas realizadas en base a la plantilla Control de requisitos de seguridad que debe incluirse si no está en el espacio del proyecto y completarse teniendo en cuenta la Normativa de Desarrollo de Aplicaciones Web Seguras , así como las indicaciones de OWASP Top Ten.

• Resumen: Breve resumen de las pruebas que se han realizado, para conocer las pantallas que se han cubierto y la carga media estimada de usuarios.

• Justificaciones: En el caso de que no se pueda solventar algún problema conocido por causas ajenas al grupo de de desarrollo justificarlo aquí.

Poniendo en el campo del filtro el siguiente contenido: 

↑ Ir a menu

1.6 Pruebas de usabilidad

Las pruebas de usabilidad se realizarán en coordinación con el CAU, o en su defecto con usuarios al que está destinada la aplicación a construir y que no la conocen todavía, permitiendo tener una perspectiva externa al grupo sobre la facilidad de uso de la funcionalidad implementada. Estas pruebas deberán hacerse siempre que se vaya a poner nueva funcionalidad a disposición de los usuarios finales y antes de que el personal del CAU conozca la aplicación, por lo que se debe contemplar dentro del ciclo de desarrollo de la release.

Para realizarlas se deberán llevar a cabo las siguientes acciones: el Responsable del proyecto creará la correspondiente tarea en Jira para que el equipo registre el tiempo de preparar y realizar la pruebas de usabilidad. 

También deberemos editar el apartado Plan de Release > Control de calidad > Pruebas de usabilidad editando la macro existente:

Poniendo en el campo del filtro el siguiente contenido: 

Una vez puesta la tarea se concertará una cita con el CAU usando el servicio cita previa en el apartado usabilidad (a dicha prueba asistirán un técnico del CAU y uno del equipo de desarrollo, no se recomiendan más asistentes para agilizar la prueba).

Concertada la cita, el equipo de desarrollo debe preparar un guión para el técnico del CAU de manera que le pueda orientar para realizar la tarea. Es imprescindible que ese guión proporcione un contexto adecuado (incluyendo detalles que no afectan directamente en la prueba pero sí hacen que se tenga una visión global del escenario) pero no indique acciones concretas a realizar, dicho contexto debe tener toda la información necesaria para realizar las acciones, pero no instrucciones concretas, por ejemplo:

Para la realización de la prueba se recomienda reservar un portatil (si no se posee uno) en la aplicación espacios e instalar la herramienta OBSSutido para capturar tanto el vídeo como el audio de la prueba.

Una vez concluida la prueba el equipo guardará el video en Umubox y creará un link público incluyéndolo en el Jira creado para realizala.

↑ Ir a menu

1.7. Pruebas de aceptación

Las pruebas de aceptación son las que hacen los usuarios finales en la aplicación y certifican que la funcionalidad proporcionada se ajusta a los requisitos del proyecto. Existen diferentes formas de llevarlas a cabo por parte de los grupos de desarrollo:

• Haciendo que los usuarios pongan jiras

• Mediante intercambio de correos

• Mediante documento excel compartido

• etc.

Por tanto no se va a definir una metodología concreta sobre cómo realizarlas ya que depende, sobre todo, de la disponibilidad y predisposición de los usuarios finales, la cual no se puede controlar a priori. No obstante sí que vamos a definir una metodología para registrar y procesar las incidencias reportadas por los usuarios en las pruebas.

Para ello, deberemos registrar un Jira de tipo Bug con la etiqueta sdaym_test_aceptacion en nuestro proyecto por cada incidencia que reporte un usuario que se encuentre probando la aplicación. En la descripción pondremos lo que ha estado probando, y en caso de ser un error, en Test plan, describiremos cómo reproducirlo.

Una vez terminadas las pruebas el Responsable del proyecto deberá crear un Jira de gestión para elaborar un informe de todo lo que se ha probado y validado por parte de los usuarios finales. El informe se anexará al Jira para poder tenerlo incluido en el espacio de la release.

Una vez creados los Jiras deberemos editar el apartado Plan de Release > Control de calidad > Pruebas de aceptación modificando la macro existente:

Poniendo en el campo del filtro el siguiente contenido: 

↑ Ir a menu