– is automation a solution?
'The days when clients could wait for multiple years between projects and upgrades are long gone. Clients want to be agile and need the ability to react quickly to changing business needs, implement a new policy and comply with the latest legislation and regulation. Test automation is an essential element of being able to execute regular cost effective and repeatable upgrades.
At ION, as part of our development lifecycle, test automation and acceptance test-driven development are rigorously implemented while we build our software in continuous integration environments. Furthermore, our clients can use the same test tools and Test Automation Service for their own testing; this minimises the need for manual, error-prone and labour-intensive testing, which in turn significantly reduces the number and duration of downstream test cycles.'
This is how David Atzeni, Director of Research & Development at ION Trading – now the owner of many treasury and commodity management systems – summarises the effect of transition to agile software development on testing. But it is not only ION clients that face the challenge of this change; more and more software manufacturers are converting to agile development, also in the area of treasury management systems, such as SAP or FIS.
For example, Dirk Joachim Henn, Product Manager for SAP Treasury, and Jean-Philippe Lombardi, Director of Agile Transformation, describe the approach of SAP as follows: 'SAP started its agile journey to succeed in the cloud many years ago. First and foremost, SAP applies SCRUM@SCALE in all programs in order to receive early feedback – also from end users in the course of design thinking projects. Further, the teams put criteria in place to ensure not only external, but also internal quality of the software. The latter is particularly important to keep productivity high.'
You can find a detailed description of the characteristics of agile software development and its effects in our December Newsletter entitled 'Impact of agile software development on TMS projects' here.
The overall conclusion is that manufacturers strive to respond more quickly to client or legal requirements and to be able to offer new functionalities by shortening their development cycles (sprints), which are combined into blocks. Usually, a sprint takes two to four weeks. At the end of a sprint, two things happen:
For instance, six such sprints are combined into one block and supplied to clients. That means that businesses receive a bundle of new functionalities every few months (e.g. in the case of six sprints of two weeks each, every three months), which should be ultimately integrated into the production operation. For this reason, major upgrade projects for treasury management systems (TMS) will become increasingly rare in the future. These will be replaced by ongoing activities resulting in the TMS always being up-to-date. That means ongoing testing – essentially also for the specialist department, which needs to accept every new functionality.
Before a new functionality can be adopted into the production operation, it has to be tested. In conventional projects, the following test phases are differentiated and run:
It is apparent that these conventional, comprehensive test cycles cannot be run every three months – at least not if they are primarily manually conducted, which is the case at many businesses.
The requirements arising from the transition of TMS manufacturers to agile development coincide with the frequently made good intention by businesses to improve testing (generally speaking this is made when it concerns creating the necessary test cases). In the course of a TMS upgrade or launch project, it has been shown time and again that businesses do not plan adequate time for testing and, in particular, for the preparation for this. As a consequence, test documentation and the associated reusability suffer in particular.
In order to be able to take up production of new functionalities at short intervals, standardised test cases are imperative. This cannot be manually worked out each time as this would tie up too many resources on an ongoing basis. Furthermore, new test cases need to be supplemented owing to newly added functionality. As a result, the prerequisite test catalogue is constantly being extended. Automating testing is thus a logical consequence. A reduction in the test scope or even waiving individual test phases increases the risk that errors occur in the production operation, which is to be avoided where possible.
For the time being this means an increased effort in the form of a separate project to launch a tool to automate testing. This is divided into three steps:
It is clear that the testing of units, integration and performance can be automated, as a minimum. As already mentioned, acceptance tests are also used to train users. Here too a fundamental rethink is necessary. Owing to the short intervals in which new functionalities are made available, there will no longer be major changes between the old and new release of the treasury management system. This is an ongoing process consisting of many small steps. As a result, learning constantly takes place on the running system. It is useful if the users concerned already participate in the manufacturers' presentations. Naturally commensurate documentation and communication by the manufacturer are imperative.
The earlier mentioned trend for switching over to agile software development will not spare manufacturers of treasury management systems. Treasury should accept the changes that this brings at an early stage. The introduction of test automation is a separate project which ideally should not be combined with an upgrade project or a new launch as this would significantly increase the project risks.
Andrew Owens, Group CTO for treasury solutions at FIS summarises the current situation and approach. His statement can also be understood as a call to treasury to actively get to grips with this topic: “FIS uses agile development across our Treasury and Payments development groups. We also have a high degree of alignment across these groups. The combination of agile processes with our ‘Continuous Integration’ frameworks is helping us to increase software quality and development velocity, whilst providing our product management team with a large amount of flexibility on setting and adjusting the product roadmaps.
FIS has a mature ‘Continuous Integration’ framework in place for our treasury and payments solutions. The scope of this framework includes automated build and testing, where we run many thousands of tests at least daily. We use a variety of tooling to assist with unit testing, GUI testing, integration testing, end-to-end testing and security vulnerability testing (static code scanning). The FIS testing framework is in place internally and we are also offering it to our clients in case they want to utilise it for their testing requirements.”
Source: KPMG Corporate Treasury News, Edition 64, Februar 2017
Author: Karin Schmidt, Senior Manager, Finance Advisory, email@example.com
© 2017 KPMG AG Wirtschaftsprüfungsgesellschaft, ein Mitglied des KPMG-Netzwerks unabhängiger Mitgliedsfirmen, die KPMG International Cooperative (“KPMG International”), einer juristischen Person schweizerischen Rechts, angeschlossen sind. Alle Rechte vorbehalten.