testing

One of the most frustrating aspects of software testing is that it typically is viewed as an expense that should be minimized. Sure, you can argue until you drop that it is cheaper to find problems in test than it is in the field, but deep down everyone still wants to spend as little time and money on testing as they think they can get away with. That's why Linda Hayes always has been motivated to find a way to make testing a profit center. And it seems as if she just found her first real-life example. In this column, she describes how one company is positioning to make testing a profitable department.

This article is a continuation of a previous write-up on "What to Test When It's Not Your Code." As mentioned previously, test strategies should be radically different and flexible when it comes to testing code delivered by any vendor external to an organization. Similarly, the rationale behind deciding what does not need to be tested or what is given the lowest testing priority for external software products should be radically different from the rationale practiced for in-house software products. The reason for the differences has a lot to do with the risk posed by the third-party application on the daily operations of the organization. Also, the credibility of the vendors can play a major role when deciding what takes a lower priority in testing.

People have been automating software development, testing, and deployment processes since the stone age of software. The toolsmith of today shares a lot in common with these ancestral automation efforts. In this week's column, Danny Faught details how toolsmiths can learn by studying the computer subcultures of the past and present that are similar to their own.

Object orientation, the least talked about component of test automation, might be the most important factor. In this column, Dion Johnson explains how effective test automation is heavily reliant on objects.