“Issue ping-pong” foundation

An engineer opens a PR and closes the issue.

QA tests, finds a bug, and reopens.

Engineer pushes again. QA retests. Reopen.

…and the loop repeats.

Not only does this “issue ping pong” kill velocity, but it also feels like death by a thousand cuts for team morale.

What should have been a quick issue to resolve gets stretched way beyond what is reasonable.

Why does it happen?

Before questioning an engineer's coding abilities, here’s one of the things that could lead to this.

Culture.

There’s nothing wrong with code not working on the first try. That’s part of the process of building software. You write code. Run it. See what breaks. Rewrite it until it works.

What is a problem is that engineers are relying on other people to discover that it doesn’t work.

And that often stems from the culture of: “an engineer's job is done when code is in the repository.”

Not from the coding skills.

Not from the tooling.

But from the definition of what “done” means.

Shift it to “an Engineer's job is done when code is working as expected in production,” and it makes a difference in the quality of the issue handed over for testing.

With more ownership over the issue throughout the SDLC, engineers hand over the issue for QA when they have validated that it works as expected in the staging environment.

By the time QA sees it, the first line of checks has already passed.

It isn’t only culture, of course. Reopens also come from unclear acceptance criteria, environment mismatches, and more.

But addressing culture is the prerequisite for tackling the rest.

It doesn’t matter how clear the acceptance criteria are if the engineers don’t check them.