NCT Tester Competence Assessment common mistakes
NCT Tester Competence Assessment · Understand the traps and how to avoid them.
Treating 'error', 'defect', and 'failure' as interchangeable in scenario questions, so a question that asks what the tester observed is answered with the word that describes the root cause instead of the observable deviation from expected behaviour.
Everyday speech uses these words loosely, and candidates memorise a single glossary sentence rather than mapping each term to a moment in the causal chain (human error → defect in a work product → failure during execution). Under time pressure they pick the most familiar word rather than the one matching the scenario's stage.
What to do instead
Before answering, locate the scenario on the chain: if a person made a wrong decision, it is an error; if the wrong decision is embedded in a document or code, it is a defect; if the system misbehaves while running, it is a failure. Practise with three-line scenarios and label each line explicitly, and note that a defect can exist for years without ever producing a failure.
Answering 'exhaustive testing is impossible' to any question that mentions completeness, including questions about exit criteria or when to stop testing, instead of applying the risk-based or coverage-based stopping rule the question actually describes.
The seven testing principles are learned as a list of slogans, so the first principle becomes a reflex answer. Candidates do not read what the question is really asking about - prioritisation, coverage thresholds, or agreed exit criteria - and default to the most quotable phrase.
What to do instead
For each principle, write one concrete decision it drives. Exhaustive testing drives prioritisation by risk and agreed coverage; defect clustering drives where to concentrate effort; the pesticide paradox drives test case refresh. When a question mentions stopping, look for the stated exit criteria or coverage target and answer with that, not the slogan.
Confusing the test levels with the test types: describing component testing as 'unit testing done by developers only', or labelling a system-level non-functional check as integration testing because two systems talk to each other.
Levels (component, integration, system, acceptance) are defined by the object under test and the phase, while types (functional, non-functional, structural, change-related) are defined by what you are looking for. The two dimensions overlap in real projects, and candidates collapse them into one ladder.
What to do instead
Use a two-axis grid: rows are levels, columns are types, and any cell can legitimately hold a test. Ask two separate questions of every scenario - what is the object under test (fixes the level) and what characteristic is being examined (fixes the type). A performance test at system level and a performance test at component level are both valid and different.
Assuming a review's formality is determined by the number of participants, or calling any meeting with the author present a walkthrough, rather than identifying the review type from its process characteristics such as defined roles, entry criteria, and recorded findings.
Textbook definitions of informal review, walkthrough, technical review, and inspection are memorised as a list, but exam scenarios describe process details, not labels. Candidates match on surface cues like 'meeting' or 'team' and ignore the deciding features.
What to do instead
Build a comparison table keyed on process features: presence of a moderator, defined roles, individual preparation, entry and exit criteria, formal recording, and follow-up. An inspection has all of them; a technical review has documented findings and peers but is less rigid; a walkthrough is author-led; an informal review has none of the formal apparatus. Classify by features, never by headcount.
Reading a control-flow question and reporting statement coverage when the question asked for decision coverage, or claiming 100% decision coverage implies 100% statement coverage without checking for decisions with no statements in the branch.
Coverage formulas are memorised as fractions but not tied to what counts as a testable item. Candidates also carry a half-remembered rule about one coverage subsuming another and apply it in the wrong direction or without the exception.
What to do instead
For every coverage question, first list the items to be covered (statements, decision outcomes, conditions) and count them explicitly. Remember decision coverage subsumes statement coverage in the usual case, but statement coverage does not guarantee decision coverage, and a decision whose branch contains no executable statement breaks the simple implication. Recompute from the item list rather than recalling a rule.
Applying equivalence partitioning and boundary value analysis to a field but forgetting to derive expected results for the invalid partitions, then being surprised that the 'number of test cases' answer is wrong.
Candidates practise with valid inputs, which feel natural, and treat invalid inputs as error handling rather than as required test conditions. The technique is remembered as 'pick one value from each class' without the complementary step of testing the boundaries and the invalid classes.
What to do instead
For each input, draw three regions: below the valid range, inside it, and above it. Take one representative from each partition and, for ordered data, the values at each boundary and its immediate neighbours (for example minimum−1, minimum, minimum+1, maximum−1, maximum, maximum+1). Count test cases from that table, and always state the expected result beside each one, including the expected rejection for invalid classes.
Producing a test estimate by summing the effort for every requirement equally, without adjusting for risk, complexity, or the uncertainty of unfamiliar areas, and presenting it as a single number.
Estimation is treated as arithmetic rather than judgement. Candidates want a defensible-looking figure and believe a single number reads as more professional than a range, so they skip the risk adjustment and the assumptions that make an estimate usable.
What to do instead
Estimate per risk item, not per requirement: high-risk, complex, or unfamiliar areas get a multiplier and a wider range. Present three-point estimates (optimistic, most likely, pessimistic) with stated assumptions and dependencies, and note what would change the number. In monitoring questions, tie progress back to those assumptions rather than to percentage of test cases executed alone.
Classifying every defect by severity and priority as if they always agree, so a crash on a rarely used screen is logged as high priority, or a cosmetic error on the login page is logged as low severity.
The two attributes feel like one judgement about 'how bad', and candidates have not internalised that severity is a technical impact judgement while priority is a business scheduling judgement made with stakeholders.
What to do instead
Ask two separate questions: how much does this harm the system or its users (severity), and how soon must it be fixed relative to other work (priority). Then practise the four combinations, especially high severity with low priority (a crash in a feature not yet launched) and low severity with high priority (a misspelling in the company name on the home page). State both explicitly in defect reports.
Assuming a test automation tool increases coverage or finds new defects by itself, or that record-and-playback scripts remain maintainable as the product changes, instead of recognising that tools execute designed checks and that scripts need the same design and maintenance discipline as code.
Tool questions invite enthusiasm, and vendor-style messaging about codeless automation shapes expectations. Candidates also underestimate maintenance cost because they have not seen a suite decay after several releases.
What to do instead
Frame every tool answer around what the tool does not do: it does not decide what to test, does not judge whether an unexpected result is acceptable, and does not remove the need for maintenance. For record-and-playback, expect brittleness against UI changes and prefer keyword-driven or data-driven structures with reusable components. When asked about tool selection, weigh integration, skills, and total cost of ownership, not feature count.
Reporting a defect in a way that assigns blame or omits the environment and reproduction steps, then defending the report when a developer cannot reproduce it, rather than treating the report as a communication artefact that must stand on its own.
Testers under pressure write for themselves as a reminder and for the moment of discovery, not for a reader who was not there. Frustration with rejected defects can also push tone toward accusation, which shifts the conversation from the product to the people.
What to do instead
Write every report so a stranger can reproduce it: exact build and environment, preconditions, numbered steps, expected versus actual result, evidence, and severity with justification. Describe the product's behaviour, never a person's competence. When a defect is disputed, restate the observed facts and ask a neutral question about expected behaviour rather than escalating the disagreement.