Home / Blog / How-To Guides / How to Write Test Cases for Contact List (With Examples)

How to Write Test Cases for Contact List (With Examples)

Writing effective test cases for a contact list feature is crucial for ensuring a robust and user-friendly application. A well-defined set of test cases goes beyond simple "add contact" and "view cont

June 07, 2026 · 20 min read · How-To Guides

# How to Write Test Cases for Contact List (With Examples)

Writing effective test cases for a contact list feature is crucial for ensuring a robust and user-friendly application. A well-defined set of test cases goes beyond simple "add contact" and "view contact" scenarios, encompassing a wide range of positive, negative, edge, and boundary conditions that mimic real-world user interactions and potential system failures. This guide will walk you through the process of crafting high-signal test cases for contact lists, providing concrete examples and a structured approach that can be applied to any platform – mobile, web, or desktop. We'll cover the anatomy of a good test case, explore different testing types, and demonstrate how to create a comprehensive test matrix. We'll also touch upon data setup, prioritization, traceability, and the complementary role of autonomous testing in achieving complete coverage.

The primary goal when writing test cases for a contact list is to validate its core functionalities, data integrity, user experience, and resilience under various conditions. This includes ensuring contacts can be added, edited, deleted, searched, and displayed accurately, while also accounting for unique scenarios like duplicate entries, special characters in names, and varying data formats. By following a systematic approach, you can build confidence in the quality of your contact list feature.

The Anatomy of a High-Signal Test Case

A high-signal test case is one that, when executed, provides meaningful information about the system's behavior. It's specific, unambiguous, and designed to isolate a particular aspect of functionality or a potential defect. For a contact list, each test case should have a clear structure to ensure reproducibility and accurate reporting.

Essential Components of a Test Case

Every well-formed test case, regardless of the feature, typically includes the following elements:

Example: Basic Contact Creation

Let's illustrate with a simple example for adding a contact:

  1. Navigate to the "Add New Contact" screen.
  2. Enter "John" into the "First Name" field.
  3. Enter "Doe" into the "Last Name" field.
  4. Enter "123-456-7890" into the "Phone Number" field.
  5. Enter "john.doe@example.com" into the "Email" field.
  6. Tap the "Save" button.

This structured approach ensures clarity and repeatability, which are fundamental to effective testing.

Types of Test Cases for Contact Lists

To achieve comprehensive coverage, test cases should be designed to cover various testing types. For a contact list, this involves not only verifying that expected actions work (positive testing) but also exploring how the system behaves when given invalid or unexpected input (negative testing) and examining the limits of its capabilities (boundary and edge case testing).

Positive Test Cases

These tests verify that the application functions correctly under normal, expected conditions. They confirm that the primary features work as intended.

Negative Test Cases

Negative tests are designed to uncover defects by providing invalid, unexpected, or malformed data, or by performing actions in an incorrect sequence.

Edge and Boundary Cases

Edge cases occur in unusual circumstances, often at the extremes of valid input ranges or in specific system states. Boundary cases specifically test values at the limits of acceptable input.

User Experience and Accessibility Test Cases

Beyond functional correctness, it's vital to test the user experience and ensure the application is accessible to all users.

Designing a Comprehensive Test Matrix for Contact Lists

A test matrix is a table that maps test cases to requirements, features, or test types. It provides a high-level overview of the testing effort and helps ensure that all critical areas are covered. For a contact list, a well-designed matrix can be an invaluable tool.

Elements of a Contact List Test Matrix

A typical test matrix for a contact list might include the following columns:

Example Contact List Test Matrix

Here is a sample test matrix demonstrating various test cases for a contact list feature. This matrix focuses on key functionalities and scenarios.

Test Case IDFeature AreaTest TypeRequirement IDTest Case SummaryPriorityStatusNotes/Defect ID
TC_CL_ADD_001Add ContactPositiveREQ_CL_ADD_01Verify successful addition of a new contact with valid details.High
TC_CL_ADD_002Add ContactNegativeREQ_CL_ADD_02Attempt to add contact with missing mandatory "First Name".High
TC_CL_ADD_003Add ContactNegativeREQ_CL_ADD_03Attempt to add contact with invalid "Email" format.Medium
TC_CL_ADD_004Add ContactEdgeREQ_CL_ADD_04Add contact with special characters in "First Name" (e.g., O'Malley).Medium
TC_CL_ADD_005Add ContactEdgeREQ_CL_ADD_05Add contact with a very long "First Name" (e.g., 100+ chars).Low
TC_CL_ADD_006Add ContactBoundaryREQ_CL_ADD_06Add contact with only required fields populated.High
TC_CL_EDIT_001Edit ContactPositiveREQ_CL_EDIT_01Verify successful editing of an existing contact's phone number.High
TC_CL_EDIT_002Edit ContactPositiveREQ_CL_EDIT_02Verify editing multiple fields of an existing contact.High
TC_CL_EDIT_003Edit ContactNegativeREQ_CL_EDIT_03Attempt to save contact edits with invalid "Email" format.Medium
TC_CL_EDIT_004Edit ContactEdgeREQ_CL_EDIT_04Edit a contact to have an empty "Last Name".Medium
TC_CL_DEL_001Delete ContactPositiveREQ_CL_DEL_01Verify successful deletion of a contact.High
TC_CL_DEL_002Delete ContactNegativeREQ_CL_DEL_02Attempt to delete a contact that does not exist.Low
TC_CL_SEARCH_001Search ContactPositiveREQ_CL_SCH_01Search for a contact by exact "First Name".High
TC_CL_SEARCH_002Search ContactPositiveREQ_CL_SCH_02Search for a contact by partial "Last Name".High
TC_CL_SEARCH_003Search ContactPositiveREQ_CL_SCH_03Search for a contact by "Email" address.High
TC_CL_SEARCH_004Search ContactNegativeREQ_CL_SCH_04Search for a contact with a query that yields no results.Medium
TC_CL_SEARCH_005Search ContactEdgeREQ_CL_SCH_05Search for contacts with names containing special characters.Medium
TC_CL_VIEW_001View ContactPositiveREQ_CL_VIEW_01Verify all fields are displayed correctly for a contact.High
TC_CL_SORT_001Sort ContactsPositiveREQ_CL_SORT_01Verify contacts are sorted alphabetically by "Last Name".High
TC_CL_SORT_002Sort ContactsPositiveREQ_CL_SORT_02Verify contacts are sorted alphabetically by "First Name".High
TC_CL_ACC_001AccessibilityAccessibilityREQ_ACC_01Verify contact list is navigable using screen reader.High
TC_CL_PERF_001PerformancePerformanceREQ_PERF_01Measure load time for contact list with 1000 contacts.Medium

This matrix provides a structured way to plan and track testing. The "Priority" column helps in deciding which tests to execute first, especially under time constraints.

Data Setup and Management for Contact List Testing

The effectiveness of test cases for a contact list is heavily dependent on the quality and variety of test data used. Without appropriate data, even the most meticulously crafted test cases may fail to uncover critical defects.

Strategies for Test Data Generation

Managing Test Data for Different Scenarios

Example Python Snippet for Data Generation (using Faker):


from faker import Faker
import random

fake = Faker()

def generate_contact_data(num_contacts=1):
    contacts = []
    for _ in range(num_contacts):
        first_name = fake.first_name()
        last_name = fake.last_name()
        phone_number = fake.phone_number()
        email = fake.email()
        contact = {
            "first_name": first_name,
            "last_name": last_name,
            "phone_number": phone_number,
            "email": email,
            "notes": fake.text(max_nb_chars=100)
        }
        contacts.append(contact)
    return contacts

# Generate 5 sample contacts
sample_contacts = generate_contact_data(5)
for contact in sample_contacts:
    print(contact)

# Example of generating data with specific constraints
def generate_complex_contact():
    first_name = fake.first_name() + random.choice(["", "-Jones", "'Smith", " O'Malley"])
    last_name = fake.last_name()
    phone_number = f"{random.randint(100, 999)}-{random.randint(100, 999)}-{random.randint(1000, 9999)}"
    email = f"{first_name.lower()}.{last_name.lower()}@{random.choice(['example.com', 'mail.net', 'service.org'])}"
    return {
        "first_name": first_name,
        "last_name": last_name,
        "phone_number": phone_number,
        "email": email
    }

complex_contact = generate_complex_contact()
print("\nComplex contact example:", complex_contact)

This example illustrates how to programmatically generate varied and realistic contact data, which is essential for thorough testing.

Prioritization and Traceability of Test Cases

Not all test cases are created equal. Prioritization helps focus testing efforts on the most critical functionalities, ensuring that the core features are stable. Traceability ensures that every requirement is covered by at least one test case.

Prioritizing Contact List Test Cases

Test case prioritization is typically based on:

Priority Levels:

Establishing Traceability

Traceability is the ability to link requirements to test cases, and often to defects as well. This is usually managed through a Requirements Traceability Matrix (RTM) or within a Test Management Tool.

Benefits of Traceability:

Tools like Jira with plugins (e.g., Zephyr, Xray), TestRail, or Azure DevOps can effectively manage traceability by linking requirements, test cases, and defects within a single platform.

Manual vs. Automated Testing for Contact Lists

Both manual testing and automated testing play vital roles in ensuring the quality of a contact list feature. They are not mutually exclusive but rather complementary approaches that offer different benefits.

The Role of Manual Testing

Manual testing involves a human tester interacting with the application to find defects. It excels in areas where human judgment, exploratory instincts, and user experience evaluation are paramount.

Example Manual Test: Imagine a user receives a notification that a contact has been updated, but when they open the contact, the changes aren't reflected. A manual tester might try to reproduce this by quickly editing a contact, then immediately navigating away and back, or even force-quitting the app and reopening it to see how state is managed.

The Power of Automated Testing

Automated testing uses scripts and tools to execute predefined test cases and compare actual results against expected results. It is highly effective for repetitive tasks, regression testing, and performance testing.

Example Automated Test (Conceptual using Appium for Android):


# Conceptual Appium script for adding a contact
from appium import webdriver
from appium.webdriver.common.mobileby import MobileBy
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

# Setup driver
desired_caps = {
    "platformName": "Android",
    "deviceName": "emulator-5554",
    "appPackage": "com.example.contacts",
    "appActivity": ".MainActivity",
    "automationName": "UiAutomator2"
}
driver = webdriver.Remote("http://localhost:4723/wd/hub", desired_caps)
wait = WebDriverWait(driver, 10)

try:
    # 1. Navigate to Add Contact screen
    add_button = wait.until(EC.element_to_be_clickable((MobileBy.ACCESSIBILITY_ID, "Add Contact")))
    add_button.click()

    # 2. Enter details
    first_name_field = wait.until(EC.element_to_be_clickable((MobileBy.ID, "com.example.contacts:id/first_name_edittext")))
    first_name_field.send_keys("Test")

    last_name_field = driver.find_element(MobileBy.ID, "com.example.contacts:id/last_name_edittext")
    last_name_field.send_keys("User")

    phone_field = driver.find_element(MobileBy.ID, "com.example.contacts:id/phone_edittext")
    phone_field.send_keys("9876543210")

    # 3. Save Contact
    save_button = driver.find_element(MobileBy.ID, "com.example.contacts:id/save_button")
    save_button.click()

    # 4. Verify contact is in list
    contact_name_in_list = wait.until(EC.presence_of_element_located((MobileBy.XPATH, "//android.widget.TextView[@text='Test User']")))
    assert contact_name_in_list.is_displayed()
    print("Contact 'Test User' found in list. Test Passed.")

except Exception as e:
    print(f"Test Failed: {e}")

finally:
    driver.quit()

This script automates the basic "add contact" flow. For a real-world scenario, you’d add assertions for confirmation messages, error handling, and verification of all fields.

Synergy of Manual and Automated Testing

The most effective strategy combines both. Manual testing can focus on exploratory testing, usability, and identifying new types of defects, while automated testing handles the heavy lifting of regression and repetitive checks.

Tools like SUSA (susatest.com) represent a modern approach by using autonomous exploration to discover new flows and potential issues, then automatically generating regression scripts (e.g., Appium for Android, Playwright for Web). This bridges the gap, allowing autonomous discovery to inform and enhance both manual and automated testing efforts. The autonomous platform explores the app itself, mimicking user behavior with various personas, and identifies dead buttons, crashes, ANRs, and UX friction. It then uses this discovered knowledge to auto-generate scripts, ensuring that the most critical user flows are covered by automation.

Writing Specific Test Cases: A Deeper Dive with Examples

Let's expand on the test cases introduced earlier and add more specific examples, focusing on scenarios that often cause issues in contact list applications.

Contact Creation Scenarios

Beyond the basic positive case, consider:

  1. TC_CL_ADD_007: Add Contact with Only Mandatory Fields
  1. TC_CL_ADD_008: Add Contact with All Optional Fields
  1. TC_CL_ADD_009: Attempt to Add Contact with Duplicate Phone Number
  1. TC_CL_ADD_010: Add Contact with International Phone Number Format
  1. TC_CL_ADD_011: Add Contact with Long Name (Boundary)

Contact Editing and Deletion Scenarios

  1. TC_CL_EDIT_005: Edit Contact - Change Phone Number and Email
  1. TC_CL_EDIT_006: Edit Contact - Remove All Details
  1. TC_CL_DEL_003: Cancel Deletion

Search and Filtering Scenarios

  1. TC_CL_SEARCH_006: Search for Contact with Special Characters
  1. TC_CL_SEARCH_007: Search by Partial Phone Number
  1. TC_CL_SEARCH_008: Case-Insensitive Search

Data Integrity and Edge Cases

  1. TC_CL_DATA_001: Contact with Empty Fields
  1. TC_CL_DATA_002: Contact with Extremely Long Notes
  1. TC_CL_DATA_003: Contacts with Identical Names (Boundary)

Integration with Autonomous Testing Platforms

While manual test case design is essential, it represents only one facet of a comprehensive testing strategy. Modern development cycles demand efficiency and broad coverage, which is where autonomous testing platforms like SUSA come into play.

How Autonomous Testing Complements Manual Test Cases

Autonomous testing platforms, such as SUSA (susatest.com), are designed to explore applications like a human user

Test Your App Autonomously

Upload your APK or URL. SUSA explores like 10 real users — finds bugs, accessibility violations, and security issues. No scripts.

Try SUSA Free

Related Articles