I have had a bit of ongoing debate and discussion with the developers on my team about the amount of information expected when a developer completes work on a ticket and passes it to QA.
We are an agile shop (we've used scrum, kanban, and hybrids of the two) with a typical team ratio of one QA resource per four developers (and the Technical Owner, who usually contributes about half the code of a full time dev).
My argument is that when we are fully staffed with developers, it is trivially easy for the test queue to get backed up. If there is insufficient documentation provided in the ticket when it moves into Ready-For-Test, I have to either:
- Find the developer and get verbal clarification. typically easy, but if someone is working from home or out, it can cause delays.
- Go into git to see if there is documentation there, and if not, try to read the source code
- Try to find notes in code review tool to learn what was done.
Items 2 and 3 are tools that I don't use often (and have varying levels of access), so I'm stumbling around in them. Often the code review doesn't have anything more than a Pass/Fail assessment, so I don't learn anything from them.
Most of the time, things run smoothly, and when I need to talk to a developer, I can find him and learn what was implemented and how to approach my testing. But when that is not the case, I think that comments in jira (beyond "Done, ready for test", or similar) are a reasonable request and should be expected. I get a lot of push back from dev that they have already documented their work in other tools and shouldn't be asked to add anything in jira.
My question is, what level of documentation or comments within Jira (or any other issue tracking tool) does QA expect when dev completes their work on a ticket?