Question 1
Difficulty: medium
How do you decide what to test first when a sprint has limited time and multiple features are ready for QA?
Sample answer
I start by focusing on business risk, user impact, and dependency chains. If time is tight, I don’t try to test everything evenly; I prioritize the flows that would hurt the product most if they failed. For example, I would validate critical paths like login, checkout, payment, or data-saving behavior before lower-risk UI edge cases. I also look at what changed in the sprint, because newly touched code is more likely to break than stable areas. If there are integrations involved, I test those early too, since failures there can block whole releases. I like to communicate my priorities clearly to the team so everyone understands what is covered and what remains at risk. That way, if we need to make a release decision, it is based on a realistic picture of quality rather than a false sense of completeness.
Question 2
Difficulty: easy
Describe your process for writing effective test cases for a new feature.
Sample answer
When I write test cases for a new feature, I first make sure I truly understand the expected behavior, edge cases, and business rules. I usually start by reviewing requirements, mockups, and acceptance criteria, then I ask questions early if anything is vague. After that, I break the feature into testable scenarios: happy path, negative cases, boundary conditions, permissions, data validation, and any integration points. I also think about how the feature could fail in real use, not just how it should work in a perfect environment. I try to keep the test cases clear enough that someone else could run them without guessing, but not so rigid that they become hard to maintain. If the feature is complex, I’ll group related checks into a traceable set so coverage is easy to review. I see good test case design as a mix of structure, curiosity, and product thinking.
Question 3
Difficulty: medium
Tell me about a time you found a bug that others missed. How did you approach it?
Sample answer
In one project, the team had tested a feature thoroughly in the main workflow, but I noticed a small inconsistency when switching between roles and editing the same record. It was not an obvious defect, but it suggested the system might be saving the wrong state under a specific sequence of actions. Instead of stopping at the surface issue, I started narrowing down the conditions: browser, user role, data state, and timing. I documented the exact steps, captured screenshots, and checked whether the issue was reproducible in different environments. It turned out to be a logic problem in how permissions were refreshed after an update. What helped most was staying curious and not assuming that a feature is correct just because the main path works. I think good QA is about noticing small signals and following them until you understand the actual risk behind the symptom.
Question 4
Difficulty: easy
How do you test a bug fix to make sure it is truly resolved and has not introduced new issues?
Sample answer
I always verify a bug fix from two angles: the original problem and the surrounding behavior. First, I reproduce the issue in the pre-fix state if possible, so I know exactly what was broken. Then I test the fix using the same conditions that caused the bug, because sometimes a patch only addresses one visible symptom. After that, I run nearby scenarios to make sure the change did not create side effects. For example, if a validation rule was updated, I would check normal input, boundary values, and any dependent workflows. I also compare the fix against the acceptance criteria or product intent, not just the ticket description, because a technically “fixed” issue can still behave incorrectly from a user perspective. If the bug was severe or the code area is risky, I may ask for targeted regression coverage before closing it. The goal is confidence, not just closure.
Question 5
Difficulty: medium
What is your approach to regression testing in an agile environment?
Sample answer
In an agile environment, I treat regression testing as a focused safety net rather than a huge last-minute phase. I keep a core regression set for the highest-risk user journeys and then expand based on what changed in the sprint. Every release does not need the same depth in every area; the key is to test what is most likely to break and what would be most costly if it did. I also try to keep regression fast and repeatable by maintaining clear test data, reusable checklists, and automation for stable flows where it makes sense. When a new feature touches shared services or common components, I pay extra attention to those dependencies because regressions often appear there. I like to work closely with developers and product managers so I know which changes are truly isolated and which might affect more of the application than initially expected. Good regression testing protects speed instead of slowing it down.
Question 6
Difficulty: medium
How do you handle a situation where a developer disagrees with your bug report?
Sample answer
If a developer disagrees with my bug report, I try to stay focused on facts rather than defending my opinion. I’ll walk through the exact steps, expected result, actual result, and any supporting evidence like logs, screenshots, or screen recordings. If the issue is about interpretation rather than behavior, I go back to the requirement or user story to clarify the intended outcome. I also try to understand whether the disagreement is about severity, reproducibility, or whether the behavior is actually acceptable by design. In some cases, I may retest together in the same environment to rule out environment-specific differences. I respect when developers ask sharp questions, because that often improves the quality of the report. My goal is not to “win” the conversation; it is to make sure the product behaves correctly and the team has a shared understanding of the issue. Clear, calm communication usually resolves the disagreement quickly.
Question 7
Difficulty: hard
What experience do you have with test automation, and how do you decide what to automate?
Sample answer
I look at automation as a way to protect stable, repetitive, high-value checks rather than trying to automate everything. The best candidates are tests that run often, have clear expected outcomes, and would be expensive or time-consuming to repeat manually, such as smoke tests, core regressions, and critical API validations. I’m careful about automating areas that change constantly or are highly visual, because those can create more maintenance than benefit. I also think about reliability: if a test is flaky, it loses value quickly, so I prefer to automate only when the system and test design are solid. My approach is to collaborate with developers and QA peers to identify where automation can give the team faster feedback in CI/CD. I may not write every script myself depending on the team setup, but I understand the strategy, can review test logic, and can debug failures well enough to keep the suite useful and trusted.
Question 8
Difficulty: medium
Describe a time when you had to test a feature with incomplete requirements. What did you do?
Sample answer
I’ve worked on features where the requirements were still evolving, and in those cases I try to reduce ambiguity early instead of testing against assumptions. I start by identifying what is known: the business goal, the user flow, and any acceptance criteria that already exist. Then I list the open questions that affect test coverage, such as validation rules, permission behavior, error handling, and edge cases. I usually bring those questions to the product owner or developer quickly so the team can clarify expectations before too much work is done. While waiting, I may draft exploratory test ideas and provisional cases based on likely behavior, but I label them clearly as assumptions. That keeps the team moving without pretending we have certainty we don’t actually have. I’ve found that this approach helps prevent last-minute surprises and also encourages better requirements, because QA can expose gaps before they become production problems.
Question 9
Difficulty: easy
How do you ensure good collaboration between QA, developers, and product managers?
Sample answer
I think strong collaboration starts with shared goals and early communication. QA should not appear only at the end of a sprint; I prefer to be involved as soon as a feature is being shaped, because that is when risks and ambiguities are easiest to catch. With developers, I aim for fast, respectful feedback and specific bug reports that help them reproduce issues quickly. With product managers, I focus on understanding user value and business priorities so I can test what matters most. I also like to keep conversations practical: if a requirement is unclear, I ask for examples; if a defect is risky, I explain impact in plain language. I have found that trust grows when QA is seen as a partner in delivery, not a gatekeeper. That means being thorough, but also being reasonable, responsive, and willing to adjust when new information changes the plan. Good collaboration improves quality and delivery speed at the same time.
Question 10
Difficulty: hard
If you were testing a login flow and users reported intermittent failures, how would you investigate the issue?
Sample answer
For an intermittent login issue, I would first try to define the pattern behind the failures. I’d collect details like browser, device, time of day, network conditions, user role, and whether the failure happens on first attempt or after retries. Then I’d reproduce the flow repeatedly under controlled conditions to see whether there is a timing issue, session expiration problem, or dependency on a backend service. I would also check logs, authentication responses, and any client-side errors to identify where the process is breaking down. Because intermittent problems often involve environment or concurrency factors, I would test across browsers and compare behavior in staging versus production-like setups if possible. I’d look at whether the issue correlates with password resets, MFA, cached tokens, or load spikes. My goal would be to narrow it from “sometimes login fails” into a precise, actionable defect. Intermittent issues are frustrating, but with structured investigation they usually become understandable.
