testing-test-case

Link to requirement/task/PRD Acceptance criteria / expected behavior Key user scenarios list Requirement/AC identifiers (if any) Scenario priority/criticality Known bugs/risks list Environment and data constraints </input_requirements> This skill describes how to design test cases; documenting them is optional If documentation is still needed, the format can be used as a template Use Given-When-Then Separate positive/negative scenarios One case = one check Apply equivalence partitioning and boundary values State preconditions and postconditions Separate critical branches into their own cases Separate test data from steps </test_design> Steps are reproducible without interpretation Expected result is verifiable and unambiguous No duplicates or overlaps Edge cases and validation errors are covered Test data and initial state are stated There is a link to the requirement/AC or acceptance criterion Documenting cases is optional, but the check logic must be explicit </quality_rules> Do not mix multiple scenarios in one case Do not use vague wording Do not include more than one requirement/AC in one case Do not leave implicit assumptions about data </do_not> TC-LOGIN-001: Valid login with existing user Clear scenario, expected outcome is verifiable Check login works No steps and no expected result