PMO doesn't decide anything (our PMs can barely decide what they have for breakfast).
However, it's a fact of life that because the requirements change mid sprint, the estimates are invalid without the expectation of delivery changing. This usually ends up in a negotiation, where the PM will flex the deadline a little and the Dev team have to flex a little from the ideal perfect world.
Specifically in my office, the CI server will throw an "amber warning" if code coverage is below 80% and we all try to keep it green. But if we have a tight deadline, we can sacrifice 20% test coverage and still release (the CI server won't let anyone release anything below 60%).
So, given the requirements change (other than bug fix), and deadlines are always tight, test coverage is an easy sacrifice - though that doesn't mean we don't write tests.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
PMO doesn't decide anything (our PMs can barely decide what they have for breakfast).
However, it's a fact of life that because the requirements change mid sprint, the estimates are invalid without the expectation of delivery changing. This usually ends up in a negotiation, where the PM will flex the deadline a little and the Dev team have to flex a little from the ideal perfect world.
Specifically in my office, the CI server will throw an "amber warning" if code coverage is below 80% and we all try to keep it green. But if we have a tight deadline, we can sacrifice 20% test coverage and still release (the CI server won't let anyone release anything below 60%).
So, given the requirements change (other than bug fix), and deadlines are always tight, test coverage is an easy sacrifice - though that doesn't mean we don't write tests.