How can I improve Jira ticket Hygiene (content detail)?

Question

My developers keep on putting short to no descriptions in tickets which are intended for me to do testng with.

I then find it impossible to work on due to lack of specific details. I keep bugging them for more details but they continue to put in short to missing descriptions. I've set a hard line of details needed before I work on them but that has only partly solved the problem as now some tickets are left hanging for important issues and the backlog is growing.

Answer 1

Avoid trying to direct people to change as it often backfires

Instead, use some or all of the following techniques:

• Ensure there is a healthy and robust discussion of testing during the initial ticket sprint planning sessions.
• Initiative '3 amigos' discussions when requirements / testing is not clear
• Share knowledge and best practices through giving workshops, lunch and learns and presentations
• Initiative a 'ticket best practices' session, document the agreed on standards and then refer to them for compliance
• Use retrospectives to bring up workflow issues like this that you'd like to hear suggestions from others for improvement on
• Use standup to ask questions when information is needed.
  Over time it will be obvious that more detailed tickets would be helpful
• Accept and practice calm and constant repetition through multiple channels.
  Don't be discouraged by how much effort it takes
• Be consistent over time about (always) needing more detail in a nice fun friendly manner.
  Good (i.e. lazy) programmers will correct their own behavior
• Show why and how the information makes a difference in each case (not generalizations).
  This is the most logical and thus persuasive argument to programmers

Agree on good tickets habits for all such as:

• Steps to reproduce
• Screenshots - or even better video
• Agreed on severity level definitions
• What specifically to test

Seriously consider using a BDD tool so that these discussions are captured as requirements and you have documentation as code via tests

Finally, work with:

• your manager
• your product owner
• your scrummaster

Quality for the customer is obviously their job too and getting the others to play nice is ALSO their job.

Answer 2

This sounds like developers and testers are missing requirements. This doesn't mean you need a huge formal requirements document, but in the very least each product enhancement needs acceptance criteria. Each defect report needs steps to reproduce.

Developers should not be writing acceptance criteria. Someone on the product side needs to do this. If a developer creates a defect report, they better include steps to reproduce. If they don't, as soon as you get assigned the ticket reassign it back to the developer with a comment to add exact steps to reproduce.

If you get an enhancement without acceptance criteria you need to contact a product person to get this information. If you have no "product person" then you have identified your problem. It cannot be just developers and testers. You need someone to gather the information from the users or client and work with developers and testers to ensure everyone understands what needs to be done.

Because if you don't understand what needs to be done, how on Earth is a developer supposed to understand? The problem does not reside with developers. It resides with the overall process of bringing work to the team. I bet developers get just as frustrated as you due to lack of information.

Answer 3

I think you answered your question well, there's little to add on the side of what should be done. However, it might be useful to see what not to do when facing such a situation:

• hope the problem will eventually go away. It won't, people don't like to change and there even might be more reasonable causes of the problem like programmers being under too much pressure and thus not really having time to write info into tickets. Either way, it needs to be actively dealt with.
• not talk to developers in person. It's easy to slip into over-using email, slack, teams or whatever other online channel is used, but that's not helping the situation nearly as much as personal conversation would. If there's a chance you can talk to the devs, it should be preferable over online communication.
• pretend to have all the information and go on to test it anyway. Obviously this is a good way to forget something important and create a much bigger problem later on.
• blame developers. This might not be their fault at all, many companies simply have too much work for their people, so the people naturally find ways to cut out what's possible and focus on more important parts of their job. If this is the case, more conversations in your team and with your project manager about the situation might help make the situation more bearable. The goal from the tester's point of view is to make others realise than no information going to testers really hurts the whole team in the long run (more time needed for testing, potentially more bugs in production, more angry testers, communication in the team worsens since people tend to be more angry at each other etc.)
• not be an example. Maybe the case is developers feel you as a tester don't provide enough information in tickets, so why should they try harder? Make your tickets be an example, write information into them in a way it saves developer's time and they might follow on your example.

All in all, becoming active in solving the problem is a good strategy, being passive not so much.