🔎 F4 · Reading Schema: required, type, enum, example
F4 · Reading Schema: required, type: An OpenAPI schema is a **guide to a signup form**: `required` says which fields cannot be left BLANK (the red-starred fields), `type` says wh
An OpenAPI schema is a **guide to a signup form**: `required` says which fields cannot be left BLANK (the red-starred fields), `type` says what kind of data each field expects (a name or a number), `enum` says a field only accepts SPECIFIC values (like a dropdown), and `example` is a sample filled-in copy showing how to fill the form. So why know these 4 words individually — isn't "look at the schema" enough? Because each one BIRTHS a DIFFERENT test scenario: a missing `required` births the "what happens without this field?" test, a wrong `type` births the "what happens if I send the wrong data type?" test, an out-of-`enum` value births the "what happens if I send an undefined value?" test. The Java equivalent is Bean Validation annotations: `required` ≈ `@NotNull`/`@NotBlank`, `type` ≈ the field's Java type (`String`, `Integer`), `enum` ≈ a Java `enum` class or `@Pattern`. For QA, READING a schema is the fastest way to produce a LIST of test scenarios — in F6 you will do exactly this, systematically.
The Bug Record's Schema
🎬 From a Schema Line to a Test Scenario
enum: [LOW..CRITICAL]
3 test scenarios are born
The tester reads the schema: `required: ["title", "severity", "reporter"]`.
This line alone births a test scenario: "if I POST without title, do I get 400?"
`type: "string"` births another scenario: "what if I send a number instead of title?"
`enum: [LOW,MEDIUM,HIGH,CRITICAL]` births a third scenario: "what if I send severity: 'URGENT' (an undefined value)?"
The lesson — every constraint in the schema systematically turns into at least one negative test scenario; reading a schema is really a test design technique.
The Order for Turning a Schema into Test Scenarios
List required fields…
Design a "what if I send without it?" negative test for each required field.