A test case is a documented set of conditions to verify a feature. Standard components include a unique ID, title, preconditions, test data, test steps, expected result, actual result, and status (plus priority and requirement link).
A well-written test case has: Test Case ID (unique), Title/Description (what it verifies), Preconditions (state needed before running), Test Data (inputs), Steps (numbered, unambiguous actions), Expected Result (what should happen), Actual Result (filled during execution), Status (Pass/Fail/Blocked), and often Priority and a Requirement ID for traceability. Good test cases are clear (any tester can execute them identically), atomic (verify one thing), independent, traceable to requirements, and reusable. Vague steps or missing expected results make a case unexecutable. Test-case writing quality is a core manual-testing interview signal.
TC_LOGIN_02: Title 'Login with invalid password'; Precondition 'user registered'; Data 'valid user + wrong pass'; Steps '1. enter user 2. enter wrong pass 3. click login'; Expected 'error: Invalid credentials; no session'.
What makes a test case 'good', and what's wrong with a step like 'test the login page'?