One of the (unjustly) maligned or at least overlooked features of Oracle Intelligent Advisor is the Excel Test Case platform. Even today, with a product that has been mature for years, we still regularly come across customers who either simply dont know it exists, or who for whatever reason do not use it. Here are some of the excuses we hear :

• We don’t need to test, we use the debugger
• We don’t need to use Excel Test Cases, we’re running this as a interview
• Our project is too simple, doesn’t have any rules in it
• Somebody did create some but they don’t work any more

There are plenty more, frankly, absurd excuses that we hear. But the above can be broadly broken into two categories

1) We don’t know how to manage a project
2) We don’t know how to use the Excel Test Case

Of course this article is designed to make a point, so the first item is pretty harsh. But it does boil down, in many cases, to a lack of understanding of how to deliver stable and high-performance results – if you don’t take into account PSR (Performance, Scalability and Reliability) then perhaps you should?

But let’s not get into those metaphysical questions. Let’s stick with the other common response – we don’t know how to use Excel Test Cases. Now let’s do this step by step:

1) We don’t need to test, we use the debugger.

The debugger is a great tool for looking at specific scenarios or indeed for creating a specific Test Case. But it remains a tool for developers – so that we can check the behavior of the rules and understand if we have done something wrong. It has a strong role in helping us determine reliability of our rules, but it’s not designed for more than that. Consider the customer who has 9 input attributes, some boolean, some numeric and a couple of text attributes and a date. There are rules to derive conclusions from these. It’s a tiny project, but when you think about :

4 booleans – so 2 to the power of 4 (16) combinations just for these. Now start scaling, with the text attributes (let’s imagine they have lists of 5 values just for fun), 2 numeric values which have a range of values between 0 and 10 (only) and you begin to realise that the debugger is not going to give you anything like the coverage you need to be sure of your rules doing what they are supposed to do. And someone who insists that yes it does “because I’ve saved all my scenarios in this folder, here” doesn’t understand the goal of automating the tests – and getting decent feedback about individual tests, attribute performance and more.

More worryingly, the lack of Test Cases often shows an inability to reliably (re) test after modifications / enhancements to be sure that there have not been any cases of regression.

2) We don’t need to use Excel Test Cases, we’re running this as a interview

ANY Oracle Intelligent Advisor project is a decision automation engine. The fact that there is an HTML (or Java, or XML, or JSON, or anything else) layer on top of the determination engine is irrelevant – there are rules to be tested and I’m guessing you want to automate the tests to some degree – otherwise we can lock you in the room with 100s of scenarios written out by hand and you can try them yourself (Yes, once upon a time).

3) Our project is too simple, doesn’t have any rules in it

The other day, whilst reviewing another company’s work in the course of an audit, we came across (and not for the first time, sadly) a project that had NO RULES in it. Not a single document – no Word, Excel or Decision Service. Everything was packed into 10 JavaScript files. I’m serious. Please, if your partner is producing things like this, take a step back and think whether the product or the partner is right for you. Oracle Intelligent Advisor is a decision automation platform, so if there are no decisions being taken / answers being determined by Oracle Intelligent Advisor, then there is a big problem. Sometimes I feel like sending out links to our articles on Selling Oracle Intelligent Advisor and What is Oracle Intelligent Advisor to everyone in a project like that, and asking them if they had ever seen any of it before.

4) Somebody did create some but they don’t work any more

This is my personal bugbear. What a surprise! You modified the project, which requires you re-test everything but you cannot / or you will not because “the Excel Test Cases don’t work any more”. Of course they don’t because you changed the project! Failure to keep the Test Cases in line with the User Stories, Bugs, Updates or whatever else it is that you are implementing / adding to your project. So you stop using Test Cases when you need them most. This can be due to a failure to understand the idea of “Expected Result” columns versus “Actual Results” – in an evolution we should be looking at the “Expected Result” columns since we know what the automation used to show as a result (in the previous version) , now we need to see if it still produces the same result.

Let’s look at the top five things that Excel Test Cases can do for you in your Oracle Intelligent Advisor project.

1. Get the business involved. I’ve worked on several projects where we have embedded business users whose only job is to build and test “real” business cases for us with the Excel Test Case functionality. Developers can only go so far, they dont know the actual “on the ground” reality in many cases. So having a “test squad” ensures that we get a feed of real-life, true-to-reality cases and “edge cases”. In addition, the team is faster than we are at identifying issues. These team members don’t write rules, but they do know how to interpret and write / comment / edit Test Cases.
   
2. Provide performance information. We’ve already written about the benefits of getting detailed execution data from the determinations in your Test Cases. As your projects get larger and you begin to automate large-scale decisions using the Batch Assessment engine, then this will become even more interesting and useful.
   
3. Provide robust data about the behaviour of your project. Yes, we know that this should be obvious – whether your project has entities, inferred entities or even temporal reasoning, you can still test it with Excel Test Cases. And if you are not testing it, does that mean the end users or the end customers will test it for you? We all know how that usually turns out.
   
4. Narrow down testing issues using the Debugger. Yes, of course the debugger has a role to play. Not only can you come via a Test Case into the Debugger, but the Where Used option is Test Case aware as well. And if you really have found a new Scenario, you can create a brand new Excel file for it as well.
   
5. Bring you peace of mind. Having a complex project with thousands of scenarios that all report that they have passed their tests initially. But it is even better running the tests after modifications and confirming that the “Expected” columns match the previous set of Test Case results – proof that your modifications have not caused anything to break. Remember – Actual Values are good for first time runs or new rules. Expected Values are great for regression tests to see if the engine still responds as it used to.

There are dozens more reasons to use them but if you are in any doubt, hopefully this has helped.

And while we are at it, don’t forget you can run tests without even using Oracle Policy Modeling!