摘抄

The subtitle says it all—“Building Quality into Software.” We’ve always known that

we can’t test quality in by testing after coding is “done.” Quality has to be baked in.

To do that, the entire delivery team, including developers, has to start building each

feature by thinking about how to test it. In successful teams, every team member has

an agile testing mind-set. They work with the delivery and customer teams to understand

what the customers need to be successful. They focus on preventing, rather

than finding, defects. They find the simplest solutions that provide the right value.

In my experience, even teams with experienced professional testers need developers

who understand testing. They need to be able to talk with designers, product

experts, testers, and other team members to learn what each feature should do. They

need to design testable code. They need to know how to use tests to guide coding,

from the unit level on up. They need to know how to design test code as well as—or

even better than—production code, because that test code is our living documentation

and our safety net. They need to know how to explore each feature they develop

to learn whether it delivers the right value to customers.

I’ve encountered a lot of teams where developers are paid to write production

code and pushed to meet deadlines. Their managers consider any time spent testing

to be a waste. If these organizations have testers at all, they’re considered to be less

valuable contributors, and the bugs they find are logged in a defect tracking system

and ignored. These teams build a mass of code that nobody understands and that is

difficult to change without something breaking. Over time they generally grind to a

halt under the weight of their technical debt.