Newsletters

6 Critical Reasons Why You Can't Afford To Delay Automating Your Software Testing

Critical Reason Number 3...Reduce Product Defects

The bugs...the bugs...can't seem to get rid of the bugs.

I trust you are finding and eliminating the bugs in your products, but at what price? Is the cost of quality becoming a burden? Do you have any of the symptoms below of a system that is not performing well?

  • A test cycle that takes weeks to complete?
  • The Quality Assurance Team working late into the night 7 days a week?
  • An all out fire drill requiring volunteers from all departments to do full scale testing just weeks before release?
  • Distributors/resellers and worse yet, clients, doing testing by default?
  • A test burden that seems to be getting more and more difficult?
  • Knowingly releasing the product without desired testing because you simply ran out of time?

These are just some of the many, many symptoms of an under performing testing process. It takes some steps to eliminate these symptoms. This issue will talk about a methodology you can begin implementing quickly to reduce the number of defects introduced to the field.

Reduce Product Defects (introduced to the field)

Traditional Software Development Environment

In an extreme traditional software development environment, as shown in Diagram 1 below, the bulk of the development is completed before the application is thrown over the wall to the testing team. This team is often made up of volunteers, subcontractors or borrowed personnel from other departments in the organization. The crash exercise is performed just before the product is released to the field. The test team works double shifts, Saturdays and Sundays, whatever it takes. Defects are recorded and fixes are provided for the defects found. The lack of time allows at best, a quick verification of the fixes. However, there never seems to be time to retest the entire product to determine if the fix affected any other function in the software. So the sad reality is that clients end up finding many of the problems.

Automated Test Environment

In an automated testing environment as shown in Diagram 2 below, the product is tested frequently, whenever there is a new build, daily is desirable. The frequency is often increased as the release date approaches. This is dependent on the development method being deployed. Defects are posted, fixed and re-tested on a daily basis. The complete test is run to flush out any problems introduced by the fixes.

The end result is that defects are identified and corrected before being introduced to the field. The chaos of last minute testing is eliminated. The quality assurance and development organizations work seamlessly resulting in a higher quality product and a reduced cost of quality.

"The difference is like night and day. With automation there is no expediting, no fire fighting, no week-end crash test exercises. You would have to experience the before and after to appreciate it."
Dexter Sealy, VP of Engineering, CardScan

Go here to view the CardScan case study.

In the next issue we will discuss Critical Reason Number 4.

By: Clayton Blaylock, Senior Vice President of qaSignature
Please e-mail your comments to cblaylock@qasignature.com or call me directly @ (617) 510-6545.

Click here for a PDF copy of the complete white paper:

«« Back to qaSignature Newsletter Archive