When faced with a new toy such as a kid’s wagon or bicycle, or perhaps a new lawnmower or gas grill, I do most what American men do—I skip the directions and simply try to put the darn thing together. Following all those individual steps just slows me down and I wonder by bother—until I end up with a bag of extra “unused” parts or until I realized that I’ve just permanently inserted some part into another part without first slipping a critical gasket or handle in between.

Instructions, like the testing phase of application development or enterprise integration projects, just slow things down. That is until the failures and errors stop popping up, applications start breaking or the CEO wants to know why customers are upset. As much as I would like to skip the instructions, it’s often wiser to invest the time upfront to ensure the quality of the job. It’s the same thing with testing.

Let’s take a look at what typically happens in IT shops today. Most IT organizations have a mission to support and enable the business. And most IT organizations have actually done a great job over the past few years of adapting to a range of ever-changing business requirements, some of which we’ll discuss shortly.

But a key process for most IT organizations is still creating, deploying, managing, and modifying applications—both custom-built applications and off-the-shelf solutions. In addition, there’s been a significant increase in the amount and types of integrations that need to be done with existing and new applications—creating an even more complex environment to manage.

Let’s imagine the proto-typical application development process. At the starting point we have the requirements definition and planning phase, where an organization defines—hopefully—what a new application or modification needs to do. Then we have a development phase, where the application code is developed, followed—again hopefully—by a testing phase before the application is put into production. Theoretically, the code is being testing along the way and test assets are being created.

On paper, it’s pretty straightforward and seems well organized. Reality, however, is a different matter. What happens in the real world can look quite different from this scenario—the planning may not be complete or done correctly, necessitating thrashing between development and requirements gathering, business expectations can push or dictate deployment schedules, reducing the time available for testing. Frequently, when push comes to shove, application testing is the loser. If application functionality needs to be delivered to meet business needs, and the code hasn’t been completely tested, it may still be rolled out into production with the expectation that errors will be fixed after the fact.