Ask HN: What do you do after you finish your work during a sprint?
Is it fair to start on the next sprint's work?
Is it fair to start on the next sprint's work?
My issue is that I am feeling pressured from having to handhold QA after I fix a bug. I spend more time doing this than actually writing code.
Here is a typical process to fix a bug in our application: 1. A bug is found 2. The reporter logs a ticket into JIRA often lacking how to reproduce the bug, and what the expected results are. 3. The SE gets assigned the ticket and needs to contact the reporter to find out how to reproduce and figure out what the expected result is. 4. After development, it is up to the SE to show the QA person how to test this new feature or confirm that the bug is fixed.
A few comments on QA: They are non-technical. Documentation is poor, so the SE's need to show QA how to reproduce the bugs and what the expected result is. SE's tried making step-by-step videos on how to test the code change, but that has proven to be a waste of time, as SE's are still asked to be hands on with QA. Sometimes there will be a bug deep in the architecture that can't be reproduced in the front-end. QA is very lost at how to test these. Also, we get a lot of cases, where QA thinks that a test failed, but it turns out that they just had lack of knowledge of the acceptance criteria and prior functionality.
Management doesn't want to enforce a process because it slows everything down.
Honestly, I'm pretty lost here because I can hardly articulate the intricacies of the entire situation. Is this common? I'd really like to get some sage knowledge on what's going on here, cause all I see is a painful cycle.