Chapter 6 — Learning objectives
Learning objectives
FL-6.1.1K2Explain how different types of test tools support testing
FL-6.2.1K1Recall the benefits and risks of test automation
K-level breakdown
| LO | Level | What it means for the exam |
|---|---|---|
| FL-6.1.1 | K2 — Explain | Given a tool name or description, identify what type it is and how it supports testing. "Which statement BEST explains how a static analysis tool supports testing?" |
| FL-6.2.1 | K1 — Recall | Recognize a benefit or risk from a list. "Which of the following is a RISK of test automation?" |
Chapter 6 is short (2 LOs). Most exam questions will be a list of statements — identify which is a benefit, which is a risk, or which tool type supports a given activity.
Core message
Simply acquiring a tool does not guarantee success. Each new tool requires effort for introduction, maintenance, and training. Benefits are real — but so are the risks.
6.1 Tool support for testing
Test tools support many test activities
The syllabus uses "examples include, but are not limited to" — so the list is not exhaustive. Even a spreadsheet counts as a test tool in the context of testing.
📋
Test management tools
Facilitate management of the SDLC, requirements, tests, defects, and configuration. Increase test process efficiency.
e.g., Jira, TestRail, Azure DevOps, Zephyr
🔍
Static testing tools
Support the tester in performing reviews and static analysis — check code without executing it.
e.g., SonarQube, ESLint, Checkstyle, PMD, FindBugs
✏️
Test design & implementation tools
Facilitate generation of test cases, test data, and test procedures from specifications or models.
e.g., Cucumber (BDD), model-based testing tools, data generators
▶️
Test execution & coverage tools
Facilitate automated test execution and measure coverage (statement, branch, etc.).
e.g., Selenium, Playwright, JUnit, TestNG, JaCoCo, Istanbul
⚡
Non-functional testing tools
Allow the tester to perform non-functional testing that is difficult or impossible to perform manually (performance, security, load).
e.g., JMeter, Gatling, OWASP ZAP, k6, LoadRunner
🔄
DevOps tools
Support the DevOps delivery pipeline — workflow tracking, automated build process, CI/CD integration.
e.g., Jenkins, GitHub Actions, GitLab CI, Docker, Kubernetes
💬
Collaboration tools
Facilitate communication and sharing among team members and stakeholders.
e.g., Slack, Microsoft Teams, Confluence, Miro
📦
Scalability & deployment tools
Support deployment standardization and scaling of test infrastructure.
e.g., Virtual machines, Docker containers, Kubernetes, VirtualBox
🛠️
Any other test tool
Any tool that assists in testing counts — even a spreadsheet is a test tool in the context of testing.
e.g., Excel (test cases), mind-mapping tools, word processors
Tool types mapped to test activities
| Test activity | Tool type | Example |
|---|---|---|
| Managing test cases, defects, requirements | Test management | Jira, TestRail |
| Code quality analysis without running code | Static testing | SonarQube, ESLint |
| Generating test cases from models/specs | Test design & implementation | Cucumber, model-based tools |
| Running automated test suites | Test execution | Selenium, Playwright, JUnit |
| Measuring code coverage | Test coverage | JaCoCo, Istanbul |
| Load & performance testing | Non-functional testing | JMeter, Gatling, k6 |
| Security vulnerability scanning | Non-functional testing | OWASP ZAP, Burp Suite |
| Continuous integration / deployment | DevOps | Jenkins, GitHub Actions |
| Team communication & documentation | Collaboration | Confluence, Slack |
| Isolated test environments | Scalability & deployment | Docker, VMs |
The syllabus says "any tool that assists in testing" counts — this is intentionally broad. The exam may present an unusual tool and ask you to classify it.
6.2 Benefits of test automation
6 key benefits (K1 — recall all)
Time saved by reducing repetitive manual work
Execute regression tests, re-enter test data, compare expected vs actual results, check coding standards — all done faster by a tool.
Execute regression tests, re-enter test data, compare expected vs actual results, check coding standards — all done faster by a tool.
Prevention of simple human errors through greater consistency and repeatability
Tests are consistently derived from requirements, test data created systematically, tests executed by tool in the same order with the same frequency — no fatigue or oversight.
Tests are consistently derived from requirements, test data created systematically, tests executed by tool in the same order with the same frequency — no fatigue or oversight.
More objective assessment and measures too complicated for humans
Automated coverage metrics, defect density calculations, trend charts — impossible or impractical to compute manually at scale.
Automated coverage metrics, defect density calculations, trend charts — impossible or impractical to compute manually at scale.
Easier access to information about testing
Statistics, graphs, and aggregated data about test progress, failure rates, and test execution duration — supports better test management and reporting.
Statistics, graphs, and aggregated data about test progress, failure rates, and test execution duration — supports better test management and reporting.
Reduced test execution times → earlier defect detection, faster feedback, faster time to market
Automated suites run in minutes vs hours for manual — critical for CI/CD pipelines.
Automated suites run in minutes vs hours for manual — critical for CI/CD pipelines.
More time for testers to design new, deeper and more effective tests
When routine regression is automated, testers can focus on exploratory, creative, and complex test design instead of repetitive execution.
When routine regression is automated, testers can focus on exploratory, creative, and complex test design instead of repetitive execution.
Benefits at a glance
⏱️ Saves time on repetition
✅ Consistent & repeatable
📊 Objective metrics
📈 Better reporting
🚀 Faster feedback
🧠 Testers focus on creative work
6.2 Risks of test automation
8 key risks (K1 — recall all)
Unrealistic expectations about the benefits of a tool
Teams expect automation to solve all problems. Overestimating functionality and ease of use leads to disappointment and wasted investment.
Teams expect automation to solve all problems. Overestimating functionality and ease of use leads to disappointment and wasted investment.
Inaccurate estimations of time, costs, and effort
Underestimating time to introduce a tool, maintain test scripts, and change existing manual processes. Automation is expensive to build and maintain.
Underestimating time to introduce a tool, maintain test scripts, and change existing manual processes. Automation is expensive to build and maintain.
Using a test tool when manual testing is more appropriate
Not every test should be automated — exploratory testing, one-off checks, and tests requiring human judgment are often better done manually.
Not every test should be automated — exploratory testing, one-off checks, and tests requiring human judgment are often better done manually.
Relying on a tool too much — ignoring human critical thinking
Automation cannot replace tester judgment. Over-reliance means defects requiring creative analysis may be missed.
Automation cannot replace tester judgment. Over-reliance means defects requiring creative analysis may be missed.
Dependency on the tool vendor
Vendor may go out of business, retire the tool, sell to a different vendor, or provide poor support (slow responses to queries, no upgrades, defect fixes delayed).
Vendor may go out of business, retire the tool, sell to a different vendor, or provide poor support (slow responses to queries, no upgrades, defect fixes delayed).
Using open-source software that may be abandoned
Open-source tools may stop receiving updates, meaning no bug fixes or compatibility updates. Internal components may require frequent manual updates.
Open-source tools may stop receiving updates, meaning no bug fixes or compatibility updates. Internal components may require frequent manual updates.
Automation tool not compatible with the development platform
Tool may not support the language, framework, OS, or browser versions used in the project — causing integration failures.
Tool may not support the language, framework, OS, or browser versions used in the project — causing integration failures.
Choosing an unsuitable tool that does not comply with regulatory requirements or safety standards
In regulated industries (medical, finance, aviation), tools must meet specific compliance requirements. A non-compliant tool creates legal and safety risk.
In regulated industries (medical, finance, aviation), tools must meet specific compliance requirements. A non-compliant tool creates legal and safety risk.
Risks at a glance
🎯 Unrealistic expectations
🧮 Bad cost estimates
🔧 Automating the wrong tests
🤖 Over-reliance on tools
🏢 Vendor dependency
🌐 Open-source abandonment
💻 Platform incompatibility
⚖️ Regulatory non-compliance
Benefits vs Risks — full comparison
Side-by-side table
| ✅ Benefit | ⚠️ Corresponding risk |
|---|---|
| Saves time on repetitive manual work | Inaccurate estimates of effort to build & maintain automation |
| Greater consistency and repeatability | Over-reliance on tools — ignoring human critical thinking |
| More objective metrics and coverage | Unrealistic expectations about tool functionality |
| Faster test execution and time to market | Tool not compatible with the development platform |
| Better test reporting and information access | Vendor dependency — vendor goes out of business or stops support |
| Testers free for creative, deeper test design | Using automation where manual testing is more appropriate |
| — | Open-source tool abandoned — no further updates |
| — | Tool does not comply with regulatory/safety standards |
Important syllabus statement
"Simply acquiring a tool does not guarantee success. Each new tool will require effort to achieve real and lasting benefits — for tool introduction, maintenance and training."
This single statement is the foundation of the entire chapter. The exam will often test whether candidates understand that automation has a cost and cannot be treated as a magic solution.
When NOT to automate
- One-off tests that will never be repeated
- Tests requiring significant human judgment (exploratory, usability)
- When the system under test changes too frequently (high maintenance cost)
- When the benefit does not justify the setup and maintenance effort
- When manual testing is faster and equally effective
Exam tip: "Using a test tool when manual testing is more appropriate" is listed as a RISK in the syllabus — not a benefit. Automation is not always the right answer.
Key points & exam traps
Quick-recall: 6 benefits
| # | Benefit |
|---|---|
| 1 | Saves time by reducing repetitive manual work |
| 2 | Prevents simple human errors — greater consistency and repeatability |
| 3 | More objective assessment and measures too complicated for humans |
| 4 | Easier access to information for test management and reporting |
| 5 | Reduced test execution times → earlier detection, faster feedback, faster time to market |
| 6 | More time for testers to design new, deeper, more effective tests |
Quick-recall: 8 risks
| # | Risk |
|---|---|
| 1 | Unrealistic expectations about the benefits of a tool |
| 2 | Inaccurate estimations of time, costs, effort to introduce and maintain |
| 3 | Using a test tool when manual testing is more appropriate |
| 4 | Relying on a tool too much — ignoring human critical thinking |
| 5 | Dependency on the tool vendor (closure, tool retirement, poor support) |
| 6 | Open-source tool may be abandoned — no further updates |
| 7 | Automation tool not compatible with the development platform |
| 8 | Tool does not comply with regulatory requirements or safety standards |
9 tool types (FL-6.1.1)
| # | Tool type | Supports… |
|---|---|---|
| 1 | Test management | SDLC, requirements, tests, defects, configuration management |
| 2 | Static testing | Reviews and static analysis (no code execution) |
| 3 | Test design & implementation | Generating test cases, test data, test procedures |
| 4 | Test execution & coverage | Automated test execution and coverage measurement |
| 5 | Non-functional testing | Performance, load, security — difficult/impossible manually |
| 6 | DevOps | Delivery pipeline, workflow tracking, automated builds, CI/CD |
| 7 | Collaboration | Team communication and documentation |
| 8 | Scalability & deployment | VMs, containers — standardized test environments |
| 9 | Any other tool | Anything that assists in testing (even a spreadsheet) |
Common exam traps
Trap 1: "Acquiring a tool guarantees testing success" → FALSE — tool introduction requires effort, training, and maintenance.
Trap 2: "Test automation eliminates the need for manual testing" → FALSE — some tests are better done manually; over-reliance is a listed RISK.
Trap 3: "Open-source tools are always a safe choice" → FALSE — abandonment is a listed RISK.
Trap 4: "Using a tool when manual testing is better" → This is listed as a RISK, not a neutral decision.
Trap 5: "Automation always reduces costs" → Not necessarily — inaccurate cost/effort estimation is a listed RISK.
Trap 6: A spreadsheet — IS a test tool in the context of testing (syllabus explicitly states this).
Trap 2: "Test automation eliminates the need for manual testing" → FALSE — some tests are better done manually; over-reliance is a listed RISK.
Trap 3: "Open-source tools are always a safe choice" → FALSE — abandonment is a listed RISK.
Trap 4: "Using a tool when manual testing is better" → This is listed as a RISK, not a neutral decision.
Trap 5: "Automation always reduces costs" → Not necessarily — inaccurate cost/effort estimation is a listed RISK.
Trap 6: A spreadsheet — IS a test tool in the context of testing (syllabus explicitly states this).