Writing test cases is one of the most important responsibilities of a software QA engineer. A well-written test case helps testers verify application functionality, identify defects, and ensure that the software behaves as expected under different conditions.
However, writing test cases for real-world applications is not always straightforward. In actual projects, requirements can be incomplete, business rules can be complicated, and users may interact with an application in ways that developers and testers did not initially consider.
For example, testing a login page is not limited to checking whether a user can log in with valid credentials. A QA engineer must also consider invalid passwords, locked accounts, empty fields, session expiration, password visibility, security restrictions, and multiple failed login attempts.
This is where practical test case writing becomes important.
In this article, we will understand how to write effective test cases, what information to include, how to identify different test scenarios, and how to write test cases using examples from real-world applications.
What Is a Test Case?
A test case is a set of predefined steps, conditions, input values, and expected results used to verify a particular application feature or functionality.
It explains what needs to be tested, how to perform the test, and what result should be obtained.
A test case generally contains the following information:
Field | Description |
|---|
Test Case ID | Unique identifier of the test case |
Test Scenario | Functionality or condition being tested |
Test Case Title | Short description of the test |
Preconditions | Conditions that must be satisfied before execution |
Test Steps | Actions performed by the tester |
Test Data | Input values required for execution |
Expected Result | Result expected from the application |
Actual Result | Result observed during execution |
Status | Pass, Fail, Blocked, or Not Executed |
Priority | Business importance of the test case |
Not every organization follows exactly the same template. Some teams also include environment, requirement ID, test type, severity, and automation status.
The important thing is that another tester should be able to understand and execute the test case without asking the original author for clarification.
Understand the Requirements Before Writing Test Cases
One common mistake among beginners is starting to write test cases immediately after receiving a requirement.
A QA engineer should first understand what the feature is supposed to do.
Requirements may come from different sources, including:
Business Requirement Documents (BRD).
Software Requirement Specifications (SRS).
User stories.
Acceptance criteria.
Functional specifications.
UI/UX designs.
Discussions with developers and business analysts.
Consider the following user story:
"As a registered user, I want to log in using my email address and password so that I can access my account."
Before writing test cases, identify the business rules.
For example:
Users must enter a registered email address.
Password is mandatory.
Both credentials must be valid.
Invalid credentials should display an appropriate error message.
Accounts should be temporarily locked after five consecutive unsuccessful login attempts.
Users should have an option to reset their password.
Password characters should remain hidden by default.
These rules provide a foundation for identifying test scenarios.
If a requirement is unclear, discuss it with the business analyst, product owner, or development team instead of making assumptions.
Identify Test Scenarios Before Writing Test Cases
A test scenario describes what functionality or condition needs to be verified. A test case explains how to verify it.
For example:
Test Scenario | Test Case |
|---|
Verify user login | Login with valid email and password |
Verify invalid login | Login with an incorrect password |
Verify mandatory fields | Submit the login form without entering credentials |
Verify account security | Attempt login after five consecutive failures |
Verify password reset | Reset password using a registered email |
A single test scenario can have multiple test cases.
When identifying scenarios, consider the following testing techniques.
Positive Testing
Positive testing verifies whether the application works correctly when valid inputs and expected conditions are provided.
For a login feature, examples include:
Login using valid email and password.
Login using email with uppercase and lowercase characters where the application treats email addresses case-insensitively.
Login after successfully resetting the password.
Navigate to the dashboard after successful authentication.
Negative Testing
Negative testing checks how the application behaves when invalid inputs or unexpected conditions are provided.
Examples include:
Login with an incorrect password.
Enter an unregistered email address.
Submit the form with both fields empty.
Enter an invalid email format.
Attempt login using an inactive account.
Boundary Value Testing
Boundary Value Analysis focuses on testing values at the minimum and maximum limits of an input field.
Suppose a password must contain between 8 and 20 characters.
Useful test cases include:
Enter a password containing 7 characters.
Enter a password containing exactly 8 characters.
Enter a password containing 9 characters.
Enter a password containing exactly 20 characters.
Enter a password containing 21 characters.
Boundary testing is useful for password fields, age restrictions, transaction limits, file uploads, and other input validations.
Equivalence Partitioning
Equivalence Partitioning divides input data into groups that are expected to behave similarly.
For example, if an application accepts ages between 18 and 60:
Instead of testing every possible age, a tester selects representative values from each group.
These techniques help QA engineers identify meaningful test cases without creating unnecessary duplicates.
Practical Example 1: Writing Test Cases for a Login Page
Let's consider a real-world e-commerce application where registered customers can log in using their email address and password.
Assumptions for this example:
Email address must be registered.
Password must be correct.
Five consecutive unsuccessful login attempts temporarily lock the account.
Both fields are mandatory.
The following test cases cover the major functional conditions.
Test Case ID | Test Case Description | Expected Result | Priority |
|---|
TC_LOGIN_001 | Login with valid email and password | User should successfully log in and reach the dashboard | High |
TC_LOGIN_002 | Login with an incorrect password | Appropriate error message should appear | High |
TC_LOGIN_003 | Login with an unregistered email | Application should reject the login attempt | High |
TC_LOGIN_004 | Submit login form with both fields empty | Mandatory field validation should appear | High |
TC_LOGIN_005 | Submit login form with email empty | Email validation should appear | High |
TC_LOGIN_006 | Submit login form with password empty | Password validation should appear | High |
TC_LOGIN_007 | Enter an invalid email format | Application should display email validation | Medium |
TC_LOGIN_008 | Enter password exceeding the permitted length | Application should enforce the configured password limit | Medium |
TC_LOGIN_009 | Enter an incorrect password five consecutive times | Account should be temporarily locked according to the business rule | High |
TC_LOGIN_010 | Select Forgot Password | User should be redirected to the password recovery process | Medium |
Detailed Test Case Example
A test case should contain enough information for another tester to execute it independently.
Test Case ID: TC_LOGIN_001
Test Case Title: Verify login with valid email and password.
Preconditions:
User must have an active registered account.
Login page must be accessible.
User must know the correct credentials.
Test Data:
Test Steps:
Open the application.
Navigate to the login page.
Enter the registered email address.
Enter the correct password.
Click the Login button.
Observe the application response.
Expected Result:
The application should authenticate the user successfully and redirect them to the appropriate dashboard.
Actual Result: To be updated after execution.
Status: Not Executed.
This format makes the test case clear, repeatable, and easy to review.
Practical Example 2: Writing Test Cases for an E-Commerce Application
E-commerce applications contain several interconnected features, including product search, shopping carts, checkout, payments, and order management.
Testing only whether a product can be purchased is not sufficient. A QA engineer must also verify how the application handles different customer actions and business conditions.
Consider a shopping cart feature.
The following scenarios should be covered:
Test Case ID | Test Case Description | Expected Result |
|---|
TC_CART_001 | Add an available product to the cart | Product should be added successfully |
TC_CART_002 | Add the same product multiple times | Quantity should increase according to application rules |
TC_CART_003 | Remove a product from the cart | Selected product should be removed |
TC_CART_004 | Update product quantity | Cart quantity and total amount should be updated |
TC_CART_005 | Enter quantity as zero | Application should follow the defined quantity validation rules |
TC_CART_006 | Enter a negative quantity | Application should reject the invalid quantity |
TC_CART_007 | Add an out-of-stock product | Application should prevent purchasing unavailable stock |
TC_CART_008 | Apply a valid discount coupon | Eligible discount should be applied |
TC_CART_009 | Apply an expired coupon | Application should display an appropriate error |
TC_CART_010 | Refresh the cart page | Cart data should remain consistent according to the session and cart persistence rules |
Important Business Scenarios
Some scenarios require more than simple field validation.
For example, consider two customers attempting to purchase the last available product.
The application must prevent both customers from successfully purchasing the same single inventory unit.
Other important scenarios include:
Product price changes after adding an item to the cart.
Discount expires while a customer is checking out.
Customer removes a product after applying a coupon.
Cart contains products from different sellers.
Payment fails after the order has been initiated.
Customer refreshes the page during checkout.
These scenarios help identify defects that may not appear during basic functional testing.
Practical Example 3: Writing Test Cases for an Online Banking Application
Banking applications require careful testing because they handle sensitive financial transactions.
Consider a fund transfer feature where a customer can transfer money from one bank account to another.
Before writing test cases, understand the transaction rules:
Source account must be active.
Destination account must be valid.
Transfer amount must be greater than zero.
Sufficient account balance must be available.
Transactions must be recorded correctly.
Duplicate transactions must be prevented.
Sample test cases:
Test Case ID | Test Case Description | Expected Result |
|---|
TC_BANK_001 | Transfer a valid amount to an active account | Transaction should complete successfully |
TC_BANK_002 | Transfer an amount greater than the available balance | Transaction should be rejected |
TC_BANK_003 | Transfer zero amount | Application should display validation |
TC_BANK_004 | Transfer a negative amount | Application should reject the transaction |
TC_BANK_005 | Enter an invalid destination account | Transaction should not proceed |
TC_BANK_006 | Submit the transfer request multiple times | Duplicate transactions should be prevented |
TC_BANK_007 | Refresh the page after submitting a transfer | Transaction should not be processed twice |
TC_BANK_008 | Transfer the maximum permitted amount | Application should follow the configured transaction limit |
TC_BANK_009 | Verify account balance after a successful transfer | Source and destination balances should be updated correctly |
TC_BANK_010 | Verify transaction history | Transaction details should be recorded accurately |
What Should QA Engineers Pay Special Attention To?
Financial transactions involve more than checking a success message.
A QA engineer should verify:
Whether the source account is debited correctly.
Whether the destination account is credited correctly.
Whether transaction records are generated.
Whether failed transactions are handled properly.
Whether retrying a request creates duplicate transactions.
Whether concurrent transactions maintain correct account balances.
For financial systems, transaction integrity, concurrency, auditability, and data consistency are important testing considerations.
How to Write Better Test Cases for Complex Applications
Writing more test cases does not automatically mean better test coverage. The objective should be to cover important business functionality, realistic user behavior, and potential failure conditions.
Here are some practices that help improve test case quality.
1. Write Clear and Specific Test Case Titles
Avoid generic titles such as:
"Check Login"
Instead, write:
"Verify that an active user can log in using valid email and password."
A specific title helps testers understand the purpose of the test without reading every step.
2. Keep Test Steps Simple
Each step should describe one action wherever possible.
Avoid combining multiple unrelated actions into a single step. Clear steps make execution and defect investigation easier.
3. Include Realistic Test Data
Use test data that represents actual application usage.
For example, when testing an e-commerce checkout, consider:
Different product categories.
Multiple delivery addresses.
Valid and invalid discount codes.
Different payment methods.
Products with different stock availability.
For sensitive applications, use synthetic or approved masked data rather than real customer information.
4. Cover Positive, Negative, and Boundary Scenarios
Do not focus only on successful user journeys.
Consider invalid inputs, minimum and maximum values, empty fields, duplicate requests, interrupted sessions, and unexpected application responses.
5. Avoid Duplicate Test Cases
Two test cases should not verify exactly the same condition unless there is a clear reason, such as testing different roles, environments, or business rules.
Review existing test cases before creating new ones.
6. Map Test Cases to Requirements
Maintain traceability between requirements, test scenarios, and test cases.
A Requirement Traceability Matrix (RTM) helps identify requirements without test coverage and makes it easier to understand which tests need updates when requirements change.
7. Review Test Cases With the Team
A second review can identify missing scenarios, incorrect assumptions, unclear steps, and incomplete expected results.
Developers, business analysts, product owners, and other QA engineers can provide useful feedback.
Common Mistakes to Avoid While Writing Test Cases
Even experienced testers can miss important details when working under tight deadlines.
Some common mistakes include:
Common Mistake | Better Approach |
|---|
Writing test cases without understanding requirements | Clarify business rules before starting |
Testing only positive scenarios | Include negative and boundary conditions |
Writing unclear test steps | Use simple, executable instructions |
Using unrealistic test data | Use representative and controlled data |
Missing expected results | Define the expected application behavior |
Creating duplicate test cases | Review existing coverage |
Ignoring integration scenarios | Test interactions between connected modules |
Not updating outdated test cases | Review cases whenever requirements change |
Focusing only on UI validation | Include API, database, security, and integration checks where applicable |
How to Prioritize Test Cases
In real projects, QA teams often have limited time for testing. Therefore, it is important to identify which test cases should be executed first.
Risk-based testing helps prioritize test cases according to business impact and the likelihood of failure.
A practical classification is:
Priority | Description | Example |
|---|
Critical | Failure can cause major business or financial impact | Duplicate bank transactions |
High | Failure affects important application functionality | User cannot log in |
Medium | Failure affects secondary functionality | Incorrect sorting of products |
Low | Minor issue with limited business impact | Incorrect spacing or alignment |
Priority should be decided based on business risk, not simply the complexity of the test case.
For example, a small validation issue in a payment process may deserve higher priority than a major visual issue on an informational page.
Tools Used for Writing and Managing Test Cases
QA engineers use different tools depending on project size, team structure, and testing requirements.
Some commonly used options include:
Microsoft Excel: Useful for maintaining manual test cases and simple test execution reports.
Jira: Helps manage requirements, defects, and testing activities through integrations and extensions.
TestRail: Provides dedicated test case management and execution tracking.
Azure DevOps: Supports test plans, test suites, test cases, and requirement traceability.
Zephyr: Provides test management capabilities within Jira-based workflows.
The choice of tool depends on the project. A small application may not require a dedicated test management platform, while a large enterprise application may benefit from centralized test case management.
Conclusion
Writing test cases for real-world applications requires more than listing steps and expected results. A QA engineer must understand business requirements, identify user behavior, consider negative conditions, and evaluate what could go wrong during actual application usage.
Practical examples from login pages, e-commerce applications, and banking systems show why test coverage should include positive, negative, boundary, integration, and business-critical scenarios.
The most effective test cases are clear, reusable, maintainable, and directly connected to application requirements.
As a QA engineer, focus on testing the application from the user's perspective while also considering business rules, system behavior, and potential failure conditions. This approach helps identify meaningful defects before they reach production and improves the overall quality of the software.
Join the conversation! Your thoughts help the community grow.