I would push back hard on this question.
An interview question is a machine designed to extract a signal from a candidate. Let's examine the parts of this machine.
"The most" has already been commented on. Why is it important that the answer be the most interesting? Why are you asking the candidate to solve an optimization problem in your interview? If ...
Some opinionated points from my experience, doing mostly development and operations with only a bit of QA and support, for the past few decades. Make of them as you will.
I don't think it matters if bugs are picked up during formal QA, or by developers doing other work, or even customers or consultants. They should be treated, mostly, the same. My opinion is ...
To be honest, I wouldn't be able to come up with any defect in particular.
If I were you, I'd rephrase my questions as situations, for example:
What actions would you take if you had to reopen a defect for the fifth time?
You need to retest a defect which has been resolved by a developer without any further comments or explanation. What actions would you ...
The severity of a bug is a measure of how important the bug is to the end user: how much it breaks, how badly it breaks things, how difficult it is to get work done with this bug in place.
The priority of the bug is a measure of how important the bug is to the development team. This will take into effect the severity, but also the development time and ...
This is very common.
There are basically 3 parts to the problem:
Track stats to know when the backlog is getting worse or improving, week to week
Figure out what things you need to change to stop making it worse week to week
Clean up the backlog you created, bit by bit
I'll focus on part 3 - the cleanup - but ...
Take a deep breath
and look at the big picture
Talk to folks / your boss about standards. Have a meeting. Agree on standards including items such as special characters. Take short term initiatives this month to reduce long-term repetitive pain next year.
and allow for humans
I've lost track of the number of times I've: typed weird characters by ...
There is a third way, a middle of a road way, if you wish:
don't polute the backlog with many low priority bugs, but group them in an epic or a story that might hold them.
So, instead of having 20 low priority front end (for example) hot fixes that take 10 minutes coding each but you don't want to build a vesion for each of them, you can have a dedicated ...
I would say that product owner (or whoever ultimately decides what the team works on) can decide that some bugs will not be fixed for one reason or another. Then I would close those bugs documenting this fact so that later it is clear what has happened.
I wouldn't close them just based on time as I see it should be conscious decision to close them and time ...
I am terrible at recalling names, places, restaurants, and... bugs I have investigated. I usually ask my girlfriend or my friend to give me a name of a place we have been together or an actress in a movie with have seen. That's how my brain is wired. I don't like it but I get used to it. I guess some candidates might be like that.
But if you task me with ...
A generic answer is: It's contextual; the team and stakeholders (which is who understand better the context) should work towards finding a good way - and periodically analysis its efficacy and improve on it.
However, I see three major approaches. E.g.:
1 - The team defines strict rules for labels:
High: The user cannot use some feature
Medium: The user ...
One of the Context-Driven Testing principles is:
The product is a solution. If the problem isn’t solved, the product
Another way to say this is that software should work for its user, not for some generic/arbitrary/commonly-used set of definitions of how things should be.
When he says
Even if someone gives, the error message is ...
In addition to Michael Durrant's excellent answer and the equally good comments, I'd suggest you consider a few things:
If you have not already done so, devote some time to analysis of your bug backlog. You will probably find some combination of the following things:
The bugs cluster in certain areas of the application. These will typically be the areas ...
I go with reject and move-on.
The downside is that other folks and new folks will keep discovering the bug 'anew' and have to remember them in their head. Which sounds like a huge problem.
In practice I have found that the fear is worse than the reality. Also consider that in many systems the number of bugs based on the combination of different devices, ...
You deal with them the same way as any other bug report. Review the bug and decide what (if anything) to do about it.
If you decide to do nothing, tag it in the bug database with "won't fix" and add a description of a work-round, if available.
That doesn't "pollute" your backlog. When you have decided not to fix them they are no longer in ...
The ratings that I see in common use and have used historically are:
Severity 1 - Critical issue, crash or data loss
Severity 2 - Major issue, but no crash or data loss and no workaround
Severity 3 - Issue, with no crash or data loss and a workaround exists.
Severity 4 - Fit an finish issues.
The main decision that needs to occur for each bug is "Are we ...
A label is just a label.
It is far more important to understand what stands behind them, so people can easily say when to assign a certain severity to a bug and understand what such severity means in terms of business impact. This is important because depending on the severity* your stakeholders may take appropriate action. E.g. stop releasing the product ...
I was asked a question like this at my last interview, and it took me a bit of time to think back and come up with a good answer. This was partly due to a dearth of experience - at that time I had only held internship positions.
After I read your question, I repeated the exercise, trying to come up with my favorite bug in a span of time that would be ...
This is not QA decision but business decision. If performance is satisfactory for the customer - it is good enough.
Also remember that the most important speed is speed to the market - deliver most value for your customers to make money to support additional development of the product. If product is late to the market, and is beaten by inferior competition, ...
I would say such a question might spotlight how deep the candidate understands the technologies, analyze the root-causes and is able to troubleshoot issues.
As per my experience I can remember several interesting defects, but I consider them interesting because I did find the root-causes of them in code, or in environment or in human-factor etc.
If a ...
Bug severity is the impact bug will have on the system which is basically derived from but not limited to
The probability of the user getting the issue
Is there any easy workaround/How easily user can recover from the impact of the bug
The application under test (example: A bug of a status not updating in a certain rare scenario can be ...
There is no one "right" answer. The number and type of categories of defects that would be appropriate to your context depend upon several factors, including:
Type of application
Your team size
The level and frequency of "in the hallways" conversations between people on the team
The number of bugs you have "hanging around" waiting to be taken care of
I don't know if I'm just too literal, but when I get asked these sort of questions, I get hung up on the word "most". It's not too hard to come with a bug, but making sure that I've never seen any bugs that were more interesting is a tall order. So my advice would be to get rid of the word "most". Also, if you're looking for general aptitude rather than ...
I think it's an excellent question. I think it's likely to help you understand:
(a) what kind of technical challenges the interviewee is accustomed to dealing with. (Do they choose a programming problem, a human interface problem, or a systems architecture problem? Do they interpret "bug" to mean not meeting the spec, or not meeting the business ...
The answer, as suggested by comments, is quite easy.
You cannot fix something that you cannot duplicate. Period.
I have been on both sides of this issue and I can tell you that it's frustrating for both sides, but unless you can reproduce a problem, how will you know when it is "fixed?"
This does not make it any easier for the software developer, and ...
If you aren't getting good answers, then perhaps you can modify the question slightly to help the interviewee. The word "interesting" can be interpreted in so many different ways, and perhaps that is where your candidates are getting stuck?
Maybe you are looking for the "hardest to find" bug, maybe the "hardest to fix" bug, maybe the "most off the wall" ...
It's a great question because it separates code copiers/script kiddies from actual software engineers.
A well-known, very expensive piece of analytical software owned by a large company (I won't say their name, but their initials are I, B and M) would refuse to allow drill-down access to data via SSL.
The company isn't going to but another service ...
Personally, I ask the other team members if such and such a problem is something we even want to deal with. If we agree it's not, I don't bother opening a new bug because obviously no one cares and I don't like doing work that's considered useless.
I think what's important is that the team, the customer, or whoever decides what quality is with a concrete ...
I suggested this in the comments but figure it works just as well as an answer:
Keep the low priority bugs around, especially things that aren't hard to fix in principle. Use them as onboarding exercises for new people. They'll be just as good for learning codebases and team processes as anything else; delays from lack of experience won't disrupt anything ...
I would like to consider each of the cases separately:
Low Priority - Low priority bugs do not stay low priority always. They always have a tendency to become high priority if enough of the users complain (or a important customer raises it). Closing doesn't seem to be a good option.
Edge Cases - Remember Murphy's law. These tend to happen and they happen ...
I like to use the following:
Visualize each one falling on your head...
The beauty of this system is when you also visualize a truckload of sand being dumped on your head. Even though a system may have no huge issues, too many small issues can make it unusable as well.