Whether that action strictly qualifies to be described as “making the product better” is a matter of semantics. I think of it like this: the product is better now because I found this bug and convinced my colleagues to fix it. Sure, I didn’t fix it myself, but, if I hadn’t found it, a customer would have, and the product would have suffered as a result.

So, that’s my yard stick – not bugs found, or tests done, but bugs fixed. It works for me, and I think it is a good way to evaluate if I am doing a reasonable job.

Let me prove my point. If you had a tendency to cry wolf, or were perpetually out of sync with the devs… what would happen? Someone would fix that problem, probably through peer pressure.

In other words, I think you're probably pretty good at bug advocacy. You're also in a place where bug advocacy is less about people skills and more about facts. You still have to collect and explain those facts effectively.

Anyway, I think your situation brings up a good point about context. I still think a testers job is to make the product better, but what that means varies widely based on the context of the organization, product, and other things.

In your case, you've got a sweet gig and your life is pretty pleasant and productive. In another environment that is not as healthy or effective, it might mean something entirely different. But the job is the same – to make the product better. A tester might have to do much more than test stories to make that happen, but it's still part of the job.

There are three major functions in creating software: Someone has to decide what the software should do, someone has to make it do things, and someone has to evaluate what it’s actually doing.

If you’re not writing code, you’re not making it do things. So you can’t make it better. As a tester, you should be telling people as accurately as possible what it’s actually doing. Yes, the goal of that information is to make it better, and all the points you made about advocacy still hold. But ultimately it’s the people writing code who have to make it do that.

Eventually you’ll always find out if it’s not doing the right thing. What testing does is let you find out before you give it to the users.

Consider this: in a team composed of sensible/smart/alien-level-genius members the need for bug advocacy doesn't really arise because the business makes reasonable choices about what gets fixed when and how that gets prioritized among the backlog of other tasks. So what does a tester do without a need for advocacy? Just find bugs in the running software and report them? I'm okay with that if that's true.

This brings me back to my original question: What is the tester's job?
Understanding is all that I seek at this time.