Blog de noviembre, 2025


Actualización normativa de automatización de pruebas funcionales 


 

Nos complace informarles de la actualización normativa Automatización de pruebas funcionales  en su versión PRE-RELEASE que regula la organización y entrega de pruebas automatizadas. Esta actualización sustituirá la versión anterior e introduce cambios relevantes que buscan mejorar la trazabilidad, la alineación con metodologías de desarrollo y la coherencia con la normativa de entregas. 

A continuación, destacamos los cambios más relevantes que introduce.

  • Directriz 3 y Directriz 12 actualizadas .Se incorpora y actualiza la información relativa a la carpeta Script de datos, alineandola con la estructura del repositorio definida en la normativa de entregas.
  • Directriz 13: Entrega de los .features Se redefine el enfoque de entrega de los ficheros .features, haciéndolo aplicable tanto a proyectos ágiles como a proyectos en cascada, lo que aporta mayor flexibilidad metodológica.
  • Nueva Directriz 15: Trazabilidad y etiquetado de pruebas Se añade una directriz específica para garantizar la trazabilidad de las pruebas, reforzando la transparencia y el control en la ejecución.
  • Eliminación de la antigua Directriz 13: Reporte Se suprime la directriz relativa al informe de resultados de las pruebas automatizadas, ya que esta información queda recogida dentro de los modelos de desarrollo (cascada/ágil) y en la documentación requerida en cada caso.

Las Implicaciones para los equipos de desarrollo y QA

  • Los equipos que se inician en la automatización de pruebas funcionales, deberán adaptar sus repositorios de pruebas y scripts de datos para cumplir con la nueva estructura de carpetas (“scripts”).

  • La entrega de los ficheros de pruebas automáticas (.feature) deberá seguir los criterios actualizados, tanto en proyectos ágiles como tradicionales.

  • Es imprescindible que cada prueba automatizada tenga su etiquetado de trazabilidad, según lo estipulado, para facilitar su seguimiento, filtrado y auditoría.

  • Ya no se requiere entregar el informe de resultados como directriz separada (“Directriz 13. Reporte”), pero sigue siendo clave que los resultados se documenten dentro del ciclo de entrega del proyecto.

Esta actualización normativa representa un paso adelante, ya que adapta el proceso a diferentes metodologías de trabajo, mejora la trazabilidad de las pruebas y simplifica la documentación, evitando duplicidades innecesarias. Es una oportunidad para que los equipos optimicen sus prácticas de automatización y garanticen mayor calidad y control. 


Recomendamos consultar el documento completo de la normativa disponible en el espacio normativo de Confluence PRE-RELEASE: Automatización de pruebas funcionales  y pueden contactar con la Oficina de Calidad <oficinadecalidad.sspa@juntadeandalucia.es>para consultar cualquier duda o aclaración que necesiten sobre la misma.


La versión 1.74.0 del catálogo de componentes web transversal, se ha liberado en los repositorios digitales de medios de la STIC.

Versión Actual

Versión: 1.74.0
Fecha Publicación:   


Próxima Release

Versión: 1.75.0
Fecha Prevista de Publicación: TBA



Podréis consultarlos desde el    Storybook del SAS.


Otros recursos

Recordad que el acceso a los Storybook es a través de la red corporativa del SAS.

Para cualquier duda pueden escribirnos a la Lista de Arquitectura(    l-arquitectura.stic.sspa@juntadeandalucia.es    ) y trataremos de daros soporte con la mayor brevedad que nos sea posible


Se ha liberado la versión 1.74.0.
Esta versión incluye principalmente el empty state, un nuevo componente para mostrar la ausencia del dato.
A continuación, se muestra  un resumen de los cambios más importantes.

Nuevos componentes

Añadido wc-stic-empty-state

El empty state es un componente que se utiliza cuando no hay información disponible para mostrar en un componente o sección de la aplicación.

Debe implementarse siempre que la ausencia de datos pueda generar confusión o necesidad de orientación. Su propósito es informar sobre la situación actual y, cuando proceda, ofrecer al usuario los siguientes pasos.

Se puede ver un ejemplo de uno de nuestros empty states en esta imagen:

A su vez, el empty state tiene distintos tipos de especializaciones, dependiendo de si este se muestra por un error ocurrido, por mantenimiento porque no hay datos o porque el dato todavía no ha cargado. La lista completa de empty states disponibles es:

  • <stic-empty-state-technical-error>
  • <stic-empty-state-no-content>
  • <stic-empty-state-forbidden>
  • <stic-empty-state-suggest>
  • <stic-empty-state-welcome>
  • <stic-empty-state-no-results>
  • <stic-empty-state-job-done>
  • <stic-empty-state-loading-error>
  • <stic-empty-state-backend-error>
  • <stic-empty-state-update-in-progress>
  • <stic-empty-state-required-config>
  • <stic-empty-state-functional-error>
  • <stic-empty-state-fast-loading>
  • <stic-empty-state-embedded>
  • <stic-empty-state-medium-load>
  • <stic-empty-state-slow-load>

 También contamos con especializaciones de carga, como por ejemplo el stic-empty-state-fast-loading que muestra también un loader para enseñar el progreso de la carga:

Finalmente contamos con un tipo embebido cuyo espacio es más reducido para integrarlo dentro de componentes ya disponibles:

 

Añadido wc-stic-illustration

También se ha añadido un componente que puede comunicar una idea por sí solo o reforzar el mensaje textual en otros componentes. Además, este componente contribuye a mantener la coherencia en todo nuestro producto, fortaleciendo así la identidad de nuestra marca. Este componente es usado dentro del mismo empty state para enseñar ilustraciones que acompañan a los mensajes de error. A continuación se pueden ver algunas de nuestras ilustraciones disponibles en este componente:

Cambios en componentes

Cambios en wc-stic-table

Se ha adaptado el componente tabla para que use el empty state con celdas vacías y cuando no hay datos. Por ejemplo puede verse esta tabla que tiene algunos campos sin datos usando el empty state embebido:


A parte de estos cambios se han solucionado errores y mejorado funcionalidades menores, puede ver el registro completo de cambios accediendo a este  sitio.




Guía Jira para la gestión y seguimiento de la ejecución de pruebas y sus resultados

Esta guía está dirigida a los proveedores responsables del desarrollo y mantenimiento del productoSu propósito es proporcionar información sobre el flujo de trabajo implementado en Jira, diseñado para la gestión de la ejecución de pruebas en el entorno del desarrollo y reporte del resultado de las mismas, incluyendo evidencias del resultado satisfactorio o evidencias de defectos identificados que requieren correcciones.

Este modelo permite:

  • Centralización:  toda la información de testing (planes, ejecuciones, resultados, evidencias) gestionada en Jira, facilita facilita un seguimiento unificado y auditable.

  • Asegurar la trazabilidad entre requisitos, casos de uso, pruebas y resultados.

  • Estandarización de procesos de validación, reduciendo errores y duplicidades.
  • Colaboración: mejorar comunicación entre los distintos actores: proveedor, área de proyectos y funcionales, Oficina de Calidad (OCa) y otros departamentos de la DGSIC.

  • Control y mejora continua: facilita la revisión, validación y despliegue de versiones en entornos productivos.

  • Eficiencia: reduReducir tiempos y errores en reduce tiempos y errores gracias a la reutilización de artefactos y pruebas.


Este enfoque mejora la trazabilidad y transparencia del ciclo de pruebas, además de reforzar la confianza en los resultados. El proceso se vuelve más ágil, auditable y alineado con los estándares de calidad de la DGSIC.

El documento correspondiente se ha publicado en el espacio Confluence "Gobierno técnologico" de la DGSIC donde pueden consultar todos los detalles. 




Estructura organizativa de scripts de base de datos por versión del producto

Actualización en relación a la estructura de los scripts recogidos en la normativa gestión de entregas, alineando la misma con la mejora en los procesos de integración continua abriendo camino hacia procesos automatizadados. 

De modo resumido: 


La carpeta /scripts del repositorio del código fuente deberá incluir una subcarpeta por cada versión del producto (siguiendo la nomenclatura de tres dígitos) como hasta ahora. Los nuevo . Cada una de estas subcarpetas contará con una nueva organización, que incluirá los scripts DDL y DML necesarios para la actualización y carga de datos, junto con los scripts de ejecución y reversión correspondientes a la versión. Esta estructura permite garantizar la idempotencia de los scripts, para asegurar una ejecución automática y libre de errores durante los procesos de actualización o despliegue.

De esfa forma, la estructura de carpetas y scripts quedará de la siguiente forma:

El detalle de los cambios requeridos se encuentran definidos en el "ANEXO I: Estructura de la carpeta scripts" del artículo normativo  Gestión de entregas 

En las entregas en curso no se aplicará esta nueva estructura organizativa de los scripts a efectos de revisión. No obstante, es importante tener en cuenta esta directriz para las futuras entregas, con el fin de garantizar la correcta adaptación a la normativa vigente y favorecer la evolución de los procesos en el marco de la mejora continua.