Before embarking on software tests....

For the past few weeks I’ve been getting back in the swing of planning software testing – the reason for silence here on the blog. As a bit of background I should tell you that the projects I have worked on in the past include “off the shelf” implementations as well as new product development. I have been involved in testing from determining the strategy to execution and everything in between.


One thing I have learned and tried to impress on my clients is the absolute need to understand how the business works before embarking on testing. More importantly, understand how the business will operate. It is important to understand how things work today but the majority of time should be spent on working through how the business will function using their new tool. You cannot imagine how you will test the product until you understand clearly how it will work for you. You should know from the start that this is no small feat; you will face challenges to achieving this vision.

Believe it or not your greatest challenge will be to get the business owners and user groups to accept that their work will change. Why bother getting a new tool if you want to continue working as you always have? The organization is investing in the new technology with a view to improving their situation: saving time or money. The team assessing business processes and software usage must understand this. The only way to reach this understanding is to encourage the group to keep their minds open; this new technology allows them the opportunity to fix processes that were once unfixable. If you cannot get over this challenge save your money; the business is not ready for new tools.

The second most challenging aspect in understanding how the business will operate with your new tools is the lack of knowledge about the new tool. Only time and effort can overcome this challenge. I suggest that you first identify a few key users and ensure they get trained to a high degree directly by the vendor. Your vendor should also be engaged heavily at the start of the business engagement process. This will accomplish two things: system expertise is used to quickly clarify if the tool can respond as the business thinks it should; it will also greatly increase the business confidence in the vendor and the tool.

I realize that the executive is driven to implement quickly to start seeing the return on investment as soon as possible. My goodness! They chose the product; shouldn’t they already know that the functional impact is naturally minimal? With this logic they often discount the need for such deep assessment and want to get right into the meat of the testing. I can make one promise: if you skip an exercise to validate the match between the operation of the business and the software functionality, you will spend far more time in testing than you ever imagined. Your tests will repeatedly stall for discussions and analysis to determine if a test outcome is a bug or a misunderstanding. Where would you prefer to spend your time (and money)?