By Dick Stark

Two weeks ago, RightStar visited a large Global 50 organization to present QA Symphony’s (QAS’) Test Management platform, qTest. Previously the organization had standardized on Jira as a development platform for approximately 5000 developers. Now they are evaluating vendors to replace its current test management platform.

Testing is a very important piece of the Quality Management component of the software development life cycle. When I first began programing back in the late 1970’s, I learned very quickly the old adage, that “nothing works right the first time.” And if it did, it would most likely be a fluke. I worked in a sales support role for a minicomputer company and helped develop a price quotation system for the sales team. Since this was before spreadsheet software was invented, this was an exciting project for me. I was responsible for development, testing, defect fixing, and support. Since my program was replaced in a few years with a spreadsheet program, I learned very quickly how things can change.

The waterfall method of developing software delivers the “completed” code to to the testers, a separate group responsible for making sure the software works as designed. With the programmers relieved of the testing burden, the code delivered is often “bug ridden,” since it is the testers and not the programmers’ job to find the bugs.

We’ve since learned that the sooner defects are found, the cheaper it is to fix them. A study by IBM found that each hour of code inspection saved 20 hours of testing time, and 82 hours of rework time, had the defects made it to production.

This makes an excellent case for the continuous software development model with a test management framework. The agile approach places greater responsibility on the developers for avoiding defects. They, not the testers are responsible for code approaching “zero defects.” And a testing platform ensures that the developers write their own tests and helps guarantee that their own code works before they release it into the pipeline.

This approach shifts quality to the left. To do this some organizations require that code be peer reviewed, or pair programming, where programmers work together in pairs, one at the keyboard, and the other looking over his or her shoulder.

Today it is generally accepted that most software will go to general availability with known and unknow defects, in the rush to get the product to market. We’ve all experienced this with some software released too soon in an effort to balance the risk of too many defects with the reward of being first to market. An interesting question that Mark Schwartz poses in his book, a Seat at the Table, is whether testing can be good enough to catch all defects. The answer is no, but a good process and a test management platform can help.

Quality is incredibly important at RightStar for project delivery. Most of our projects may have User Acceptance Testing (UAT) before go-live. It is of course much better to fix any defects during UAT, rather than after the go-live. This means that RightStar must not be just “software implementers with screwdrivers,” but experts at assessing quality in technical practice, and understanding how the successful delivery of a quality project will reduce the overall costs, improve the efficiency and speed of our deliverables, and lead to more satisfied customers.