Ruankao Software Evaluator (Intermediate) cheat sheet

Number systems: binary 0-1, octal 0-7, hexadecimal 0-9/A-F. Convert by grouping 4 bits per hex digit and 3 bits per octal digit; 1 KiB = 2^10 = 1024 bytes.

Two's complement: invert all bits and add 1 to negate. An n-bit signed range is -2^(n-1) to 2^(n-1)-1; 8 bits gives -128 to 127.

IEEE 754 single precision: 1 sign bit, 8 exponent bits (bias 127), 23 mantissa bits; double precision uses 11 exponent bits (bias 1023) and 52 mantissa bits.

Operating system roles: process scheduling, memory management (paging/segmentation), file systems, device drivers. Paging removes external fragmentation but can add internal fragmentation on the last page.

SDLC models: waterfall (sequential, phase gates), V-model (each development phase pairs with a test level), spiral (risk-driven iterations), incremental/iterative, agile (short sprints, continuous feedback).

Coupling and cohesion: aim for low coupling between modules and high cohesion within a module. Data coupling < stamp < control < common < content coupling in increasing badness.

Structured analysis/design tools: data flow diagram (process, data store, external entity, data flow), ER diagram, state-transition diagram, structure chart, and data dictionary.

UML diagrams: use case, class, sequence, activity, state machine, component, deployment. Sequence diagrams model time-ordered message exchange; activity diagrams model workflow and concurrency.

Software maintenance types: corrective (fix defects), adaptive (environment change), perfective (improve quality/performance), preventive (reduce future deterioration). Perfective usually consumes the largest share.

Testing vs debugging: testing detects and reports failures from observed behavior; debugging locates and removes the defect. Testing cannot prove absence of defects, only their presence (Dijkstra).

Error, defect (fault), and failure chain: a human error introduces a defect in code or documents; executing that defect under conditions produces a failure.

Verification asks 'are we building the product right' (conformance to specification); validation asks 'are we building the right product' (meets user needs).

Test process stages: planning, analysis and design, implementation and execution, evaluating exit criteria and reporting, test closure activities (ISO/IEC/IEEE 29119).

Seven testing principles: testing shows presence of defects; exhaustive testing is impossible; early testing saves cost; defect clustering (Pareto); pesticide paradox; testing is context dependent; absence-of-errors fallacy.

V-model mapping: unit test <-> detailed design, integration test <-> architectural design, system test <-> requirements analysis, acceptance test <-> user requirements.

Entry criteria gate test execution (test basis available, environment ready, test cases approved); exit criteria gate completion (coverage threshold, defect density, unresolved-defect severity limits).

Static testing (reviews, inspections, static analysis) finds defects without executing code; dynamic testing executes the software. Reviews range from informal to formal inspection with defined roles and entry/exit criteria.

Equivalence partitioning: divide inputs into classes where all values are treated alike; test one valid and one invalid value per class. Combine with boundary value analysis for edges.

Boundary value analysis: for a range a-b, test a-1, a, a+1, b-1, b, b+1. For 2-value BVA test only a, a+1, b-1, b; for 3-value add the outside points.

Decision table testing: columns are rules (combinations of conditions), rows are conditions and actions. Number of rules = product of condition values; collapse impossible or equivalent rules.

State transition testing: model states, events, transitions, and guards. Derive test cases covering all states (all-states), all transitions (all-transitions), and invalid transitions.

Use case testing covers typical and alternative flows through a scenario; pairwise (all-pairs) testing covers every pair of parameter values to cut combinatorial explosion.

Statement coverage requires every executable statement executed; decision (branch) coverage requires every decision outcome taken. 100% decision coverage implies 100% statement coverage, not vice versa.

Condition coverage tests each Boolean condition true and false; MC/DC requires each condition independently affect the decision outcome. MC/DC is weaker than multiple-condition coverage but stronger than decision coverage.

Path coverage tests all paths through the control flow graph; loops make path count unbounded, so loop testing uses zero, one, two, and maximum iterations.

Experience-based techniques: error guessing (based on defect history), exploratory testing (simultaneous learning, design, and execution), and checklist-based testing.

Unit testing verifies individual components in isolation, often using stubs and drivers; performed by developers with white-box techniques.

Integration testing verifies interfaces between components. Strategies: big-bang, top-down (uses stubs), bottom-up (uses drivers), sandwich/hybrid, and incremental.

System testing verifies the complete integrated system against requirements, including functional and non-functional types, in an environment close to production.

Acceptance testing: user acceptance (UAT), operational acceptance, contractual and regulatory acceptance, and alpha (in-house) vs beta (at customer site) testing.

Functional testing types: smoke (basic health check), sanity (narrow deep check after a fix), regression (ensures changes did not break existing behavior), retest (confirms a specific defect fix).

Non-functional testing types: performance, load, stress, usability, security, reliability, maintainability, portability, compatibility, and localization.

Confirmation (retest) testing re-executes the failed case after a fix; regression testing re-runs a broader suite to detect side effects. They serve different purposes and are not interchangeable.

Test levels differ by object under test, test basis, responsible role, and environment; test types can be applied at any level (e.g., performance testing at unit or system level).

Test planning outputs: test plan, test schedule, effort estimate, resource and environment needs, risk register, entry/exit criteria, and test deliverables.

Estimation techniques: metrics-based (from historical test effort per requirement or per test case), expert judgment, and percentage-of-development-effort (commonly cited ranges around 30-40% of project effort for testing).

Risk-based testing prioritizes by risk = likelihood x impact; high-risk items get more test depth and earlier execution.

Defect life cycle: new -> assigned -> open -> fixed -> retest -> closed, with reject/deferred/reopen branches. Severity is technical impact; priority is fix urgency; they are independent attributes.

Defect report essentials: unique ID, title, environment/build, preconditions, reproduction steps, expected vs actual result, severity, priority, attachments, reporter and status.

Defect metrics: defect density (defects per KLOC or per function point), defect removal efficiency (defects found before release / total defects), and defect age.

Test progress monitoring uses metrics: test case execution rate, pass/fail ratio, defect find/fix rate, requirement coverage, and residual risk; report via dashboards and test summary reports.

Configuration management for testing: version control of testware, baseline of test items, controlled change of test cases, and traceability from requirements to tests to defects.

Automation suitability: stable, repeatable, high-volume, data-driven, and regression-prone tests suit automation; exploratory, usability, and one-off tests generally do not.

Automation ROI = (manual execution cost saved x runs) - (tool + script development + maintenance cost); scripts must run enough times to amortize cost.

Test automation framework types: linear (record-playback), modular, data-driven (test data separated from scripts), keyword-driven, hybrid, and behavior-driven (Given/When/Then).

The test automation pyramid favors many unit tests, fewer service/API tests, and few UI tests, because UI tests are slow and brittle.

Locator strategy for UI automation: prefer stable IDs and accessibility attributes over absolute XPath or positional CSS, which break on layout change.

Automation maintenance costs usually dominate; design with page objects, reusable libraries, and independent test data to reduce script churn.

Continuous integration runs automated suites on every commit; flaky tests (nondeterministic results) must be quarantined because they erode trust in results.

Automation does not replace exploratory testing; it frees manual effort for higher-value investigation. Metrics like pass rate must be paired with coverage to be meaningful.

Tool categories: test management, requirements management, static analysis, test design, test execution/automation, performance, security, defect tracking, and configuration management.

Tool selection criteria: fit to process and technology, licensing and total cost of ownership, vendor support, learning curve, interoperability, and proof-of-concept results.

Test environment components: hardware, OS, network configuration, databases, test data, and third-party interfaces; environment should mirror production closely enough for valid results.

Test data management: synthetic generation, masking/anonymization of production data, data refresh strategy, and reset between runs for repeatability.

Static analysis tools detect code smells, complexity, dead code, and potential null or resource leaks without execution; they complement but do not replace reviews.

Open-source versus commercial tools trade cost against support, integration, and compliance; a pilot on a representative project validates the choice before rollout.

Environment drift causes false failures; version and document environment configuration and treat it as a controlled configuration item.

Virtualization and containers enable rapid, reproducible environment provisioning; snapshots allow clean state reset between test cycles.

Performance testing types: load (expected peak), stress (beyond limits to find breaking point), spike (sudden surge), endurance/soak (sustained load over time), and scalability (behavior as load/resources grow).

Key metrics: response time (average and percentile, e.g., 90th/95th), throughput (transactions per second), error rate, and resource utilization (CPU, memory, disk, network).

Little's Law: concurrency = throughput x response time (L = lambda x W); use it to reconcile virtual user counts with observed throughput.

Percentiles matter more than averages: a 95th-percentile response time of 2 s means 95% of requests completed within 2 s; averages hide tail latency.

Workload modeling: define user profiles, think time, ramp-up, steady state, and ramp-down; realistic think time prevents unrealistic saturation.

Bottleneck analysis order: application code, database (slow queries, locks), application server (thread pool, GC), then network and infrastructure.

Acceptance criteria for performance are stated as thresholds (e.g., 95% of requests under 2 s at 500 concurrent users with error rate below 1%) and verified against baselines.

Endurance testing detects memory leaks and resource exhaustion that appear only after hours of sustained load; monitor heap and connection pools over time.

CIA triad: confidentiality, integrity, availability. Security testing verifies these properties plus authentication, authorization, non-repudiation, and auditability.

OWASP Top 10 categories include injection, broken access control, cryptographic failures, insecure design, security misconfiguration, and vulnerable components; test each with targeted cases.

Injection testing: input such as ' OR '1'='1 or SQL comment sequences should be rejected or safely parameterized; parameterized queries and input validation are the defenses.

Cross-site scripting (XSS) defenses: output encoding, input validation, and Content Security Policy; test reflected, stored, and DOM-based variants.

Reliability metrics: MTBF (mean time between failures), MTTF (mean time to failure), MTTR (mean time to repair), and availability = MTBF / (MTBF + MTTR).

Reliability growth models (e.g., Musa, Goel-Okumoto) estimate failure rate from defect discovery data; they assume defects are fixed and reliability improves over time.

Fault injection and recovery testing verify graceful degradation, failover, and data integrity after crashes or network partitions.

Security testing is not penetration testing alone: it also covers threat modeling, secure code review, configuration review, and vulnerability scanning across the lifecycle.

ISO/IEC 25010 quality model defines eight product characteristics: functional suitability, performance efficiency, compatibility, usability, reliability, security, maintainability, and portability, each with sub-characteristics.

ISO/IEC/IEEE 29119 covers software testing: concepts and vocabulary, test processes, documentation, techniques, and keyword-driven testing.

ISO 9001 addresses quality management systems; ISO/IEC 12207 covers software life cycle processes; ISO/IEC 15504 (SPICE) covers process assessment capability levels.

Capability Maturity Model Integration (CMMI) levels: 1 initial, 2 managed, 3 defined, 4 quantitatively managed, 5 optimizing.

Quality cost categories: prevention (training, reviews), appraisal (testing, inspection), internal failure (defects found before release), external failure (defects found after release); external failure is most costly.

Quality assurance focuses on process (preventing defects); quality control focuses on product (detecting defects via testing and inspection).

Defect removal efficiency and defect density are process-quality indicators; coverage and pass rate are product/test-quality indicators; use both together.

Standards provide a common vocabulary and auditable process baseline, but tailoring to project size and risk is expected; blind conformance can add cost without value.

Key terms: defect/fault/bug (a flaw), failure (observable deviation), error (human mistake), test oracle (expected-result source), test basis (source for deriving tests).

Coverage vocabulary: statement coverage, branch/decision coverage, condition coverage, path coverage, and requirement coverage; 'coverage' means the proportion exercised of a defined total.

Test process verbs: derive test cases, execute tests, log defects, triage, retest, regress, and sign off. 'Triage' means prioritizing and assigning reported defects.

Common collocations: 'reproduce a defect', 'raise/log a defect', 'fix a defect', 'verify a fix', 'meet exit criteria', 'pass/fail a test case'.

Passive and impersonal style is common in test reports: 'It was observed that...', 'The test case is considered passed when...'; avoid first person in formal reports.

Contrast connectors used in test documentation: 'whereas' (contrast), 'therefore' (consequence), 'provided that' (condition), 'in order to' (purpose).

Reading comprehension strategy: identify the subject (what is tested), the condition (when), and the expected result; these three map to a well-formed test case.

Ambiguity traps in exam English: 'must' vs 'should' (mandatory vs recommended), 'may' (permitted), 'shall' (requirement in standards), and 'not necessarily' (denies implication).