Question 1
Difficulty: medium
How do you approach testing a new feature when you receive only a brief requirement and a deadline is close?
Sample answer
I start by clarifying the business goal and the riskiest parts of the feature. If the requirement is brief, I’ll quickly ask targeted questions about expected behavior, supported browsers or devices, validation rules, and any edge cases the team already knows about. Then I build a small, focused test plan around the highest-risk scenarios first, because time usually matters more than trying to cover everything equally. I’ll test the happy path, obvious negative cases, and anything that could break the user flow or data integrity. If I find an issue early, I report it clearly with steps, screenshots or video, and severity based on user impact. I also keep communication active so the product owner and developers know what has and hasn’t been covered. That way, even under pressure, the team gets useful feedback instead of just a long checklist.
Question 2
Difficulty: easy
Describe how you would write a test case for a login page.
Sample answer
I’d start by identifying the main user journeys and then break them into positive, negative, and boundary cases. For a login page, I would include valid credentials, invalid username, invalid password, both fields blank, and one field missing. I’d also test things like leading or trailing spaces, password masking, password reset links, account lockout behavior, and error message clarity. If the application has security or usability requirements, I’d include session timeout, remember-me behavior, and how the page behaves after repeated failed attempts. A strong test case should be easy for someone else to execute, so I’d write clear steps, expected results, and any data needed. I also like to keep test cases modular, so if the login flow changes later, I can update only the affected parts instead of rewriting everything. That makes the test suite more maintainable over time.
Question 3
Difficulty: medium
How do you decide whether a bug should be labeled as high, medium, or low priority?
Sample answer
I look at both user impact and business impact, and I try not to confuse priority with severity. A bug can be severe technically but not urgent for release, or it can be moderate technically but affect a critical business flow. I ask: does it block a user from completing a core task, does it affect many users, is there a workaround, and is there a release or compliance risk? For example, if checkout is failing, that’s likely high priority because it directly affects revenue. If a label is slightly misaligned on one browser, that’s usually lower priority unless it affects accessibility or brand trust. I also consider frequency. A rare bug may be less urgent than one that happens every time. When I log the issue, I explain the impact clearly so the team can make a shared decision instead of relying on my label alone.
Question 4
Difficulty: medium
Tell me about a time you found a bug that others had missed. What did you do?
Sample answer
In one project, I was testing a form that seemed straightforward, and most of the team had already signed off on it. While checking edge cases, I noticed that if a user entered a very long value in one field and then navigated backward in the browser, the form would preserve partial data incorrectly and sometimes submit without showing an error. It wasn’t a flashy bug, but it had the potential to create bad records and confuse users. I documented the exact steps, captured screenshots, and retested it on a couple of browsers to confirm it wasn’t isolated. Then I explained the business impact in the bug report rather than just saying the form was broken. The developers were able to reproduce it quickly and fix it before release. That experience reminded me that good manual testing is often about curiosity and patience, not just following the obvious path.
Question 5
Difficulty: easy
What is the difference between smoke testing and regression testing?
Sample answer
Smoke testing is a quick check to confirm that the basic build is stable enough for deeper testing. I use it to answer one question: does the application still work at a fundamental level after a new build or deployment? For example, I’d verify that the app opens, the main pages load, and the key workflow doesn’t immediately fail. Regression testing is broader. It checks whether a recent change accidentally broke existing features that used to work. That often means retesting areas related to the update and other core paths that could be affected indirectly. In practice, I usually do smoke testing first because there’s no point running a large regression pass if the build is unstable. Then, if the build passes smoke, I focus on regression areas with the highest risk. Both are important, but they serve different purposes in the release cycle.
Question 6
Difficulty: hard
How do you test a feature when there is no documentation or the requirements are incomplete?
Sample answer
When documentation is missing, I treat testing as both discovery and validation. I start by exploring the feature in the application to understand how it behaves today, then I talk to the developer, product owner, or business analyst to confirm the intended outcome. I try to learn the user’s goal first, because that helps me identify what matters most. From there, I create test scenarios based on the flow I observed, common user mistakes, and likely boundary conditions. I’ll note assumptions clearly so the team knows where I’m filling in gaps. If something feels ambiguous, I don’t guess silently; I ask for clarification or raise the concern early. That approach prevents rework and helps the team tighten requirements. I also keep my test notes organized, because incomplete requirements often evolve, and it’s useful to show how the behavior changed over time.
Question 7
Difficulty: medium
How do you handle a situation where a developer disagrees with the bug you reported?
Sample answer
I stay focused on the evidence and the user impact. If a developer disagrees, I don’t take it personally or argue based on opinion. I walk through the exact steps to reproduce the issue, share screenshots or video if I have them, and explain what I expected versus what actually happened. If the behavior depends on environment or data, I’ll verify it in the same setup they used so we’re comparing the same conditions. Sometimes the disagreement comes from different assumptions about requirements, so I’ll pull in the original acceptance criteria or ask the product owner to clarify. I think the best outcome is not “winning” the discussion, but getting to the correct behavior for the user. If it turns out I was wrong, I update the report and learn from it. If I’m right, I keep the tone respectful so we can move quickly toward a fix.
Question 8
Difficulty: easy
What steps do you take to test a bug fix before closing the ticket?
Sample answer
I first confirm the original issue is reproducible in the right environment so I know I’m testing the real problem. Then I retest the exact steps that triggered the bug and verify the fix actually changes the behavior. I don’t stop there, though, because a good fix should not break nearby functionality. I usually check related flows, inputs, or screens that could be affected by the same code path. If the bug was in a checkout form, for example, I’d test both the specific failure and nearby cases like different payment methods or error handling. I also make sure the fix works in the same browser or device where the bug appeared. Once I’m satisfied, I update the ticket with clear notes and retest evidence if needed. I want to be sure the issue is resolved, not just hidden by a temporary workaround.
Question 9
Difficulty: medium
How do you prioritize your testing tasks when multiple features and bugs are assigned at once?
Sample answer
I prioritize based on risk, deadline, and dependencies. First, I look at what could block the release or cause the most user harm if it fails. Those items go to the top. Then I check whether any tasks depend on another team’s work or on an unstable build, because that affects the order I can realistically test things. I also separate bug verification from new feature testing so I don’t lose track of critical fixes. If everything feels urgent, I communicate with the team and ask for guidance on what matters most for the current sprint or release. I’ve found that transparency is better than trying to silently do everything at once. I also keep a running list of what I’ve covered, what remains, and what risks are still open. That helps me stay organized and gives stakeholders a clear view of testing status.
Question 10
Difficulty: easy
What makes a manual QA tester effective on a cross-functional team?
Sample answer
A strong manual QA tester is effective because they communicate clearly, think like a user, and stay curious. On a cross-functional team, I’m not just looking for defects; I’m helping improve the product by asking good questions early. That means I need to explain issues in a way developers can act on, and I need to translate technical behavior into business impact for product and support teams. I also try to be proactive instead of waiting for someone to hand me a perfect test plan. If I notice a risk, I raise it. If I see a pattern in bugs, I share it. At the same time, I respect deadlines and understand that perfect coverage isn’t always possible. The best QA people I’ve worked with are collaborative, reliable, and comfortable speaking up when something doesn’t feel right. That mindset helps the whole team ship with more confidence.
