9 programs
Choose the best training program according to your career.
Improve the performance of your business with our innovative Industrial Training Program.
Read More →
Our instructor-led training classes are designed to make you an expert.
Read More →
Real-life case studies are a great way to demonstrate your practical knowledge.
Read More →
Explore blogs, latest technologies and industry updates with practical examples.
Read More →
Browse all available training programs and choose the right one for your career.
Read More →Know more about who we are and what we stand for.
Discover our mission to equip individuals with essential IT skills and industry expertise.
Read More →Learn, practice and plan your career — bilkul free.
Book a free video counselling session and pick the right course for you.
Read More →Download the software testing test case guide PDF from Uncodemy: a standard template, design techniques and a worked login example.
This page offers Uncodemy's test case guide as a PDF download. A test case is a documented set of inputs, steps and expected results that checks one specific behaviour of the software. The guide gives a standard template, explains design techniques such as boundary value analysis and equivalence partitioning, and works through a login example you can adapt.
Download the guide below. Each download is its own file, and everything in it is also explained on this page.
A standard test case template, writing good steps and expected results, design techniques, boundary value and login examples, and review tips for your test suite.
A short form asks for your details before the download starts. Your details are used only to share study material and course information.
A test case describes one check of the software in enough detail that anyone on the team can run it and reach the same verdict. It states the starting conditions, the exact steps, the data to use and the result that should happen.
Test cases serve three purposes. They guide testers so that nothing important is forgotten. They make testing repeatable, so the same check can be run on every release. And they are evidence of what was covered, which matters when someone asks whether a feature was tested.
A good test case is small, specific and independent: it checks one thing, it does not depend on another case having run first, and its expected result is clear enough that a pass or fail is not a matter of opinion.
| Field | What to write | Example |
|---|---|---|
| Test case ID | A unique identifier | TC-LOGIN-001 |
| Title | One line saying what is checked | Login succeeds with valid credentials |
| Module and requirement | Where it belongs and what it traces to | Login; REQ-12 |
| Preconditions | State needed before starting | User account exists and is active |
| Test data | Exact values to use | Email: test.user@example.com; valid password |
| Steps | Numbered actions | 1. Open login page 2. Enter email 3. Enter password 4. Click Login |
| Expected result | What should happen | User lands on the dashboard and sees their name |
| Actual result and status | Filled in at execution | Pass or Fail, with notes |
| Priority and type | Importance and category | High; Functional |
Write steps as short, imperative sentences that describe actions and name the screen elements involved. Avoid vague wording such as "check that it works" or "verify the page".
The expected result must be observable and specific: not "login should work" but "the dashboard page opens, the welcome message shows the user's name and no error appears". Put one verification point at the end of each case where possible; a case that tries to check ten things makes failures hard to diagnose. Keep test data separate and explicit, never assume the tester will invent a suitable value.
Writing a test case for every possible input is impossible, so testers use techniques that choose a small set of inputs most likely to reveal defects.
Equivalence partitioning divides inputs into groups that the software should treat the same way and tests one value from each group. Boundary value analysis focuses on the edges of those groups, where mistakes are most common. Decision tables list combinations of conditions and the resulting actions, which is useful for rules with several factors.
State transition testing checks that a system moves correctly between states, such as an order moving from placed to paid to shipped. Error guessing uses experience to try inputs that have caused trouble before.
| Input length | Class | Expected result |
|---|---|---|
| 7 | Just below the lower boundary | Rejected with a length error |
| 8 | On the lower boundary | Accepted |
| 9 | Just above the lower boundary | Accepted |
| 19 | Just below the upper boundary | Accepted |
| 20 | On the upper boundary | Accepted |
| 21 | Just above the upper boundary | Rejected with a length error |
| ID | Title | Test data | Expected result |
|---|---|---|---|
| TC-LOGIN-001 | Valid login | Registered email and correct password | Dashboard opens |
| TC-LOGIN-002 | Wrong password | Registered email and wrong password | Error: invalid credentials; user stays on login page |
| TC-LOGIN-003 | Unregistered email | Unknown email and any password | Generic error; no hint about which field is wrong |
| TC-LOGIN-004 | Empty fields | Both fields blank | Validation messages for both fields |
| TC-LOGIN-005 | Invalid email format | Text without an at sign | Format validation message |
| TC-LOGIN-006 | Password is masked | Type any password | Characters are hidden |
| TC-LOGIN-007 | Account lockout | Several wrong attempts in a row | Account locks or a delay applies, according to the requirement |
| TC-LOGIN-008 | Leading and trailing spaces in email | Valid email with spaces | Behaviour matches the requirement; no crash |
Positive cases confirm that valid input produces the correct result. Negative cases confirm that invalid input is handled safely with a clear message. Boundary cases check the edges of allowed ranges.
A balanced suite includes all three; a suite of only positive cases misses most real defects.
A test case suite is a living asset. Have a colleague review new cases against the requirement, remove duplicates and retire cases for features that no longer exist.
After each release add cases for defects that escaped, so that the same problem is caught next time. Tag cases by priority so that a short run of the most important ones can be used when time is tight.
Want to write test cases the way QA teams do at work? Explore Uncodemy's courses and learn from industry trainers.
