BCS-O common mistakes
BCS-O · Understand the traps and how to avoid them.
Treating 'error', 'defect', and 'failure' as interchangeable when answering terminology questions, for example calling a wrong line of code a failure.
Everyday speech uses these words loosely, and candidates memorize the three terms as a list without mapping each to a point in the causal chain (human error, then defect in a work product, then failure as deviation of delivered behavior from expected behavior).
What to do instead
Draw the chain once: a person makes an error, which introduces a defect into an artifact, which may cause a failure when executed. For each practice question, locate the described event on that chain before reading the options, and reject any option that uses the wrong link.
Listing test levels (component, integration, system, acceptance) and test types (functional, non-functional, structural, change-related) as if they were the same taxonomy, so answers pair 'functional testing' with 'system testing level'.
Both sets of terms appear together in study material, and candidates sort them by memory order rather than by the two different questions they answer: where in development versus what characteristic is examined.
What to do instead
Keep two separate mental tables. Levels answer 'when and on what object'; types answer 'what quality attribute or technique'. Practice classifying each activity twice, once by level and once by type, and note that any type can occur at any level.
Confusing verification with validation, for example saying reviews of requirements are validation because they involve users.
The words sound alike, and candidates fix on who performs the activity instead of what is being checked: conformance to specified requirements versus fitness for intended use in the operational context.
What to do instead
Anchor on the classic question pair: verification asks whether we built the product right against its specification; validation asks whether we built the right product for user needs. For each scenario, ask which document or expectation the activity compares against.
Applying the seven testing principles mechanically, such as claiming exhaustive testing is achievable for small systems or that testing can prove the absence of defects.
Principles are memorized as slogans, and distractors are written as plausible-sounding absolutes that candidates accept because they recognize the vocabulary rather than the logical claim.
What to do instead
For each principle, write one sentence stating what it rules out (for example, 'absence-of-errors fallacy rules out equating bug-free with successful'). Scan answer options for absolute words like 'prove', 'all', 'complete', and test them against those sentences.
Mixing up the test process activities and their outputs, for example naming 'test analysis' when the scenario describes deriving concrete test cases with preconditions and expected results.
Analysis, design, implementation, and execution are described in similar language, and candidates match on keywords like 'identify' without checking whether the output is a condition, a case, a procedure, or a result log.
What to do instead
Memorize the output of each phase: analysis yields test conditions; design yields test cases and coverage items; implementation yields procedures and suites; execution yields actual results and incident reports. Classify the artifact named in the question first, then choose the activity.
Treating the test plan and the test strategy as one document, or assigning ownership of the strategy to the test manager of a single project.
Both describe approach and scope, so candidates default to whichever term appears in the scenario without considering organizational versus project scope and long-term versus project-specific applicability.
What to do instead
Separate by scope and lifetime: the strategy is organization-level, generic, and reused across projects; the plan is project-specific, with schedule, resources, and entry/exit criteria. When a scenario mentions a single release or budget, the answer is the plan.
Confusing the roles and duties of the test manager and the tester, for example assigning test design or incident analysis to the manager in an answer.
Job titles vary across employers, so candidates import assumptions from their own workplace instead of using the exam's task breakdown of planning and control versus analysis, design, and execution.
What to do instead
Learn the task lists as two columns and check the verb in the question: planning, monitoring, and control belong to the manager; analyzing, designing, implementing, and executing belong to the tester. Answer from the syllabus split, not from personal job experience.
Choosing a black-box technique that does not fit the stated input model, such as selecting equivalence partitioning for a scenario describing combinations of conditions and their interactions.
Candidates recall technique names but not the trigger conditions, so they pick by familiarity; decision tables, state transition testing, and boundary value analysis are especially prone to being swapped.
What to do instead
Build a trigger-to-technique map: partitions of equivalent data for equivalence partitioning, edges of ordered ranges for boundary value analysis, combinations of conditions with actions for decision tables, and sequences of events for state transition. Read the scenario for the noun that matches the map before answering.
Miscomputing coverage or test counts from a given model, for example counting boundary values as one per range or forgetting invalid partitions and their boundaries.
Candidates know the definition but skip the systematic enumeration under time pressure, and they overlook that each boundary typically needs a value on, just below, and just above the edge, plus values for invalid ranges.
What to do instead
Use a written procedure: list partitions, mark valid and invalid, then for each ordered partition take the minimum, maximum, and their immediate neighbors. For decision tables, count rule columns before collapsing. Recheck the arithmetic once before selecting an option.
Selecting the wrong review type for a scenario, for example calling a formal, documented, multi-role inspection a walkthrough, or omitting that a technical review is peer-led and documented.
The review types differ along several axes at once (formality, documentation, individual versus team examination, defined process roles), and candidates compare on only one axis such as 'meeting held'.
What to do instead
Compare the types in a small matrix with columns for formality, documentation, individual versus team, and defined roles. Inspections are the most formal with defined roles and entry criteria; walkthroughs are author-led learning sessions; technical reviews are documented peer reviews; informal reviews have no defined process.