How to Ensure Your Modernization Project is a Success Part 3
In our previous post, we suggested that you establish a team early on to mine your database for edge cases and other examples that can be used for regression testing, define expectations ahead of time based on those examples, and test-as-you-go. In our final post of this series, we’ll go deeper into testing.
Why is Regression Testing So Important?
Regression testing is done to validate that an application functions as expected after a code change or other update. In decision migration projects, regressions tests ensure that the decision outcomes in your new system match your expectations. What’s important to remember is that you’re comparing decision outcomes and not the rules themselves.
Another reason that regression testing is a must-do is that it will help you identify what we call “logic band-aids.” These are those messy workarounds that you had to do outside your legacy system to make it work properly. Usually these workarounds exist because your legacy system lacked enough expressivity and/or functionality on its own. Logic band-aids can live in various places, including your code, your database, or your UI. Finding them is one of the hardest parts of the migration project. Regression tests can clue you in on where to look. And once you find them, you should replace them with easy-to-understand decision logic on the new system.
Regression Testing Best Practices
Regression testing can be time consuming, so here are ways that you can speed up the process (and your overall migration project):
INCLUDE REGRESSION TESTING CAPABILITIES AS PART OF YOUR NEW TECHNOLOGY EVALUATION:
As regression testing should not only be a part of your migration process but also an ongoing part of decision management, your new system should allow you to run regression tests easily. What to look for include the ability to run hundreds of thousands (if not millions) of test cases quickly, the ability to easily filter out test cases where outcomes do not meet expectations (ex. add QA flags), and the ability to report on decision outcomes (ex. custom dashboards). This short video shows you how you create dashboard reports in SMARTS to monitor and compare KPIs when you modify decision logic.
BUILD YOUR LIBRARY OF TEST CASES AS PART OF YOUR PLANNING PROCESS:
We already mentioned this in our previous post but want to reiterate it here. Ideally, by the time you start your migration, you should have your test cases ready, so that you can test-as-you-go. In addition, once you have your library, you can continue to use these test cases for regression testing every time you modify your decision logic moving forward.
AUGMENT REGRESSION TESTING WITH BUSINESS VERIFICATION:
Regression testing only works when your old system is error-free. So even if your decision outcomes in the new system match what’s in the old, the outcomes may not be accurate. This is where business verification comes in handy. These are additional business rules applied to your business rules to validate that your decision logic is correct. For example, you may have a rating table that segments people into different tiers where the higher the tier, the higher the rating. You can create a verification rule that checks whether Tier 1 < Tier 2 < Tier 3, etc. If Tier 3 < Tier 2, you know you have an error in your table. Focus your verification rules on higher-level patterns like this to help you catch any errors from your old system. And like with regression testing, continue to run these checks every time you modify your decision logic post migration.
Want to learn how SMARTS empowers business analysts to make smarter, faster operational decisions? Contact us today to request a custom demo.
