Diagrama

1. Introducción y alta tarea en JIRA

Las Tareas QA  sobre el código fuente de nuestras aplicaciones engloban diferentes aspectos a validar:  código correcto y sin bugs ni vulnerabilidades, correcta documentación, sistema de log adecuado, correcta  gestión de API 's expuestas y garantizar que la aplicación es segura frente ataques.

En este punto el  Responsable técnico principal o los responsables técnicos del proyecto deberán crear una Tarea QA dentro de la Release en la que se está trabajando para asegurar que todos los hitos QA relacionados con el código fuente se han cumplido y que el equipo encargado de supervisar y verificar las Tareas QA de el visto bueno a los resultados aportados.

Una vez terminado el trabajo el miembro del equipo de desarrollo encargado de realizar la Tarea QA cerrará dicha tarea, y creará una subtarea externa que será una petición de servicio a DJ-AT-MNCS para verificar que la recogida de evidencias ha sido correcta. El contenido del Jira a crear es el siguiente

La revisión a realizar comprobará que se han realizado las siguientes acciones:

2. Comprobar que el código fuente es correcto y sin problemas conocidos

El código debe estar implementado de manera correcta para que no contenga ni vulnerabilidades conocidas ni problemas de estabilidad.

Para ello se usará la herramienta SAST (Static Application Security Testing) SonarQube,  la aplicación no deberá presentar ningún bug ni vulnerabilidad .

También se deberán reducir los CodeSmell lo máximo posible dentro de lo razonable (en caso de duda en este punto consultar con MNCS).

3. Revisar que el código fuente esté bien documentado

El código fuente debe tener comentarios suficientes para que un desarrollador ajeno al proyecto pueda orientarse. Todas las API's que se expongan a otras aplicaciones deberán tener estar documentadas , dicha documentación deberá ser accesible vía web por cualquier equipo que desee consultarla.

Todas las API's REST deberán tener documentación en formato OpenAPI ( Documentar APIs con OPENAPI ).  Las API's Soap deberán estar documentadas mediante Enunciate  ( Documentar APIs REST con Enunciate ). La documentación de dichas APIs una vez terminada deberá ser validada por MNCS.

4. Verificar que el sistema de log esté bien configurado y adecuado

La aplicación deberá tener log suficiente para poder trazar las acciones de un usuario en el sistema . También tendrá que estar  configurado para su uso en Lagar  lo que nos otorgará la capacidad de poder crear paneles y filtros que mejoraran el seguimiento de las acciones llevadas a cabo en la aplicación ( Visualización de Logs de FundeWebJS en LAGAR ).

5. Asegurar que las API's expuestas esté bien implementadas y sigan los estándares de la industria

Las  API's deberán estar correctamente implementadas  para todos los casos posibles (válidos o situaciones de error). 

En el caso de las API's REST deberán usar el mecanismo de gestión de errores indicado por MNCS ( Manejo de errores en servicios REST ), deben  utilizar los verbos HTTP correctos según la situación en la que nos encontremos ( Buenas prácticas con servicios REST ) y deben devolver las entidades pertinentes según la acción en curso (evitar entidades genéricas). Los servicios SOAP deben incorporar en el cuerpo de la respuesta un mensaje informando del tipo de respuesta, si es errónea o no y con un mensaje aclaratorio.

En el caso de las API's Soap la API deberá apoyarse en un XML Schema formado por la aplicación donde se contemplará la inclusión de mensajes y códigos de respuesta aparte del resultado pedido para que la aplicación cliente pueda reaccionar ante posibles problemas. En caso de requerir seguridad deberá contemplar lo indicado en Servicios web seguros , también debe garantizar que no acepta DTD o fuentes externas para evitar inyección de XML o ataques de denegación de servicio basado en el uso de DTD o XML maliciosos.

6. Verificar que la aplicación tiene implementados test unitarios

Para las aplicaciones FundewebJS los backends tienen que tener implementados test unitarios que validen el desarrollo realizado y que cubran la mayor parte del código programado que sea posible. Estos test serán lanzados por el servidor de integración continua en cada despliegue por lo que deben funcionar correctamente o el proyecto no desplegará.

A nivel de QA se deberá analizar que la cobertura ofrecida por los test es suficiente en base a las particularidades del proyecto, buscando la maximización de la misma dentro de las posibilidades que se dispongan. Es especialmente importante tener en cuenta que la lógica de negocio es la que debe tener la mayor cobertura. Los resultados estarán disponibles en el análisis del proyecto que hace SonarQube

7. Registro y publicación de resultados

La Tarea QA creada estará reflejada dentro del espacio de Confluence del PÓRTICO en la Release correspondiente a las fechas en las que se realizó la tarea. Toda la información sobre esta tarea y su validación deberá quedar registrada en la propia   Tarea QA o en las Subtarea Test que pueda tener.

En este caso se deberá registrar:

• Enlace a SonarQube
• Enlace a la documentación de las APIs que tenga el proyecto (si las tiene)
• Confirmación de que el sistema de logs está en Lagar
• Test unitarios dentro del código fuente de la aplicación