Hacker News Reader

Comment by namdnay | Hacker News Reader

> I’m going to start trying this at work. I wonder how it will be received?

You’ve never done that at work? In every company I’ve worked for, nobody would bat an eyelid at dropping an issue that hasn’t been touched for more than a year

View on HN

That's how we got that stupid bot on GitHub that constantly says "comment here or I'll close this". From time to time I have to waste my time that way. I wonder if this means maintainers want us all day bumping bugs?

I have this “ready with tests” PR for almost a year now, and every time I get a notification it’s either the bot or someone who really wants the PR to be merged bumping it up for me. I don’t even care so much about it any more…

Without testing to see if it is actually fixed? Never. Though, to be honest, it is QA who is testing it, not us developers. But, only QA can close a ticket and no way would they close it without being 100% sure it is fixed.

For QA to test tell if it's fixed, they must have a test case. If there is a test case here, the devs wouldn't have to guess?

The bug reproduction steps (along with expected vs actual behaviour) are in the opening comment of the bug report, so they really should not have had to guess.

See my response to kortilla above.

QA is not your test suite. Test your own code, submit working code, let QA try to break it.

Dont just push code and expect others to point out your flaws. Take some responsibility.

See my response to kortilla above.

> Though, to be honest, it is QA who is testing it, not us developers.

Developers absolutely should be testing for the issues they know about. QA is there to look for unknown issues.

Any company that depends on QA for testing and doesn’t make devs to it is miserable to work for (both as a dev and a QA).

Not where I work. QA are the ones who first look at all reported issues. They see if they can replicate the reported issue. If they can’t they contact the reporter and try to figure out why they can’t replicate it. Once they can replicate it they write up the ticket with replication steps and add it to the backlog to be assigned out in a sprint. They attend all meetings and explain the issues. Once the developer thinks they have fixed the issue they send it back to QA to verify it is fixed. Then QA reaches out to the person that reported the issue to tell the about the resolution.

Have you ever sent the issue back to QA as fixed, and then they do their reproducer and it’s not fixed? That’s roughly the scenario we’re asking you to have empathy toward.

That’s not testing, that’s triage. If you don’t bother writing unit tests yourself as a developer when you fix the tickets, then that’s the problem I’m referring to.

In most places I’ve worked, having a bug untouched for even a fairly small fraction of that time would result in someone getting, at a minimum, corrective counseling.

Corrective counseling for a single bug? I take it you’ve never worked in a US software company.

Reply on news.ycombinator.com