Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I've found that even QA people casually write "X feature doesn't work" in bug reports, when they could give 10x more information, like: "the page stalls and shows the spinner continuously", "the button is grayed out and I can't click it", "the output is garbage letters", "the result is not the expected value", etc.


They probably assume that the person whose job is to maintain the code can more efficiently investigate the nature of the problem, provided they give instructions on how to reproduce it.


How do we know whether or not we're properly reproducing whatever they're seeing if we don't know what we're seeing?

I've seen scenarios where a set of reproduction steps actually showed two things wrong. QA was sending it back for one of the things, but they didn't say what was wrong, only that something was wrong and here's how to reproduce it. The developer saw the other problem, and fixed it. The result when shipped back to QA?

"You didn't fix the problem, but I opened a new defect now for the other thing you broke."


The instructions of "how to reproduce it" should include detailed description of what was seen and thus is being reproduced.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: