QA gets a bad reputation when it is treated as a gate at the end of a sprint instead of a habit woven through it. The fix is not less testing — it is testing that runs in parallel with development instead of after it.
Test while the feature is being built, not after
A QA engineer who reads a ticket the day it starts, not the day it is marked done, can write test cases and flag ambiguous acceptance criteria before a developer builds the wrong thing. That single shift eliminates most of the back-and-forth people associate with slow QA.
Automate the repetitive, keep humans on the judgment calls
Regression suites should run automatically on every pull request — that is table stakes, and it catches the boring-but-critical breakages instantly. Manual exploratory testing is where humans add the most value: trying the weird input, the slow network, the back-button-mid-flow case an automated script would never think to check.
Make the pipeline part of "done"
A feature is not done when the code merges — it is done when it has passed automated checks and a manual pass. Baking that into your Definition of Done means QA is not a separate phase competing for calendar time; it is just what "finished" means.