Manual Test Case Creation

Comprehensive guide to creating detailed, well-structured test cases.

When to Use Manual Creation

Precise Control

Exact wording and structure tailored to specific needs.

Custom Scenarios

Unique edge cases and workflows not covered by AI.

Exploratory Tests

Ad-hoc testing scenarios and specialized tests.

Accessing the Editor

From Dashboard

1. Navigate to CaseWriter Dashboard
2. Click "Write Test Case"
3. Editor opens in new view

From Test Repository

1. Navigate to Test Repository
2. Select target test set
3. Click "New Test Case"

From Test Case Detail

1. Open existing test case
2. Click "Edit" button
3. Editor opens with content

Test Case Title

Use action + object format for titles (e.g., "Login with valid email and password", "Add product to shopping cart"). Be specific and descriptive -- avoid vague titles like "Test 1" or "Check if it works". For naming conventions and priority guidelines, see Best Practices.

Priority & Complexity

Priority Levels

Choose priority based on business impact -- ask "What happens if this fails in production?" Priority ranges from Critical (system-breaking) to Low (nice-to-have). For the full priority assignment guide, see Best Practices.

Complexity Ratings

Complexity	Steps	Description
Simple	1-5 steps	Straightforward, minimal setup
Medium	6-15 steps	Moderate setup, some conditions
Complex	15+ steps	Extensive setup, multiple conditions

Helps With: Effort estimation, resource allocation, automation prioritization

Labels & Tags

By Feature Area

• authentication
• checkout
• search
• user-profile

By Test Type

• regression
• smoke-test
• sanity-check
• acceptance-test

By Platform

• web-only
• mobile-only
• cross-platform
• api-test

By Release

• sprint-12
• release-2.0
• hotfix

Preconditions

Good Preconditions

1. User has registered account: [email protected]
2. User is logged out of application
3. Login page is accessible and loaded
4. Test database has user record
5. Browser cache and cookies cleared
6. Internet connection is stable

Characteristics: Specific, measurable, and verifiable

Poor Preconditions

- User exists
- Page loaded

Problems: Vague, incomplete, not verifiable

Best Practices for Preconditions

• Be specific with exact values
• Include data setup requirements
• Specify user permissions/roles
• Mention environment configurations

Test Steps

Step Structure

Each step has two parts: Action (what to do) and Expected Result (what should happen)

Example Steps

Step 1:

• Action: Navigate to https://app.example.com/login
• Expected Result: Login page loads with email and password fields visible

Step 2:

• Action: Enter "[email protected]" in Email Address field
• Expected Result: Email is displayed, field border turns green

Step 3:

• Action: Enter "SecurePass123!" in Password field
• Expected Result: Password is masked with dots, field accepted

Step 4:

• Action: Click "Login" button
• Expected Result: Loading indicator appears, redirected to dashboard, welcome message shown

Writing Guidelines

Effective Actions

Good	Bad
Click "Login" button in top right corner	Login
Enter "[email protected]" in Email field	Enter data
Select "United States" from Country dropdown	Check the thing

Good actions are: Specific, clear, actionable - exact locations and values

Poor actions are: Vague, unclear, ambiguous - no specific details

Best Practices Summary

• Use action + object format for titles
• Be specific in all fields
• One action per test step
• Include observable expected results
• Use templates for common patterns
• Apply labels for easy filtering

Next Steps

• Test Repository - Manage your tests
• Best Practices - Quality guidelines