PASC common mistakes
PASC · Understand the traps and how to avoid them.
Treating a vague stakeholder wish ("the system should be fast and user-friendly") as a complete requirement and moving straight to design without eliciting measurable acceptance criteria.
Candidates memorize requirement 'types' but never practice converting informal statements into verifiable ones, so they pattern-match on the word 'requirement' and accept anything that sounds like a need.
What to do instead
For every requirement, force yourself to write the test that would prove it satisfied: a numeric threshold, a named condition, and a pass/fail check. If you cannot write that sentence, the requirement is not yet complete.
Confusing functional requirements with non-functional ones, or classifying a quality attribute (availability, response time, security) as a functional behavior.
Study material often lists NFR categories abstractly, and candidates never drill on borderline cases like 'the system shall log every login' (functional behavior) versus 'logs shall be retained 90 days' (quality/constraint).
What to do instead
Apply the test: does it describe what the system does (function) or how well/under what limits it does it (quality attribute or constraint)? Practice sorting 30 mixed statements until the classification is automatic.
Choosing an architectural style or pattern by name recognition ('microservices are modern') rather than by matching documented quality-attribute trade-offs to the stated drivers.
Pattern catalogs are memorized as definitions with pros/cons lists, so candidates recall the label but skip the step of tying the choice to specific scenarios and constraints in the prompt.
What to do instead
Before selecting a style, write the top two or three quality scenarios and the binding constraints, then justify the choice and the rejected alternative in one sentence each. If you cannot name what you gave up, you have not done the trade-off analysis.
Producing a design that violates its own stated principles, e.g., describing a 'loosely coupled' design in which the UI layer directly queries the database schema or one module reaches into another's internals.
Candidates recite definitions of cohesion and coupling but do not trace data and control flow through their own proposed structure, so contradictions slip past.
What to do instead
After drafting a design, trace one representative use case end to end and list every dependency it crosses. Flag any cross-layer or cross-module access that bypasses the stated interface, then revise.
Writing code in an exam answer that ignores the stated interface contract, error handling, or boundary conditions, and answers only the happy path.
Time pressure and habit push candidates to demonstrate the core algorithm and stop, treating edge cases as optional detail rather than part of correctness.
What to do instead
Adopt a fixed checklist for every construction answer: inputs validated, failure returns or exceptions specified, empty/single/maximum cases addressed, and resources released. Apply it even to pseudocode.
Confusing the levels and types of testing, e.g., labeling an integration check as unit testing, or claiming a code review substitutes for dynamic testing of runtime behavior.
Definitions are learned in isolation without a model of what each level can and cannot detect, so candidates assign tests to the wrong level or overstate static technique coverage.
What to do instead
Build a two-column table: test level or technique, and the class of defect it can reveal. Answer by locating the defect class first, then naming the level or technique that targets it.
Designing test cases that only confirm expected behavior, with no negative cases, boundary values, or explicit expected results, then declaring coverage adequate.
Candidates equate 'I wrote tests' with 'I tested it' and rarely practice deriving cases from a specification using equivalence partitioning and boundary analysis.
What to do instead
For each input or condition, enumerate valid, invalid, and boundary values before writing any case, and state the expected result for each. If a case has no expected result, it is not a test.
Treating configuration management as file storage: describing version control without baselines, change control, or build reproducibility, and hand-waving how a release is reconstructed.
Candidates conflate 'using Git' with configuration management and have not internalized the distinction between versioning, baselining, and release identification.
What to do instead
For any CM question, answer across four items: identification of configuration items, version control, baseline and change control, and the ability to rebuild a released configuration exactly. Missing any item is an incomplete answer.
Answering estimation and scheduling questions with a single-point estimate and no stated assumptions, dependencies, or risk buffer.
Candidates want to show confidence and a number, so they skip the uncertainty reasoning that the question is actually testing.
What to do instead
Give a range with the basis for it (analogy, historical data, decomposition), list the top assumptions and dependencies, and state how contingency is derived. An estimate without assumptions is a guess.
Describing maintenance as 'fixing bugs' only, omitting adaptive, perfective, and preventive change, and ignoring regression risk and the need to re-verify after modification.
The word 'maintenance' colloquially means repair, so candidates default to corrective work and forget the lifecycle and impact-analysis dimension.
What to do instead
For any maintenance scenario, classify the change into corrective, adaptive, perfective, or preventive, then state the impact analysis and regression testing required. Answer both the 'what kind' and 'what must be re-verified' parts.
Resolving an ethics scenario purely by what is legal or what the client asked, without naming the professional obligation, the affected parties, and the escalation path.
Candidates treat ethics items as opinion questions and answer with a verdict instead of applying a code-of-ethics framework and identifying the correct professional action.
What to do instead
Structure every ethics answer in four steps: identify the conflicting obligations, name the public-interest and competence duties, state who is harmed, and specify the escalation or disclosure action. Conclude with the action, not a moral judgment.