ISTQB Agile Tester extension guide

TL;DR

CTFL-AT can still be taken in 2026, but it is a sunset certification. If you already hold CTFL v4, official guidance indicates that the extension is generally unnecessary because Agile testing is integrated there. Take CTFL-AT only for a concrete legacy or employer need, otherwise study CTFL v4 or evaluate CTAL-AT v2.0 for advanced Agile depth.

Key Takeaways

• CTFL-AT is in its sunset phase, with English exams and training available only until May 6, 2027 and non-English availability until November 6, 2027.
• Official ISTQB guidance says CTFL-AT adds little for candidates who already hold CTFL v4 because Agile testing is integrated into the current Foundation syllabus.
• Candidates with an older Foundation certificate, a specific employer requirement, or a near-term legacy pathway may still have a rational reason to take CTFL-AT.
• The newer CTAL-AT v2.0 is the current advanced Agile route, but its audience, depth, prerequisites, exam, and cost should be checked separately.
• Effective study connects Agile values, whole-team quality, feedback, test quadrants, automation, exploratory testing, and risk rather than memorizing ceremonies.
• A good Agile tester makes work testable earlier, shortens feedback, exposes uncertainty, and helps the team learn from executable and exploratory evidence.
• Before booking, verify the exact certificate requirement, provider availability, language, prerequisite, and remaining retake window.

This ISTQB Agile Tester extension guide starts with the decision many older guides miss: CTFL-AT is still available in 2026, but it is in its sunset phase. English exams, retakes, and training are scheduled to end on May 6, 2027, with non-English availability ending on November 6, 2027. If you already hold CTFL v4, official ISTQB guidance says the extension is generally not useful because Agile testing is covered in the current Foundation syllabus.

That does not make the content worthless. It changes who should book the exam. A candidate with an older Foundation certificate, an explicit employer requirement, or a defined transition path may still benefit. Everyone else should compare CTFL v4 and the newer Advanced Level Agile Tester v2.0 before spending time and money. This guide gives you that decision framework and a practical study plan if CTFL-AT remains the right choice.

TL;DR

Do not book from a course landing page alone. Confirm the module, version, language, prerequisite, exam availability, and retake deadline with the official member board or provider.

1. Read this ISTQB Agile Tester extension guide before booking

CTFL-AT is the Certified Tester Foundation Level Agile Tester extension. It was designed to help Foundation-certified testers contribute effectively on Agile projects by understanding Agile values, whole-team collaboration, iterative delivery, continuous feedback, test techniques, tools, and the tester's changing responsibilities.

In 2026, its status is the most important fact. ISTQB has announced the sunset of CTFL-AT, with English training and exams, including retakes, available until May 6, 2027 and non-English availability until November 6, 2027. Certificates already earned do not become invalid merely because an exam sunsets. The practical issue is whether a new candidate should invest in a credential that is leaving the catalog.

The decision depends on your starting certificate. CTFL v4 was rewritten with Agile, DevOps, collaboration, and modern lifecycle context in the main Foundation syllabus. ISTQB explicitly notes that taking CTFL-AT does not appear useful for someone who is CTFL v4 certified. That is unusually direct guidance and should outweigh old roadmaps that automatically place the Agile extension after Foundation.

A rational CTFL-AT candidate in 2026 can name the need: an employer requests that exact certificate, an internal matrix rewards it before sunset, or an older prerequisite path still applies to a planned module. Agile is popular is not enough.

Before paying, document the certificate you hold, the certificate your target requires, the last exam and retake dates, provider availability in your language, and what happens if your first attempt is late in the transition. This small check prevents a large planning error.

2. Compare CTFL-AT, CTFL v4, and CTAL-AT v2.0

The names are similar, but the routes serve different situations. Use the official scheme and provider rules to confirm prerequisites because transitions can affect holders of older certificates.

CTFL v4 is not simply CTFL v3.1 plus the old extension. It is a broader rewrite. A new candidate normally gets more durable pathway value by starting there. Read the ISTQB Foundation Level study guide before assuming two Foundation exams are necessary.

CTAL-AT v2.0 is not a direct rename of CTFL-AT. It is an advanced certification aimed at deeper Agile testing capability. A candidate should compare the official syllabus, business outcomes, experience expectations, exam structure, and prerequisite rules with their actual role. Do not jump to Advanced merely because the Foundation extension is ending.

A practical portfolio can accompany any route. Show how you improved acceptance criteria, chose coverage from risk, added a fast automated check at the right layer, and used exploration to discover a product question. Hiring managers can probe this evidence more deeply than a badge.

3. Understand the CTFL-AT exam and source materials

The 2026 official exam structure lists CTFL-AT as 40 multiple-choice questions, 40 possible points, and a passing score of 26. The standard exam length is 90 minutes. A candidate taking an exam in a language that is not their first language can apply for the standard 25 percent time extension, shown as 113 minutes after rounding in the structure table. Provider procedure still controls approval.

Use only a source set matched to the exam:

1. Official CTFL-AT syllabus.
2. Applicable official glossary.
3. Current official sample questions and answers.
4. Current exam structure and rules.
5. Sunset and transition announcement.
6. Provider-specific eligibility, delivery, and retake policy.

Do not combine CTFL v4 notes and CTFL-AT notes without labels. The overlap can help understanding, but the exam follows its named syllabus. Old mock banks may use stale wording or unsupported questions. Treat third-party questions as practice prompts, then verify the reasoning against official objectives.

K-levels tell you the expected cognitive task. Recall and understanding questions still require precise reading, while application objectives require you to use a concept in a scenario. Build notes around what you must do, not how many pages a chapter has.

A sample exam score is diagnostic. For every wrong or guessed answer, record the objective, missed clue, incorrect assumption, and rule that would prevent recurrence. Repeating the same paper until the answer position feels familiar is not preparation.

Finally, protect your timeline. The exam might be available for months, but training schedules, language sessions, and retake opportunities can be narrower. Work backward from the final date with a buffer rather than planning your first attempt at the edge of sunset.

4. Learn Agile values through testing behavior

An Agile tester does not merely attend stand-ups or move test cases into a sprint. The role supports frequent delivery by helping the whole team understand quality risk, create testable examples, obtain fast feedback, and learn from product behavior.

Translate values and principles into observable work:

• Collaborate with developers and business representatives before implementation.
• Prefer useful, maintainable evidence over documentation produced for its own sake.
• Adapt coverage when risk and product learning change.
• Test small increments continuously rather than protecting a late test phase.
• Make quality information visible without becoming a release gatekeeper.
• Improve the system of delivery in retrospectives.

The whole-team approach does not mean responsibilities disappear. Developers, testers, product people, designers, security specialists, and operations bring different expertise. Quality becomes shared while specialized testing skill remains valuable. The tester asks questions others may not see, models risk, explores behavior, and coaches testability.

Agile testing also requires independence of thought. Collaboration should not reduce constructive challenge. A tester can work closely with a developer and still evaluate assumptions, choose adversarial data, and seek independent evidence. Independence is a perspective and organizational consideration, not a wall between roles.

For exam scenarios, distinguish an Agile behavior from a ceremony label. Daily meetings do not make feedback effective if defects wait until the sprint ends. A written test plan is not automatically non-Agile if it is concise, useful, and maintained. The question is whether the practice supports value, collaboration, feedback, and adaptation in context.

5. Apply testing across an iteration and release

Testing begins before code. In backlog refinement, help split work, reveal assumptions, identify quality risks, and turn vague examples into testable acceptance criteria. During planning, make test activities, data, environments, dependencies, and automation work visible.

During implementation, collaborate on examples and checks at multiple layers. Review unit and component evidence where appropriate, execute exploratory charters against emerging behavior, and keep defects or questions close to the change. Avoid building a large queue for the final day.

Continuous integration should provide fast signals on every meaningful change. A healthy pipeline usually orders faster, focused checks before slower broad suites. The exact layers vary, but the principle is quick localization. A single slow UI suite is a fragile feedback strategy.

At review, demonstrate product outcomes and discuss evidence, not only completed tickets. At retrospective, examine delay, escapes, flakiness, environment problems, and collaboration friction. Choose a measurable improvement small enough to try in the next iteration.

Release testing may span multiple iterations. System qualities, end-to-end integrations, migration, exploratory campaigns, performance, security, accessibility, resilience, and operational readiness can require broader coordination. Agile delivery does not remove these risks. It encourages earlier, incremental evidence.

Use a readiness conversation instead of a magical QA sign-off. Summarize important risks, acceptance evidence, unresolved defects, environment confidence, and what was not tested. The product owner or accountable release stakeholder then makes a business decision with clear information.

For a broader view of early feedback, see shift-left testing practices for QA teams. Shift left is effective only when it changes decisions and feedback timing, not when it moves the same late test tasks earlier on a schedule.

6. Use Agile testing quadrants and the test pyramid carefully

Agile testing quadrants are a communication model for balancing tests that support the team and tests that critique the product, across business-facing and technology-facing perspectives. They are not a mandatory sequence or a rule that every quadrant must contain the same number of tests.

Use the quadrants to discover missing conversations. A team with excellent unit coverage may still lack business exploration. A team with many manual end-to-end cases may lack fast technology-facing support checks. The model exposes imbalance, then context determines action.

The test pyramid is another heuristic. It encourages many fast lower-level checks and fewer broad UI checks, but counting shapes is not the goal. Boundaries, architecture, risk, and observability determine the useful mix. A service-heavy product may have extensive contract and integration tests. A visual workflow still needs focused UI evidence.

Automation is valuable when it shortens feedback and preserves stable expectations. It is less useful when teams automate unclear behavior, duplicate the same assertion across every layer, or accept flaky red-green noise. Decide what risk the check proves, why that layer is appropriate, and who will maintain it.

Manual testing is not synonymous with unstructured testing. Exploratory work, usability evaluation, and risk investigation require human cognition. Automated checks are not synonymous with all testing. Strong Agile teams combine executable feedback with human learning.

7. Turn acceptance criteria into executable examples

Three Amigos collaboration brings business, development, and testing perspectives together around examples. The names are less important than the perspectives. Ask about rules, boundaries, failures, roles, data, state, timing, and observable outcomes before implementation.

Suppose a story says: Premium customers receive free delivery. Questions include whether the benefit applies to guest checkout, expired membership, mixed sellers, restricted locations, or orders changed after payment. Concrete examples expose missing rules faster than debating adjectives.

This self-contained Playwright test uses current @playwright/test APIs and no external website. It renders a tiny behavior, verifies the premium example, and can run with the Playwright test runner:

import { test, expect } from '@playwright/test';

test('premium customer receives free delivery', async ({ page }) => {
  await page.setContent(`
    <label>
      Customer type
      <select aria-label="Customer type">
        <option>Standard</option>
        <option>Premium</option>
      </select>
    </label>
    <button>Calculate delivery</button>
    <output aria-live="polite"></output>
    <script>
      const select = document.querySelector('select');
      const output = document.querySelector('output');
      document.querySelector('button').addEventListener('click', () => {
        output.textContent = select.value === 'Premium'
          ? 'Delivery: Free'
          : 'Delivery: $5';
      });
    </script>
  `);

  await page.getByLabel('Customer type').selectOption('Premium');
  await page.getByRole('button', { name: 'Calculate delivery' }).click();

  await expect(page.getByText('Delivery: Free')).toBeVisible();
});

The check is intentionally small. It does not prove membership validity, price calculation, backend enforcement, accessibility quality, or browser integration with a real service. State those gaps. Executable examples are valuable when the team agrees they represent business rules, while broader testing covers other risks.

Keep scenarios readable and focused. Avoid turning business examples into a second programming language full of UI selectors and setup noise. Details needed only by automation belong in supporting code or fixtures.

8. Combine exploratory testing, risk, and feedback

Agile teams operate with incomplete information, making exploratory testing especially useful. Create short charters around current risks, execute near the change, and debrief quickly so learning affects the iteration.

A charter format can be: Explore target with resources to discover information related to risk. For the premium delivery feature: Explore membership changes during checkout using account controls and concurrent sessions to discover inconsistent price or authorization behavior. This focuses learning without prescribing every click.

Capture lightweight notes: data, areas visited, variations, observations, questions, defects, and coverage. The notes support handoff and learning but should not become a transcript of every action. Attach evidence when it helps reproduction.

Risk analysis stays continuous. New information can change likelihood, impact, detectability, or exposure. A third-party outage, architecture change, production incident, or new customer segment may reorder work. A static risk spreadsheet reviewed only at release is not Agile risk-based testing.

Fast feedback has quality dimensions. A fast signal that is flaky or opaque can waste time. Optimize for trustworthy, actionable feedback: deterministic setup, useful failure messages, isolated state, correct oracles, and clear ownership. Preserve first-failure evidence before reruns.

Production monitoring can extend learning after release when privacy, safety, and organizational controls are respected. Logs, metrics, traces, feature flags, canaries, and user feedback reveal behavior pre-release environments cannot fully reproduce. Testing in production complements, not excuses, pre-release engineering.

Use retrospectives to improve the feedback system. Measure a specific delay, such as time from commit to a reliable service-test result, rather than celebrating a larger automation count. The goal is better decisions, not activity volume.

9. Build a focused CTFL-AT study plan before sunset

First, confirm that CTFL-AT is still the correct credential. If yes, plan backward with enough time for a retake inside the official availability window. Do not let a course schedule become your eligibility analysis.

Use four study loops:

Source and map

Read the learning objectives, mark K-levels, and map each to the official chapter and glossary terms. Separate CTFL-AT examinable material from newer CTFL v4 or CTAL-AT ideas you may study for context.

Explain and contrast

Explain concepts in your own words and contrast common confusions: whole-team responsibility versus loss of expertise, continuous testing versus constant UI execution, automated checking versus testing, and iteration completion versus release readiness.

Apply

Take one feature through refinement, examples, risk, quadrants, automation selection, exploratory charter, execution evidence, and retrospective improvement. This creates retrieval cues stronger than chapter summaries.

Calibrate and time

Use official sample questions, explain every option, record guessed answers, and attempt fresh sets under the official time limit. Practice the provider's delivery format if a demo is available.

Study with an error log. Categories may include missed Agile value, role confusion, lifecycle misconception, wrong quadrant purpose, automation overreach, objective mismatch, or qualifier missed. Write a correction rule and retest it later.

Avoid exam dumps. They can be inaccurate, breach exam rules, and teach answer recognition instead of judgment. The certificate is temporary value if the knowledge disappears at the first interview scenario.

10. Use the ISTQB Agile Tester extension guide at work

Whether or not you take CTFL-AT, convert the material into visible behaviors. Improve one refinement discussion by bringing boundary examples. Replace one slow UI setup with a controlled lower-layer fixture. Create one risk-based exploratory charter. Add one useful pipeline artifact. Track one feedback delay through a retrospective experiment.

A portfolio case study can show:

• Original story and questions raised.
• Concrete examples and clarified acceptance criteria.
• Risk map and chosen test layers.
• One runnable automated example.
• Exploratory charter and findings.
• Release evidence and residual risk.
• Retrospective change and expected signal.

This evidence is useful in Agile QA interviews. If you need scenario practice, connect it with manual testing interview questions for experienced testers. Replace model answers with your actual team context.

On a resume, list the exact certification name and year only after passing. Describe applied outcomes in experience bullets. Collaborated in refinement to expose refund-state gaps and added service-level examples for critical rules says more than Worked in Agile.

If you decide against CTFL-AT, the study is not wasted. You can use official content to repair gaps, then pursue CTFL v4, CTAL-AT v2.0, or role-specific engineering. The broader decision framework in is ISTQB worth it in 2026 helps compare certification with the best alternative use of your time.

The end goal is not to defend a process label. It is to help a team deliver valuable product increments with timely, credible information about quality.

Interview Questions and Answers

Q: What is the role of a tester on an Agile team?

The tester contributes specialized quality and test expertise within whole-team ownership. I help refine examples, identify risk, improve testability, select evidence at appropriate layers, explore behavior, and communicate uncertainty. I do not wait for a separate test phase.

Q: Does Agile eliminate test documentation?

No. Agile favors useful documentation and communication over documents produced without value. I keep risk notes, examples, charters, automation, and release evidence at the level needed for collaboration, audit, maintenance, and decisions.

Q: What are Agile testing quadrants used for?

They help teams discuss a balanced set of business-facing and technology-facing tests that either support delivery or critique the product. They are a thinking model, not a sequence or a required test-count ratio.

Q: How do you test within a short iteration?

I begin in refinement, make data and environment needs visible, collaborate on lower-level checks, and explore increments as they emerge. I keep feedback continuous and reserve broader cross-cutting work for coordinated release-level coverage when needed.

Q: What is the difference between automated checking and exploratory testing?

Automated checks compare implemented behavior with encoded expectations efficiently. Exploratory testing uses human learning to design and evaluate tests while interacting with the product. They answer different needs and work well together.

Q: How do you decide which acceptance tests to automate?

I consider business importance, repetition, stability, feedback speed, layer, setup cost, oracle clarity, and maintenance. I automate focused examples where executable feedback helps and preserve human evaluation for risks that require learning or judgment.

Q: How do you contribute during backlog refinement?

I ask about actors, rules, boundaries, states, failures, dependencies, observability, and quality characteristics. I use concrete examples to expose disagreement and help split work into testable increments.

Q: What would you improve in an Agile team's testing process?

I would identify the largest feedback constraint from evidence, such as late requirement questions, flaky pipeline results, or shared test data. Then I would run one small experiment with a defined signal and review the result in the retrospective.

Common Mistakes

• Booking CTFL-AT after CTFL v4 without checking official guidance: The current Foundation already integrates Agile testing.
• Ignoring the 2027 sunset: Plan the first attempt and any retake inside the published window.
• Confusing CTFL-AT with CTAL-AT v2.0: They are different levels and pathways.
• Studying ceremonies instead of principles: Connect every practice to collaboration, value, feedback, or adaptation.
• Treating the tester as the quality owner: Quality is shared, while testing expertise remains specialized.
• Leaving testing until the last sprint day: Start analysis and examples before implementation.
• Automating every acceptance criterion through the UI: Choose the fastest layer that proves the risk.
• Calling unscripted clicking exploratory testing: Use charters, notes, learning, and debriefs.
• Using quadrants as a sequence: They are a conversation model, not a lifecycle.
• Reporting only pass percentages: Include risk, scope, reliability, defects, and residual uncertainty.
• Memorizing old mock banks: Calibrate with official materials for the exact module.
• Claiming certification proves Agile experience: Pair it with real or clearly labeled practice evidence.

Conclusion

The right use of this ISTQB Agile Tester extension guide in 2026 begins with a transition decision. CTFL-AT remains available for a limited period, but candidates who already hold CTFL v4 generally do not need it. Candidates with a concrete legacy requirement should verify prerequisites and timing immediately, while experienced practitioners should compare the newer CTAL-AT v2.0 route.

Whichever route you choose, apply the ideas. Bring testing into refinement, create concrete examples, balance fast checks with exploration, and communicate residual risk. Those behaviors outlast any syllabus transition and provide the evidence Agile QA employers actually probe.

Interview Questions and Answers

Frequently Asked Questions

Related Guides

• ISTQB Advanced Test Analyst guide
• ISTQB Foundation Level study guide
• Automation Tester Salary in Canada (2026)
• Automation Tester Salary in Germany (2026)
• Automation Tester Salary in India (2026)
• Automation Tester Salary in UK (2026)