How to report a bug that has no technical solution?

Question

When we were testing a project, which would require an Excel sheet as an input. The only validating mechanism of this whole file importing process was offered by Excel macro (validate against inputs' format, length and etc) and it was very limited.

I talked to developers and business analysts, they agreed due to budget no more work was going to be spent on improving this issue.

As the current company policy, for every issue we raise, we need to provide a solution as well.

I do not think I should leave this issue as it is, what solutions are there?

.

Answer 1

First of all, "no technical solution" isn't exactly correct. From my understanding, the technical solution is in fact very simple; either:

• improve the Excel macro to provide better validations
• or, make the import function of your application more robust to prevent errors (abort the import) and to clearly signal the problem values to the user.

I propose you first do a basic risk analysis:

• how many times will this occur?
• what is the business impact when it occurs?

As a tester, you advise on the quality and risk; management decides. If you communicate that this issue will cost the company money(*), you bet they'll have it fixed in no time. :) If it doesn't, then the issue is simply an inconvenience for the users. In this case, as Yu Zhang says, they should be aware of the issue through a manual or guidelines.

(*) Losing money can be direct but also indirect, examples: reduced efficiency, reputation damage leading to customer loss, faulty input data leading to incidents, in turn leading to reduced available resources on helpdesk and IT, ...

Answer 2

It takes serious diligence for you to continue pursuing this issue; I would have given it up already :-)

In short, the only validation you have is from Excel and developers are not going to do anything about it; and you wonder what you can do to improve software quality.

It is not uncommon for a software project to run out of budget or time before it is completed, e.g. all software has shortcomings or even bugs (That is why we release patches.)

Without knowing all the details of this project, personally, the solution I would provide is:

• Clarify who the end users are, e.g. who is using this Excel sheet. Are they likely to be more technically minded users or less technically minded users?
• Recommend business analysts in charge of this process of writing a user manual (you will need to tailor this manual for its intended users) to show which inputs are wrong and which inputs are right. You can even provide a draft to business analysts if that is required.
• Document the potential risks that this poor validating mechanism may cause in the future.

When there is no technical solution, the least you can do is to provide documents that prevent end-users from typing invalid inputs. If you can not have automated validation mechanism to prevent mistakes, then you will have to educate end users to prevent mistakes.

Answer 3

Think about the implications of the issue. What is the risk due to not fixing it? What would happen if unvalidated data is imported? Might people die? Might people get hurt? Might the business lose money or customers? Might the business have to pay compensation to others? Will there be any noticeable effect?

If the risk is high then have another conversation with your manager.

You should also raise the issue as a limitation or even as a bug in the system. You should incude you understanding of the risks of not fixing it. For the solution you could describe briefly several possible options.

• Create a proper validator for the spreadsheet.
• Describe the issue in the user's documentation, explaining that user's must create the data carefully, also explaining some of the consequences of badly formatted data.
• Do nothing. Just remember it as a limitation of the system.

Answer 4

Question's title

You're not speaking of a bug that has no technical solution, but of one that the company at this time doesn't intend to solve.
It would probably be better to change the question's title, to something like "How to report a bug that I know the company currently doesn't want to solve".

---

Solution proposal

The question as is written now can be read as if you're required to solve the problem before you can file a bug ticket for it.
I'm pretty sure it's not so (if it is your company is demented), and what you mean is that you need to provide a solution proposal.

---

What to do

If so, in general the fact that you know that the problem is not going to be solved for the time being should not thwart your filing of the bug in any way.

A problem remains a problem even if there's no budget to fix it at this time, and filing a bug for it is useful in that:

1. It documents the problem. Although it's not very likely that every user of the product will check its bug filings before using it, there's a chance that someone will and he will become aware that he needs to keep this problem into account when using the product.
2. It increases a lot the likelihood that it will get fixed in the future: the bug ticket will be seen frequently by the developers, every time they will think a little about it and:
   • at a certain point some of them might have formed such a good idea about how to fix it that it will have become quick and cheap to do it, and so it will be probably get done.
   • there might be times in your product's lifecycle when all the existing bug are reconsidered for fixing (for example when working towards a new major release).
     At those times there's a good chance that there will be time/budget for fixing the problem in subject, but if it hasn't a bug entry most likely no one will know about it and so that won't happen.
     There's a chance that someone will remember it and bring about it even if it doesn't have a bug entry, but it's not very likely.

Note that even projects that are born with a short lifetime, where you don't expect to ever get back to fix the remaining bugs, very frequently live much longer, and so bug reports will have more usefulness than you anticipate.

---

Further report of temporary mitigation

However, knowing that the bug won't be fixed at this time can still be a useful information for you:
all right, there's no budget/time to fix the problem properly at this time, but then there's frequently some cheap temporary mitigation that can be done to protect against it: in this case, most likely you can warn the users in the documentation and/or in a warning at the time when the file has to be specified.

This is not an alternative solution, as it would most likely be better to have proper, safe validation inside the software; so, you should still file a bug with the request for complete validation, but you should also report a request for the addition of warnings in the documentation and/or in the input process.
You'll most likely need to file a separate bug entry for this (unless your bug tracking system supports specifying temporary mitigations in the same ticket - I don't know any that do).

---

Security

Note that if the the problem might cause security issues publicizing it to the users might no be a great idea: if the application is an internal one it's most likely ok, if you are not too much concerned with insider threats, otherwise it's probably better not to.

However, I'm sure no company would ever release a software with known security bugs! _{(need a thousand ROTFL gifs here)}

Answer 5

Agreed to the solution given by FDM.

However I would like to suggest that you take out all the issues of this type. Once you have the list and you also got confirmation from business analyst that these issues are not going to be fixed due to budget constraints, just file the issues and mention those in the excel sheet where you maintain your test scenarios.

In this way there will be track in

• bug tracking system (like JIRA)

• excel sheet (test scenarios)

  (Why this- A QA should always be ready with records/proofs)

Also, you would like to drop an email to all the stakeholders clearly stating that these issues are not going to be fixed in a polite way so that there will also be a record.

Now regarding the solution of the bug, you may check the business impact it will have if this bug is discovered as stated by other fellow members above.

Answer 6

As the current company policy, for every issue we raise, we need to provide a solution as well. I do not think I should leave this issue as it is, what solutions are there?

I would recommend that if you wish to do something that goes against the current company policy, you should work with management to update the current company policy. Maybe to allow for bugs that will not have solutions. If the company will not do that you may need to accept that a solution is required in order to file the bug. yuch.

Answer 7

As the current company policy, for every issue we raise, we need to provide a solution as well. I do not think I should leave this issue as it is, what solutions are there?

You suggest the solution (or possible solutions, from quick-and-dirty to good-and-proper), and then you let business managers to decide which one to adopt and to worry about the budget and resources.

QA cannot assure quality. It only can assist business deciders with information about system, it's status, and detected bugs. It is up to business to make the decisions.