QA Interview Questions (2026): Q&A, Tips & Examples

QA interview rounds are not just about reciting definitions. Interviewers test how you think when a feature ships with no test cases attached, how you prioritise testing when you do not have time to test everything, and whether you understand why a testing practice exists, not just what it is called.

The demand for QA engineers in Nepal and globally is growing fast. Mid-level QA engineer roles in Nepal now pay between NPR 55,000 and NPR 102,000 per month, and senior automation engineers earn NPR 120,000 to NPR 221,000 per month, with companies actively hiring at every level, from interns to QA leads.

Whether you are sitting for your first QA internship interview or targeting a senior automation engineering position, this guide covers everything: concepts, tools, scenario questions, and preparation tips, broken down by experience level. Not sure where QA fits in your career path yet? Start with our complete guide on how to get into QA before diving into interview prep. And when you are ready to build hands-on skills, our Quality Assurance training course gives you real projects, real tools, and real test cases to talk about in interviews.

How to Prepare for a QA Interview

Memorising definitions is not enough. Companies want QA engineers who can apply testing principles to real product problems. Here is what you need to do before you walk into the room.

1. Core Concepts You Must Know

Before anything else, you need to be solid on the fundamentals, not just able to define them, but able to explain them clearly without a script.

Understand the full QA vs QC vs Testing distinction clearly, the single most common opening question in Nepal QA interviews
Know SDLC and STLC inside out, including how they run in parallel rather than sequentially. A clear understanding of SDLC vs STLC is something almost every interviewer in Nepal probes within the first ten minutes
Be fluent in the bug life cycle: New, Assigned, Open, Fixed, Retest, Verified, Closed, Reopened
Understand the difference between severity and priority, and be ready to give a real example of each
Know the testing pyramid: unit tests at the base, integration tests in the middle, end-to-end tests at the top

A clear understanding of what is quality assurance gives you a foundation that connects every concept and tool you learn after it.

2. Tools You Should Be Familiar With

Interviewers at most Nepal-based IT companies and global remote roles expect you to speak confidently about the tools you have actually used, not just tools you have heard of. Structure your preparation by category:

Bug Tracking & Test Management: JIRA, TestRail, Zephyr
Automation: Selenium, Cypress, Playwright
API Testing: Postman, Newman
Performance Testing: Apache JMeter, k6
CI/CD: Jenkins, GitHub Actions
Version Control: Git, GitHub

For each tool, prepare one real example of how you used it, even in a training project. Saying "I built a Postman collection with 20 test assertions covering positive and negative auth scenarios" is far stronger than "I know Postman."

Check out our breakdown of the most important QA tools and what each one does for a deeper look at how these fit together.

3. Building and Presenting Your Portfolio

In Nepal's current QA hiring market, a working portfolio beats a certification every time. Interviewers want proof that you can do the work, not just that you passed a test.

What makes a strong QA portfolio:

A GitHub repository with real test cases, a Selenium framework using Page Object Model structure, and clear README files explaining what each project does
A documented bug report sample, written the way you would in a real sprint, steps to reproduce, severity, screenshots
A Postman collection exported as JSON, with test assertions and environment variables, showing what API scenarios it covers
A JMeter test report, even from a demo application, showing load testing results and your interpretation of them

Practical QA skills get you interviews. A portfolio gets you offers.

4. Researching the Company Before the Interview

Before you walk in, know exactly what stack the company uses. Read the job posting carefully, every tool they mention is a potential interview question.

If the job description mentions Selenium heavily, prepare 5 to 6 Selenium-specific answers and at least one real example
If they are API-heavy, such as a fintech company or one running microservices, revise Postman, REST concepts, and authentication testing scenarios
Research how mature their QA process is. Do they have a dedicated QA team, or is testing shared across developers?
Prepare 2 to 3 questions to ask them. It shows you think strategically, not just technically.

Map your preparation to the company's stage in the QA career roadmap, an early-stage startup's testing maturity looks very different from a mature enterprise QA process.

QA Internship Interview Questions

Landing a QA internship in Nepal is competitive. Interviewers know you do not have years of production experience, but they do expect structured thinking, basic technical understanding, and evidence that you have actually tried things on your own.

Concept Understanding Questions

Q1. Why did you choose QA?

Do not say "I am not good at coding so I chose testing." Give a real answer. Talk about the specific satisfaction of finding what breaks before a real user does, or genuine curiosity about how software gets validated before it reaches the public. Interviewers remember candidates who show authentic interest rather than a fallback explanation.

Q2. What does a QA engineer actually do day to day?

A QA engineer spends most of their time on a consistent set of activities:

Reviewing requirements for testability
Writing and executing test cases
Logging bugs in JIRA with clear reproduction steps
Retesting fixes once developers resolve them
Participating in daily standups and sprint planning

They are not just clicking through an app looking for broken buttons, they are involved in the quality conversation from the start of every sprint. Our QA engineer guide covers this full daily breakdown in detail.

Q3. What is the difference between a developer and a QA engineer?

A developer writes application code, features, logic, APIs, databases. A QA engineer validates that those features work as intended and catches what the developer might have missed, often because they are looking at the feature from the user's perspective rather than the code's perspective.

In practice, the roles overlap in good teams. Developers write unit tests for their own code. QA engineers, especially at the automation level, write scripts that are themselves a form of code. The wall between the two roles is intentionally thin in modern Agile teams.

Practical & Portfolio Questions

Q1. Walk me through a test case you have written.

If you have written one, even in a training project, walk through every part: the precondition, the exact steps, the expected result, and at least one negative scenario you included alongside the happy path. Be specific. "I wrote a test case for a login form covering valid credentials, an incorrect password, an empty username field, and a maximum character limit on the password field" is a strong answer because it shows layered thinking, not just a single happy-path check.

Q2. Have you used JIRA or any bug tracking tool before? Walk me through how you would log a bug.

Talk through the components of a complete bug report:

A clear, specific title
The exact steps to reproduce the issue
The expected result versus the actual result
The severity level
A screenshot or screen recording if possible

If you have used JIRA in a training project, mention it specifically rather than describing bug reporting in the abstract.

Q3. What QA tools have you installed and used in a practice project?

Be honest. List what you have actually used, even if it is just Postman against a free public API like Reqres.in, or Selenium running against a demo site like SauceDemo. Interviewers consistently respect honesty far more than a list of tools you have only read about but never opened.

Entry-Level QA Interview Questions

At the entry level, interviewers expect you to handle real tasks, writing test cases, logging bugs clearly, running basic regression checks. The questions get more specific and more practical than internship-stage questions.

Manual Testing & Process Questions

A strong answer demonstrates structured thinking rather than just listing random checks.

Happy path: valid username and valid password should log the user in successfully
Negative scenarios: incorrect password, non-existent username, empty fields, and special characters in either field
Edge cases: maximum character limits, SQL injection attempts in the input fields, account lockout behaviour after multiple failed attempts, and session handling after a successful login
Non-functional checks: confirming the login page loads within an acceptable time and that the password field masks input correctly

Q2. What happens when you find a bug during testing?

You log it in JIRA, or whatever bug tracking tool the team uses, with:

A clear title
The exact steps to reproduce it
The expected versus actual result
A severity level
A screenshot

From there, the bug enters the standard life cycle: it gets assigned to a developer, moves through Open and Fixed once addressed, and comes back to you for retesting before it is marked Verified and Closed.

The part interviewers actually pay attention to is whether you describe this as a structured process rather than a vague "I tell the developer."

Q3. How do you decide what to test first when you do not have time to test everything?

Prioritise based on risk: focus first on the core business-critical paths, for a fintech app, that means login and payment flows above almost everything else, then on areas of the code that changed most recently, since recent changes carry the highest risk of new defects.

Communicate clearly to your team lead exactly what is and is not being tested given the time constraint, so the decision is a shared, visible one rather than a silent gap that surfaces later.

Basic SQL & Tooling Questions

Q1. Why does a QA engineer need to know SQL?

A QA engineer uses SQL to verify that the data the UI shows actually matches what is stored in the backend database, rather than just trusting that what appears on screen is correct. A form might display a successful order confirmation while the underlying database record was never actually created correctly. Basic SQL queries let you check directly rather than relying entirely on what the interface tells you.

Q2. What is the difference between a test plan and a test case?

Test plan: the overall strategy document for a feature or release, what will be tested, which testing types apply, what tools will be used, and what the entry and exit criteria are.
Test case: one specific, executable scenario within that plan, the actual steps you run to verify a single piece of functionality.

Think of the test plan as the roadmap and the test case as one specific turn-by-turn direction within that roadmap.

Q3. What is a Requirement Traceability Matrix (RTM) and why does it matter?

A Requirement Traceability Matrix maps each business requirement to its corresponding test cases, ensuring full test coverage and making it easy to track which requirements have actually been tested. It matters because it becomes the evidence trail during audits or client reviews where you need to prove that every requirement was genuinely validated before release, not just assumed to be covered.

Mid-Level QA Interview Questions

By the 1 to 3 year mark, interviewers expect you to have built and maintained real automation and tested real APIs, not just executed test cases someone else wrote.

Automation Framework Questions

Q1. What is the Automation Testing Life Cycle (ATLC)?

The Automation Testing Life Cycle defines the structured stages of building an automation suite:

Identifying which test cases are suitable for automation
Selecting the right tool and framework
Designing the framework architecture
Developing and executing the automation scripts
Generating reports
Maintaining the suite as the application evolves

A common mistake is jumping straight to scripting without going through the earlier stages, especially test case selection, which leads to automating the wrong things.

Q2. What locator strategies do you know in Selenium?

The main locator strategies are ID, Name, Class Name, Tag Name, Link Text, CSS Selector, and XPath.

ID: generally the most reliable and fastest locator when available, since IDs are meant to be unique on a page
CSS Selector: fast and flexible for targeting elements based on attributes or hierarchy
XPath: the most powerful and flexible option, capable of traversing the DOM in both directions, but it is also typically the slowest and most fragile if the page structure changes

A strong candidate explains the order of preference: prefer ID, then CSS Selector, and reserve XPath for cases where the other options cannot reliably target the element.

Q3. What is a flaky test and how do you fix it?

A flaky test is one that produces inconsistent results, passing sometimes and failing other times, without any actual change to the underlying code. Flaky tests usually come from:

Timing issues
Unreliable locators
Shared test data that gets modified between runs
Environment instability

Fixing flaky tests typically involves:

Replacing implicit waits with proper explicit waits tied to specific conditions
Isolating test data so tests do not interfere with each other
Stabilising locators Flaky automation suites are one of the most common real-world frustrations in QA, and your answer here reveals whether you have actually maintained a live suite or only written scripts in isolation.

Q4. What is data-driven testing?

Data-driven testing is a framework approach where test scripts are separated from the test data, with the data stored externally in a file such as a CSV, Excel sheet, or JSON file. The same test script then runs repeatedly with different sets of input data pulled from that external source.

This is especially useful for testing the same workflow, like a registration form, with dozens of different valid and invalid input combinations without writing a separate script for each one.

Q5. What is the difference between TestNG and JUnit?

Both are testing frameworks for Java-based test automation.

TestNG: offers more advanced features out of the box, built-in support for parallel test execution, flexible test configuration through XML files, data providers for data-driven testing, and more granular control over test grouping and dependencies.
JUnit: simpler and lighter, commonly used for unit testing within development teams.

In Nepal's QA market, TestNG is more common in dedicated automation frameworks because of its parallel execution and reporting capabilities.

API & CI/CD Questions

Q1. How do you test authentication in an API?

Authentication testing covers several distinct scenarios beyond simply confirming that a valid login works:

Valid credentials, expecting a successful response with a token
An invalid or modified token, expecting a 401 Unauthorized response
An expired token, expecting the same 401
No token at all, expecting 401
A valid token that lacks sufficient permissions, expecting a 403 Forbidden response rather than 401

For Bearer Token authentication specifically in Postman, you select Bearer Token under the Authorization tab and paste the token, and Postman automatically adds the correct Authorization header to the request. Covering all five of these scenarios, not just the happy path, is what shows an interviewer you actually understand how to test authentication thoroughly.

Q2. What is Newman and how does it integrate with CI/CD?

Newman is Postman's command-line tool that runs exported Postman collections outside the desktop application, typically inside a CI/CD pipeline. You export your collection and environment as JSON files from Postman, then run them with a single Newman command from the terminal.

This means your full API regression suite can run automatically every time a developer pushes code, with Newman generating HTML or JUnit reports that show exactly which assertions passed or failed.

Q3. How do you integrate automated tests into a CI/CD pipeline?

You typically export your test suite, Selenium scripts, Postman collections via Newman, or JMeter test plans, and configure a pipeline tool like Jenkins or GitHub Actions to run them automatically on a trigger, usually a code push or pull request.

A simple GitHub Actions example would install the required tooling, check out the repository, and run the test command as one of the workflow's steps, with the build failing automatically if any test assertion fails. This stops broken code from ever reaching the main branch.

Q4. What is continuous testing?

Continuous testing means automated tests run automatically at every stage of the CI/CD pipeline, triggered by every code commit, rather than testing happening as a separate, manual phase after development finishes. This typically includes:

Unit tests running on every commit
Integration and API tests running on every pull request
Regression suites running before deployment

The goal is instant feedback: a developer knows within minutes whether their change broke something, rather than finding out days later.

Senior QA Interview Questions

At senior level, interviewers stop asking what tools you know and start asking how you think, how you handle production incidents, and whether you can build out a QA process from scratch.

Strategy & Leadership Questions

Q1. How do you decide what to automate and what to keep manual on a new project with limited time and budget?

Start with risk and repetition. Anything that runs more than three or four times, like regression suites and smoke tests, belongs in automation. Anything that requires human judgment, like exploratory testing, usability evaluation, and UAT, stays manual regardless of budget.

With limited time specifically, prioritize automating the highest-risk, highest-frequency paths first, login, payment, and core business workflows, and accept that lower-traffic features may stay manually tested longer than ideal. Being explicit about that trade-off, rather than pretending you can automate everything immediately, is what interviewers are actually listening for.

Q2. What metrics do you use to report QA health to non-technical stakeholders?

Translate technical metrics into business language. Instead of reporting raw defect counts, report defect trends relative to release size. Instead of automation coverage percentage alone, explain what that coverage actually protects against, "80% of our critical payment flows are covered by automated regression, which means we catch payment-breaking changes before they reach production."

Stakeholders care about risk and stability, not the mechanics of how testing happens. A senior QA engineer translates between the two fluently.

Q3. How do you build a test strategy for a product with no existing QA process?

Start by understanding the business risk profile, which features, if broken, would cause the most damage. Map those to a layered testing approach:

Unit tests with developers
API tests for backend logic
A focused set of UI automation for critical user journeys
Manual exploratory testing for anything new or high-risk

Define entry and exit criteria early so the team has a shared understanding of what "tested" actually means before the first release. Build the regression suite incrementally rather than trying to achieve full coverage from day one, prioritising the paths most likely to break or cause the most damage if they do.

Scenario-Based Questions

Q1. A critical bug is found in production right before a major release. What do you do?

A strong answer follows a clear sequence rather than panicking through the explanation:

First, assess the actual severity and the number of users or systems affected
Second, try to reproduce the issue in a controlled environment using logs, screenshots, or error messages from production
Third, communicate the issue clearly to the relevant stakeholders, including realistic impact and timeline
Fourth, collaborate with developers on a hotfix or a temporary workaround to limit user impact immediately
Fifth, once the fix is ready, test it thoroughly in staging, including a focused regression pass on related functionality, before it goes back to production
Finally, after the immediate fire is out, investigate why the bug was not caught during the original testing cycle, whether that points to a coverage gap, a wrong assumption, or unclear requirements, and feed that finding back into the team's process

This last step, the post-incident review, is often what separates a junior answer from a senior one.

Q2. A bug appears in production but cannot be reproduced in the QA environment. What is your approach?

Start by comparing the production and QA environments directly: configuration differences, data differences, or version mismatches are the most common causes of this exact scenario. Review logs from production carefully for the specific conditions under which the bug occurred, including timestamps, user actions, and any error traces.

Check whether the issue might be related to:

Specific data only present in production
A particular user permission level
A timing or concurrency issue that simply does not occur under QA's lower traffic conditions

Also review your original test coverage to see whether this particular path was ever actually tested.

Q3. A developer says a bug is "by design." How do you handle this disagreement?

First, calmly ask the developer to walk you through the specific requirement or design document that supports their position, since sometimes this resolves the disagreement immediately. If the requirement is genuinely ambiguous or was never clearly documented, escalate to the product owner or business analyst rather than letting it become a standoff between QA and development.

If it turns out the behaviour really was intentional but creates a poor user experience, frame your pushback around user impact and business outcomes rather than simply repeating "it's a bug." This keeps the conversation focused on the product rather than becoming personal.

QA Interview Do's and Don'ts

A few quick, tactical reminders that apply no matter which level you are interviewing for.

Do's:

Do bring real examples for every tool you list on your CV, even from a training project
Do ask clarifying questions when a scenario is vague, this mirrors exactly what you would do on the job
Do admit when you do not know something and explain how you would find out
Do explain your reasoning out loud, interviewers are evaluating your thought process, not just your final answer
Do mention specific outcomes when describing past work, test coverage percentage, bugs caught before release, time saved through automation

Don'ts:

Don't memorize definitions word for word without understanding the reasoning behind them
Don't claim experience with a tool you have only briefly explored, follow-up questions will expose the gap quickly
Don't say "I have never missed a bug" or "I have never disagreed with a developer," these answers read as dishonest rather than impressive
Don't list automation tools without explaining why you chose one over another for a specific situation
Don't skip asking questions at the end of the interview, staying silent signals a lack of genuine interest in the role

QA Interview Tips for Nepal's Job Market in 2026

Companies like F1Soft, eSewa, Khalti, Leapfrog Technology, and Cotiviti run multi-round QA interviews: an HR screening, a technical round, often live test case writing or a Selenium or Postman exercise, and a final culture-fit round. Knowing this structure ahead of time helps you prepare for each stage differently rather than treating the whole process as one undifferentiated conversation.

Fresher and entry-level rounds in Nepal weigh manual testing fundamentals and basic SQL heavily. Automation knowledge is a bonus at this stage, not a strict requirement. Mid-level interviews test Selenium and Postman hands-on, sometimes through a live coding exercise or a take-home assignment you complete before the final round. Senior interviews increasingly include a system design or test strategy discussion, sometimes a whiteboard scenario where you walk the interviewer through how you would build out QA process for a new product from scratch.

Be ready to discuss ISTQB certification if you have it, since Nepal's outsourcing companies value it for international client credibility. Ask the interviewer about their current manual-to-automation ratio and how QA gets involved in sprint planning, this signals that you think about process and team dynamics, not just individual test execution.

Before walking into any interview, it genuinely helps to understand the scope of QA in Nepal so you can speak confidently about industry trends, growth areas, and where the role is headed, rather than only being able to discuss your own technical skills.

Conclusion

QA interviews reward engineers who understand why a practice exists, not just its definition, at whichever level you are interviewing for. Preparing across fundamentals, manual testing, automation, API testing, and scenario-based judgment questions gives you the range Nepal's IT companies test for, from your first internship interview through to a senior leadership conversation. If you are still building those fundamentals, comparing your options through the best QA course in Nepal guide is a good next step before your next interview.

If you want hands-on labs, real Selenium and Postman projects, and a portfolio that gives you actual stories to tell in interviews instead of memorised definitions, the Quality Assurance course at Skill Shikshya is built specifically for that.

QA Interview Questions (2026): Q&A, Tips & Examples

How to Prepare for a QA Interview

1. Core Concepts You Must Know

2. Tools You Should Be Familiar With

3. Building and Presenting Your Portfolio

4. Researching the Company Before the Interview

Top 20 QA Interview Questions (Quick Answers)

Q1. What is Quality Assurance? How is it different from Quality Control and Testing?

Q2. What is the difference between SDLC and STLC?

Q3. What are the different levels of testing?

Q4. What is the difference between functional and non-functional testing?

Q5. What is a test case? What components does a good test case include?

Q6. What is the bug life cycle? Walk me through each stage.

Q7. What is the difference between severity and priority?

Q8. What is manual testing and when do you use it over automation?

Q9. What is exploratory testing?

Q10. What is the difference between smoke testing and sanity testing?

Q11. What is regression testing and why does it matter?

Q12. What is automation testing and when should you not automate a test?

Q13. What is the Page Object Model and why is it used?

Q14. What is the difference between Selenium and Cypress?

Q15. What is the difference between implicit wait and explicit wait in Selenium?

Q16. What is API testing and why is it important?

Q17. What HTTP status codes should a QA engineer know?

Q18. What is Postman and what are collections and environments?

Q19. What is performance testing? What are load, stress, and spike testing?

Q20. What metrics do you track to measure testing effectiveness?