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

Agile QA Engineer Interview Questions & Answers

40 questions for Agile QA Engineer interviews — 4 easy, 29 medium, 7 hard.

About the Agile QA Engineer role

Agile QA engineers work inside Scrum or Kanban teams, writing acceptance tests with BDD, testing stories as they are built, maintaining regression in the CI pipeline and running exploratory sessions. They combine CTFL knowledge of shift-left, test-first approaches and the test pyramid with tools like Postman and Selenium, and act as quality advocates within the whole team approach. It is a popular next step for manual testers after one to three years.

BDD scenarios API testing CI pipelines Exploratory testing Test automation basics
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

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.
02

You join a Scrum team with two-week sprints. What testing activities would you do during a sprint?

Testing Throughout the SDLCMedium
Save to ▾
Show answer
I would join backlog refinement to review stories and acceptance criteria, help estimate test effort in sprint planning, write acceptance tests early, pair with developers on automation, test each story as soon as it is ready, keep regression running in the CI pipeline, run exploratory sessions on new features and share testing feedback in the retrospective. Testing runs continuously rather than at the end of the sprint.
03

How do you learn from sample exams instead of just counting your score?

Test Tools and Exam PreparationMedium
Save to ▾
Show answer
After each timed attempt, review every question, including correct guesses. For each mistake, note the learning objective, the chapter and why the right option is correct in the syllabus text. Group mistakes by chapter to find weak areas, re-read those sections, and redo similar questions after a few days. Aim for consistent scores of 32 or more out of 40 before the real exam.
04

Build a decision table for a loan rule: approve if salary is at least 30,000 and credit score is at least 700; refer if only one is met; otherwise reject.

Black-Box Test TechniquesMedium
Save to ▾
Show answer
Conditions R1 R2 R3 R4 Salary >= 30000 T T F F Score >= 700 T F T F Actions Approve X - - - Refer to officer - X X - Reject - - - X Two Boolean conditions give 2 x 2 = 4 rules, so 4 test cases give 100 percent decision table coverage.
05

Find the minimum tests for statement and branch coverage when there are two independent if statements in sequence.

White-Box, Experience and Collaboration-Based TestingMedium
Save to ▾
Show answer
if a > 0: s1 if b > 0: s2 Statement coverage: one test with a = 1 and b = 1 runs s1 and s2, so 1 test. Branch coverage: each if needs a true and a false outcome. Tests (a = 1, b = 1) and (a = 0, b = 0) cover all four branches, so 2 tests.
06

Show a simple CI pipeline step that runs automated tests on every push.

Test Tools and Exam PreparationHard
Save to ▾
Show answer
name: tests on: [push, pull_request] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-python@v5 with: python-version: '3.12' - run: pip install -r requirements.txt - run: pytest --junitxml=report.xml The pipeline fails if any test fails, giving fast feedback to the developer.
07

Compare TDD, ATDD and BDD.

Testing Throughout the SDLCMedium
Save to ▾
Show answer
All three are test-first approaches. In TDD, developers write a failing unit test, write code to pass it, then refactor. In ATDD, acceptance tests are derived from acceptance criteria with the team and business before development starts. In BDD, desired behaviour is written as Given/When/Then scenarios in natural language that stakeholders understand and that can be turned into executable tests. All three support shift-left.
08

How do you use the ISTQB glossary to prepare effectively?

Test Tools and Exam PreparationMedium
Save to ▾
Show answer
Each learning objective lists keywords that you must know. Make flashcards for them with the exact glossary definition and one example from your own work, such as 'test basis: the user story for checkout'. Review them daily with spaced repetition. Pay attention to similar terms, like test condition versus test case, and confirmation versus regression testing, because exams use them as distractors.
09

In the CTFL exam you have ten questions left and only five minutes. What should you do?

Test Tools and Exam PreparationEasy
Save to ▾
Show answer
There is no negative marking, so never leave a question blank. Quickly answer the easier ones first, eliminate obviously wrong options on the rest and pick the best remaining choice. Flag nothing new for review now. To avoid this situation, aim to spend about one minute per question in the first pass and skip long calculation questions to revisit later.
10

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.
11

The product owner writes vague acceptance criteria such as 'search should work well'. What do you do?

White-Box, Experience and Collaboration-Based TestingMedium
Save to ▾
Show answer
I would suggest a short three-amigos session with the product owner and a developer. Together we would turn the vague criterion into testable ones, for example 'searching by product name returns matching items sorted by relevance', 'no results shows a helpful message' and 'results load in under 2 seconds'. Writing them as Given/When/Then scenarios makes them clear and ready for ATDD.
12

A test suite executes 8 of 10 executable statements and 3 of 4 branches. What are the coverage figures?

White-Box, Experience and Collaboration-Based TestingHard
Save to ▾
Show answer
Statement coverage = 8 / 10 x 100 = 80 percent. Branch coverage = 3 / 4 x 100 = 75 percent. To raise them, look at the control flow graph to see which statements and which branch outcome were missed, then design inputs that force execution down those paths. Coverage tools in CI pipelines report these numbers automatically for each build.
13

You have three years of testing experience and three weeks to prepare for CTFL. How do you plan?

Test Tools and Exam PreparationMedium
Save to ▾
Show answer
Experience helps, but the exam follows syllabus wording, not company practice. Week 1: read chapters 1 to 3 and the glossary terms in each learning objective. Week 2: study chapters 4 to 6, practise BVA, decision tables, state transitions, coverage and estimation calculations. Week 3: take timed official sample exams, analyse every wrong answer against the syllabus, and revise weak chapters.
14

What are the risks of test automation?

Test Tools and Exam PreparationMedium
Save to ▾
Show answer
Unrealistic expectations about what a tool can do; inaccurate estimates of the time, cost and effort to introduce and maintain it; using a tool where manual testing is better; relying on the tool too much and ignoring critical thinking; dependency on the tool vendor, which may go out of business or retire the tool; open-source tools being abandoned; and tools not compatible with the development platform or not meeting regulations.
15

How are CTFL v4.0 exam questions distributed across chapters?

Test Tools and Exam PreparationMedium
Save to ▾
Show answer
Approximately: Chapter 1, Fundamentals of Testing, 8 questions; Chapter 2, Testing Throughout the SDLC, 6; Chapter 3, Static Testing, 4; Chapter 4, Test Analysis and Design, 11; Chapter 5, Managing the Test Activities, 9; Chapter 6, Test Tools, 2. Chapters 4 and 5 carry half the marks and include most K3 questions, so practise techniques and estimation thoroughly.
16

Your organisation is moving from the V-model to DevOps. How should the test strategy change?

Testing Throughout the SDLCHard
Save to ▾
Show answer
I would push component tests and static analysis into the pipeline on every commit, build a test pyramid with many unit tests, fewer API tests and few UI tests, provision environments through infrastructure as code and add production monitoring. Testers shift from long test phases to continuous risk analysis, exploratory testing and quality coaching. I would plan training and track metrics like lead time and escaped defects.
17

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.
18

How did you give feedback on a senior colleague's document that had many issues?

Static TestingMedium
Save to ▾
Show answer
Situation: a senior architect's design missed several error-handling flows. Task: give feedback respectfully. Action: I grouped comments by theme, framed them as questions with concrete examples, noted the strong sections, and offered to discuss in person rather than only posting comments. Result: he accepted most points, appreciated the clear feedback, and later invited me to review his designs earlier.
19

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.
20

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.
21

A review meeting turns into people blaming the author. How do you handle it as moderator?

Static TestingMedium
Save to ▾
Show answer
I would refocus the discussion on the work product, not the person, remind everyone of the review objectives, and record the anomaly neutrally. Afterwards I would speak privately with the people involved. To prevent repeats, I would set ground rules, train participants and make sure review results are never used to judge individuals. Authors in a safe culture share work openly, so reviews find more defects.
22

How does acceptance test-driven development (ATDD) work?

White-Box, Experience and Collaboration-Based TestingHard
Save to ▾
Show answer
ATDD is a test-first approach. The team, including business, developers and testers, analyses the story and acceptance criteria in a specification workshop, then writes test cases before implementation. Positive tests come first, then negative tests and non-functional characteristics. Tests are written in a form stakeholders understand, cover every criterion without going beyond the story, and are often automated so they become executable requirements.
23

A developer says one value per partition is enough. Why might you still add boundary tests?

Black-Box Test TechniquesMedium
Save to ▾
Show answer
Equivalence partitioning assumes all values in a partition behave the same, but many defects occur at the edges, where developers write '>' instead of '>=' or use the wrong limit. One middle value like 35 in an 18 to 60 range will never reveal these. Boundary value analysis adds tests at 17, 18, 60 and 61, so the two techniques together give good coverage with few tests.
24

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.
25

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.
26

Your automated regression suite fails randomly, and the team no longer trusts it. What do you do?

Test Tools and Exam PreparationMedium
Save to ▾
Show answer
Flaky tests are a known automation risk. I would quarantine flaky tests so they do not block the pipeline, then find the causes: hard-coded waits, shared test data, test order dependency or unstable environments. Fixes include explicit waits, independent test data, isolated environments and retries only for known infrastructure issues. I would track the flaky rate and return fixed tests to the main suite.
27

How has ISTQB knowledge helped you in your job?

Test Tools and Exam PreparationMedium
Save to ▾
Show answer
Situation: our team wrote test cases with no clear technique, and suites kept growing. Task: improve efficiency. Action: I applied equivalence partitioning and boundary value analysis to the form validations and used decision tables for pricing rules, removing redundant tests. Result: we cut the regression suite by about 30 percent while finding more boundary defects, and my lead asked me to train two juniors.
28

What is the value of white-box testing?

White-Box, Experience and Collaboration-Based TestingMedium
Save to ▾
Show answer
White-box testing considers the whole implementation, so it can find defects even when the specification is vague, outdated or incomplete. Coverage gives an objective measure of thoroughness. It can also be used in static testing, for example dry runs of code or pseudocode. Its main weakness is that it cannot detect omissions: if a requirement was never implemented, no white-box test will notice it.
29

The requirements are incomplete and release is in two days. How do you test?

White-Box, Experience and Collaboration-Based TestingMedium
Save to ▾
Show answer
I would use session-based exploratory testing. I would write short charters for the riskiest areas, agree priorities with the product owner, run time-boxed sessions, note defects and questions, and debrief after each session. I would add error guessing for common failure types and a quick checklist for critical flows, and report clearly which areas were covered and which risks remain.
30

Why does CTFL v4.0 recommend starting non-functional testing early?

Testing Throughout the SDLCHard
Save to ▾
Show answer
Non-functional tests are often left to the end, but late discovery of performance or security problems can threaten the whole project. v4.0 recommends starting early, even at component level, for example measuring response time of a key service. Some tests need special environments such as a usability lab. Many non-functional tests reuse functional tests but measure a different quality, like checking login speed under 500 concurrent users.
31

Tell me about a time testing was squeezed at the end of a sprint. What did you do?

Testing Throughout the SDLCMedium
Save to ▾
Show answer
Situation: stories reached me only in the last two days of each sprint. Task: stop testing from being a bottleneck. Action: I proposed writing acceptance criteria and test cases during refinement, asked developers to merge smaller stories earlier, and automated API checks in the CI pipeline. Result: within three sprints, carried-over stories fell from five to one, and the team added early testing to its definition of done.
32

What certification path can you follow after CTFL?

Test Tools and Exam PreparationHard
Save to ▾
Show answer
After CTFL you can take Advanced Level modules: Test Analyst, Technical Test Analyst and Test Management. Specialist modules include Test Automation Engineering, Performance Testing, Security Testing, Mobile Application Testing, Usability Testing and AI Testing, among others. Expert Level certifications follow for experienced professionals. Choose based on your role: automation engineers pick technical paths, while leads pick test management.
33

How does decision table testing work, and how is coverage measured?

Black-Box Test TechniquesMedium
Save to ▾
Show answer
Decision tables model combinations of conditions and the resulting actions, which suits business rules. Each column is a rule: one combination of conditions with its actions. With n Boolean conditions, a full table has 2 to the power n columns. Coverage items are the feasible columns, so coverage is exercised columns divided by feasible columns. Tables can be minimised by merging columns where a condition does not affect the outcome, shown with a dash.
34

A company uses its own testing terms that differ from ISTQB terms. How do you handle this in the exam and at work?

Test Tools and Exam PreparationHard
Save to ▾
Show answer
In the exam, always answer using the ISTQB syllabus and glossary definitions, because questions are written from them. At work, I would map local terms to ISTQB ones, for example 'sanity check' to a smoke test, and help the team build a shared glossary. A common vocabulary reduces misunderstandings, especially when working with distributed teams or clients.
35

A manager says, 'Testing found zero defects in this release, so the software is defect-free.' How do you respond?

Fundamentals of TestingMedium
Save to ▾
Show answer
Testing shows the presence of defects, not their absence, so finding none only reduces the probability of undiscovered defects. I would also raise the absence-of-defects fallacy: did our tests cover real user needs? I would share coverage data, untested risk areas and whether our tests may have worn out. A more accurate statement is 'no defects were found within the agreed coverage and risk scope'.
36

Tell me about an exploratory testing session that found a critical defect.

White-Box, Experience and Collaboration-Based TestingMedium
Save to ▾
Show answer
Situation: a ticket booking app had passed all scripted tests. Task: run a one-hour exploratory session on seat selection. Action: I tried quick double taps, switching networks and booking the same seat from two devices. Result: two users could book the same seat. I logged a detailed report with videos, it was fixed before release, and concurrency tests were added to the regression suite.
37

How do you register for the CTFL exam in India?

Test Tools and Exam PreparationEasy
Save to ▾
Show answer
Register through the ISTQB member board for India or an ISTQB-accredited exam provider. Create an account, choose CTFL v4.0, and pick either an online proctored exam or a test centre. For online exams, check your webcam, microphone and internet in advance, and keep a valid government photo ID ready. Results are usually shared soon after the exam, followed by the certificate.
38

How does component integration testing differ from system integration testing?

Testing Throughout the SDLCMedium
Save to ▾
Show answer
Component integration testing focuses on interfaces between components of the same system and is usually done by developers or testers who know the architecture, often with stubs and drivers. System integration testing focuses on interfaces with other systems and external services, such as payment gateways or government APIs, and needs production-like environments. Incremental integration, top-down or bottom-up, is preferred over big-bang because it localises defects.
39

What categories of test tools does CTFL v4.0 describe?

Test Tools and Exam PreparationEasy
Save to ▾
Show answer
Test management tools, static testing tools, test design and implementation tools, test execution and coverage tools, non-functional testing tools, DevOps tools such as CI/CD pipelines and build tools, collaboration tools, and tools supporting scalability and deployment standardisation such as virtual machines and containers. Any tool that assists testing counts, even a spreadsheet. Tools improve efficiency, quality and repeatability.
40

What changed in CTFL v4.0 compared with the 2018 syllabus?

Test Tools and Exam PreparationMedium
Save to ▾
Show answer
v4.0 added Agile and DevOps content: the whole team approach, test-first approaches like TDD, ATDD and BDD, shift-left, retrospectives, collaboration-based test approaches, the test pyramid and testing quadrants. It renamed the pesticide paradox to 'tests wear out', removed use case testing and decision coverage, focused white-box testing on statement and branch coverage, and described test roles instead of job titles.

Frequently asked questions

What does a Agile QA Engineer do?

Agile QA engineers work inside Scrum or Kanban teams, writing acceptance tests with BDD, testing stories as they are built, maintaining regression in the CI pipeline and running exploratory sessions. They combine CTFL knowledge of shift-left, test-first approaches and the test pyramid with tools like Postman and Selenium, and act as quality advocates within the whole team approach. It is a popular next step for manual testers after one to three years.

Which skills are tested in a Agile QA Engineer interview?

Expect questions on BDD scenarios, API testing, CI pipelines, Exploratory testing, Test automation basics. Most rounds also ask you to explain a project and solve one practical problem live.

How do I prepare for a Agile QA Engineer interview?

Revise Testing Throughout the SDLC, White-Box, Experience and Collaboration-Based Testing, Test Tools and Exam Preparation 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

Testing Throughout the SDLC questionsWhite-Box, Experience and Collaboration-Based Testing questionsTest Tools and Exam Preparation questions

Other roles

Manual Test EngineerQA AnalystTest AnalystTest 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