Testability requires interfaces for observing and controlling software, either built into the software itself or provided by the software ecosystem. Observability exposes the input and output data of components, as well as monitoring execution flow. Controllability provides the ability to change data and drive actions through the component interface. Without testability interfaces, defects are harder to find, reproduce, and fix. Manual testing can be improved by access to information these interfaces provide, while all automated testing requires them. Alan Myrvold shares software component diagrams that show patterns of testability. These patterns will help you architect and evaluate the observability and controllability of your system. Apply these testability patterns to describe and document your own testability interfaces.

Automated unit tests verify that a component is working as expected.  They also serve as a way to understand how code works, though this doesn't always happen by reading tests.  Sometimes understanding comes from tweaking the tests to observe new failures, or rewriting the tests themselves. 

Quality assurance is more than just testing software through processing a series of controlled inputs and outputs. It must also include an assessment of all the deliverables associated with the project. Developers and testers often view software documentation as merely a source of information, not as artifacts that require evaluation. All software documentation should undergo a rigorous quality assessment just as the actual software is subject to comprehensive testing. Mark Haynes describes quality models and attributes that can be used to evaluate requirements documents. He shows how imprecision (that will haunt you later) can be detected and removed through a set of formal criteria and informal heuristics. To experience using these techniques, Mark shares examples of poorly written requirements for you to evaluate and improve. Additional quality attributes, even subjective ones, can be used to conduct a quality dialogue.

Peter Schuh writes that it is not a good thing that the use of the term refactoring has grown so common, which makes him cringe every time he hears a business person say the word. Refactoring is meant to be one skill of many that is second-nature to a journeyman programmer.