...

• Pruebas de código fuente: Se realizarán tal y como se indica en MEDEA
• Pruebas de accesibilidad web: Sólo se tienen que realizar cuando se realicen cambios en el frontend del proyecto. Deberán ajustarse a los plazos que indica en OAW y se recogen dentro de la metodología.
  • ¿Si hago un pequeño cambio en el frontend de algún servicio tengo que hacer el análisis de la pantalla y actualizar la declaración de accesibilidad?
    • Si el cambio es pequeño y no incorpora elementos nuevos no es necesario porque ya estarán contemplados en la declaración existente. En caso contrario se deberá analizar y, si incorpora nuevos incumplimientos, modificar la declaración de accesibilidad existente.
  • ¿Si hago un cambio sustancial o introduzco un servicio nuevo tengo que hacer el análisis de la pantalla y actualizar la declaración de accesibilidad?
    • En este caso sí que es obligatorio hacer el análisis de la pantalla para detectar nuevos incumplimientos posibles. La declaración de accesibilidad sólo se deberá actualizar si se detectan incumplimientos nuevos.
  • ¿Cuándo debo hacer el informe de accesibilidad que se presenta al Observatorio de Accesibilidad Web?
    • Este informe se hace una vez cada 3 años, salvo que MNCS pida que se haga expresamente, independientemente que durante ese periodo se hayan puesto en marcha nuevos servicios o no.
    • Cuando venzan los 3 años se deberá hacer el informe basándose en todos los análisis de las pantallas ya realizados y ampliando con los servicios nuevos que todavía no tengan el análisis hecho.
• Pruebas de seguridad: Se realizarán tal y como se indica en MEDEA
• Pruebas funcionales: En el caso de mi campus todas las pruebas funcionales de las APIs se deben hacer con Cucumber. De esta manera tenemos, a la vez, test funcionales en el código y pruebas funcionales actualizadas en todo momento. Esto supone un gran beneficio ya que, gracias a cómo se describen los test con Cucumber podemos alinearlos directamente con los requisitos dados por el responsable de la API y utilizar el propio lenguaje usado para describirlos, lo cual facilita el asentamiento del dominio y un punto común entre responsable del producto y API desarrollada.
• Pruebas de carga: Se realizarán tal y como se indica en MEDEA. Se deberán realizar en local para asegurar que la aplicación tiene un buen rendimiento antes de lanzarlos en los servidores con el departamento de sistemas. Desde MNCS se recomienda usar JMeter y VisualVM (en local) para lanzar el test y medir la memoria RAM utilizada. No obstante se puede utilizar cualquier herramienta que permita obtener, al menos, los siguientes resultados:
  • Por cada petición diferente que haga nuestro test
    • Tiempo medio de respuesta
    • Porcentaje de error
    • Bytes transmitidos
    • Número de peticiones realizadas
  • A nivel global:
    • Memoria RAM máxima
    • Memoria RAM mínima
    • Evolución de la memoria RAM durante la ejecución del test
• Pruebas de usabilidad: Se realizarán tal y como se indica en MEDEA
• Pruebas de aceptación: Se realizarán tal y como se indica en MEDEA. En este caso también pueden servir de apoyo los test Cucumber realizados en las pruebas funcionales ya que deberían cubrir todos los requisitos del proyecto.

7. Rendimiento

Aunque las pruebas funcionales ya contemplan este puto. Es importante resaltar que las APIs alojadas en Mi Campus deben tener un coste bajo tanto en memoria, como en tiempos de respuesta. En el caso de que tengamos problemas con alguna API hay que analizar detenidamente el coste en recursos ya que la arquitectura, al ser ligera, no debería presentar problemas en este punto.

Dependiendo del servicio y sus circunstancias , también podemos establecer los criterios de escalado en la infraestructura, hay servicios más o menos pesados, con más o menos concurrencia. La ventaja de tener un gestor de PODs (Kubernetes) es que el escalado se hará de manera automática según los criterios que establezcamos, por lo que garantizamos que la gestión de los recursos se hace de la manera más óptima posible.

No obstante hay que estar atento atentos a la monitorización de nuestros PODs para ver si están funcionando correctamente o tienen caídas con determinada frecuencia. Este último aspecto, asumiendo que el servicio está lo más optimizado posible, nos puede indicar si los recursos que tengamos asignados son suficientes o no. En este caso, justificando la necesidad con un estudio del código de la aplicación más su casuística, podremos solicitar más recursos, no obstante nos tendremos que asegurar que no se puede mejorar el rendimiento de ninguna manera antes de intentar aumentar el consumo de nuestros PODs.

8. Logs y monitorización

Toda la monitorización que podemos hacer sobre los servicios de Mi Campus se encuentra en Lagar, que es una herramienta que nos va a permitir tanto tener acceso a los logs de las aplicaciones como al rendimiento de los diferentes PODs.

...