I am the lead QA on a software team that has a lot of stakeholders who are constantly changing the requirements so there end up being of small cosmetic bugs that need to be changed. Most of them shouldnt take too long for the developers to fix but they want to have the ticket/bug filed anyway.

How can I get them to do the work instead of wanting paper work? They just seem like they are being stubborn.

  • 4
    How would you suggest the developers track the bugs that you are finding if not through the bug tracking system? Have you suggested that alternative to the developers? If so, what were the concerns? Jul 14 '20 at 21:30
  • 3
    Call me old fashioned, but I have a hard time getting past rapidly changing requirements and being in QA simultaneously
    – Steve
    Jul 14 '20 at 21:42
  • 1
    It actually sounds like they are doing the work. Are you responsible for assigning work to these developers? If you are not that person you shouldn’t be doing anything
    – Donald
    Jul 14 '20 at 22:35
  • 3
    "Is this place just a dev circle jerk? Is that why you are all siding with them?" Go ahead. Ask your fellow QA experts. I guarantee you they'll give you the same answers. sqa.stackexchange.com Jul 14 '20 at 23:50
  • 1
    I think you have a ticket system that looks fine on the developers side, but is uncomfortable to use for the stakeholders for some reason. So the latter just send an email, and the developers have to c&p the info into the ticket system, which is annoying. Advanced ticket systems automatically let me create a branch in version control, mark the tickets as "urgent/in work/waiting for feedback/need validation" etc.
    – Karl
    Jul 15 '20 at 12:08

They are not "being stubborn". Proper ticketing is important for many reasons:

  1. It helps developers keep context. If you pull 5 developers into a room and show them 30 bugs, and then say "fix these", I guarantee you that no more than 7 of those bugs will actually get fixed. Bombarding a developer (or anyone) with too much information causes some information to get lost. A properly executed ticketing system allows the developers to read the information they need when they need it so they don't lose any information. This is also why you, as QA, have to write the tickets, so the developers have all the context they need.

  2. It helps keep track of what's done and what's left to be done. If you have 30 bugs, they're not all going to get fixed today, and by the time they get fixed, it's hard for a developer to know what's been fixed and what's not. It's also hard to know what's in progress; if I pick up a task but someone else is already working on that task, then work is being duplicated. And yes, "it's easy to just ask", but you don't want to shout to your whole team "Who's working on X" every 10 minutes.

  3. It provides a paper trail, so that, in a month from now, when you as QA say to a developer "that's so dumb why did you implement this", they can come back to you and say "in ticket MYPROJ-1234 you said this feature was required". It puts accountability on the ticket author (in this case you) to not give the developers busy work, or to sabotage them by giving them contradictory tasks. It also gives you leverage over PM to say "you told me to do XYZ, and I wrote the developers a ticket MYPROJ-1234 to do that, and they did it, so why are you whining?"

  4. It provides a way for you, as QA, to verify that the work done is the work that should be done. If you say "I need you to do X", and then they do Y and they say "ok, X is done", and you say "that's not X, that's Y, what the heck", you have nothing to point to in terms of requirements. In particular, properly written tickets also give you as QA something to test against: a ticket should be testable, and that means that you as QA have test cases that you can use to verify that this change was made. Then when you test it and it doesn't work properly, you can go back to the developer and say "I told you to do this, but my test doesn't work, why is it still broken"

There are many many other reasons why a ticketing system is necessary and useful. Your developers aren't making busy work for you, they are making sure everything is done properly.

  • 1
    Perfect explanation of what should happen!
    – PeteCon
    Jul 14 '20 at 22:59

they want to have the ticket/bug filed anyway

What you describe is very close to proper use of bug-tracking system.

The point is that every little thing takes time.

Most of them shouldn't take too long for the developers to fix

That is unimportant. The fact that these pieces of work (bug fixing) takes > 0 effort, means the team should have a way to schedule and prioritize this work. Bug tracker system allows that.


Why do the developers want a ticket for every "little" change ?

  • They want your QA-ers to articulate exactly what the bug is and what the desired behaviour of the software should be. So everyone is on the same page about how the bug should be fixed. Since the stakeholders constantly change the requirements, as you state your yourself, this is extra important for the developers. Both to do their work correctly and cover their own backs when some stakeholder comes up with another "little" change which might be not be communicated to everyone.

  • When commiting changed code to a source control system it is good practice give as comment/description of the change, a ticket number. So later it is possibly to track why some code was changed.

  • The developers needs tickets to plan/prioritize their work, fill in their timesheets and/or just being able to tell their manager what they are doing at the moment and for whom.


Background: I have worked as QA, Software Development and Product Management in different companies.

In software engineering, tickets are often required for compliance to document changes being done to a code base and whether it followed the company process for all code changes. For instance, in my company all code must be code reviewed and tested before it can be merged and deployed to production. Tickets are also used to track some body of work so that it could de-prioritized, or reassigned easily.

I think the issue is not with the ticketing system, but with rapidly changing requirements:

a lot of stakeholders who are constantly changing the requirements so there end up being of small cosmetic bugs that need to be changed.

The onus should be on those stakeholders changing the requirements to properly track those changes and record them in the ticketing system. The QA team exists largely to guard against regressions and inconsistency with implementing requirements due to the changes in the system.

  • 3
    "onus" is the word you want ;)
    – D. SM
    Jul 14 '20 at 21:47

You're honestly the first QA person I've encountered on this side of the argument. Developers hate paperwork too. So why do we tolerate it in this case? In addition to what others have said:

  1. We have a terrible memory for that sort of thing. Not only are we likely to forget all the features people have asked for, we are likely to forget details like what version a bug was fixed in.
  2. People asking us for status makes us grumpy. Everyone is happier when people don't have to bother us as much.
  3. We don't always know who is the best developer to make a change. We might need to hand off a ticket for anything from expertise to someone going on vacation. If the history is all tied up in face-to-face conversations or someone's email, it makes it a lot more difficult to collaborate.
  4. We can't always tell up front what is a "little" bug. I recently had a "misaligned button" bug that ended up taking weeks, because it required carefully moving a bunch of code to completely different packages.

I agree with the other answers, but want to add one thing.

who are constantly changing the requirements so there end up being of small cosmetic bugs that need to be changed

A change in requirements is not a bug. If a developer does the work according to the prior requirements and does it correctly, the changed requirement is new work. New work needs to be budgeted for and prioritized accordingly. You can't just stuff it into existing tickets without things being delayed or pressuring developers.

I can see the argument that tickets for small fixes would not be required, but that would only be true in startup type companies where the developers understand what the product is and only with minor tickets. If the developers must answer to someone else, they want the tickets to justify why something took so long or what work they did last sprint.

If the tickets are being tied to velocity or points, then stuffing the fixes into other things also hides the true cost of the project (or the cost of the indecisive project managers).

  • As a dev myself - this exactly is what I felt when I read "stakeholders who are constantly changing the requirements". Product management constantly wanting to move the goalposts dives me up the wall!
    – brhans
    Jul 15 '20 at 17:13

Most of the answers explained very well why proper bugtracking is a necessity in every software development project. But I would like to address the actual perceived problem that the overhead required for managing a ticket is in no relation to the severity of the problem. This can often be a problem which occurs when the bugtracking process is too convoluted and bureaucratic.

In that case it can make sense to debate if certain things within that process are actually necessary. Bugtracking software is often highly customizable, which causes some organizations to overengineer. They introduce required fields for information which is of little practical use or doesn't apply in many cases and introduce process steps which provide little to no value. So it can be beneficial to reevaluate the bugtracking process from time to time with all participants and see if there are things which can be streamlined or optimized without losing anything of value.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .