Save Time and Money in Business Intelligence: Test! -

How to make a potential 60% saving by integrating automated testing into Business Intelligence Projects

If you read my last post with Business Intelligence (BI) projects tips you’ll know I think testing is not a luxury and now I want to illustrate this.

Going by experience, I estimate from original plan to realization most projects run 75-80% over budget. I think automated testing can save 60% of this budget-overrun. Here’s why.

Let’s say the original plan looks something like this with an overall estimated budget of 31 man-days to implement a feature.

Original project plan diagram, four project phases have an estimated cost of 31 man-days

In my experience the reality looks more like my outline below with 55 man days needed. That’s where I get my increase of 75-80%, not to mention the time delay, the dissatisfied clients and hierarchy, and the added stress and tension for the team.

Actual project execution, with 24 extra man-days cost caused by overlooked details and various hiccups

To remedy this situation, in my humble opinion, testing is the answer. This is how I’d recommend doing it. It can ensure the overrun is kept to a minimum and that the extra hours can be included in the initial budget. If my estimated overrun is correct, then we could make a 60% saving.

Illustration of the savings introduced by having a testing process

My preferred types of testing for BI projects

“So what kind of testing is best?” I hear you ask. Test Driven Development is my answer. This is usual practice for most software development projects but I am yet to see it in BI projects and it frustrates me. Especially when we know we can save time and energy by potentially reducing project overrun.

Need for the systematic use of an automated test process before UAT

In order to follow best practice, the development work needs to be tested before delivery in a User Acceptance Testing (UAT) environment. The best way I see this happening for BI projects, is for the technical team to set up and use a dedicated testing environment between initial development and UAT. This allows developers to detect and fix problems before the solution gets to end users.

This testing environment should include unit testing and functional testing. I recommend these two areas of testing, as I believe their implementation in BI projects, as shown above, can really make the difference. Unit testing because it tests the actual units/components of the software: it validates that each unit performs as it should, or shouldn’t. And functional testing because it takes a step back from the software components and tests if the solution is functioning well in delivering correct and reliable intelligence data.

In both cases, running the tests should be automated, thanks to testing framework software that is easy to set up and has proven results. I would recommend developing testing templates that the team can help create and use (and reuse) in both types of testing.

Conclusion

So in conclusion, I think testing has to be an indispensable part of the BI project life cycle, in order to deliver quality work on time. And when I say quality I also mean quality in the data – it’s so embarrassing when end users come complaining of mistakes they made in their business because of your system’s incorrect data! We really have to avoid this along with wasting time and money, and that’s why testing is an essential mitigation step.

Are you interested to know more about the specific approaches? I’d love to discuss them with you. Please contact me for a chat about testing – it’s one of my favorite subjects.

And now for a little Dilbert to help us keep perspective:

Dilbert comic strip: Dilbert says, 'I spent the week writing a test script for our product.' Wally says, 'And I wrote a test script to test Dilbert's test script.' Wally says, 'Your script was almost perfect. Keep up the good work, buddy.'

Category: business. Published by Mehdi on March 23rd 2020