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 ...
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 ...
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 ...
QA found a critical bug.
I'm probably missing something here, but isn't the answer fully determined by that alone? Doesn't the word ‘critical’ mean that it prevents release? If it could be released, then it wouldn't be critical, merely serious.
If it weren't for that, then yes, you'd make sure all the relevant stakeholders were informed and consulted, and ...
Given a simple application diagram how would you test it or what will
be your test plan or test strategy.
The only answer to a question like this is: "There is no such thing as 'go there and test'". Testing is performing a risk investigation activity. Any investigation has goals and questions to be answered.
So, what type of testing one usually do ...
In addition to what the other answers have said, I would say the interviewer is looking for how you, as a new addition to a team, would deal with a no-win situation. Frankly, I'd suspect that- at minimum - the company has found itself in this kind of situation in the past. At worst (I freely admit that I'm cynical) something similar is going to be facing ...
Does the employer mean the degree of automation? Or a test object? Or isolation of components?
And you can keep asking, which is a good thing in my opinion. You obviously want to clarify what they mean by this broad question. That might help you see how they approach testing, and it will help them see what you have experience with.
what does the employer ...
Communicate. Early and often
For this release
Assess the situation as best you can but be sure to pull in the rest of the team and get their input, advice and opinions. Err on the side of over-communicating and most of all don't let fear stop you from being honest. Using a good communication form - slack, teams, etc. may be better than long ...
There is a production release planned tomorrow. QA found a critical bug.
Been there, done that. This is how we handled a similar situation in past.
Go-live was scheduled around mid-night for a project where I was working as Lead QA. Around 2 AM, we found a critical bug. The best course of action - "communicate properly" the news to your Product ...
There is a production release planned tomorrow. QA found a critical
bug. The dev team is working hard to fix it with extra effort but they
aren't anywhere close to a solution. The marketing team is asking for
the production release.
Are we talking about an Internet facing application like a web site ? Then knowingly pushing a seriously flawed application is ...
Considering the given piece of code following cases can given 100% Decision and 100% Statement Coverage.
Width = 10
Length = 5
Width = 5
Length = 10
Now, you add the three statements to print the result. These will also be covered with the above mentioned cases.
Since there is no new decision added to the script, it would be obvious that new ...
I hope this will help you understand why the answer is 4.
100% Decision coverage
The code traverses 4 paths/decisions for 100% Decision coverage.
This happens when the decision statements are nested. In this case
"height > width" with execute only if "width > length" is true.
"height > length" with execute only if &...
Statement coverage means every statement had to be executed.
Decision coverage measures the coverage of conditional branches. Branch coverage measures the coverage of conditional and unconditional branches. At 100 %, they give the same result. You can see a discussion on differences between these two here.
I added spaces so it's a bit more readable.
It is clearly a hypothetical question and answer differ based on scenarios here:
Defect Spotted: Severity 2 (vulnerability defect in a password field by performing SQL injection)
Days before release: found 3 Days before release in 50 days cycle
Protocol: I will reach to application owners, BA,Product Owners to be alerted about delays caused in ...
For such general questions, the interviewer is mainly looking for how much knowledge you have about the tools you have used and are you able to practically apply those or not. The questions is really generic, so you should probably start with requirement clarification.
Since the concern brought out was mainly on test coverage. I think the following are some ...
My answer would probably be a question:
What are the risks involved in the application? The minimum number of tests would greatly depend on these risks. I think most risks are not covered by minimal path coverage. Like Joao said, adding infrastructure to the test mix could explode the number of test cases. Which might be worth it if people could die based on ...
You can use state transition logic ,
here each form has two actions , one is save and another is goto next
And this form is available across two interface (web and Mobile)
So there can be the list 12 test cases
(Total forms or state * Total action) * Total interface =( 3 * 2 ) * 2 = 12
Here i consider transiting to next state involve testing of that state ...
"What is the minimal number of tests to cover the functionality" is not an answerable question. You said "a user must complete all 3 steps" and then you said "user can X", "user can Y" - however, the type of question you should ask is "will the user do X?". This is a more profound question that cannot be ...
My approach would be:
Assess the importance of the change;
Give the developers a timeframe to attempt resolving the bug (e.g. 2 business days);
If the bug is still present, have the developers not include the change in the release branch (there is a pre-release branch right?), else prioritise testing/QA of the change;
Inform the marketing team what ...
You should write what you know to be true, and not just list types of testing from some internet forum. Employers want to know how can you help them in their business, they are not interested in giving you a job just for the sake of you having a job.
That means, if you were doing functional testing, you should know what does it mean - how to distinguish it ...
The first thing that comes to mind is -- were these tests ever working before? If so then, don't panic. Something has changed either in the codebase or the testing framework that is probably causing groups of them to fail. Track that down and see if you can eliminate several thousand fails at a go. You're still going to need to go read over the ones passing ...
If interviewer was mentioning bugs and not test failure ( if its test failure refer answer by @Lewis
First of all having 10000 active bugs in a product is really big red flag .
And you should never release such a product. But if the management decision is still to release then,
The answer the interviewer was expecting would be "severity"
The team ...
Based from my experience as testmanager and now as tech-recruiter (but still with passion for SW-testing) I can tell you how it is working in Germany.
Studying more testing related stuff before interview:
For me as tech-recruiter this doesn't make sense just to mention some good sounding buzzwords. For us it is important to get an authentic ...