...
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.
...
| Info |
|---|
project = MI_PROYECTO AND issuetype in ("Tarea Test", "Subtarea Test") AND labels = sdaym_accesibilidad and fixVersion=VERSION_DE_LA_RELEASE |
| Ancla | ||||
|---|---|---|---|---|
|
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.
...
| Advertencia |
|---|
Actualmente para proyectos Fundeweb no se pueden realizar test de integración debido problemas con el contexto de Arquillan. En este punto se pueden hacer test unitarios y simulaciones de test de integración usando las aserciones de JMeter (ver documentación 2. Test de carga con JMeter) |
| Ancla | ||||
|---|---|---|---|---|
|
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:
Alta tarea JIRA: "Realización de pruebas de carga" | |||
|---|---|---|---|
Tipo de tarea: | "Tarea test" | Pórtico: | Asociado al Proyecto |
Disciplina: | "P9. Gestión de la calidad del software" | Proceso: | "Realizar pruebas de carga" |
Etiqueta: | sdaym_test_carga | Versión correctora: | Versión correspondiente a la release en la que estamos. |
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
...
| Advertencia |
|---|
Para la realización de las pruebas de carga en el entorno del test es necesario contar con el departamento de sistemas (servidores + bases de datos) y con MNCS (ayudar con problemas en la ejecución del test). Para ello se deben solicitar Jiras a ambos grupos a DJ-AT-GRUPO y enlazarlo como tarea externa al Jira del test de carga que vamos a realizar. |
| Ancla | ||||
|---|---|---|---|---|
|
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.
...
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.
| Ancla | ||||
|---|---|---|---|---|
|
1.5. Pruebas de seguridad
...
| Info |
|---|
project = MI_PROYECTO AND issuetype = "Tarea Test" AND labels = sdaym_seguridad and fixVersion=VERSION_DE_LA_RELEASE |
| Ancla | ||||
|---|---|---|---|---|
|
...
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.
| Ancla | ||||
|---|---|---|---|---|
|
...
| Info |
|---|
Clave del proyecto: Código Jira del proyecto Tipo de test: Etiqueta sdaym_test_aceptacion Versión correctora: Versión correspondiente a la release en la que estamos. |