What is normal communication when a developer moves a ticket to Ready for Test?

Question

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:

1. Find the developer and get verbal clarification. typically easy, but if someone is working from home or out, it can cause delays.
2. Go into git to see if there is documentation there, and if not, try to read the source code
3. 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?

Answer 1

If there is adequate documentation of the work the dev team has done in a another tool, then I would try to get access to that tool and work off of that. However, if you still aren't able to gain the needed information, you should standardize what is included when a task is moved to Ready to Test. This could be a note in the Jira, link to notes from another source, test plan, or anything else that has enough information for you to do your job quickly and thoroughly. You are just as much a member of the team as they are, and if you need them to supply you with more/better information they should be willing to do a little extra work (should be pretty minimal, generally).

Answer 2

Documenting everything in Jira is a possible waste. Everyone in the team should already understand what is expected to get the user story DoneDone, this includes all testing. If you do not know what and how to test I would question your current proces, not the level of documentation.

Agilish teams should focus on testing before or in parallel and not at the end. The LESS framework has a great read about thinking about testing.

How to achieve test independence in spirit without separating testing? By writing tests before implementing code . The test cannot be influenced by the implementation, because it does not exist yet. This way, test-driven development achieves the spirit of independence without separation of departments.

Writing tests a soon as possible should greatly help you to having enough information how to finalize the testing efforts when "coding" is done.

My current team starts each user story with two tasks before any code is created:

1. Design & Architecture discussions (read this)
2. Writing a test plan for user story

Often the sessions are done with two people and the outcome is shared with the full-team to get final feedback. With this information we create tasks and all start working to complete this user story in parallel. As a dedicated tester now would be the time to start on automated integration and functional tests or giving the testplan more details like more boundary cases. By working in parallel on the same task we prevent all user stories to be coding done and not 100% finished at the end of the iteration. Be sure to prevent mini-waterfalls during your iteration, because this probably leads to QA taking shortcuts to get stuff into production as committed, since you do not have enough time to test everything. Or it leads to testing done the next iteration.... :)

The user story testplan currently consists of the following steps:

• Happy path test-cases
• Acceptance test-cases
• Exploratory testing session
• Risk assessment
• Aimed automated test coverage
• Usability tests if applicable
• Thinking about performance needs
• Thinking about security needs

We try to cover the Agile testing quadrants and think upfront what we would like to test. Being an Agile tester is not about doing all the test work at the end, but to make sure the team uses and implements testing practices to make high quality maintainable and extendable software.

Other must reads:

• Agile testing book
• Technical Excellence pages of the LESS framework (covers most Agile testing practises)

Answer 3

In the response ideally we should verify below details:

• Defect status: Resolved/Rejected/Won't Fix/Ready To Test

• Comments[ of Developer]: What he/she has exactly fixed/changed and if particular condition he/she wants to specify to test thoroughly

• Version: Commit version[Fixed under]

Then you can easily proceed to bake new build & use to test !

Answer 4

"Definition of done" should include that every "done" bug has a test plan.

Such test plan could include the steps to replicate original bug, and any other steps to test any other functionality which might be affected by the changes.

If test plan is missing, bug is not done yet.