Success story - LABORAL Kutxa

Implementation of the quality management process - QA

An error occurred while processing the template.
The string doesn't match the expected date/time/date-time format. The string to parse was: "lun, 21 jul 2025 06:00:00 +0000". The expected format was: "EEE, dd MMM yyyy HH:mm:ss Z".
The nested reason given follows:
Unparseable date: "lun, 21 jul 2025 06:00:00 +0000"

----
FTL stack trace ("~" means nesting-related):
	- Failed at: #assign parsedPublishDate = rawPublis...  [in template "48478917202330#20121#713300" at line 4, column 1]
----
1<#assign rawPublishDate = .vars["reserved-article-display-date"].data> 
2<#assign currentLang = locale.getLanguage()> 
3<#setting locale=currentLang> 
4<#assign parsedPublishDate = rawPublishDate?datetime("EEE, dd MMM yyyy HH:mm:ss Z")> 
5<#setting time_zone="Europe/Madrid"> 
6${parsedPublishDate?string("yyyy-MM-dd'T'HH:mm:ssZZ")} 
An error occurred while processing the template.
The string doesn't match the expected date/time/date-time format. The string to parse was: "mié, 26 nov 2025 09:52:33 +0000". The expected format was: "EEE, dd MMM yyyy HH:mm:ss Z".
The nested reason given follows:
Unparseable date: "mié, 26 nov 2025 09:52:33 +0000"

----
FTL stack trace ("~" means nesting-related):
	- Failed at: #assign parsedDate = rawDate?datetime...  [in template "48478917202330#20121#713304" at line 4, column 1]
----
1<#assign rawDate = .vars["reserved-article-modified-date"].data> 
2<#assign currentLang = locale.getLanguage()> 
3<#setting locale=currentLang> 
4<#assign parsedDate = rawDate?datetime("EEE, dd MMM yyyy HH:mm:ss Z")> 
5<#setting time_zone="Europe/Madrid"> 
6${parsedDate?string("yyyy-MM-dd'T'HH:mm:ssZZ")} 
#

Success story - LABORAL Kutxa

Implementation of the quality management process - QA

In the absence of a unified and shared test registry, there was a need for its creation and exploitation in order to be able to secure past and new functionalities.

The project

In the absence of a unified and shared test registry, there was a need for its creation and exploitation in order to be able to secure past and new functionalities. In addition, the use of a tool for the recording of automated test plans and runs, and the collection of evidence demanded by the audit department was missing.

Problems identified:

  • Lack of a testing strategy and a shared repository that allow their re-use.
  • Isolated initiatives in the use of a tool for the automation of tests and, therefore, low effectiveness in the continuous deployment process (CI/CD).
  • Incipient but unsuitable test automation frameworks nor with optimised use.
  • Lack of good practice and vision of QA management. Absence of KPIs to give feedback on the product status and to raise improvements.

The challenges

  • Recording evidence for internal/external audits

  • Management of host test data

  • Implementation of different automation frameworks

The solution

Defining a QA strategy: Definition of a QA strategy to raise the quality maturity of online banking. This includes the assessment and implementation of different types of tests: APIs, E2E, performance, security, UX testing, compatibility...

Implementation of good practices

Proposal and support in the implementation of good practices such as:

  • Use of POM (Page Object Model) for automated test frameworks.
  • Use of dashboards to generate monitoring KPIs.
  • QA participation in HU specification processes.
  • Aligning QA with audit for evidence management

Functional testing and recording of tests: The use and exploitation of Azure Test Plans is explored in depth with the aim of fostering team collaboration and visibility when planning, designing and executing tests, both manual and automated.

Test automation: It is essential to significantly expand the capacity of manual testing, reduce costs and, above all, integrate testing processes into CI/CD cycles or pipelines, making the process to release a new version much more agile and secure.

Analysis of tools: The QA team conducted a comparison to advise the client on the use of a tool that would allow mobile devices to run manual and automated tests, such as Sauce Labs and BrowserStack. After the choice, it will be implemented and configured to be part of the quality process.
 

The result

After the first phase of analysis and with the QA team already participating in the development team by carrying out the specification and execution of manual tests, the benefits obtained in the project have been evident. This has led the client to expand the team from 1 Agile QA to 3, in order to cover more developments and increase test coverage.

In addition, the QA Architect's involvement promotes the implementation of new initiatives that help them advance to new maturity milestones, such as the implementation of automation for different types of testing.

More successes