CSQE common mistakes
CSQE · Understand the traps and how to avoid them.
Answering questions about cost of quality by labelling every inspection, test cycle, and review as appraisal cost, without separating internal failure costs such as rework found before release.
Candidates memorise the four cost categories as a list and never practise sorting borderline activities; prevention and appraisal feel like the 'good' costs, so anything proactive gets dumped there, and rework discovered in-house is forgotten because it is invisible in the final product.
What to do instead
Build a two-axis sort: was the money spent to keep defects from happening (prevention), to find them (appraisal), or after one was found (failure)? Then ask whether the defect escaped to the customer. Drill with mixed lists of 20 activities until sorting is automatic.
Treating the software quality plan as a document written once at project start and then answering process questions as if plans are static artefacts.
The plan is often taught as a template-filling exercise, so candidates learn its table of contents but not its role as a living control document that is baselined, reviewed, and revised when scope or risk changes.
What to do instead
Learn the plan by its functions: what will be done, by whom, when, against which standards, and how conformance will be verified. Practise describing how a change in requirements triggers plan revision and re-baselining, and link each plan section to the process area it controls.
Confusing verification with validation when the stem describes reviewing requirements for completeness versus testing the delivered product against user needs.
The shorthand 'verification = are we building it right, validation = are we building the right thing' is memorised as a slogan, but candidates fail to apply it to concrete activities such as requirements reviews, traceability checks, and acceptance testing.
What to do instead
Classify activities by the question they answer: does this work product conform to its specification (verification) or does the product satisfy intended use (validation)? Sort a list of 15 activities, including static reviews and beta tests, and note that both can occur at every life-cycle phase.
Assuming a CMMI or process-maturity level equates to product quality, and choosing the highest maturity level as the answer whenever a scenario asks how to improve quality.
Maturity models are prominent in the body of knowledge and easy to recall as a ladder, so candidates substitute 'higher level' for actual causal reasoning about defect prevention, measurement, and process control.
What to do instead
Separate process capability from product outcomes. For each scenario, identify the specific quality problem (escape rate, review effectiveness, test coverage) and select the practice that addresses it; treat maturity level as context, not as an answer key.
Calculating defect density, defect removal efficiency, or yield using inconsistent denominators, such as mixing defects found in review with defects found in test, or counting duplicated defect records.
Metrics appear as simple formulas in study material, but exam items embed messy data: reopened defects, severity filters, and defects found after release. Candidates plug numbers into a remembered formula without deciding what belongs in the numerator and denominator.
What to do instead
Before computing, write down the unit of measure and the population being counted. Practise with items containing reopened and deferred defects, and state explicitly whether escaped defects are included. Check that numerator and denominator refer to the same scope and phase.
Selecting a sampling or inspection approach without considering the stated risk level, sample size, or defect-detection probability, and defaulting to 100 percent inspection whenever quality is emphasised.
Candidates associate more inspection with better quality and overlook that inspection effectiveness depends on preparation, rate, and inspector capability, and that sampling plans carry defined consumer and producer risk.
What to do instead
Learn the inputs that drive inspection design: defect severity, volume, historical escape rate, and cost of undetected failure. For sampling items, identify the acceptable quality level and lot tolerance, then reason about which risk the customer bears before choosing a plan.
Mixing up the roles of a quality assurance function and a testing function, answering that QA owns test execution or that testers own process audits.
In many organisations the titles are used loosely, so candidates import workplace habits instead of the body-of-knowledge distinction between process-oriented assurance and product-oriented verification.
What to do instead
Anchor each role to its output: QA produces process definitions, audits, and improvement actions; testing produces verification evidence about the product. For scenario items, ask whether the question is about how work is done or about the work product itself, then assign the role.
Ignoring the software configuration management and change-control angle when a scenario describes defects traced to uncontrolled changes, and instead answering with more testing.
Testing is the most familiar quality activity, so it becomes the default remedy; candidates miss that many defect-escape scenarios are caused by unmanaged baselines, parallel versions, or changes made without impact analysis.
What to do instead
For any scenario involving wrong versions, missing fixes, or regressions, first check configuration identification, baseline control, and change review. Practise mapping symptoms to control weaknesses before considering additional test coverage.
Answering risk-management items by ranking risks only on likelihood or only on impact, and skipping mitigation and contingency planning in the response.
Risk exposure as likelihood times impact is easy to state but candidates apply it incompletely under time pressure, and they treat risk identification as the end of the activity rather than the start of a planning cycle.
What to do instead
Use a fixed three-step habit: identify and score exposure, choose a response (avoid, mitigate, transfer, accept), then define the trigger and contingency. Work through scenarios where the highest-exposure risk is not the most likely one, and justify the chosen response.
Treating measurement and analysis as reporting whatever numbers the tool produces, rather than defining the question, the metric, and the decision the metric will drive.
Study material presents metrics as definitions to memorise, so candidates can recite formulas but cannot evaluate whether a proposed metric is valid, actionable, or prone to gaming in a given scenario.
What to do instead
For every metric, state the decision it informs, its data source, its known biases, and its interpretation limits. Practise critiquing proposed measures such as lines of code or defect counts per tester, and propose a balanced set tied to the stated quality goal.