I've been working as a manual software tester for 5 years and I find out that I always hope there is no issue in the app under tested.

e.g: The company gave us 3 days to do regression testing every sprint. If no issue is found, we can finish on time and go home. If I find an issue/bug, we need to spend time reporting it and follow up on the issues; this might cause us to work overtime since we need to finish up the regression testing and also waste time reporting the bug.

It kinda feels like every time we find a bug, it's a "punishment" for more works.

Is it the nature of all manual testing jobs?

  • Welcome to the community! When doing regression testing, is it for the entire app or just the feature being changed? Is any of the tests being automated for regression purposes?
    – Lee Jensen
    Commented Apr 26 at 17:41
  • Definitely not. Reporting bugs and following up need to happen in the standard hours of your work. Not overtime.
    – papakias
    Commented May 29 at 9:53

1 Answer 1


Is it the nature of all manual testing jobs?

Short answer: no, but I suspect it's all too common.

To me that's a culture red flag. For starters, what does it mean for "the company" to give you three days to do regression testing? Is that a manager, a project lead, a scrum master, or some higher up person doing the giving?

Any of those would be an antipattern to me if you're intending to be agile. Principles #5 and #11 from the Agile Manifesto strike me as especially relevant:

  1. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  1. The best architectures, requirements, and designs emerge from self-organizing teams.

Of course, if the company isn't even pretending to practice agile, the above might not help much. But if they claim to be, pointing at the agile principles could help encourage a change in behavior.

What I would much rather see is the team providing and owning its own estimates and organizing its own work. It could also help for the testers to be working more closely with the developers to find ways to test throughout the sprint, not just waiting until the end, but I think that's a secondary issue.

In any case, if the company/team behavior incentivizes shallow testing and avoiding reporting problems, that's a culture problem. You may not be able to fix it by yourself, but if I were in your shoes I would start finding allies. Do you have good rapport with the developers on your team? Raise your concern in a retro (if you have them) and see if you can get the whole team (or at least more than just you) to buy in on pushing back on the "three days for regression testing" handed down from on high.

There are a lot more questions I could ask, but I'll limit it to one: if the development work for a sprint runs late, do the developers work overtime to complete it at all costs, or does it just roll over to the next sprint? If the latter, see what happens if you do responsible testing for your three days, reporting problems as you go, and just report at the end of the sprint on what hasn't yet been tested due to the problems you've found.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.