Not every test belongs in every stage of the pipeline; choosing the right place for each test suite is one of the most important QA decisions in a CI/CD world. Good placement balances fast feedback for developers with deeper confidence before releases.
Mapping Test Types to Pipeline Stages
A typical strategy is to run static analysis and unit tests on every commit, API and selected UI smoke tests in CI, and broader regression or performance suites on schedules or before releases. This keeps the “red/green” feedback loop fast while still building strong safety nets.
Example mapping:
- Pre-commit: linters, very fast unit tests
- CI (per push/PR): full unit tests, key API tests, UI smoke tests
- Nightly: broader regression suites, longer UI flows
- Pre-release: end-to-end tests, performance and security checksWhen you propose where to run a new test suite, always ask how often it needs to run and how long it takes.
Common Mistakes
Mistake 1 — Running full regressions on every commit
This kills productivity.
❌ Wrong: Putting all UI and API tests into the main CI job.
✅ Correct: Choose a small, representative smoke set for CI and run larger suites on a schedule.
Mistake 2 — Leaving critical checks only for nightly jobs
This delays discovery.
❌ Wrong: Detecting broken login or checkout flows hours after a bad merge.
✅ Correct: Ensure critical paths are covered by fast tests in the main CI pipeline.