# QA Engineer interview questions and answers

Source: https://digitalcvmaker.com/interview-questions/qa-engineers
Last updated: 2026-10-01

QA engineer interviews test whether you can find the bugs that matter before users do, through both manual and automated testing. Expect questions on test case design, bug life cycle, severity and priority, test types, Selenium or Playwright, API testing, SQL checks and test strategy, often with a live task such as writing test cases or a small script. Practise the 20 questions below out loud and prepare for the follow-ups.

QA hiring usually runs as an online test on testing concepts and sometimes coding, a technical round that may include writing test cases or an automation script live, a round with a QA lead or manager on strategy and past projects, and a final HR discussion.

## Role and technical questions

### 1. What is the difference between severity and priority? Give an example where they differ.

Round: Role · Level: Fresher

**What they’re checking:** Whether you understand how bugs are classified and triaged, and that technical impact and business urgency are separate judgements.

**Sample answer:**

> Severity is how badly a bug affects the system’s functionality, and it is usually set by the tester. Priority is how soon it needs fixing, and is usually decided by the product owner or lead based on business needs. They often match, but not always. A spelling mistake in the company name on the home page is low severity, since nothing breaks, but high priority because every visitor sees it and it hurts the brand. A crash in a rarely used admin report export is high severity, but it may be low priority if only one internal user needs it once a quarter and there is a workaround.

**Likely follow-ups:**

- Who has the final say on priority?
- What severity levels have you used?

### 2. Write test cases for a login page with email, password and a Remember me option.

Round: Role · Level: Fresher

**What they’re checking:** Whether you think beyond the happy path to negative, boundary, security and usability cases, which is the core of test design.

**Sample answer:**

> Positive cases: login with valid email and password; login with Remember me ticked, close and reopen the browser and stay logged in; untick it and confirm the session ends after closing. Negative cases: wrong password, unregistered email, empty fields, email without @, leading or trailing spaces, and the right error shown without revealing which field was wrong. Boundary cases: maximum length for email and password. Security cases: password is masked, account locks after the set number of failed attempts, login form uses HTTPS, SQL injection text in fields is rejected safely, and session is invalidated on logout. Usability: tab order, Enter key submits, and the page works on mobile.

**Likely follow-ups:**

- Which of these would you automate first?
- How would you test the account lock timing?

### 3. Explain the bug life cycle you follow in your team.

Round: Role · Level: Fresher

**What they’re checking:** Whether you know how defects move through statuses and who acts at each stage, which shows you have worked in a real QA process.

**Sample answer:**

> When I find a bug, I log it as New in Jira with steps to reproduce, expected and actual results, environment, build number, screenshots or a screen recording, and severity. The lead or product owner reviews it, and it becomes Assigned to a developer, or is marked Rejected, Duplicate or Deferred with a reason. The developer moves it to In Progress, then Fixed, and it is deployed to the test environment. I retest it. If it works, I mark it Verified and then Closed after the release. If it still fails, I move it to Reopened with fresh evidence. I also run a quick regression around the fix.

**Likely follow-ups:**

- What makes a good bug report?
- What do you do when a developer says it cannot be reproduced?

### 4. Explain boundary value analysis and equivalence partitioning using an age field that accepts 18 to 60.

Round: Role · Level: All levels

**What they’re checking:** Whether you can apply formal test design techniques to reduce the number of tests while still catching the most likely errors.

**Sample answer:**

> Equivalence partitioning divides inputs into groups that the system should treat the same way, so one value from each group is enough. Here there are three partitions: below 18 is invalid, 18 to 60 is valid, and above 60 is invalid. I might test 10, 35 and 70. I would also add invalid types like letters, decimals and an empty value. Boundary value analysis focuses on the edges, where developers often make mistakes such as using less than instead of less than or equal. So I test 17, 18 and 19 at the lower boundary and 59, 60 and 61 at the upper one. Together that gives strong coverage with few cases.

**Likely follow-ups:**

- How would you apply this to a date range?
- What is decision table testing?

### 5. What is the difference between smoke, sanity and regression testing?

Round: Role · Level: All levels

**What they’re checking:** Whether you know when each type of testing is used in a release cycle and can plan test effort sensibly.

**Sample answer:**

> Smoke testing is a quick, broad check on a new build to confirm the critical functions work, such as login, search and checkout, before deeper testing starts. If smoke fails, the build is rejected. Sanity testing is a narrow, focused check after a specific fix or small change, to confirm that the change works and nothing obvious around it broke. Regression testing is wider: it rechecks existing features after changes to catch side effects, and it is the main candidate for automation because it is repeated every release. In my team, smoke runs automatically on every deployment, and the full regression suite runs nightly and before each release.

**Likely follow-ups:**

- How do you choose what goes into a regression suite?
- How long does your regression suite take to run?

### 6. In Selenium, how do you handle elements that load slowly or have changing IDs?

Round: Role · Level: All levels

**What they’re checking:** Whether you write stable automation using proper waits and locators instead of fixed sleeps and brittle XPaths.

**Sample answer:**

> For slow elements, I use explicit waits with WebDriverWait and expected conditions, such as waiting until an element is clickable or visible, with a sensible timeout. I avoid Thread.sleep, because it either wastes time or is not long enough. I also avoid mixing implicit and explicit waits, since that can cause unpredictable wait times. For changing IDs, I ask developers to add stable test attributes like data-testid. If that is not possible, I use relative XPath or CSS based on stable attributes or visible text, for example contains on part of a class name or a label next to the field. Absolute XPaths break on the smallest layout change.

**Likely follow-ups:**

- How do you handle a stale element exception?
- How would you handle an iframe or a new browser tab?

### 7. How have you designed an automation framework using the Page Object Model?

Round: Role · Level: Experienced

**What they’re checking:** Whether you can structure test automation for maintainability and scale across a team, not just write individual scripts that only you understand.

**Sample answer:**

> In my last project I built a framework with Java, Selenium, TestNG and Maven. Each page of the app had a page class holding its locators and actions, such as LoginPage with a login method, so tests never touched locators directly. When the UI changed, I updated only one class. Test data came from JSON files per environment, and configuration like base URL and browser came from properties files. A base test class handled driver setup and teardown, with screenshots on failure. Reports were generated with Extent Reports, and the suite ran in Jenkins with parallel execution on Selenium Grid. Common waits and utilities lived in a helper package.

**Likely follow-ups:**

- What is the difference between Page Object Model and Page Factory?
- How do you manage test data that changes between runs?

### 8. What do you validate when testing a REST API?

Round: Role · Level: All levels

**What they’re checking:** Whether you test APIs thoroughly beyond the status code, covering data, errors, security and performance basics.

**Sample answer:**

> I check the status code for each scenario, such as 200 or 201 for success, 400 for bad input, 401 without a token, 403 for a user without permission and 404 for a missing resource. Then the response body: correct fields, data types and values, validated against the schema. I check headers like content type, and response time against the agreed limit. Negative tests cover missing fields, wrong types, very long values and invalid IDs. For create or update calls, I verify the change in the database or with a follow-up GET. I use Postman for exploration and RestAssured or Playwright API tests for automation in the pipeline.

**Likely follow-ups:**

- How do you chain requests that depend on each other?
- How would you test pagination?

### 9. Some of your automated tests pass and fail randomly. How do you fix flaky tests?

Round: Role · Level: Experienced

**What they’re checking:** Whether you can diagnose unreliable automation systematically, since flaky suites quickly destroy the whole team’s trust in testing.

**Sample answer:**

> First I quarantine the flaky tests from the release gate so they stop blocking builds, but I track them visibly. Then I look for patterns in failures: the same step, certain browsers, parallel runs or a particular time. The common causes I find are timing problems fixed with proper explicit waits, tests depending on each other or on shared data, fixed with independent test data per test, and environment issues like slow third-party services, which I stub or mock. I check screenshots and logs from failed runs. Each fix is verified by running the test many times in a loop. I also track a flaky test rate so the problem does not quietly grow.

**Likely follow-ups:**

- Should flaky tests ever be deleted?
- How do you make tests independent in parallel runs?

### 10. You have two days to test a new payment feature before release. How do you plan it?

Round: Role · Level: Experienced

**What they’re checking:** Whether you can use risk-based testing under time pressure, focusing effort where failure would hurt users and the business most.

**Sample answer:**

> I would first spend an hour with the product owner and developer to understand the changes and the riskiest areas. For payments, those are amount calculations, failures and retries, duplicate payments and refunds. I would rank scenarios by risk: successful payment with each method, failure and timeout handling, double click on pay, bank callback arriving late, refund flow and amount rounding with discounts. Day one covers high-risk scenarios on staging with the payment gateway sandbox. Day two covers regression of checkout through our automated suite, plus exploratory testing. I would clearly report what was not tested, so the release decision is made with known risks.

**Likely follow-ups:**

- How would you test a payment gateway timeout?
- Who decides whether to release with open bugs?

### 11. How do you use SQL while testing an application?

Round: Role · Level: All levels

**What they’re checking:** Whether you can verify data at the database level and prepare test data, which catches bugs the user interface hides.

**Sample answer:**

> I use SQL to check that actions in the app store the right data. For example, after placing an order, I query the orders and order_items tables to confirm the totals, status and timestamps, and check that stock reduced in the inventory table. I also look for side effects, like duplicate rows after a double submit, using GROUP BY with HAVING COUNT greater than one. For test data, I find users in a particular state, such as accounts with expired subscriptions, instead of creating them through many screens. In migration testing, I compare record counts and sample values between old and new tables. I only run read queries on shared environments unless allowed otherwise.

**Likely follow-ups:**

- Write a query to find orders with no items.
- How do you test a stored procedure?

## Behavioural questions

### 12. Tell me about a time a developer rejected a bug you reported.

Round: Behavioural · Level: All levels

**What they’re checking:** Whether you handle disagreement with developers through evidence and calm discussion, keeping the focus on product quality rather than winning.

**Sample answer:**

> I reported that the order confirmation email sometimes showed the wrong delivery date. The developer marked it as cannot reproduce. Instead of reopening it with an argument, I looked for the pattern and found it only happened for orders placed after 11 pm, because the server used UTC while the email template used local time. I added exact steps, two order IDs and screenshots from the email logs, then sat with the developer for ten minutes to show it. He found the time zone bug quickly and thanked me. Since then I try to identify the pattern behind any intermittent bug before reporting it.

**Likely follow-ups:**

- What if he still disagreed?
- How do you build a good relationship with developers?

### 13. Describe a critical bug you found just before a release. What did you do?

Round: Behavioural · Level: All levels

**What they’re checking:** Whether you raise serious risks clearly and quickly under pressure, and support the team in deciding what to do.

**Sample answer:**

> On the evening before a release of an insurance policy app, while doing exploratory testing, I found that applying a discount code twice reduced the premium twice. I recorded the exact steps and the financial impact on a sample policy, then called the QA lead and the product owner immediately instead of only logging it. The developer found the missing check within an hour. We had two choices: delay the release or ship with the discount feature turned off. The product owner chose to disable discounts for a day. I retested the fix the next morning and we enabled it with a quick regression.

**Likely follow-ups:**

- Why had the bug not been found earlier?
- What did you add to the regression suite?

### 14. Tell me about a bug you missed that reached production.

Round: Behavioural · Level: Experienced

**What they’re checking:** Whether you own escapes honestly and improve the testing process afterwards, rather than blaming developers or requirements.

**Sample answer:**

> A bug reached production where the app crashed for users who had set a very long display name. I had tested the profile screen, but only with normal names. When it was reported, I reproduced it within minutes and the fix went out the same day. In our review, I accepted that my test cases did not include boundary values for text fields on that screen. I added length and special character cases for every text input across the app, and I created a shared test data set with extreme values that all testers use. I also added an automated test for that crash.

**Likely follow-ups:**

- How do you decide which edge cases to test?
- How did your manager respond?

### 15. How did you convince your team or manager to invest in test automation?

Round: Behavioural · Level: Experienced

**What they’re checking:** Whether you can make a business case for quality investments, using data rather than enthusiasm.

**Sample answer:**

> Our manual regression took four testers about three days per release, and releases were every two weeks. Bugs in older features were still escaping because people were tired by day three. I tracked the time spent for two releases and listed the most repeated test cases. Then I proposed automating the top sixty regression cases over two sprints, starting with checkout and login. I showed that once done, those cases would run overnight and free roughly two tester-days per release for exploratory testing. My manager approved a pilot. After it worked, we automated more, and regression time dropped to under a day.

**Likely follow-ups:**

- Which test cases did you decide not to automate?
- How did you keep the automation maintained?

### 16. How do you test when requirements are incomplete or keep changing?

Round: Behavioural · Level: Fresher

**What they’re checking:** Whether you can work with ambiguity by asking good questions and using exploratory testing, instead of waiting for perfect documents.

**Sample answer:**

> In my first project, a startup was building a delivery tracking screen and the requirements were a few lines in a ticket. I listed my questions, such as what happens when the rider’s location is unavailable or the order is cancelled midway, and took them to the product manager in a short call. The answers became acceptance criteria in the ticket, which helped developers too. Where details were still unclear, I did exploratory testing with notes on what I tried and what looked wrong. I also compared behaviour with similar apps, and flagged differences as questions rather than bugs.

**Likely follow-ups:**

- What is session-based exploratory testing?
- How do you report what you covered in exploratory testing?

### 17. Tell me about a time you had to test under a very tight deadline.

Round: Behavioural · Level: Fresher

**What they’re checking:** Whether you prioritise sensibly and communicate coverage honestly when there is not enough time to test everything.

**Sample answer:**

> During my internship, a client demo moved two days earlier, and the build I was testing arrived late. I could not run all ninety test cases. I asked my lead which flows the client would see in the demo and focused on those first: registration, search and the booking flow. I tested them on the browsers the client used and logged bugs with clear priority. Then I covered other areas with quick exploratory checks. I sent a short note listing what was tested, what was not, and known issues. The demo went smoothly, and my lead said the coverage note helped her plan the next round.

**Likely follow-ups:**

- What did you leave untested?
- How would you plan it differently now?

## HR round questions

### 18. Why do you want to build a career in software testing?

Round: HR · Level: Fresher

**What they’re checking:** Whether a fresher sees testing as a real career with growth, not a backup option, and has relevant interest or skills.

**Sample answer:**

> During my final-year project, I enjoyed finding problems in our app more than adding features. I found a bug where two users booking the same slot at the same time both got a confirmation, and fixing it taught me how much users depend on testing. I like thinking about how things can break and from the user’s point of view. I have learned manual testing basics, written test cases for my project, and started Selenium with Java and Postman for APIs. Over the next few years I want to grow into automation and performance testing, and later lead a quality team.

**Likely follow-ups:**

- What testing tools have you practised?
- Would you be comfortable doing manual testing at the start?

### 19. Some of our projects need support during release nights and weekend deployments. Is that acceptable?

Round: HR · Level: All levels

**What they’re checking:** Whether you understand the occasional off-hours nature of release testing and can commit to it reliably.

**Sample answer:**

> Yes. In my current role I support releases roughly twice a month, usually late evening, to run smoke tests on production right after deployment and confirm that critical flows work. I understand releases cannot always happen in office hours, especially for systems used during the day. I would like to know how often it happens here and whether there is a comp-off or rotation, so I can plan. I also try to reduce release-night effort by having the production smoke suite automated and ready, so checks take minutes rather than hours.

**Likely follow-ups:**

- What do you test right after a production deployment?
- Have you ever had to recommend a rollback?

### 20. What salary do you expect for this QA automation role?

Round: HR · Level: Experienced

**What they’re checking:** Whether you give a realistic, reasoned figure based on your skills, especially your automation experience.

**Sample answer:**

> I currently earn ₹7.5 lakh CTC with three and a half years in QA, the last two mainly in automation with Selenium, Java and RestAssured, including building our framework and running it in Jenkins. This role is fully automation-focused with ownership of the framework, so I am looking for ₹10 to 11 lakh fixed. I am flexible on the structure and would also value certification support, for example for ISTQB advanced or a cloud course. My notice period is 30 days, so I could join quickly.

**Likely follow-ups:**

- Why do you think the jump is justified?
- Do you have any other offers?

## How to prepare for a qa engineer interview

- Practise writing test cases for everyday features such as login, search, cart and payment within ten minutes, because this is a very common live task.
- Be ready to write a small automation script without help, including locators, an explicit wait and an assertion, in the language on your resume.
- Revise testing terms precisely: severity versus priority, smoke versus sanity, verification versus validation, and test plan versus test strategy.
- Prepare one story about a critical bug you found and one about a bug you missed, with what you changed afterwards.
- Learn basic SQL queries and API testing with Postman, since most QA roles now expect both alongside user interface testing.

## Questions about qa engineer interviews

### What is asked in a QA engineer interview?

Expect testing concepts like test design techniques, bug life cycle, severity and priority, and test types, plus practical tasks such as writing test cases for a feature. Automation roles add Selenium or Playwright, a programming language, framework design and CI integration. Many interviews also include API testing, SQL queries and a discussion of your current project’s test process.

### Should a fresher start in manual or automation testing?

Many freshers start with manual testing, which builds the test design skills that automation depends on. But learning automation early improves your options and growth. Learn manual testing concepts well, then practise Selenium or Playwright with one language, along with Postman for APIs, and build a small framework on GitHub to show in interviews.

### Is ISTQB certification necessary for QA jobs?

It is not required by most employers, but the foundation level helps freshers by teaching standard terms and techniques, and some service companies value it for client projects. For experienced testers, practical automation skills and project experience matter much more. If you take it, be ready to show how you apply the concepts in real testing.
