test design

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.

Test automation is often hard to do well, especially when testing a complex system where the results may be dynamic and hard to predict precisely. For instance, how would you test a price finder for highly volatile products such as airline tickets, where the data comes from live, third-party systems? While manual testers can interpret such results to decide whether a system is working correctly, the interpretation may be much harder to codify in an automated test. In this week's column, Julian Harty describes an approach that may help you to improve the accuracy of your automated testing even in these volatile environments.

This article discusses the logic of system testing and how to construct the valid proofs that testers can use to assess the quality of a software product.

Staged integration versus continuous integration—which does your team prefer? Can't decide if one is better than the other? In this column, Johanna Rothman explains that you can create the perfect blend of the two. Developers and testers benefit from frequent builds, but be careful with how much you build. Build too much or too little and a project could topple.