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 ...
This may be culture-specific, but from my point of view, you’re asking for someone to work for free. The interview should be the interview; you don’t ask someone to do more work after the interview. And from your point of view, how do you know you can trust that the person in question was the one who did the homework? If you want them to do some live ...
as a QA responsible person should I reject the release or send the release to marketing team with known bug
Neither one. You should let all people involved know that there is such and such bug. You should communicate clearly what the bug means to customers and other people who use the product or are somehow involved (stakeholders). This might be a team ...
IMO, your interview process shows that your company doesn't really understand QA to begin with.
QA has specific goals. It isn't "sit here with our software for x hours and figure things out". It needs to be clearly categorized, and there should be a pass/fail list of objectives.
Your scenario is unrealistic, because there is no way to ever finish. At ...
Continue testing in this situation would be counter-productive and may lead to a "deadlock" - when the reported issues would depend on each other recursively.
make sure the management is aware of the situation
sit down with the development team - determine the most critical and problematic areas and the step-by-step process to get out of the testing "...
You know, the funny thing is, this almost became a good interview tool.
If I walked in to a QA interview, and the interviewer said, "By the way, when you're done, we'd like you to bug-hunt our production product when you go home," my first thought would be: You clearly don't care about your QA programmers (Why would you? If you feel you can get random ...
I have had about 4 QA automation jobs, about 10 interviews, and was on the other side of the interview table about 10 times.
QA Automation involves writing automated testing projects. These are software projects which can be very complex, often requiring:
Managing deployments of applications
Starting and stopping application servers
Setting up test data, ...
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 ...
If I was being interviewed and was asked this question, first of all I would start off by trying to quench my curiosity.
How much time do I have?
What type of a toaster is it?
How much power limit does it operate on as per the vendor?
Does the vendor provide any user manual or claims documentation?
How does it work? Is it timer based or manual toaster?
Don't be afraid, finding someone more senior than you is fun, your finding a teammate you can learn from. Do understand X+ years does not mean more senior, experience is something that does not necessarily come with time.
What do you expect from a candidate better then you?
At-least same basic level
A Senior should be able to teach, might need very good ...
This is a simple, if uncomfortable, situation to be in. Unfortunately, it does happen from time to time and you need to be ready for it.
The fact that the defect has been found close to the deadline is, in the short term, irrelevant. Your team has found a high severity defect, so you report it. Given the short timescales, you ensure that everyone who ...
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 ...
Answering your particular question "Is it possible?" I would say "Yes, it is.". There are many aspects that could impact how active QA could be involved on the prior phases. For example:
Is that an automation QA or manual QA
How strong soft and hard skills of particular QA engineer are
How well the job was done from the top bottom phases
How well is the ...
From my experience - Faster feedback and more testing (in the form of automated tests ideally).
If behaviour doesn't change but code is refactored often, then behaviour of system should be covered by automated checks. We have unit tests, integration tests and ui tests that are run after every commit.
If requirements and behaviour changes often, then ...
It depends, mainly on the risks. I might consider creating a taskforce to decide the go-no-go situation. Some example risks:
Technical risks: Can we restore the issue later? Can the defect destroy data?
Business risks: Can we lose clients/users due to this issue?
Marketing risks: Will our growth halt if we do not release now?
Maybe you can communicate the ...
As dzieciou commented, this can vary pretty dramatically. I will give you some ideas about what I look for when interviewing an experienced QA Engineer. One of the most important things I look for - whether the role is primarily manual or automated testing - is the ability to perform root cause analysis.
For instance, if a candidate has experience ...
Deciding to release with severe bug (and escalate next release with a fix) or postpone release is business decision. It can be done only by someone who understands how customer works.
Maybe it is not a big deal at the end, and you can go on with the release (and inform customers what bug is, and find workaround until bug is fixed.
Maybe system is not safe ...
Ideally, suspend the testing. And it's time to refer the Test Plan document.
This is the time when one should look at the Testing suspension and resumption criteria section in the Test Plan document.
I can refer to the following three points that are generally mentioned under testing suspension criteria and this scenario looks like falling under point 1 and/...
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 ...
As others have said, there is no single correct answer. The interviewers are probably looking to see how you would handle a stress situation with a tight deadline.
Risk/Impact - This might be a major bug, but what you do depends a lot on how likely it is that the bug will occur in production, how much damage it will do if it occurs, and whether there is a ...
And as a homework we have asked to test the game and find critical bugs
No, no, no.
It is not your place to give "homework" from a job interview, least of all "homework" that involves doing your job for you for free.
Nothing related to the core gameplay, and nothing really critical.
I'm not surprised — you put in place no structure. No ...
There are many factors that come up when interviewing someone, the main things an interviewer would be looking for would depend on many factors like the role, experience, team size, Job description etc;
Some of the most generic things that an interviewer would be looking for are:
How passionate is the candidate about the quality and the overall quality ...
Neither. The correct answer here is to properly inform everyone who has a stake (so the marketing team and the developers who are working on the fix, and probably the QA members who discovered the bug and whoever you as QA lead for this project report to) and get a meeting scheduled ASAP to determine whether the bug is worth delaying the release for. The ...
Telling the interviewer what is less important than telling them why. They asked for the two best cases - not just a list of cases. This means that you need to explain to them why these cases are "better" than the many other cases you could have offered up. It doesn't matter if you give good answers if you cannot also explain why they are good answers.
A user story describes a piece of functionality from the perspective of a user. A classic example is:
As a registered customer, I need to see a list of my orders so I can
manage my purchasing.
A test scenario is a description of how a piece of functionality is expected to behave, with no specific perspective. The user story example I gave implies ...
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 ...
I think it's a good practice to give some demo Game & ask the tester to find some bugs in the game it helps to figure out these basic qualities of the candidate like.
Decision making capability (Bug or not)
Attention to details (Instruction sheet)
Efficiency of the candidate
Focus on random application (Layman approach)
Naturally, it depends.
What types of testing you will do first?
If you will be working with this product for a long time, you probably will want to focus on understanding its functions.
The goal here is not to find problems, but to learn in order to improve your mental model of the components of the product.
There is where Testing Tours, more ...
Well, the important thing in the question is to be sure you understand the world beyond your nose. Of course you're not directly impacted by the SDLC, but still, 80% of the shop around you will be. In other words, the recruiter asks the question to ensure you are able to get out of your role, and see things as a whole.
That's important for your career to be ...
Before answering this question, I would like to explain Why requirements are changing continuously in any Development Cycles:
People change their minds for many reasons and do so on a regular basis. This happens because:
They missed a requirement: A stakeholder will be working with an
existing system and realize that it's missing a feature.