Medium ISTQB Interview Questions

In v4.0 the old 'pesticide paradox' was renamed 'tests wear out'. If the same tests are repeated many times, they become less effective at finding new defects because the code they exercise has already been fixed. Testers should modify existing tests and test data and write new tests. The exception is automated regression testing, where repeating the same tests is valuable because the goal is to confirm nothing has broken.

Test analysis answers 'what to test': it analyses the test basis, identifies testable features, defines and prioritises test conditions, and evaluates the test basis for defects. Test design answers 'how to test': it turns test conditions into test cases, identifies coverage items, defines test data requirements and designs the test environment. Example: the condition 'login with a locked account' becomes, in design, a case with exact inputs and the expected error message.

Testware is any work product created during the test process. Examples: test plan and risk register from planning; progress reports and control directives from monitoring and control; prioritised test conditions from analysis; test cases, test charters and coverage items from design; test procedures, automated scripts, test suites and test data from implementation; test logs and defect reports from execution; and the test completion report with lessons learned from completion.

Traceability links test basis items such as requirements, risks and user stories to test conditions, test cases, results and defects. It lets teams measure coverage, assess the impact of changes, support audits in regulated domains and report progress in business terms, for example 'requirement R12 has three passed tests and one open defect'. When a requirement changes, traceability shows exactly which tests must be updated or re-run.

v4.0 describes roles, not job titles. The test management role owns the test process, the test team and leadership of test activities, mainly planning, monitoring and control, and completion. The testing role owns the engineering side: test analysis, design, implementation and execution. One person can hold both roles, and in Agile teams some management tasks are done by the team while cross-team coordination may sit with a test manager.

Testing is a form of quality control (QC): a product-oriented, corrective approach that checks work products. Quality assurance (QA) is process-oriented and preventive: it improves processes on the idea that a good process produces a good product. Test results are used by both. QC uses them to fix defects, and QA uses them as feedback on how well the development and test processes are performing.

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

This points to the 'tests wear out' principle. I would review the suite against recent changes and defect data, refresh test data and steps, add tests for new features and risky areas, and run exploratory sessions to find new kinds of defects. Stable regression checks are still worth keeping and automating, because their job is to confirm unchanged areas still work, not to discover new defects.

Read the test basis and list testable aspects. Conditions: a transfer within the limit succeeds; a transfer of exactly 50,000 succeeds; a transfer above 50,000 is rejected with a clear message; several transfers in one day are added together against the limit; the limit resets the next day; zero or negative amounts are rejected. Prioritise them by risk, then design test cases with exact amounts using boundary value analysis.

Collect the failure details and logs, reproduce the issue and identify the defect. Then ask 'why' repeatedly until you reach a process cause. Example: a wrong discount was shown; why? the code used an old rule; why? the requirement changed without notice; why? there was no change review step. Action: add change notifications and a review step. Fixing root causes prevents whole families of similar defects.

Situation: while testing our final-year e-commerce project, I found checkout accepted expired coupon codes. Task: report it clearly before the demo. Action: I reproduced it three times and logged clear steps, expected and actual results, screenshots and the coupon data, and marked severity high because it meant revenue loss. Result: the developer fixed it within a day, and I added a regression test for coupon expiry.

Situation: a developer marked my defect 'works as designed'. Task: resolve it without conflict. Action: I re-read the user story, attached the acceptance criteria that contradicted the behaviour, and discussed it calmly with the developer and product owner, focusing on user impact rather than blame. Result: the product owner confirmed it was a defect, and we clarified the story wording so similar confusion did not happen again.

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.

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.

DevOps joins development and operations through a CI/CD pipeline. Benefits for testing: fast feedback on code quality, shift-left through automated component tests and static analysis on every commit, stable environments through automation, more visibility of non-functional qualities and less repetitive manual work. Risks: the pipeline must be defined and maintained, CI/CD tools must be set up, and automation needs extra resources. Manual testing from the user's perspective is still needed.

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.

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.

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.

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.

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.

Situation: our releases had many defects traced to unclear requirements. Task: reduce them without slowing delivery. Action: I showed data that about 40 percent of defects started in requirements, piloted requirement reviews and three-amigos sessions in one team, and tracked the results. Result: requirement-related defects dropped by roughly half over two releases, and other teams adopted the practice.

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.

Requirements defects such as inconsistencies, ambiguities, contradictions, omissions and duplicates; design defects like inefficient database structures or poor modularisation; coding defects such as variables with undefined values, unreachable or duplicated code and excessive complexity; deviations from standards; incorrect interface specifications; security vulnerabilities like buffer overflows; and gaps in test coverage, such as missing tests for an acceptance criterion.

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.

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.

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.

Reviewers log anomalies: observations that differ from what they expected. Not every anomaly is a defect; some turn out to be misunderstandings, open questions or improvement suggestions. During communication and analysis the team decides each anomaly's status, owner and required action, and confirmed ones become defects for the author to fix. This keeps reviews constructive instead of treating every comment as the author's mistake.

I would log these as anomalies in a review because they are not testable. I would ask stakeholders for measurable criteria, for example 'search results appear within 2 seconds for 95 percent of requests at 1,000 concurrent users' and 'a new user completes registration in under three minutes without help'. Testable requirements make test design, acceptance and sign-off objective and prevent disputes later.

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.

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.

Plan: define scope, objective and exit criteria and choose reviewers with the right expertise. Initiate: share the document, checklist and timeline. Individual review: each reviewer logs anomalies in a shared tool. Communication and analysis: the moderator runs the meeting, the team discusses anomalies and agrees actions. Fixing and reporting: the author updates the document, defects are tracked, and results are checked against exit criteria.

Situation: reviewing a refund user story, I noticed it did not say how partial refunds work on discounted orders. Task: clarify it before development started. Action: I logged the gap, set up a 15-minute call with the product owner and developer, and we added three acceptance criteria with worked examples. Result: the feature shipped without the refund calculation errors that had hurt an earlier release.

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.

BVA applies to ordered partitions. In 2-value BVA each boundary has two coverage items: the boundary value and its closest neighbour in the adjacent partition. In 3-value BVA there are three: the boundary and both neighbours. For a valid range 18 to 60, 2-value gives 17, 18, 60, 61, and 3-value gives 17, 18, 19, 59, 60, 61. 3-value is stricter and can catch defects like 'x == 18' written instead of 'x >= 18'.

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.

In 3-value BVA, each boundary gives the boundary value plus both neighbours. Lower boundary 5 gives 4, 5 and 6. Upper boundary 15 gives 14, 15 and 16. So the six values are 4, 5, 6, 14, 15 and 16. Compared with 2-value BVA (4, 5, 15, 16), the extra values 6 and 14 help detect mistakes in comparison operators inside the range.

Each Choice coverage needs every partition from each input used at least once, and one test can cover one partition of each input at the same time. So the minimum equals the largest number of partitions: 3. Example tests: card with new, UPI with existing, wallet with new. Covering all combinations would need 3 x 2 = 6 tests, which is not required for Each Choice.

Valid partitions: 0-39, 40-59 and 60-100, plus two invalid partitions: below 0 and above 100, so 5 partitions. Boundaries in 2-value BVA: -1, 0, 39, 40, 59, 60, 100 and 101, which is 8 values. Five tests give 100 percent EP coverage, and eight tests give 100 percent 2-value boundary coverage. Note that output partitions like fail, pass and distinction also guide the partitioning.

Partitions: 0 or less is invalid, 1 to 498 pays 40, and 499 or more ships free. EP tests: 0 rejected, 250 pays 40, 800 free. 2-value BVA adds 0 and 1 at the lower edge and 498 and 499 at the free shipping boundary. Combined minimal set: 0, 1, 250, 498, 499 and 800, each with the expected fee clearly stated.

When conditions are not Boolean, multiply the number of values of each condition. Customer type has 3 values and the order condition has 2, so the full table has 3 x 2 = 6 rules. Each rule becomes one test case for 100 percent decision table coverage. If, for example, platinum always gets the same discount regardless of amount, those two columns can be merged, giving 5.

State transition testing fits because behaviour depends on the current state and events. I would draw the diagram, for example placed to shipped, shipped to delivered, placed to cancelled, delivered to returned, and build a state table. Tests cover every valid transition and attempt invalid ones, such as cancelling a delivered order or returning an undelivered one, checking the system rejects them correctly.

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.

Situation: I was testing a scholarship form where students aged 17 to 25 were eligible. Task: design efficient tests for the age rule. Action: I applied boundary value analysis and tested 16, 17, 25 and 26. Result: 25 was wrongly rejected because the code used 'less than 25'. The developer fixed it, and I shared the BVA checklist with the team so others used it too.

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.

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.

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.

User stories are written collaboratively by business, development and testing. The 3 Cs are Card (the medium describing the story), Conversation (how the story will be used, documented or verbal) and Confirmation (the acceptance criteria). A good story follows INVEST: Independent, Negotiable, Valuable, Estimable, Small and Testable. If stakeholders cannot say how to test a story, it is probably unclear or does not reflect real value.

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.

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.

Coverage shows which code was executed, not that the code is correct or complete. The defect may come from a missing requirement that was never coded, which white-box testing cannot detect; from specific data values not used in tests; from integration or environment issues; or from wrong expected results. Coverage is a useful measure of thoroughness, but it must be combined with black-box and experience-based techniques.

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.

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.

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.

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.

In release planning, testers help write testable user stories and acceptance criteria, take part in product and quality risk analyses, estimate test effort for stories, define the test approach and plan release testing. In iteration planning, they join detailed risk analysis of stories, check testability, break stories into testing tasks, estimate testing effort and identify the functional and non-functional aspects to test.

Estimation based on ratios uses historical figures, such as a development-to-test effort ratio. Extrapolation uses measurements from the current project, for example averaging the last three iterations. Wideband Delphi is an expert-based technique where experts estimate separately and iterate until consensus; Planning Poker is an Agile variant. Three-point estimation uses optimistic, most likely and pessimistic values to calculate a weighted estimate and its standard deviation.

Risk-based prioritisation orders tests by the results of risk analysis, running tests for the highest risks first. Coverage-based prioritisation orders by coverage, running tests that achieve the most coverage first; additional coverage prioritisation picks each next test by the extra coverage it adds. Requirements-based prioritisation follows the priorities of requirements set by stakeholders. Dependencies can force a lower-priority test to run first.

Test monitoring gathers information about testing to check progress and whether exit criteria are met, using metrics like test case progress, defect counts, coverage and cost. Test control uses that information to give guidance and corrective actions, such as reprioritising tests or changing the schedule. Test completion collects data from finished activities to consolidate experience, testware and other information, usually at milestones like release or end of iteration.

A test progress report is produced regularly during testing, for example daily or per sprint. It covers the period, progress against plan, impediments, metrics, new or changed risks and planned work. A test completion report is prepared at the end of a test level, iteration or project. It summarises testing, evaluates quality against the plan, lists deviations, unmitigated risks, open defects, metrics and lessons learned.

Score each risk for likelihood and impact on a scale such as 1 to 5, and multiply to get the risk level. Example: wrong interest calculation, likelihood 3 and impact 5, level 15; slow report export, likelihood 4 and impact 2, level 8; spelling errors, 4 and 1, level 4. Test the highest levels first and most deeply, using more rigorous techniques and earlier test execution.

The suite looks like an inverted test pyramid. I would push checks down: move business logic checks to unit tests, cover service rules with API tests, and keep only a small set of end-to-end UI tests for critical user journeys. I would also run tests in parallel and split suites into a fast smoke stage and a fuller nightly run. Feedback becomes faster and tests less flaky.

I focus on decisions they need to make. I use a short dashboard: overall status in plain words, coverage of key requirements, open critical defects and their business impact, top risks with mitigation, and what is needed from them. I avoid jargon, use simple charts and trends, and keep detailed data available for anyone who wants it. Different audiences may need different levels of detail.

Situation: a regulatory change had to go live in five days. Task: test it without missing critical risks. Action: I ran a quick risk analysis with the product owner, focused on calculation rules and reports, automated repetitive data checks, and gave daily status updates. Result: we released on time with no production defects in high-risk areas, and lower-risk cosmetic issues were fixed in the next sprint.

A false positive is a test result that reports a defect when none exists, for example a test failing because of wrong test data or an unstable environment. A false negative is a test that passes even though a defect is present, so the defect is missed. False positives waste time and reduce trust in tests; false negatives are more dangerous because defects escape to production.

Configuration management identifies, controls and tracks work products such as test plans, test cases, scripts, test results, test data, environments and the test object itself. It ensures all configuration items are uniquely identified, version controlled, tracked for changes and related to each other so traceability is kept. Baselines can only be changed through formal change control. This lets testers know exactly which build and testware versions were tested.

A failure can be caused by the test itself or the environment, not the test object. Common causes include wrong expected results, outdated test data, incorrect test scripts, misconfigured environments, network issues or unavailable third-party services. CTFL v4.0 therefore talks about anomalies, which are analysed before being reported as defects. Logging every failure as a defect without analysis creates false positives and wastes developer time.

I would re-check that I can reproduce it, then add missing details: exact build version, environment, browser or device, user role, test data, timestamps, logs and a screen recording. I would check whether it is intermittent and note the frequency. If needed, I would reproduce it live with the developer. If it truly cannot be reproduced, we can keep it open with monitoring rather than close it.

High severity, low priority: the app crashes when exporting a report in a legacy format that almost nobody uses; the impact is severe but rarely triggered, so it can wait. Low severity, high priority: the company logo is misspelled on the home page before a major launch; functionality is unaffected, but brand impact makes it urgent. Severity reflects impact, priority reflects business urgency.

I would set up a short daily triage to merge duplicates and link them to one master defect. Testers should search existing defects by module and keywords before logging, and use clear titles in a standard format such as 'Module - action - result'. Defined components and labels make searching easier. Tracking duplicate rates also shows whether the guidance is working.

These failures are caused by the environment, not the test object, so they should not be logged as product defects. I would raise one environment issue with the infrastructure team, mark the test results as blocked or environment failure, and re-run after the certificate is renewed. I would also suggest monitoring certificate expiry so the same false positives do not recur.

Possible causes include a code merge that overwrote the fix, a fix made only in one branch, or a deployment of an older artefact. I would re-open the defect with evidence and the build numbers, ask the team to check version control history, and add an automated regression test for the defect so it is caught immediately if it returns again.

Defect density = defects / size = 45 / 15 KLOC = 3 defects per KLOC. If other modules average 1 defect per KLOC, this module is a defect cluster, so I would increase test depth there, ask for a code review or refactoring, and add more regression tests. Compare density only across similar code, because language and complexity affect the numbers.

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.

Situation: before a release, my manager wanted a payment defect marked minor. Task: stay honest without creating conflict. Action: I explained the actual impact with data, how often it occurred and affected users, and suggested keeping severity accurate while lowering priority if the business accepted the risk, with a workaround documented. Result: the manager agreed, and the risk was recorded transparently.

Automation saves time by reducing repetitive manual work such as regression runs, comparisons and data entry. It prevents simple human errors through greater consistency and repeatability. It gives more objective assessment, such as coverage, and access to measurements too complex for humans. It reduces test execution times, giving faster feedback and earlier defect detection, and frees testers to design new and deeper tests.

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.

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.

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.

Re-read the stem for keywords such as 'most likely', 'best', 'first' or 'not'. Compare both options strictly against the syllabus wording, not your company's practice. Often one option is partly true or too absolute, using words like 'always' or 'guarantees'. Choose the option that fully matches the syllabus definition. Practising official sample exams builds this habit.

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.

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.

Read the instruction carefully, because you must select exactly two options and usually get the point only if both are correct. Evaluate each option separately as true or false against the syllabus. Eliminate absolute statements and options that describe a different concept. If you are sure of one, compare the remaining options carefully. These questions appear in the exam, so practise them in sample papers.

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.

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.

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.

Situation: test cases lived in spreadsheets and traceability was poor. Task: introduce a test management tool. Action: I compared options with the team, ran a two-week pilot on one module, migrated priority test cases, built simple dashboards and ran short training sessions. Result: the team adopted it within a month, and release reports that took a day now took an hour.