I do not want to shock you, but software often has bugs.  We may call these “features” or “known issues,” but in the end they are bugs.  These defects are just part of being human and trying to craft large and complex solutions.  Sometimes we make mistakes.  The challenge with these errors is finding and eradicating them whenever possible.  Thus, improving quality.  That is where testing comes in.

Not a Popular Focus

It is hard to argue that QA and testing are treated with proper respect.  These tasks that are critical for good software are often dealt with as a “nice-to-have.”  Whether the focus is unit, system, or acceptance testing the needed time is rarely allotted.

Software development has advanced and embraced the design and deployment steps along with implementation.  However, testing is still lagging in how we approach it.

Embrace All Testing Types

These are sweeping statements so your experience may be very different.  However, most projects are starting to embrace the value of testing, just in baby steps.  Development tools have been instrumental in this progress.  The ability to create and run unit tests along with implementation has made it almost an automatic step.  Unfortunately, this does not extend to the system and acceptance testing.  Even worse, that is where most bugs get through to a customer.

Unit testing is great, but just the first step.  A good strategy will include system testing to make sure the pieces fit together and work properly.  Once that is accomplished, a solid acceptance plan is needed to ensure that requirements have been met. These testing types may have different names in your company, but they boil down to three areas.  Test the code modules and components by themselves.  Then verify that the modules work together properly.  Finally, check that the solution matches the original requirements.  Much like a game of telephone, it is not hard to confuse the original goals by the time we get to the end of the project.

Improving Quality Requires Testing Throughout Implementation

The problems with making testing a step at the end of coding are cost, effectiveness, and perception.  Cost is a function of fixing issues that arise.  There are several articles written about how the cost of fixing a bug increases as you move along the life cycle.  Thus, we will take that as a given.  The sooner a bug is found, the less the cost of fixing it.  Therefore, finding bugs early in development leave us more resources to create better quality software and deliver it on schedule.

The impact of timing on the effectiveness of testing is not often discussed.  However, it becomes evident when we look at the situation.  A unit test or similar testing early on in the life cycle will have limited inputs and outputs to validate.  The permutations of data inputs and output are going to be small when compared to larger systems.  Once you start putting together those “units” the complexity increases exponentially.  Thus, testing the system increase in complexity as well.  Likewise, the likelihood of 100% test coverage starts to decrease dramatically.  When we include proper testing earlier in the life cycle, we can implement it before the software complexity gets out of hand.

The Perception of Testing

Finally, we need to look at how timing can impact the perception of testing.  When it is included throughout the implementation portion, it becomes just a part of development.  It works hand-in-hand with creating software, just like writing, compiling, and commenting code.  However, when testing comes at the end of the implementation phase, it can be seen as a blocker.  The software project was chugging along fine until the testing team stopped progress and forced the developers to go back and fix bugs.  This approach puts QA staff in the position of being the guardians of a release and the ones that bear the burden of saying whether it can proceed.  Thus, we put QA staff in the awkward position of doing their job right or letting us “ship” the product.

Baby Steps

I am a big fan of steady growth and improvement.  The issues listed above can be significant and even overwhelming to address in one shot. Instead, look for ways to make improvements with each release.  Start from simple tasks like good unit tests, get comfortable with them and then move forward.  Find the means to document, reproduce, and then automate as much as possible.  Once testing becomes automated and part of your daily development you will see dramatic improvements in software quality.  It is time for us to move software creation out of the realm of dark arts and into the light of reproducible high-quality processes.