Test case
The documented check of one behaviour: a title, preconditions, steps with expected results, and whatever metadata the team needs to filter on. A test case is a reusable asset executed many times against many builds, which is the property that separates it from a task or a ticket, and the reason issue trackers model it badly.
Also called: test script, test scenario
One case, one behaviour
The most common defect in a test library is a case that checks several things at once. "Checkout works" with fourteen steps fails on step nine, and the result says Failed for all fourteen. Nobody can tell from the report whether payment, shipping or the confirmation email broke. Split a case where the expected results stop being about the same behaviour. A case with three to eight steps is a reasonable target; a case with thirty is a procedure, and should be a checklist or several cases.
Write the expected result so a stranger could judge it
"Works correctly" and "page loads" are not expected results. "Order total shows the discounted price, $45.00, and the discount line names the code" is. The test for a good expected result is whether a tester who joined last week would mark it the same way as the author. If two people could disagree on pass or fail, the case is measuring the tester, not the product.
Test case, test scenario and test script
The words get used loosely. A scenario usually describes a user goal at a higher level ("returning customer reorders"), and one scenario turns into several cases. A script, in most teams, is the automated version: code that performs the steps. A manual case and the script that automates it can share one test case ID, which is how automated results land on the right case.
When a case should be retired
A case that has not run in a year, checks a feature that no longer exists or duplicates another case still costs review time on every change. Retire it instead of leaving it to inflate coverage. Near-duplicates are the hard part; see duplicate test case.
In QAM Hub
A test case lives in a suite and has a title, preconditions, steps with expected results, tags, custom fields and images. Each case has a TC-number that automated tests can reference in their titles. Version history with rollback is on Standard and Advanced. How to create them is in creating test suites and cases, and the longer guide is how to write test cases.