Testing is how a team gains confidence that software does what it should, and keeps doing so as it changes. Different kinds of tests catch different kinds of problems, and a balanced mix is more effective than relying on any one type.
Unit tests
Unit tests check small pieces of code, such as a single function that calculates a total or validates a date, in isolation.
Strengths: fast, precise and cheap to run often. Limits: they cannot show whether the pieces work together correctly.
Integration tests
Integration tests check that components work together: the application with its database, or one system with another through an API.
Strengths: they catch problems in the connections, which are common sources of failure. Limits: slower and more complex to set up than unit tests.
End-to-end tests
End-to-end tests drive the application as a user would, for example by signing in, creating an order and checking that it appears in a list.
Strengths: they confirm complete journeys work. Limits: slower and more fragile, so they are best reserved for the most important journeys.
Acceptance testing
Acceptance testing checks that the software meets the agreed requirements, often performed by the client or representative users against acceptance criteria.
Other important checks
- Performance testing: does the system respond acceptably under expected load?
- Security testing: are common weaknesses absent?
- Accessibility testing: can people with disabilities use it?
- Exploratory testing: skilled people trying unexpected things to find problems scripted tests miss.
The testing pyramid
A common guideline is to have many fast unit tests, fewer integration tests and a small number of end-to-end tests. This keeps the test suite fast enough to run on every change while still covering complete journeys.
Automate what you repeat
Tests that run automatically on every change, as part of a deployment pipeline, catch regressions early. Manual testing remains valuable for exploration and for judging usability.
Testing is shared responsibility
Quality is not only the tester’s job. Developers write automated tests, clients define acceptance, and everyone reports problems clearly. Testing early and continuously is far cheaper than discovering problems after release.
