i
While SimCorp as a company turns 50 this year, few might realize that SimCorp Dimension also turns a big corner – namely 25! With so many years under it’s belt, such a vast front-to-back product coverage, and with all clients running on the same code base, it is no secret that there are millions if not billions of lines of code behind it.
Therefore, quality assurance is a big part of SimCorp’s efforts to secure a high standard in software releases. They achieve this through internal testing on new code developed as well as automatic testing of existing ‘old’ code. Code is unit and functionally tested repeatedly to ensure a standard is upheld.
It is important to note that this testing is not on your data or your processes and workflows (unless of course, you are part of their V&T service offering).
The shift a few years ago by SimCorp from a 6-month release to a quarterly release was made not only to speed up time to market but it was also made to secure that issues are reported back to the developer while it is reasonably fresh in his mind. The human mind can forget what it did yesterday and will struggle to remember what it did 3 months ago, so 1 year is asking a lot.
A single automated test can find and fix more than a single defect. There may be four or five defects behind a single test case. And there may be additional defects created within its scope as work on other parts of the system is done. For example, a developer may make a mistake in merging code, deleting statements that he or she thinks are unneeded or in conflict. So, running regression tests is a best practice.
The value of a set of automated tests increases as time progresses. The interdependencies within SimCorp Dimension are huge. Small changes that might seem isolated to very specific niche areas could appear to be unrelated to one another, and if not found in time, could introduce problems in the production environment.
This begs the question: How much testing is enough with SimCorp Dimension and can you ever test too much?
No one has unlimited time and resources to keep testing, but if you in fact did, you could keep finding bugs for a very long time. Of course, no one wants to do that, and the good news is that this is not necessary.
Make sure you time box the testing effort required.
Create test scripts and make sure you find a process to make them repeatable and automate them. For example, make use of DFS to import data and then use this in your subsequent processing. Import a bond static data and set the maturity date to be floating so it can be used in the years to come. Of course, you need to factor in leap years to ensure a consistent cash flow, but that is just part of the automation. Generally, use reference dates to set dates in your testing.
The best practice is to do test cases that have defined and reproducible test steps. Running the same test case against the same data should produce the same result. And the more you can turn test scripts into automated jobs, the more confidence you will gain in your process.
Make sure you have a system in place to track defects and have a disciplined way of categorizing defects by importance and severity. Define clear, objective rules for the urgency of defects so it is clear to the testers when a defect is in fact critical. You don’t want to be constantly delaying a promotion because uncertainty is created by a constant flow of critical defects that have alternative workable solutions.
The process you establish for testing and reporting defects must support testers in verifying that the fix is correct. This is necessary for preventing constant reopening of defects. One common problem is re-using or taking a defect that was marked “fixed” and reopening it as “not fixed” because of some new problem that the tester happened to see while testing. Although it can be useful to examine why defects are being reopened, there can be many reasons for this and only some of them are easily identified as developer or tester errors.
For a smoother deployment of upgrades, new modules, and procedures, test early, test often, and automate as much of your test scripts as possible. It is guaranteed to make your life, and the lives of your team, much easier. Hopefully, we have helped highlight the importance of testing and how to so in an efficient manner. If you have any questions or comments regarding this topic, do not hesitate to reach out.