Thanks for your comment.
I’m not saying that developers should never do any mistake.
First, I’m not saying that when what has been developed is not compliant with the specification, it’s the developer’s fault. It’s the whole team’s fault. Sometimes it’s because the developer is lazy but frankly it really is the exception; the vast majority of the times it is because of a misunderstanding about what must be done. To this end, backlog grooming/refinement sessions are essentials — and that’s probably the moment when the tester has the most value to add to the team.
My point is that whenever we find out such a mismatch between what was expected and what is done, then something should be done — process-wise — to remove the cause. Using automated acceptance testing (ATDD & BDD approaches) is a typical way to do it.
As for the fresh pair of eyes, you have the whole team around to do that — not only the tester. By the way, that’s one of the reasons why practices like pair programming, mob programming and swarming are so beneficial.
If you answer me that all but the tester don’t have fresh eyes, I will answer you that the tester’s eyes aren’t fresh either. Chances are he deeply knows the product (I have witnessed more than once testers knowing the product better than the Product Owner himself) and he also has a very good understanding of what’s going on under the hood, tech-wise. What the tester is really bringing to the team is a different set of skills. To have fresh eyes, ask actual users!
Side note: of course, if you’re working in life-critical systems I can understand that you want an extra security layer and having those fresh eyes. But in those settings, those fresh eyes are an integral part of the process and are people completely outside of the team. It’s also projects where the life-critical aspect justifies spending several order of magnitude more money. On typical projects, the return-on-investment is just not worth it.
