Rex Black

The most dangerous kind of wrong is the kind of wrong that sounds reasonable, as I've said elsewhere in this book.

In the opening sentence of his novel Anna Karenina, Leo Tolstoy says that “all happy families are alike, but each unhappy family is unhappy in its own way.” In commenting on this passage, the historian Paul Johnson disagrees, retorting that the sources of unhappiness in families—alcoholism, infidelity, violence, poverty—are tiresome and common and lead to tiresome, common, and sad results.7 The commonality of problems is great news, though, because the commonality of the afflictions allows common approaches to alleviating them.

When you sell change, don't talk about your pain. Talk about their pain—and how better testing and higher quality can make it go away. People move away from pain much faster than they move towards idealized situations, especially when those situations don't provide immediate benefits.

As part of this process, the following conditions should be met:

All software is under revision control.
All test builds come from revision-controlled code.
Consistent, clear release naming nomenclatures exist for each major system.
A regular, planned release schedule exists and is followed.
A well-understood, correct integration strategy is developed and followed during the test planning stages.

Fred Brooks once observed that “adding more people to a late software project makes it later,” a statement that has become known as Brooks's Law

include, among others, the following notable examples from my own experience:

Failing to understand the dependencies while planning
Developing tightly coupled, unstable, unmaintainable, incompatible, or erroneous test systems
Picking the wrong test tools
Doing poor or inefficient bug isolation
Wasting time on trivial matters while the critical areas fall apart
Reporting bugs that aren't bugs
Failing to report bugs that are bugs
Running automated tests with the wrong parameters or in the wrong configurations
Skipping critical test cases

If someone asks later, “Why didn't you run all the tests you planned?” my answer will be, “Because I spent all my time reacting to bug fixes.” A mature process should be proactive, not reactive, but sometimes the test manager is not in control of the upstream and downstream processes that influence the testing process.

Agile advocates promote “face-to-face conversations.” This, of course, is another name for a meeting. From a marketing perspective, it was smart of the Agile advocates not to use the word meeting in the Agile manifesto, but the reality remains.

1. Technology Trigger. The first phase of a Hype Cycle is the “technology trigger” or breakthrough, product launch, or other event that generates significant press and interest.

2. Peak of Inflated Expectations. In the next phase, a frenzy of publicity typically generates over-enthusiasm and unrealistic expectations. There may be some successful applications of a technology, but there are typically more failures.

3. Trough of Disillusionment. Technologies enter the “trough of disillusionment” because they fail to meet expectations and quickly become unfashionable. Consequently, the press usually abandons the topic and the technology.

4. Slope of Enlightenment. Although the press may have stopped covering the technology, some businesses continue through the “slope of enlightenment” and experiment to understand the benefits and practical application of the technology.

5. Plateau of Productivity. A technology reaches the “plateau of productivity” as the benefits of it become widely demonstrated and accepted. The technology becomes increasingly stable and evolves in second and third generations. The final height of the plateau varies according to whether the technology is broadly applicable or benefits only a niche market.