Testing is not simply a matter of writing a few unit test or acceptance tests.
The goal of a developers is that QA should find nothing - If they do the developer team should ask themselves how it happened and take steps to prevent it in the future.
In general, the business writes the happy-path tests, while QA writes the corner, boundary, and unhappy-path tests.
While exploratory testing QA is should not be interpreting the requirements. Rather, they are identifying the actual behaviors of the system.
The authors shares the testing pyramid which displays each tests and the amount of percentage they should represent.
Unit tests -
At the bottom of the pyramid - Written by programmers for programmers in the programming language of the system - It specify the system at the lowest level. Generally the coverage number should be in the 90%.
Component tests -
These are some of the acceptance tests - Written against individual component of the system - It wraps a component sends an input and checks the output - They are decoupled from other system components
Components tests are written by QA and business analyst with assistance from development. They should cover roughly 50% of the system
Integration tests -
Integration tests are choreography tests - They do no test business rules. Rather they test how well the assembly of components dances together. Integration tests are typically written by the system architects or lead designers. They are typically not executed as part of the continuous integration test suite because they often have longer runtimes.
System tests -
These are automated test that execute again the entire integrated system. They are the ultimate integration tests. They do not test business rules directly. Rahter they test that the system has been wired correctly. These are written by systems architect and technical leads - Typically are written in the same language and environment as integration tests for the UI. System tests should cover about 10%
Manual Exploratory tests-
These tests are not automated or scripted - The intent of these tests is to explore the system for unexpected behaviors while confirming expected behaviors. The goal is not coverage or to prove out every business rules but to ensure that the system behaves well under human operation.
TDD is powerful and acceptance tests are very valuable but they should both be part of a broader testing strategy. The goal should always be QA should find nothing.