Skip to content
ISTQB
All coursesPlacement Report
‹ Back to previous sectionCourse homeAll page URLs

QA Analyst Interview Questions & Answers

40 questions for QA Analyst interviews — 22 easy, 18 medium.

About the QA Analyst role

QA analysts review requirements and user stories, identify test conditions, prepare test data and verify features against acceptance criteria. They join Agile ceremonies, perform exploratory sessions and report quality status to the team. Strong knowledge of review techniques, test levels and the whole team approach from the CTFL syllabus helps them catch defects early and communicate clearly with business stakeholders.

Requirement review Acceptance criteria Exploratory testing Agile ceremonies Test documentation
Solved for this roleStart practicing
3 QUESTIONS FREESign up to unlock the full question bank and track your progress.Unlock every question and answer, then continue practising company-wise and package-wise.
3 questions free Unlock the rest in seconds
01

A tester uses past experience to test division by zero, empty fields and invalid dates. Which technique is this?

White-Box, Experience and Collaboration-Based TestingEasy
Save to ▾
Show answer
This is error guessing, an experience-based technique. The tester anticipates mistakes based on knowledge of similar applications, typical developer errors and past failures. When done methodically by listing possible errors and designing tests for each, it is called a fault attack. It is not checklist-based testing unless the tester works from a prepared checklist of conditions.
02

Business users test a new payroll system in their own office before go-live. What kind of testing is this?

Testing Throughout the SDLCEasy
Save to ▾
Show answer
This is user acceptance testing, because intended users validate that the system meets their needs in a realistic environment before deployment. If it were a commercial product released to external customers at their own sites for feedback, it would be beta testing. If potential users tested it at the developer's site, it would be alpha testing. Look for who tests and where.
03

Find the minimum tests for 100 percent statement and branch coverage of this code.

White-Box, Experience and Collaboration-Based TestingMedium
Save to ▾
Show answer
read(x) if x > 10: print('big') print('done') Statement coverage: one test with x = 15 executes every statement, so 1 test. Branch coverage: the if has a true and a false outcome, so tests with x = 15 and x = 5 are needed, 2 tests.
04

What is the test pyramid?

Managing the Test ActivitiesEasy
Save to ▾
Show answer
The test pyramid shows that tests have different granularity and that a healthy suite has many small, fast, isolated tests at the bottom, such as unit or component tests, and fewer large, slow, complex end-to-end tests at the top, such as UI tests. Middle layers often cover API or integration tests. The pyramid helps teams plan automation so the suite is fast, stable and cheap to maintain.
05

What is branch testing and how is branch coverage measured?

White-Box, Experience and Collaboration-Based TestingMedium
Save to ▾
Show answer
A branch is a transfer of control between two nodes in the control flow graph. Branches can be unconditional, like straight-line code, or conditional, like the true and false outcomes of an if or the cases of a switch. Branch coverage = branches exercised / total branches x 100. Branch testing designs tests so that every branch, including the hidden false path of an if without else, is exercised.
06

Why is early and frequent stakeholder feedback important?

Static TestingEasy
Save to ▾
Show answer
Early and frequent feedback catches misunderstandings about requirements before they become expensive. Without it, the product may not match what stakeholders want, leading to costly rework, missed deadlines, blame games and even project failure. Regular feedback through reviews, demos and backlog refinement keeps the team focused on the most valuable features and builds a shared understanding of what is being built.
07

What are the success factors for reviews?

Static TestingMedium
Save to ▾
Show answer
Define clear objectives and measurable exit criteria; pick a review type that fits the objective, work product and people; review small chunks so reviewers stay focused; give feedback to authors so they improve; allow enough preparation time; secure management support; make reviews part of the culture to promote learning; and train participants for their roles. Review results must never be used to evaluate the performance of individuals.
08

How do you learn a new application quickly when you join a project?

White-Box, Experience and Collaboration-Based TestingEasy
Save to ▾
Show answer
Situation: I joined a project two weeks before a release. Task: become productive quickly. Action: I read user stories and help pages, did short exploratory sessions on main flows, built a mind map of features, asked a senior tester for the riskiest areas and reviewed recent defects. Result: within a week I was executing regression tests independently and found two defects in the first sprint.
09

What are the main forms of acceptance testing?

Testing Throughout the SDLCEasy
Save to ▾
Show answer
User acceptance testing is done by intended users. Operational acceptance testing is done by operations staff and covers backup, restore, installation and disaster recovery. Contractual and regulatory acceptance testing checks contract criteria or legal rules. Alpha testing is done by potential users at the developer's site, and beta testing by users at their own locations. Acceptance testing mainly builds confidence and validates fitness, not defect finding.
10

How does the choice of SDLC model affect testing?

Testing Throughout the SDLCEasy
Save to ▾
Show answer
In sequential models like waterfall and the V-model, testers join early for reviews and planning, but dynamic testing happens later once code exists. In iterative and incremental models such as Scrum, every iteration delivers a working increment, so static and dynamic testing happen at all levels in each iteration, regression testing is critical and automation is usually needed. The model affects scope, timing, documentation, techniques and automation.
11

What is checklist-based testing and what are its risks?

White-Box, Experience and Collaboration-Based TestingEasy
Save to ▾
Show answer
In checklist-based testing, the tester designs and runs tests to cover the conditions on a checklist built from experience, user needs or knowledge of why software fails. Items should be specific and testable, not vague or automatable by tools. Checklists give some consistency and guidance when detailed test cases are missing, but they become less effective over time as developers learn to avoid those mistakes, so they must be updated regularly.
12

What are the roles in a formal review?

Static TestingEasy
Save to ▾
Show answer
The manager decides what is reviewed and provides resources. The author creates and fixes the work product. The moderator, or facilitator, ensures meetings run effectively, mediating and managing time. The scribe, or recorder, collects anomalies and records decisions. Reviewers perform the review and may be team members, experts or stakeholders. The review leader takes overall responsibility, deciding who is involved and organising the review. One person can hold several roles.
13

Tell me about a time you missed a defect. What did you learn?

Defect and Configuration ManagementMedium
Save to ▾
Show answer
Situation: a defect in date formatting reached production after my testing. Task: understand why and prevent it. Action: I owned the miss, found my test data used only one locale, and added test cases for other date formats and locales. I also shared a checklist for locale testing. Result: no similar defect appeared in later releases, and I learned to review my test data as carefully as my test steps.
14

A test checks that the loan module correctly sends customer data to an external credit bureau API. Which test level is this?

Testing Throughout the SDLCEasy
Save to ▾
Show answer
This is system integration testing, because it tests the interface between our system and an external system, the credit bureau API. If it checked the interface between two internal modules of our own application, it would be component integration testing. In exam questions, keywords such as 'external system', 'third-party service' or 'other systems' point to system integration testing.
15

What is the shift-left approach in testing?

Testing Throughout the SDLCEasy
Save to ▾
Show answer
Shift-left means performing testing earlier in the SDLC. Practices include reviewing specifications from a tester's perspective, writing test cases before code, using CI/CD for fast feedback, running static analysis before dynamic testing and starting non-functional testing at component level. It costs extra effort early, but saves much more later, because a defect found in requirements is far cheaper to fix than one found in production.
16

How do you prioritise your work when several tasks are urgent?

Managing the Test ActivitiesEasy
Save to ▾
Show answer
Situation: in my internship I had regression tests, a defect retest and a test case review due the same day. Task: finish what mattered most. Action: I asked my lead which item blocked the release, did the defect retest first since a fix depended on it, then the high-risk regression tests, and moved the review to the next morning with agreement. Result: the release stayed on track.
17

What is exploratory testing and when is it most useful?

White-Box, Experience and Collaboration-Based TestingEasy
Save to ▾
Show answer
In exploratory testing, tests are designed, executed and evaluated at the same time while the tester learns about the test object. It is often structured as session-based testing with a time box, a test charter and a debrief. It is most useful when specifications are few or poor, under time pressure, or to complement formal techniques. Its success depends on the tester's experience, domain knowledge, curiosity and analytical skills.
18

Which good testing practices apply regardless of the SDLC model?

Testing Throughout the SDLCMedium
Save to ▾
Show answer
CTFL v4.0 lists these: for every software development activity there is a corresponding test activity; each test level has its own specific objectives; test analysis and design for a level begin during the corresponding development phase; and testers are involved in reviewing work products as soon as drafts are available. Together these practices support early testing and quality control in waterfall, V-model and Agile projects alike.
19

Why does 100 percent branch coverage guarantee 100 percent statement coverage, but not the other way round?

White-Box, Experience and Collaboration-Based TestingMedium
Save to ▾
Show answer
Every statement lies on at least one branch, so exercising all branches executes all statements. The reverse fails when a decision has an empty outcome. Example: 'if x > 10: print(big)' followed by 'print(done)'. One test with x = 15 runs every statement, giving 100 percent statement coverage, but the false branch is never taken, so branch coverage is only 50 percent. This is called subsumption.
20

A static analysis tool reports 2,000 warnings on legacy code. What is your approach?

Static TestingMedium
Save to ▾
Show answer
I would not try to fix everything at once. First, tune the rule set to remove irrelevant rules and false positives. Then classify warnings by severity and fix security issues and likely defects first. I would set a quality gate that blocks only new issues in changed code, so the codebase improves gradually. Trend reports each sprint show management steady progress.
21

Show two defects a static analysis tool can find without running the code.

Static TestingMedium
Save to ▾
Show answer
def get_discount(amount): if amount > 1000: rate = 0.1 return amount * rate # rate undefined when amount <= 1000 def old_helper(): return 0 print('done') # unreachable code The tool flags a possibly undefined variable, a data flow anomaly, and unreachable code. Both are found statically, before any test is executed.
22

Compare the four review types in CTFL v4.0.

Static TestingMedium
Save to ▾
Show answer
An informal review has no defined process or formal output and aims to detect anomalies. A walkthrough is led by the author and aims to educate, build consensus, generate ideas and detect anomalies. A technical review is done by technically qualified reviewers led by a moderator, aiming at consensus and technical decisions. An inspection is the most formal, follows the full process, collects metrics and aims to find the maximum number of anomalies.
23

Describe the activities of the review process in CTFL v4.0.

Static TestingMedium
Save to ▾
Show answer
Planning defines scope, purpose, quality characteristics, exit criteria, effort and timeframe. Review initiation ensures everyone has access and is ready. In individual review, each reviewer assesses the work product and logs anomalies, recommendations and questions. Communication and analysis discusses anomalies and decides their status and actions. Fixing and reporting creates defect reports, the author fixes them, and results are reported against exit criteria.
24

What is error guessing?

White-Box, Experience and Collaboration-Based TestingEasy
Save to ▾
Show answer
Error guessing anticipates errors, defects and failures based on the tester's knowledge: how the application worked before, the types of mistakes developers tend to make, and failures seen in similar applications. A methodical form is the fault attack: list possible errors, defects and failures, then design tests to expose them. Examples include division by zero, empty inputs, very long strings, special characters and wrong date formats.
25

Give a checklist you would use to review a user story.

Static TestingEasy
Save to ▾
Show answer
Is it written as 'As a [role], I want [goal], so that [benefit]'? Does it follow INVEST: independent, negotiable, valuable, estimable, small and testable? Are acceptance criteria clear, measurable and testable? Are error flows and edge cases covered? Are terms consistent with the glossary? Are dependencies and non-functional needs stated? Are vague words like 'quickly' or 'etc.' present? Log each anomaly with location, description and a suggestion.
26

What is the value of static testing?

Static TestingMedium
Save to ▾
Show answer
Static testing detects defects in the earliest phases, when they are cheapest to fix. It finds defects that dynamic testing cannot, such as unreachable code or defects in non-executable work products. It helps evaluate quality and build confidence, improves shared understanding among stakeholders, and gives fast feedback on code through static analysis in CI. Reviews cost effort, but the total cost of quality is usually lower.
27

Show the TDD red-green-refactor cycle with a small example.

Testing Throughout the SDLCMedium
Save to ▾
Show answer
# Red: write a failing test first def test_discount(): assert discount(1000) == 100 # Green: simplest code that passes def discount(amount): return amount * 0.10 # Refactor: improve design, test stays green RATE = 0.10 def discount(amount): return round(amount * RATE, 2) Repeat the cycle for each new behaviour, such as no discount below 500.
28

What is static testing and how is it different from dynamic testing?

Static TestingEasy
Save to ▾
Show answer
Static testing examines work products without executing them, through manual reviews or static analysis tools. Dynamic testing executes the software. Static testing finds defects directly, such as ambiguous requirements or coding standard violations, while dynamic testing causes failures whose defects are then located by debugging. Static testing works on non-executable products like requirements and test plans, and finds defects dynamic testing cannot, such as unreachable code.
29

Write a test charter for an exploratory session on a checkout page.

White-Box, Experience and Collaboration-Based TestingMedium
Save to ▾
Show answer
Charter: Explore the checkout page with different coupon and payment combinations to discover pricing and rounding errors. Time box: 60 minutes. Focus areas: coupon stacking, expired coupons, quantity changes after applying a coupon, currency rounding, and using the browser back button. Record test ideas, defects, questions and areas covered. Debrief with the test lead after the session to agree next charters.
30

A new tester has no domain knowledge and no detailed test cases. How can checklists help, and what is the risk?

White-Box, Experience and Collaboration-Based TestingMedium
Save to ▾
Show answer
A checklist of high-level conditions, such as validations, error messages, navigation and security basics, gives the new tester structure and consistency while learning the domain. Each run can vary slightly, which increases coverage. The risk is that checklists wear out as developers learn to avoid listed defects, so the team should update them with new defect patterns and pair the tester with an experienced colleague.
31

Write a BDD scenario for locking an account after three failed login attempts.

Testing Throughout the SDLCMedium
Save to ▾
Show answer
Feature: Account lockout Scenario: Lock account after three failed attempts Given a registered user with an active account When the user enters a wrong password 3 times in a row Then the account is locked And the message 'Account locked. Try again after 30 minutes' is shown Given sets the context, When is the action and Then is the expected outcome.
32

How do retrospectives help testing?

Testing Throughout the SDLCEasy
Save to ▾
Show answer
A retrospective is held at the end of an iteration, release or project to discuss what went well, what did not and how to improve. For testing, the benefits include more effective and efficient testing, better testware, team bonding, better quality of the test basis and stronger cooperation between developers and testers. Results should be recorded and the improvement actions tracked so that they are actually carried out.
33

A production hotfix must go live in three hours. How do you decide what to test?

Testing Throughout the SDLCMedium
Save to ▾
Show answer
I would do a quick impact analysis to see what the change touches, run confirmation tests for the defect, then a risk-based regression subset covering the changed module, its integrations and critical business flows like login and payment. I would use the automated smoke suite in the pipeline, record what was not covered, and plan fuller regression in the next regular release.
34

What is the difference between confirmation testing and regression testing?

Testing Throughout the SDLCEasy
Save to ▾
Show answer
Confirmation testing checks that an original defect has been fixed, by re-running the failed tests or new tests that cover the change. Regression testing checks that a change, including a fix, has not caused adverse effects elsewhere, in the same component, connected components or the environment. Regression suites grow and run often, so they are strong candidates for automation, typically inside a CI pipeline.
35

Explain the four test types defined in CTFL v4.0.

Testing Throughout the SDLCMedium
Save to ▾
Show answer
Functional testing checks what the system should do, covering completeness, correctness and appropriateness. Non-functional testing checks how well it behaves, using ISO/IEC 25010 characteristics such as performance efficiency, usability, security, reliability, compatibility, maintainability and portability. Black-box testing is specification-based, and white-box testing is structure-based. Any test type can be applied at any test level, with a different focus at each.
36

What are the five test levels in CTFL v4.0?

Testing Throughout the SDLCEasy
Save to ▾
Show answer
Component testing checks individual units in isolation. Component integration testing checks interfaces and interactions between components. System testing checks overall behaviour, both functional and non-functional. System integration testing checks interfaces with other systems and external services. Acceptance testing focuses on validation and readiness for deployment. Each level has its own objectives, test basis, test objects, typical defects and responsibilities.
37

Which work products can be examined by static testing?

Static TestingEasy
Save to ▾
Show answer
Almost any work product that can be read and understood: requirements, user stories, acceptance criteria, architecture and design documents, source code, test plans, test cases, test charters, backlog items, contracts, project plans, schedules and budgets. Static analysis tools need work products with a formal structure, such as code or models with defined syntax. Products that are hard for humans to interpret, like third-party executable code, are not suitable for review.
38

Explain the absence-of-defects fallacy.

Fundamentals of TestingEasy
Save to ▾
Show answer
It is a misconception that verifying software thoroughly and fixing every found defect guarantees success. A system can pass every test against its specification and still be useless if the specification was wrong or the users' real needs were missed. That is why testing must include validation as well as verification, for example early review of requirements with business stakeholders and user acceptance testing before release.
39

What is statement testing and how is statement coverage calculated?

White-Box, Experience and Collaboration-Based TestingEasy
Save to ▾
Show answer
Statement testing designs tests that execute the executable statements in the code. Statement coverage = statements executed by the tests / total executable statements x 100. Reaching 100 percent means every executable statement ran at least once, so a defect in any statement may be triggered. However, it does not guarantee that all decision logic is tested, for example the false outcome of an if without an else.
40

What formats can acceptance criteria take?

White-Box, Experience and Collaboration-Based TestingMedium
Save to ▾
Show answer
The two common formats are scenario-oriented, such as the Given/When/Then style used in BDD, and rule-oriented, such as a bullet-point verification list or a tabulated input-output mapping. Acceptance criteria define the scope of the story, reach consensus among stakeholders, describe positive and negative scenarios, serve as the basis for acceptance testing and support accurate planning and estimation. Teams can also use other formats as long as criteria are well defined and clear.

Frequently asked questions

What does a QA Analyst do?

QA analysts review requirements and user stories, identify test conditions, prepare test data and verify features against acceptance criteria. They join Agile ceremonies, perform exploratory sessions and report quality status to the team. Strong knowledge of review techniques, test levels and the whole team approach from the CTFL syllabus helps them catch defects early and communicate clearly with business stakeholders.

Which skills are tested in a QA Analyst interview?

Expect questions on Requirement review, Acceptance criteria, Exploratory testing, Agile ceremonies, Test documentation. Most rounds also ask you to explain a project and solve one practical problem live.

How do I prepare for a QA Analyst interview?

Revise Static Testing, Testing Throughout the SDLC, White-Box, Experience and Collaboration-Based Testing first using the topic sheets, practise the questions on this page aloud, then do one full mock interview to practise timing.

Topic sheets for this role

Static Testing questionsTesting Throughout the SDLC questionsWhite-Box, Experience and Collaboration-Based Testing questions

Other roles

Manual Test EngineerTest AnalystAgile QA EngineerTest LeadTest Manager

More ways to practise

Company-wise ISTQB questionsExperience-wise ISTQB questionsRole-wise ISTQB questionsCity-wise ISTQB questionsMost asked ISTQB questionsScenario-based questionsPractical / hands-on questionsHR & behavioural questionsISTQB mock interviewOnline assessment questionsTechnical round questionsManagerial round questionsISTQB topic sheets