HARBOR DESK / 09 / PRACTICE GUIDE

Security-focused QA and retesting

Go beyond the happy path: verify denial, outage, race and side-effect behavior. Define expectations independently of current implementation.

Download guide and workpapers

Original AI-assisted SecNet educational content; examples are fictional. Not a source organization publication or endorsement. Sources checked: 2026-10-21.

CODE REVIEW DESK

See the decision through the test.

Code here is a local policy model with no target connection. Passing model cases are not security approval or device tests.

Only the happy path / Weak code

Inspect an incomplete decision based on record existence or another positive signal. Consider denial cases alongside permitted use.

s=>s.happyPathPassed

A normal read test does not cover other-user, other-tenant and anonymous access. The model requires all three denial checks.

Choices and outputs last only on this open page; they do not update account progress, career status, points or certificates.

01 / EXPLANATION

Matrix and test oracle

The expected result is the test oracle. Copying current behavior into expectations preserves bugs. Select dimensions for actor, tenant, operation, resource existence and session state. Check more than a denial status: verify unchanged data, version and external effects afterward. Retain permitted cases; denying everything is not a secure and functional solution.

02 / EXPLANATION

Failure modes and races

Malformed JSON, oversized bodies or identity-provider outage must not expand access. Errors need controlled user responses and traceable operational records without secrets or personal data. Start two same-version requests together and assert the single-winner invariant. Network retries and external calls require additional idempotency design.

03 / EXPLANATION

Retest scope

Repeating the original reproduction is necessary but insufficient. Test a variant, an alternate access path and legitimate use. Control fixture data and time dependencies rather than claiming success from arbitrary repetitions. Store automated results with the tested revision. A passing local fixture does not verify the real product, browser or mobile device.

04 / EXPLANATION

Example retest package

A permission-fix retest package should include four core outcomes: permitted read 200; other-user/tenant reads 404; anonymous read 401; unchanged data after a denied update. Add stale-version writes, oversized bodies and wrong CSRF cases. Checking status alone cannot establish data integrity, which is why the actual HTTP fixture rereads title and version. A fix that denies all access can pass negative tests while breaking legitimate use; the permitted case catches that. Record command, revision and synthetic dataset, and clearly identify platform tests that were not performed.

Build the evidence yourself.

Blank workpapers are not completed tests. Fill them in your authorized environment without secrets or real personal data.

Scope and trust boundariesMarkdown · ENTest plan and expected resultsMarkdown · ENFinding and retest recordMarkdown · ENRelease decision and evidence traceMarkdown · EN
Full guide with code, outputs and reasoning ↓

Primary references

Explanations are authored by SecNet. References support method and platform context; verify current editions and organizational policy for real use.