Types Of Testing
Testing is not one activity. It is a family of activities that answer different questions, and confusion about which question is being asked is a common source of wasted effort.
Unit testing
Unit tests check a small piece of code in isolation. They are fast, numerous and cheap to run. They are the right tool for pinning down logic, edge cases and the behaviour of a function or class. They are not a good way to prove that a system works as a whole.
Integration testing
Integration tests check that separate pieces work together: the application and the database, the service and the message broker, the code and the file system. They are slower and more fragile than unit tests, so use them where the integration is the risk, not everywhere.
Acceptance testing
Acceptance tests check the product against the behaviour a user or business cares about. They are written at the level of a scenario, not a method. They give the team confidence that a feature is really done, and they are a natural fit for automated browser or API tests.
Exploratory testing
Exploratory testing is a human activity. A skilled tester learns the product while using it, following curiosity and suspicion to places a scripted test would never go. It is particularly good at finding problems in workflows, wording and edge cases that no one thought to automate.
Performance testing
Performance tests answer questions about speed, capacity and stability under load. They need realistic data and realistic traffic patterns. A performance test that does not resemble production can produce a very confident and very wrong answer.
Security testing
Security testing looks for ways the system can be abused. It includes automated scanning, dependency checks and manual review. Like performance, it is most useful when it is part of the delivery process rather than a single event at the end.
Regression testing
Regression tests protect behaviour that already works. They are the memory of the suite. Keep them focused on the behaviour that matters, because a regression suite that grows without limit eventually becomes too slow to run.
Choosing the mix
The right mix depends on the risks in the product. A small internal tool needs less than a payments system. The important thing is to be deliberate: know which question each test is answering, and do not ask a slow end to end test to do the job of a fast unit test.
For the developer side of this, read why developer testing matters. For how the tests fit into delivery, read tips on continuous delivery and CI tools.
Reference shelf
Sources and further reading for this note.