Testers can have an influence (so can anyone!)

We needed to do a story which had several tentacles, some into ugly parts of the legacy app. The story was basically to fix invalid data that's already out there, because business rules weren't enforced through the app.

Product owner never wants to "spend points", so he wanted just the very basic things that would get the immediate need resolved, and leave some other parts of the process manual. That means humans have to remember a lot of detailed, obscure business rules. That means in a couple of years, we'd get right back to where we are, with invalid data.

We do this sort of thing fairly often. It usually starts as "OK, just to get this out the door we'll do parts A and B, and we'll do C next sprint", but we never do C because the business can work around it by asking for manual updates to the database, which they seem to feel are "free". In fact, the very problem we were solving was caused by the fact that we never did the second part of a two-part series of stories, so a system requirement was just flung into a black hole.

I'm "only" (as some would say, not me) a tester, but I made my case. With fairly minor and inexpensive (say, 6-8 hours each) to 3 pages of the UI, we would prevent a lot of requests for manual updates later, and there was a high risk that the person doing the manual updates wouldn't know all the rules and would make an error. We'd also present the end users with valid data instead of, well, no data.

The product owner didn't like it much, but the developers saw the same problems I did, and wrote task cards for the three extra changes.

No matter what your main activities are on a team, if you see an issue, raise it, and present the problems and potential costs clearly. If your team can listen to reasonable arguments, you may be able to show them your point of view, and they'll likely agree with you. This shouldn't be adversarial in any way, but you can use your passion for delivering value to good effect.

We testers aren't here to be the Quality Police, but agile development should be about doing the right things "right". When you smell a hack, point it out and ask if it's reasonable to take the time to do it right.