Testing?  We Don't Need No Stinkin' Software Testing!

Testing?  We Don't Need No Stinkin' Software Testing!

All of the IT and software development leaders I speak with want to and expect to deliver high quality applications however, very few of them successfully integrate testing into the development process. In most cases, testing is an after-thought or is viewed as not as important when compared to the development aspect of the project. Therefore, if done at all, testing is allocated limited budget and resources. In my experience, the lack of commitment and integration of testing leads to problems throughout the entire development lifecycle.

Pretend for a moment that you are back in college and writing an English paper. Would you turn in your first draft without editing or proofreading? No matter how good of a student you are, your first draft is nowhere near as good as your second, third, or final draft. There is value in proofreading and having your work edited and reviewed for quality so you can produce a better result. Going back to software development, a much more complex activity then writing a paper, why would you turn in your "first draft" without "proofreading" it first?

But it costs more money!

I frequently see leaders choose to not test or to bring in a less skilled testing resource in an effort to reduce costs. However, metrics from leading industry analysts show that if defects make their way into production, costs to fix these defects increase by between 30% to over 300%! Though this is a wide range of costs, the bottom line is that it is more expensive to fix a bug once it has made its way into production then if we caught it during the development process with thorough testing.

But it takes more time!

By adding quality up front and testing during the development process, you minimize the impact of defects throughout the system and actually end up with a faster timescale. In the short term, testing may lengthen development time as it takes longer to both develop and test an individual activity. However, in the long term, the overall production timeframe is reduced. With a higher quality application, the defect and rejection rate is lower, enabling the application to meet its release timeframes and remain in production without a high churn rate for fixing bugs that were not originally caught in development.

By catching the problem at the source, you minimize the amount of change required to correct the problem. Every piece of software, whether it is a 99 cent app on your phone or a million dollar ERP system, is built upon a set of components just as if you were building a structure with Legos. When your foundation has a bad Lego piece, imagine how much you have to undo to fix that one broken piece. It is the same with software development. If the defects are on the front end, they are relatively easy to fix without having a big impact. However, if they are in the system and they have been proliferated across the code, the level of effort required to correct the exact same defect is much higher because it touches so many additional components.

But it's not my job as a developer!

Another misconception I run into is around who owns the responsibility of testing. Many organizations think that testing is just the responsibility of a designated tester or user acceptance however, testing should first be the responsibility of the developer. Going back to my earlier example about writing a college paper, if you relied only on spell check to detect your mistakes, you are going to overlook a lot of errors. This is because spell check only detects one specific type of writing error, it doesn't understand the full context of what you are writing.

So, what should I do when planning my next project?

There are three things I always recommend to clients when planning for their next development project:

  • As you are building out your next project budget, make sure to include an estimate for development as well as the testing of the software
  • Structure your project team so that your developers and testers are as close to each other as possible in the requirements gathering and development phases. The closer you keep them together, the better results you will achieve both through exploring and answering questions, getting clear understanding from both sides, and in knowing that the application meets requirements before it is handed over to the end user.
  • Make sure to include development testing as part of your team's definition of "done." A developer should never turn over code to be tested without testing it themselves first.

At Intellinet, we offer a variety of services that can help improve your development processes such as an Application Lifecycle Management (ALM) Assessment where we review your development and testing processes, identify areas where there are variances from best practices, and provide recommendations on how to move toward best practices. We also provide testing and development services both as staff augmentation - where we work alongside your team to mentor and grow their skills with more modern development practices - as well as stand-alone development and testing services independent of your development teams. Contact us today to learn more.

Get Started