Many people equate 100 percent unit test coverage with high code quality, but that is not enough. Code coverage tools only measure whether the tests execute the code; they make no judgment on the effectiveness of the tests. Testers should review unit tests, even if they have high coverage levels, and either help improve the tests or supplement them with extra tests where necessary.

Pulling data from a source system and putting it into a data warehouse is a process commonly known as extract, transform, and load, or ETL. Testing the process can be a chore—you need to be sure all appropriate data is extracted, that it is transformed correctly to match the data warehouse schema, and that it's all imported. Instead of testing the ETL process as a black box, you can pull it apart, testing each piece in isolation.

Discussions on what constitutes a “proper implementation” of test automation often focus on what tool you should use, but that is only one part of the equation. Bas Djikstra details four other things you should consider, how they contribute to the success of your test automation, and what risks are associated with failing to pay proper attention to each of them.

In the world of IT outsourcing, it is not uncommon for a company to have its applications and infrastructure developed or maintained by others. As vendors compete for this business, a common trial is testing the transition activity as a whole. How would you design acceptance criteria of a transition trial so that it is testable and clearly communicated?