Tabla de contenidos |
---|
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.
Alta tarea JIRA: "NOMBRE_APLICACION: Pruebas código fuente" | |||
---|---|---|---|
Tipo de tarea: | "Tarea QA" / "Subtarea Test" | Pórtico: | Asociado al Proyecto |
Disciplina: | "P9. Gestión de la calidad del software" | Proceso: | "Realizar pruebas sobre el código fuente" |
Etiqueta: | sdaym_test_codigo | Versión correctora: | Versión correspondiente a la Release en la que estamos. |
Una vez terminado el trabajo el miembro del equipo de desarrollo encargado de realizar la Tarea QA creará una petición de servicio a DJ-AT-MNCS con dicha Tarea QA enlazada para su revisión.
En la revisión de la Tarea QA se 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
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.
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.