You are done authoring your rules, or at least a subset of your decision logic. Now what? You need to check that your rules are working properly. Today, we will focus on traditional QA Testing.
In the coming weeks, we will review other aspects of testing such as:
- Business Performance Testing
- Runtime Performance Testing
What is QA Testing?
Obviously, QA Testing refers to the testing of business rules in this context. In the worst case scenario, users can produce test cases manually to ensure that the rules produce the proper result. That being said, it is more productive to leverage test cases with expected outcome. For Joe’s application, you know that Joe is supposed to be approved with such and such terms. You can now automate the execution of the rules, and check that they match the expected results.
Having weeks or months of historical transactions is ideal. The more transactions you have, the more comprehensive your testing will be. While there is a little investment in collecting and preparing the data, the benefit is significant.
However, if you do not have any data yet, do not give up. You can produce data by hand, or using tools such as Mockaroo. Many of our customers like to leverage Excel when possible. They simply copy one test case and create variations for each relevant attribute (age, state…). Unlike the lucky practitioners with historical data, you will have to think about the result that you expect. Though it adds a little effort, these golden test cases can be saved for the future, and reused for each wave of changes in your decision logic.
How does QA Testing work?
This part is actually trivial. Once you have uploaded your data, you just need to add a computation that compares the status of your transaction with the expected status. You have a few options here. You can create:
- a single QA Flag for every single outcome of your decision
- one QA Flag for each outcome of your decision, and likely a global one that checks that all individual flags are good
- QA Flags for just a subset of the fields you want to confirm, and, again, a global one that checks that all individual flags are good
Regardless of how many QA Flags you have, you are now ready to let the magic happen. Create a report for your QA Flag(s), and get instant gratification as the chart will let you know how many discrepancies you have.
In my projects, I like to create filters to focus exclusively on the ‘bad’ test cases. Instead of looking at the full data set, it will show me only the ones that fail QA Testing. In some cases, I end up fixing a rule after I review the test case. In some cases, I end up fixing the test case itself. You would be surprised how many time data is not supplied as expected!
Once the change is done, it is time to move on to the next ‘bad’ test case until we reach the end. QA Testing has never been easier!
Taking QA Testing to the next level
The beauty of working with data is that you can focus on actual transactions. If you are looking at older rules that you may or may not have authored personally, I highly recommend activating RedPen. That will help you pinpoint what is the issue in the rule (or test case), by overlaying them on top of each other. You can see the data next to the test done by the rule. You can see which statement in the rule is true, and which one is not. That is a time-saver in large object models.
You can tell that I am getting excited. I assure you that I am not a QA nut at all. I enjoy writing rules more than I do testing of course! This different approach to testing, with RedPen and the dashboard, has changed my perspective though. I really enjoy the rules forensics with this set of tools. Dare I say it is almost fun 😉
Additionally, once you testing is done, make sure you read our recommendations on packaging your decisions in a release.
Learn more about Decision Management and Sparkling Logic’s SMARTSâ„¢ Data-Powered Decision Manager
