How to track legacy (or non-priority) bugs if not in the product backlog?

Question

I have been reading some threads/articles online but I would highly appreciate some feedback based on my particular case.

The context: a complex sector, historically no QA, large and old legacy codebase + new code based on microservices. Not using Scrum in the intended way, only some of its notions/terms. I am the only newly hired QA per the team of 12 developers.

The problem: while testing specific features in the scope of a current sprint I often find bugs in the legacy code. And nothing comes to mind (that I would like) to track these bugs. Our product backlog in JIRA is not used according to Scrum. We add only the features/bugs that are to be added to the next sprint and that's it. This managerial decision is not discussible.

So far, I can only think of:

1. creating a separate backlog for legacy bugs (the main con: it will become a cemetery).
2. Adding them to the product backlog in JIRA but labeling them instantly with a “won’t fix” label/status so that they won’t be visible in the backlog.
3. When creating test reports for testing certain features, attach a list of found bugs to them (this looks like the past century to me, w/a risk of having several Google docs with bug reports for the same module and missing an important issue)
4. Try to convince the team to always discuss the bugs found with the devs concerned. The bugs they deem important enough to work on this/next sprint are added to JIRA and the rest are just discarded and never tracked.

Answer 1

We can set Scrum aside. The organization has not and does not appear to implement Scrum as defined in the Scrum Guide. Using Scrum terms and concepts may be counterproductive at this point.

Instead, we can focus on (software) quality assurance and the outcomes typically associated with performing the (software) quality assurance function. More specifically, we can focus on the activities and outcomes related to product quality and set aside process quality activities.

The activities to focus on include:

• Evaluating products, services, and associated documentation for conformance to requirements
• Evaluating products and services for acceptability
• Measure the quality of the products and services
• Creating and managing data, information, and records associated with quality assurance activities

To summarize these activities, a portion of software quality assurance involves ensuring that the work done by development teams meets the defined requirements (verification), that the products are usable and acceptable to stakeholders (validation), and measuring and communicating the quality of the product as determined by verification and/or validation efforts.

One problem in the current organization appears to be that there is no way to track defects in the system. This means that even if you do perform verification and validation successfully, some records (defect reports, for example) can't be managed, making it more difficult to provide information about the quality of the products and services.

As someone carrying out quality assurance functions, part of your responsibility is making sure that you have the tools needed to do your job and working with the right people from the organization to build, buy, and configure the tools to carry out the work required.

The organization has a tool that is very well suited to doing what you need. The problem statement says that formalized quality assurance is new to the organization. Outright dismissing what appears to be the best possible solution - configuring Jira to support defect tracking and analysis - is artificially limiting options. As a quality assurance specialist, you should communicate good practices to the organization, helping them improve their quality assurance practices, and ensuring that other practices (like product management) consider the information generated from quality assurance practices.

However, some of your options are good if management doesn't want to improve their processes and tool usage. In order of my preference, if improving the use of Jira is dismissed, I would move on to these options:

1. Create a separate Jira project for bugs. Even though it may become a cemetery, it will allow you to carry out the activities typically associated with quality assurance. Perhaps you can demonstrate the value of keeping track of work that may not be done in the next Sprint or two and migrate the issues into the primary project.
2. Discuss the bugs with the team, perhaps considering a zero-bug policy. Although I'm not a fan of discarding bugs just because they won't be fixed, as it precludes generating a known issues list, there is an argument that important issues will keep coming back for discussion. You could pair this with logging and immediately closing the issue for traceability and tracking how often an issue returns.
3. Document defects in your test reporting. I would expect that the product managers and developers would review these test reports and create issues in their backlog for things that are important enough. You could use these reports to focus the discussions mentioned in 2, which also means you could log and close issues for traceability if you feel that is necessary.

Answer 2

Welcome to the community!

1:12 ratio? That's rough. Normal is 1 QA to 3-5 devs! I've been in a 1:10 ration a few times. You're going to be very busy!

Anyway, this situation sounds like a transition period. Moving away from a legacy system to a microservices architecture. It can actually be considered "normal" to not fix bugs in the legacy code, since that code will be going away. That's probably why they don't want it reported since they likely no about them and are choosing to not fix them. It's also likely they are not adding new features to the legacy system.

The only caveat would be high priority/high severity bugs that prevent users from using the software, security risk, a bug that takes down production, etc.

I've worked in transitions like this. It can be hard to find bugs knowing they won't be fixed. I've seen two transitions like this:

1. Build a whole new application in a new architecture that is in a new code repository. To me, this is preferred to start from scratch like this, especially when using microservices. This way, once the new feature/API is built, the legacy system can call it fairly seamlessly.

2. Rebuild in place. This is not preferable as you're using the same code repository for the new as the legacy. Unfortunately, this is quite common as leaders see this as a "faster and cheaper way" to rebuild the architecture.

Every time I've seen this, it takes longer and costs more than anticipated since you'll be running into issues in the legacy system. From my experience, it's faster and more cost-effective to use option 1! A lot of the time, legacy systems are buggy, using out-of-date dependencies, have bloated features, etc, so starting from scratch, and fixing them will create a lot of unknown side-effects.

This managerial decision is not discussible.

Well, I'd still approach leadership with the question of "why?" Not to convince them to change their mind, but to gain clarity/understanding into the decision that was made before you joined the team.

From your options, I'd likely choose the first option to notate legacy bugs in a separate bug backlog (bug cemetery), even if that's outside of Jira and in a document. This way, if you come across that bug again, you know you've already found it and self-reported it.

Answer 3

You can create an automated check that exposes the bug. And, instead of invalidating the build, it sends an email/message to the developer about the possible problem.

This way people will be continuously warned about the issue.

Continuous, explicit, and specific alerting.