Manual Software Testing Test Cases: Complete Guide

Manual software testing helps verify that an application behaves as expected under normal, invalid, unexpected, and real-world conditions. A well-planned set of manual software testing test cases checks whether features work correctly, data remains accurate, security controls behave as intended, and users can complete important tasks without unnecessary errors.

The test cases you need depend on the application's requirements, features, risks, and intended users. However, most web and mobile applications benefit from testing functionality, input validation, database operations, file uploads, email notifications, data exports, authentication, performance, and payment workflows where applicable.

This guide explains the most important test cases and scenarios in manual software testing, with practical examples, expected results, and checklists that QA testers can adapt to their projects.

What Are Test Cases and Test Scenarios in Manual Software Testing?

A test case specifies the conditions, inputs, actions, and expected results used to verify a particular behavior of an application. A test scenario describes a broader behavior or sequence of actions that needs to be tested.

For example, testing a login feature is a test scenario. Checking whether a registered user can log in with valid credentials, whether an incorrect password produces an appropriate error, and whether a locked account is handled correctly are individual test cases.

A good test case should identify:

• Test case ID and title
• Feature or requirement being tested
• Preconditions
• Test steps
• Test data
• Expected result
• Actual result
• Pass or fail status
• Defect reference, if applicable

These details help testers execute tests consistently, document defects, and track whether requirements have been verified.

1. Functional Testing Test Cases

Functional testing test cases verify whether an application performs the functions specified in its requirements. Testers should examine both successful operations and situations in which the application must reject an action or display an error.

Important functional testing scenarios

• Verify that each button, link, menu, and navigation element works correctly.
• Check whether forms submit successfully when valid information is entered.
• Verify required-field validation.
• Check whether invalid inputs produce clear and relevant error messages.
• Confirm that calculations, totals, and displayed values are correct.
• Verify that search, sorting, filtering, and pagination work as expected.
• Check that records can be created, viewed, edited, and deleted according to user permissions.
• Verify that page refreshes do not unexpectedly duplicate or lose data.
• Check that browser back and forward navigation behaves appropriately.
• Confirm that successful operations display the correct confirmation message.

Example: In an employee management application, a tester creates an employee record, edits the employee's department, searches for the employee, and verifies that the updated information appears correctly.

The expected result is that every operation follows the defined requirements and the saved information remains consistent.

2. Form Validation and Input Field Test Cases

Input validation is essential because users may enter incomplete, incorrect, unexpected, or deliberately manipulated data.

Test cases for form validation

• Submit a form with all required fields empty.
• Enter valid data in every required field.
• Leave one required field empty at a time.
• Enter values at the minimum and maximum permitted lengths.
• Test values immediately below and above the allowed boundaries.
• Enter letters in numeric-only fields where letters are not permitted.
• Enter negative numbers, decimals, and zero where relevant.
• Enter leading and trailing spaces.
• Test permitted special characters and Unicode characters.
• Enter incorrectly formatted email addresses and phone numbers.
• Paste long strings into text fields.
• Submit a form repeatedly or click the submit button rapidly.
• Check whether validation messages identify the relevant field.
• Verify that previously entered valid information is retained when appropriate after a validation error.

Example: Registration form

Suppose a registration form requires a name, email address, and password.

Testers should derive exact limits and validation rules from the application's requirements rather than assuming that every form uses the same rules.

3. Database Testing Test Cases

Database testing checks whether application data is stored, updated, retrieved, and deleted correctly. It is particularly important for applications that manage customer records, transactions, employee information, bookings, or other business-critical data.

Database checks may require authorised access to the database, logs, or backend environment.

Database testing checklist

• Verify that submitted data is saved correctly.
• Confirm that updated information is reflected in the correct records.
• Check whether deleted records follow the application's deletion rules.
• Verify required fields and database constraints.
• Check primary key and foreign key relationships.
• Test minimum, maximum, decimal, and negative numeric values where permitted.
• Verify that data is not truncated unexpectedly.
• Confirm that date, time, currency, and numeric values are stored correctly.
• Check whether audit fields, such as creation and modification timestamps, are populated as designed.
• Verify that failed transactions do not leave inconsistent partial updates.
• Check transaction rollback behavior where applicable.
• Confirm that duplicate records are prevented when uniqueness is required.
• Verify that search and reporting results match the underlying data.
• Check that database access follows the application's permission model.
• Verify that appropriate logs are created for important data operations.

Example: Customer record update

A tester changes a customer's phone number through the application.

Expected result: The application displays the new number, the correct database record is updated, unrelated customer records remain unchanged, and any required audit information is recorded.

Testers should avoid direct database modifications in environments where such changes are prohibited or could affect real customer data.

4. Image and File Upload Test Cases

File upload features introduce validation, usability, storage, and security considerations. Testers should verify both supported uploads and attempts to submit files that the application should reject.

Image upload testing scenarios

• Upload a valid JPEG, PNG, or other supported image format.
• Upload an unsupported file format.
• Test a file larger than the configured size limit.
• Upload an image with dimensions outside the permitted range.
• Test filenames containing spaces, Unicode characters, and permitted special characters.
• Upload a file with a duplicate name.
• Replace an existing image.
• Cancel an upload where cancellation is supported.
• Test multiple-file uploads if the feature supports them.
• Verify progress indicators for large uploads where applicable.
• Confirm that the image appears correctly after uploading.
• Check image orientation, dimensions, and quality against requirements.
• Verify that uploaded files can be viewed or downloaded only by authorised users.
• Confirm that failed uploads do not leave misleading success messages or incomplete records.

File upload security checks

• Verify that file type restrictions cannot be bypassed by changing a filename extension alone.
• Check that uploaded files cannot execute unauthorised server-side code.
• Confirm that access to private files is controlled.
• Verify that appropriate malware-scanning controls are applied where required.

Expected result: Supported files are processed correctly, unsupported files are rejected safely, and the application displays meaningful feedback.

5. Email Notification Test Cases

Email functionality is frequently used for account registration, password resets, order confirmations, appointment reminders, and other notifications. Incorrect email behavior can disrupt important user workflows.

Email testing checklist

• Verify that an email is triggered by the correct event.
• Check that valid recipient addresses are handled correctly.
• Verify that invalid or missing recipient addresses are rejected or handled appropriately.
• Confirm that the subject line and sender information are correct.
• Check that dynamic placeholders contain the correct recipient information.
• Verify that special characters and international characters display correctly.
• Test HTML and plain-text email formats where supported.
• Check links, buttons, logos, and relevant footer information.
• Verify attachment names, formats, and contents where attachments are supported.
• Check that the correct recipients appear in To, CC, and BCC fields where applicable.
• Verify that emails are not unintentionally duplicated.
• Test how the application handles delivery failures or email service timeouts.
• Check password-reset links for correct expiry and single-use behavior where required.
• Review email rendering in the clients and devices supported by the application.

Example: After a customer completes a purchase, the application should create the correct order confirmation with the appropriate order number, items, amount, and recipient details.

The exact delivery behavior depends on the system's email architecture and requirements. An application may queue an email successfully without being able to guarantee delivery to the recipient's inbox.

6. Excel and Data Export Test Cases

Export functionality allows users to download application data for analysis, reporting, or record keeping. A successful download alone does not prove that the exported file is correct.

Export functionality testing scenarios

• Verify that the export button works.
• Check that the downloaded file uses the expected format and extension.
• Confirm that the filename follows the defined naming convention.
• Verify column headings and column order.
• Compare exported records with the data displayed in the application.
• Check date, time, currency, percentage, and decimal formatting.
• Verify sorting and filtering behavior in the exported results.
• Test export functionality when pagination is enabled.
• Check exports containing empty fields and special characters.
• Verify that non-English text is preserved correctly.
• Test large exports within the application's supported limits.
• Confirm that permission restrictions are applied to exported data.
• Check that the application responds appropriately if an export fails.

Example: Employee report export

A manager filters employee records by department and exports the results to Excel.

Expected result: The exported file contains the records permitted by the filter and the manager's access rights. Column headings and values are correct, and no unauthorised employee information is included.

7. Security Testing Test Cases

Security testing checks whether an application protects accounts, data, sessions, and functionality against unauthorised access and common attack patterns.

Manual security checks can identify potential issues, but they do not replace a comprehensive security assessment or specialist penetration test.

Security testing checklist

• Attempt to access a protected page without logging in.
• Verify that users cannot access another user's private records by changing a record identifier.
• Check role-based access permissions.
• Test login failure handling and account lockout or throttling where required.
• Verify password policy enforcement.
• Check that password-reset processes use appropriate verification and expiry controls.
• Confirm that logout invalidates the relevant session.
• Verify session expiry after the configured inactivity period.
• Check that sensitive information is not unnecessarily exposed in error messages.
• Test input handling for SQL injection and cross-site scripting using authorised test methods.
• Verify that sensitive data is transmitted over HTTPS.
• Check that cookies and session tokens use appropriate security attributes.
• Verify that private pages and files are not accessible to unauthorised users.
• Test file upload restrictions.
• Check that security-relevant events are logged appropriately.
• Verify that secrets, passwords, and sensitive tokens are not exposed in client-side code or logs.

Important: Perform security tests only in authorised environments using approved test data. Avoid destructive actions, denial-of-service attempts, or tests against systems without permission.

8. Performance and Responsiveness Test Cases

Performance testing examines whether an application responds within agreed expectations under specific operating conditions. Manual observations can reveal obvious delays, but reliable load and stress measurements generally require dedicated testing tools.

Performance-related scenarios

• Measure the response time of important pages under normal conditions.
• Check whether search and filtering operations complete within defined targets.
• Test form submission and report generation.
• Verify how the application behaves on slower network connections.
• Observe the interface while large files are uploaded or downloaded.
• Check whether loading indicators appear when appropriate.
• Verify that repeated navigation does not cause obvious degradation.
• Test the application under expected concurrent usage with an appropriate test setup.
• Check how the system handles timeouts and service interruptions.
• Review application and database response times where monitoring access is available.
• Observe resource usage during controlled performance tests.

Example: Product search

A tester searches for products using common and uncommon keywords, changes filters, and moves between result pages.

Expected result: Search results are accurate, interactions remain usable, and response times meet the project's defined performance targets.

Do not label an application slow or fast based on a single observation. Performance depends on factors such as hardware, network conditions, test data, caching, and concurrent activity.

9. Payment Gateway Test Cases

Payment functionality requires careful end-to-end testing because incorrect handling can lead to failed orders, duplicate transactions, inconsistent records, or incorrect payment status.

Use the payment provider's approved sandbox or test environment and its documented test credentials.

Payment gateway testing checklist

• Complete a transaction using an approved successful test payment.
• Verify that the order status changes correctly.
• Check that the correct amount and currency are submitted.
• Test declined and unsuccessful payments.
• Verify behavior when the payment provider times out or becomes unavailable.
• Check what happens when the customer cancels or leaves the payment flow.
• Test session expiry during checkout.
• Verify that repeated clicks or retries do not create unintended duplicate charges.
• Check that a delayed or repeated payment notification is handled safely.
• Verify order confirmation messages and payment receipts.
• Confirm that transaction references are recorded correctly.
• Test supported payment methods individually.
• Check refund and cancellation workflows where applicable.
• Verify that the application does not mark an unsuccessful transaction as paid.
• Confirm that the application handles payment status reconciliation appropriately.

Example: Failed payment

A customer submits an order, but the payment provider declines the transaction.

Expected result: The application clearly communicates the unsuccessful payment, does not falsely mark the order as paid, and allows a safe retry if the business rules permit it.

Payment providers differ in their callback, webhook, authentication, and retry mechanisms. Testers should use the provider's official documentation when designing detailed cases.

10. Login, Logout, and Session Management Test Cases

Authentication and session management affect both usability and security. A login form should work for valid users while preventing unauthorised access.

Login and session testing checklist

• Log in using valid credentials.
• Attempt login with an incorrect password.
• Submit the form with missing credentials.
• Test an unknown username or email address.
• Verify handling of disabled, locked, or unverified accounts.
• Check password visibility controls if provided.
• Verify the forgot-password workflow.
• Check whether reset links expire as required.
• Confirm that unauthenticated users cannot access protected pages.
• Log out and attempt to revisit a protected page.
• Test session expiry and reauthentication.
• Verify the application's remember-me feature if available.
• Check concurrent sessions and session revocation where required.
• Confirm that appropriate error messages do not reveal unnecessary account information.

Expected result: Users can access the functions permitted to them, while expired or unauthorised sessions cannot continue using protected features.

11. Search, Filter, Sort, and Pagination Test Cases

Search and data-navigation features are common sources of usability and data-display defects.

Test scenarios

• Search using a complete and a partial keyword.
• Search for a value that does not exist.
• Test case sensitivity where relevant.
• Enter spaces and special characters into search fields.
• Apply one filter and multiple filters.
• Remove filters and verify that the original result set returns.
• Sort ascending and descending by supported columns.
• Check sorting when values are blank or duplicated.
• Move between pages and verify record continuity.
• Test the first and last pages.
• Change the page size if that option is available.
• Verify that filters and sorting behave correctly after pagination.
• Check whether results update appropriately after a record is added or deleted.

Example: A tester filters orders by status, sorts them by date, and navigates to the next page.

Expected result: The result set consistently respects the selected filters and sorting rules without missing or duplicating records unexpectedly.

12. Cross-Browser and Mobile Compatibility Test Cases

A web application can behave differently across browsers, screen sizes, operating systems, and input methods.

Compatibility testing checklist

• Test supported browsers and their specified versions.
• Verify page layout at desktop, tablet, and mobile viewport sizes.
• Check navigation menus, dropdowns, modals, and pop-ups.
• Test forms using mouse, keyboard, and touch input as applicable.
• Verify that buttons and links remain usable on smaller screens.
• Check that text, images, and tables do not overflow their containers.
• Test orientation changes on supported mobile devices.
• Verify date pickers and file selectors on supported platforms.
• Check that error messages remain visible and readable.
• Test supported accessibility behaviors, including keyboard navigation and visible focus.
• Confirm that critical workflows remain functional when the screen size changes.

Expected result: The application provides the expected experience across the environments included in the project's compatibility requirements.

13. Regression Testing Test Cases

Regression testing checks whether recent changes have unintentionally affected existing functionality. It is especially important after bug fixes, feature updates, integrations, or changes to shared components.

Regression testing scenarios

• Retest the defect that was fixed.
• Verify related workflows that depend on the changed feature.
• Recheck login and user permissions after authentication changes.
• Test form submission after validation updates.
• Verify database operations after schema or data-handling changes.
• Recheck exports after changes to reports or data models.
• Test payment and order workflows after checkout changes.
• Verify notifications after email configuration changes.
• Recheck key browser and mobile workflows.
• Confirm that existing integrations still exchange the expected information.

Regression testing should be risk-based. Prioritise business-critical workflows, frequently used features, recently changed components, and areas with a history of defects.

14. Usability and Accessibility Test Cases

Usability testing evaluates whether people can understand and use the application effectively. Accessibility checks examine whether users with different abilities can interact with the interface.

Usability and accessibility checklist

• Verify that labels and instructions are clear.
• Check whether buttons communicate their purpose.
• Confirm that error messages explain how to correct the problem.
• Verify that important actions have appropriate feedback.
• Check keyboard navigation through forms and menus.
• Verify visible focus indicators.
• Check that form fields have meaningful labels.
• Confirm that important information is not communicated through colour alone.
• Review text readability, contrast, and zoom behavior.
• Check alternative text for meaningful images.
• Verify that dialogs and notifications can be navigated appropriately.
• Test supported assistive-technology workflows where possible.

Use the applicable accessibility requirements and test criteria for the project rather than relying only on visual inspection.

15. How to Write Effective Manual Software Testing Test Cases

A comprehensive checklist is useful, but individual test cases must still be specific, repeatable, and connected to requirements.

Follow these steps to develop a useful test suite.

Step 1: Understand the requirements

Review user stories, functional specifications, acceptance criteria, business rules, and relevant design documents. Clarify any ambiguous requirements before writing the tests.

Step 2: Identify test scenarios

List the user journeys and system behaviors that must be verified. For an online store, scenarios might include browsing products, adding items to a cart, applying discounts, checking out, and tracking an order.

Step 3: Identify positive, negative, and boundary conditions

Positive tests verify expected successful behavior. Negative tests verify how the application handles invalid or disallowed conditions. Boundary tests examine values near specified limits.

For a field that accepts values from 1 to 100, useful boundary tests include 0, 1, 2, 99, 100, and 101, provided those values match the field's defined rules.

Step 4: Define test data and preconditions

Specify the accounts, permissions, sample records, environment, and other conditions needed to execute each test.

Use controlled test data and avoid exposing real personal or payment information.

Step 5: Write clear steps and expected results

Each step should describe an action that another tester can reproduce. Expected results should be precise enough to determine whether the test passed or failed.

Step 6: Execute and record results

Record the actual outcome, test status, environment, and relevant evidence. When a defect occurs, document the reproduction steps and the difference between the expected and actual results.

Step 7: Prioritise and maintain the test suite

Assign priority according to business impact and risk. Update test cases when requirements change, defects are fixed, or new functionality is introduced.

16. Sample Manual Software Testing Test Case Template

Use the following example as a starting point for a test management spreadsheet or QA tracking system.

A well-maintained test case should be understandable without requiring the tester to guess the intended outcome.

17. Best Practices for Manual Software Testing

Use these practices to improve test coverage and make test execution more reliable.

• Prioritise by risk: Focus first on critical business workflows, sensitive data, and high-impact failures.
• Map tests to requirements: Maintain traceability so that important requirements have corresponding tests.
• Include negative testing: Verify not only successful operations but also invalid input, denied access, and failure conditions.
• Use boundary value analysis: Test values near specified limits instead of selecting only typical inputs.
• Apply equivalence partitioning: Select representative values from groups expected to behave similarly.
• Use realistic workflows: Test complete user journeys, including transitions between related features.
• Keep test data controlled: Use appropriate test accounts, known initial states, and repeatable datasets.
• Document defects clearly: Include steps to reproduce, expected behavior, actual behavior, and supporting evidence.
• Retest fixes: Confirm that defects are resolved and check related functionality for regressions.
• Avoid unnecessary duplication: Combine overlapping cases where doing so does not reduce meaningful coverage.
• Review security and privacy: Verify that sensitive information is protected throughout the workflow.
• Maintain the suite: Remove obsolete cases and update those affected by changed requirements.

Testing techniques such as equivalence partitioning, boundary value analysis, decision tables, and state transition testing can help testers design effective cases without creating an unnecessarily large test suite.

Conclusion

Effective manual software testing test cases and scenarios cover more than whether a button works or a page loads. They verify the application's business logic, input validation, data integrity, security, compatibility, usability, and behavior when dependencies fail.

Start with the application's requirements and most important user journeys. Add positive, negative, and boundary tests, define precise expected results, and prioritise cases according to risk. Use the checklists in this guide as a foundation, then adapt them to the application's architecture, business rules, and acceptance criteria.

A structured, regularly maintained test suite helps teams identify defects earlier, improve release confidence, and provide a more dependable experience for users.