Functional Test Cases

Functional test cases are checklists written for a non-technical tester. The tester does not read code, does not look at network requests, does not understand state machines. They follow steps a customer would follow, look at what's on screen, and tick boxes. This forces the test cases to be expressed entirely in terms of observable behaviour — which is what we ultimately ship to customers.

At Media Tech the test cases are generated from the Requirement Specification, reviewed alongside the spec, and assigned to QA before the feature enters Phase 4 of the SDLC (developer/sdlc-process).

The Welcome Screen pattern

The Welcome Screen checklist is our reference example. Every screen-level test follows this structure:

1. Entry conditions. What state the app must be in for the tester to start. "Fresh install, no account created." "Logged in as User Type B with one existing diary entry." Specific enough that two testers reach the same starting point.

2. Visual checklist. Bullet list of things that must be visible and correctly rendered. Headings, copy, images, buttons, badges, empty states. Each bullet is a yes/no. "The Welcome heading reads exactly 'Welcome to SPYN' in the brand display font."

3. Interactive checklist. Bullet list of things the tester can do and what should happen. "Tapping the 'Get started' button takes me to the email-entry screen." Each bullet has a clear pass condition and an explicit failure mode.

4. Edge cases. Connectivity dropouts, very long names, accessibility settings, dark mode, system-font scaling. Each edge case is its own checklist sub-section.

5. Language coverage. The same checklist re-run in each supported language. Strings are checked against the i18n catalogue keys named in the spec.

6. Sign-off. Tester name, date, build version, device(s) used, result (Pass / Pass with notes / Fail). Notes get logged to monday.com as observations against the feature ID.

Why non-technical

A test case a customer-success agent can run is a test case that catches what customers see. A test case that requires reading TypeScript catches different bugs — those exist too (see developer/test-cases-technical), but they're a different layer.

The non-technical bar also means the test cases double as customer-success training material and onboarding content for new QA testers. A new tester running through the SPYN functional test suite learns the product better than any documentation could teach.

QA team and assignment

Functional tests are owned by the QA Lead and assigned to the QA Testers. See hr/raci-model for the named individuals currently in those roles. Testers rotate features so that no single tester becomes the only person who knows a given area.

Failure handling

A failing functional test is a defect. Defects are logged to monday.com with severity (S1 blocker → S4 cosmetic), reproduction steps copied from the checklist, the build version, and a screenshot or screen recording. S1 and S2 defects block the release gate; S3 and S4 are scheduled into the next sprint.

Owned by

QA Lead. Audited by the Master skill on a 90-day cadence.