Ruankao Software Evaluator (Intermediate) common mistakes
Ruankao Software Evaluator (Intermediate) · Understand the traps and how to avoid them.
When asked to compute cyclomatic complexity or a minimum test-case count from a control-flow description, the candidate counts decision diamonds but forgets that the formula V(G) = E − N + 2 also counts the connected-component structure, then reports a number one or two too low when the flow graph has a single entry and exit.
The candidate memorized only the shortcut 'number of predicates + 1' and applies it mechanically even when the flow graph has multiple exit nodes or when the question gives edge and node counts instead of predicates. Under time pressure the shortcut feels safer than redrawing the graph, so the mismatch between the two formulas goes unnoticed.
What to do instead
For every complexity question, redraw the flow graph on scratch paper, label nodes and edges, and compute V(G) three ways: E − N + 2, predicates + 1, and enclosed regions. If the three disagree, the graph is wrong, not the formula. Practice on graphs with multiple exits and nested loops until the three methods converge in under two minutes.
On questions distinguishing verification from validation, or black-box from white-box, the candidate answers from the wording of the option that sounds most rigorous ('thorough code review') rather than mapping the activity to the question's actual axis (are we building the product right vs. are we building the right product; specification-based vs. structure-based).
These paired terms are taught as slogans, so candidates store them as moral judgments (review = good, testing = good) instead of as orthogonal dimensions. Exam distractors are written to reward exactly that intuition, offering plausible-sounding activities on the wrong axis.
What to do instead
Build a two-column table for each pair with a mandatory example on each side drawn from your own project. For verification/validation, anchor on 'specification conformance' vs. 'user need satisfaction'. For black/white/grey box, anchor on 'source of test basis' (requirements, code structure, or both). Answer by locating the activity in the table, not by tone.
When a scenario describes a team following a V-model or iterative process, the candidate assigns test levels to phases by name order (unit, integration, system, acceptance) instead of by the work product each level consumes, so they place integration testing after system testing or claim acceptance testing is performed by developers.
The four levels are memorized as a list, and the V-model's left-right symmetry is recalled as a picture rather than as a mapping from design documents to test bases. Scenario questions deliberately describe non-textbook orderings, which breaks list-order recall.
What to do instead
Memorize each level by its test basis and its responsible party: unit (detailed design, developer), integration (architecture/interface design, developer or independent tester), system (requirements specification, independent test team), acceptance (user needs/contract, customer or user). For any scenario, first identify the document or artifact mentioned, then derive the level from it.
On equivalence partitioning and boundary value questions, the candidate partitions inputs by the obvious valid range but omits invalid partitions entirely, or lists boundary values without stating whether each is inside or outside the range, producing a case count that is off by the number of invalid classes.
Textbook examples emphasize valid partitions because they generate the 'interesting' test cases, and candidates under exam pressure reproduce the example rather than the method. The instruction to 'design test cases for the field' is read as 'test the happy path', so robustness cases never get generated.
What to do instead
Adopt a fixed worksheet: for each input, list valid partitions, then invalid partitions (too low, too high, wrong type, empty, null), then boundaries at min−1, min, min+1, max−1, max, max+1. Count cases from the worksheet, not from memory. Train until you automatically produce both valid and invalid rows for every input variable.
When asked to select the technique for a scenario, the candidate picks decision-table testing for any rule-heavy description even when the rules involve timing, state transitions, or combinations across many parameters, where state transition or pairwise testing is the better fit.
Decision tables are the most visually memorable technique, so they become the default answer for 'business rules'. Distractor options are crafted around exactly this overgeneralization, and the scenario's key cue (order dependence, or a large parameter matrix) is buried in a subordinate clause.
What to do instead
Before answering, extract the scenario's structural cue: order/sequence dependence → state transition; many independent parameters with few interactions → pairwise/orthogonal array; combinations of conditions with actions → decision table; arithmetic ranges → boundary value. Write the cue next to each technique on a one-page decision map and drill scenario-to-technique matching separately from case design.
On questions about when regression testing is required, the candidate answers 'after any code change' without distinguishing change-impacting modifications from cosmetic ones, or claims full regression is always mandatory, missing the risk-based selection of a regression test set.
Regression testing is taught with the slogan 'rerun everything after changes', which is a safe practice but not the exam's point. The exam tests whether the candidate can reason about impact analysis and test selection, and the absolute-sounding option is usually the distractor.
What to do instead
Frame regression testing as impact-driven: identify changed modules, trace dependencies, select the regression suite by risk and coupling, and reserve full regression for high-risk or release-gate changes. Learn to recognize the trap of absolute quantifiers ('always', 'all', 'never') in options and prefer the option describing selection criteria.
On defect management questions, the candidate conflates defect severity with priority, assigning high severity to any bug that blocks their own work, or marking a cosmetic typo as low priority when the scenario says it appears on the login page of a regulated product where it is release-blocking.
In day-to-day work, severity and priority are often collapsed into one field by tooling defaults, so the candidate has no lived experience of the two-axis distinction. Exam scenarios deliberately decouple them (high severity/low priority, low severity/high priority) to test the concept.
What to do instead
Memorize the two definitions as independent axes: severity = degree of impact on the system (data loss, crash, functional failure, cosmetic); priority = urgency of the fix given business context (release blocker, next sprint, backlog). For each scenario, state the impact first, then the business urgency, and only then choose the option that matches both.
On test automation questions, the candidate recommends automating every manual test case to maximize ROI, or selects a record-and-playback tool for a suite that must run across three browsers and two OS versions, ignoring maintenance cost and portability.
Automation is framed in study material as an efficiency win, so candidates equate more automation with a better answer. The exam tests the criteria for what should be automated (stable, repetitive, high-volume, data-driven) and tool fit, not enthusiasm.
What to do instead
Learn the automation suitability checklist: stable requirements, repeatable execution, high run frequency, deterministic outcomes, and measurable ROI after maintenance. Reject options that automate exploratory, one-off, or rapidly changing tests. For tool selection, match against the stated constraints (browser matrix, CI integration, scripting skill of the team) before choosing.
On performance and load testing questions, the candidate treats load, stress, spike, and endurance testing as synonyms, or answers that the goal of stress testing is to confirm the system meets its SLA under normal load, missing that stress testing probes behavior beyond design limits and identifies the breaking point.
The four types share tooling and metrics, so they blur together in memory. Exam items describe a scenario (sudden traffic surge, sustained 24-hour run, gradual ramp beyond capacity) and expect the candidate to name the type from the load profile, which requires distinguishing them by profile, not by tool.
What to do instead
Map each type to a load profile and a question: load = expected peak, does it meet SLA; stress = beyond capacity, where does it break and how does it fail; spike = sudden surge, does it recover; endurance/soak = sustained duration, are there leaks or degradation. Memorize the profile shapes and answer by matching the described profile to the type.
On security and reliability questions, the candidate answers with generic advice ('use encryption', 'validate input') instead of naming the specific control or failure mode the scenario implies, such as missing authorization checks on an object reference, or absence of a heartbeat/failover mechanism in a reliability scenario.
Security and reliability content is broad and often studied at the level of principles rather than named controls, so recall defaults to platitudes. The exam rewards specific terminology (broken access control, injection, failover, MTBF/MTTR, redundancy) because that is what distinguishes a competent evaluator.
What to do instead
Build a control-to-threat table: each common weakness (injection, broken authentication, sensitive data exposure, missing function-level access control) paired with its specific mitigation and test method. For reliability, memorize the metric definitions (MTBF, MTTR, availability = MTBF/(MTBF+MTTR)) and the mechanisms (redundancy, failover, graceful degradation). Answer by naming the control, not the principle.
On software quality standards questions, the candidate attributes characteristics to the wrong model, for example listing 'maintainability' as a process attribute of CMMI rather than a product quality characteristic of ISO/IEC 25010, or confusing ISO/IEC 25010 product quality with ISO/IEC 25020 measurement concepts.
Multiple standards use overlapping vocabulary (quality, process, measurement), and candidates study them as isolated lists without a map of which standard defines what. Distractors exploit the vocabulary overlap, and the candidate recognizes the word but not the owning document.
What to do instead
Create a one-page standards map: ISO/IEC 25010 (product quality model: functional suitability, performance efficiency, compatibility, usability, reliability, security, maintainability, portability); ISO/IEC 25020 (quality measurement); ISO/IEC 12207 (software life-cycle processes); CMMI (process maturity). For each exam item, identify the subject (product vs. process vs. measurement) first, then select the standard.
On the professional English section, the candidate skips or rushes the English items because they assume the technical content is the same as the Chinese items, and loses points on reading-comprehension questions that hinge on a single modal verb ('shall' vs. 'should') or a negation in a requirements sentence.
The English section is treated as a translation formality rather than a distinct skill area. In standards and requirements text, modality and negation carry the normative meaning, so a candidate who reads for gist rather than for the exact operator misjudges the obligation level.
What to do instead
Practice reading short standards-style passages and identify the normative keyword in each sentence: shall (mandatory), should (recommended), may (permitted), shall not (prohibited). For each English item, underline the modal or negation before choosing an answer, and treat 'which statement is NOT correct' items with an explicit check of every option against the passage.