Passing the Test

Software is a nebulous thing; how do you know what your company has purchased without a rigid testing practice?

• You don't. You won't know what that six figure budget was spent on and you're going to spend a lot of time in meetings talking about it.

Business process requirements are notoriously complicated and can often have cascading dependencies. How do you know that a software developer (typically a person who has never held the job for which they are creating software to assist) is interpreting your set of requirements in the same manner that you are? Furthermore, how do you know that your colleagues also share your interpretation of the business process?

• Without testing you can't clearly define the process to software developers or share your vision of a project with colleagues. If you have a discussion with a colleague about new software features and how it's going to help them, you might be talking about something that doesn't actually exist, because the developer didn't build it the way you thought they did.

How can effective documentation be created? Documentation that you can hand over to a person learning the system written so impeccably well that you won't have to spend time answering "simple" follow-up questions?

• Without testing, this can't be done. You can, however, create documentation that isn't accurate, won't be very useful to an end user, and will likely cause them to avoid attempting to use future documentation from you. You need a clear understanding of the software, through defined test scripts, before you can create effective documentation.

How do you know which portions of your business process work well on your chosen software platform and which portions do not?

• Without testing, again, you don't. You also don't really understand how what you've paid for works, therefore it's difficult to understand how the project can be amended to add additional business processes.

After your software project goes live, how can you be sure that new features added to the system aren't breaking old features?

• The only way to be sure of this is to complete and document thorough regression testing for each release.

There are a lot of reasons to test early and often. So invest the time for testing early and keep the time allocated throughout the lifecycle of your project. If you don't, you'll burn more time than you would have for testing on explaining and cleaning up defects.