No where does the cliche "Failing to Plan is Planning to Fail" ring truer than in regards to testing.

First, although everyone knows you have to test applications there is a huge difference in the approach that IT takes versus software vendors. When software is your product you have a much more organized, disciplined approach to testing and, most importantly, you have resources in your company devoted to testing. IT, in contrast, with rare exceptions, does not have the luxury of testing resources. Testing is always something that is added onto someone’s to-do-list towards the end of a project. Without QA specialists, IT just does not have the expertise or experience to even know what it takes to setup and conduct a robust testing environment.

Second, regardless of what IT asks for relating to testing resources and time it is highly likely that the business will cut out that expenditure and time. The pushback you always hear is that shouldn’t testing be part of development activities? And when cut from the budget the business folks figure IT will get it tested anyways (since they rationalize that the testing tasks were just “padding” anyways!)

Finally, when the project starts getting late or over budget, testing is one of the first things that get cuts to get the project back on track. Often times testing is the last set of activities before a DW/BI release goes live and therefore the only place left to cut time from a project.

One could be generous and say that people are taking a “calculated risk” by cutting out testing but I’d suggest that there really is no calculating involved at all. When testing is cut out people are wishing that there are no application bugs or data problems. This is like playing the lottery, it is a cheap way to become rich but the problem is it is highly unlikely that it will pay off. It is certainly quicker to complete a DW/BI project if you skip or skimp on testing, but it is highly unlikely that that bet will pay off.