Test cases & bug reports
A good test case is atomic (checks one thing), repeatable and executable by someone else. Structure:
- ID and title (what it checks — clearly)
- Preconditions
- Steps (precise, numbered)
- Expected result (per step or at the end)
- Priority, status, linked requirement
Test case vs checklist: a checklist is lighter (a "what to check" list) for fast teams; a test case is detailed, good for audits/new joiners.
A professional bug report gives the developer everything needed to reproduce the bug:
- Short, specific title (where + what happens)
- Steps to reproduce
- Expected result / Actual result
- Environment (OS, browser, version, server)
- Severity, attachments (screenshot, video, logs)
Bug lifecycle: New → Assigned → In Progress → Fixed → Ready for retest → Verified → Closed (or Reopened).
Classic interview question: "A developer returned your bug as 'cannot reproduce' — what do you do?" Answer: check environment/data differences, attach video/logs, pair up on the dev's machine, note frequency if intermittent. Emphasise collaboration, not conflict.