As some will say, documentation is key, but a tedious task to do. Now if you’re like me, you may hate documentation. Lets be honest, who wants to spend hours upon hours documenting code another developer should be able to understand in no time at all. Well that’s what I thought in the past, but now I’m all about documentation, especially documenting unit test cases with TM1 components. The problem about documenting unit test cases is that there are templates upon templates, and the question is, which template is right to use? With all the different templates out there, I decided to take everything available and sort through the madness and create something that will not only be useful for a client, but also an architect who will need to validate code his from his/her team members have developed and tested.
First thing needed in any unit test template is header! Your header should include a title, prepared by, name, date, and reviewed by, name and date information.
Adding this information allows you to know what TM1 component was unit tested based by the title and it also shows you who tested the component and who also approved the unit test case.
The next section you will need to add to your unit test document is a “Test Scenario.” This is important because you want to document the type of scenario, whether it’s a TI process loading data correctly, or a dimension match what is documented within the design document. This is important because it allows the reviewer to know what type of test was conducted.
After you “Test Scenario” you need to then document to unit test case steps. This shows the reviewer the exact steps taken to execute the test scenario. This documentation is important because the reviewer can validate if the test steps are incorrect or recreate the test scenario, to validate if he or she is also getting the same issue.
Key things to add in your steps table is a Test ID, Test Case, Test Condition, Expected Results, Additional Instructions, Results (Pass/Failed) and a Image ID. We will get into more detail about the image id shortly. But documenting these following items not only helps your reviewer but also shows your client your team thoroughly tested and documented each TM1 competent.
Now with any good documentation pictures make it 10x better. What’s the say, “A picture is worth a thousand words.” This is so true. Documenting the image steps can help the reviewer validate test steps without actually re-executing the test case. This saves a lot of time for both parties. Adding the images may take more time for the tester, but then it ensures the test was done correctly and saves a lot of time for the reviewer.
Using this new approach to documenting your TM1 unit test cases will save you in the long run. Here is a template and example for future use; IBM Cognos TM1 Unit Test Template Example
Stay tuned for more fun and exciting blog posts from myself and be sure to check out the other great blog posts found on https://blogs.perficient.com/.
