| Info | ||
|---|---|---|
| ||
La elaboración de las tareas relacionadas con la calidad se desarrollan dentro de cada Release y están recogidas dentro del apartado Control de calidad |
...
Introducción
Objetivos del proceso
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 de carga: Necesarias para el paso a producción de nuestros proyectos, deben asegurar la estabilidad del mismo.
- Pruebas funcionales: Testean que nuestro proyecto funciona correctamente, depurando los fallos que se pudieran producir.
- 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
...
Las pruebas de accesibilidad deben realizarse siempre que se cree o modifique algún elemento que afecte a la interfaz de usuario de nuestro proyecto. Por lo tanto en cada release de 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:
...
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 > 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.
Datos básicos:
- URL declaración accesibilidad: La URL de la declaración de accesibilidad de nuestro proyecto.
- Método de validación: Herramienta que se ha usado para realizar la revisión de accesibilidad de 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.
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:
| Info |
|---|
project = MI_PROYECTO AND issuetype = "Tarea Test" AND labels = sdaym_accesibilidad and fixVersion=VERSION_DE_LA_RELEASE |
...
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, preferentemente con la herramienta Apache JMeter y 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:
| Info |
|---|
project = MI_PROYECTO AND issuetype = "Tarea Test" AND labels = sdaym_test_carga and fixVersion=VERSION_DE_LA_RELEASE |
...
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.
Para realizarlas el Responsable del proyecto creará las correspondientes tareas en Jira para que el equipo de desarrollo realice las pruebas correspondientes.
...
La gestión de la calidad del software se debe hacer haciendo uso de las TareaQA que tienen un ciclo de vida diferente al de una tarea normal. En esta tarea los diferentes equipos realizarán los trabajos de aseguramiento y revisión de calidad indicados en los diferentes apartados de este proceso de MEDEA y, una vez terminados, serán validados por parte de otro técnico, de manera que se asegura una revisión por pares de los procesos de calidad en los desarrollos. Cada Release deberá tener tantas TareaQA como actividades tenga este proceso.
Actividades que incluye
| Presentación de hijos |
|---|
Diagrama de actividades y resultados
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:
| Info |
|---|
Clave del proyecto: Código Jira del proyecto Año de imputación: Año en el que se crearon las tareas Tipo de test: Etiqueta sdaym_test_funcional |
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 que previamente ha realizado el equipo. El personal del CAU repetirá las pruebas creando una Incidencia 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.
...
Las pruebas funcionales se realizarán en coordinación con el CAU permitiendo tener una perspectiva externa al grupo sobre la facilidad de uso de la funcionalidad implementada. Éstas pruebas deberán hacerse siempre que se vaya a poner nueva funcionalidad a disposición de los usuarios finales, por lo que se debe contemplar dentro del ciclo de desarrollo de la release.
Para realizarlas se deberán realizar las siguientes acciones: el Responsable del proyecto creará la correspondiente tareas en Jira para que el equipo registre el tiempo de preparar y realizar las pruebas de usabilidad.
...
Una vez puesta la tarea se concertará una cita con el CAU usando el servicio cita previa en el apartado usabilidad (sólo disponible desde el enlace anterior) para realizarlas (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 de un contexto pero no indique acciones concretas a realizar, dicho contexto debe tener toda la información necesaria para realizar las acciones, pero no instrucciones, por ejemplo:
| Info | ||
|---|---|---|
| ||
Entra a la aplicación, y en el apartado de usuarios crea un usuario con nombre XXX dni YYYY rol ZZZ |
...
| title | Caso válido |
|---|
...