beam-ai-team/qa-test-case-writer

QA Test Case Writer

Generate comprehensive UI test cases for client-facing web applications and push them to Notion databases.

Safety Contract

Before creating test cases in Notion or writing local test artifacts, show the feature/module, source docs, target Notion database/page, test case prefix, and number of cases to create. Require explicit user approval in the current turn before writing files or updating Notion. Drafting test cases in chat does not require approval.

Workflow

Step 1: Gather Feature Information

Obtain complete feature details from the user through one of these methods:

1. Direct prompt: User explains the feature in conversation
2. File upload: User provides documentation (PRD, specs, design docs)
3. URL reference: User shares links to documentation

If information is incomplete, ask clarifying questions about:

• User flows and interactions
• Input fields and validation rules
• Expected behaviors and error states
• Authentication/authorization requirements
• Edge cases the user is aware of

Step 2: Determine Test Case ID Prefix

Ask user for:

1. Feature/Module name for the test case prefix (e.g., "SI" for Sign In, "WS" for Workspace)
2. Notion page URL where test cases should be created

If user provides a Notion URL, fetch the existing database to:

• Understand the existing test case ID pattern
• Check for any existing test cases to avoid duplicates
• Verify the database schema matches expected format

Step 3: Generate Test Cases

Create test cases covering these categories:

Happy Flow (P0-P1)

• Primary user journey completing successfully
• All valid inputs producing expected outputs
• Standard use cases working as designed

Edge Cases (P1-P2)

• Boundary values (min/max lengths, empty inputs)
• Special characters and unicode
• Concurrent actions
• Session handling (timeout, multiple tabs)
• Browser back/forward navigation
• Network interruptions during actions

Security Test Cases (P0-P1)

• SQL injection attempts in input fields
• XSS (Cross-Site Scripting) prevention
• CSRF token validation
• Authentication bypass attempts
• Authorization boundary testing
• Session fixation/hijacking prevention
• Sensitive data exposure in UI/console

Negative Test Cases (P1-P2)

• Invalid inputs and error handling
• Missing required fields
• Incorrect data formats
• Unauthorized access attempts

Step 4: Format Test Cases

Each test case must follow this exact schema:

| Field | Description | Example | |-------|-------------|---------| | Test Case ID | Prefix + sequential number | SI-001, WS-015 | | Test Case Title | Brief descriptive title | Valid login with correct credentials | | Pre-Condition | Required state before test | User exists with verified email | | Test Steps | Numbered steps to execute | 1) Enter email → Next 2) Enter password → Submit | | Expected Result | What should happen | Login success → Redirect to dashboard | | Test Data | Specific data for the test | Email: [email protected], Pass: ValidPass@123 | | Post Condition | State after test completes | Session active, user logged in | | Priority | P0 (Critical) to P3 (Low) | P0 |

Priority Guidelines

• P0 (Critical): Core functionality, security vulnerabilities, data integrity
• P1 (High): Important features, major user flows, significant edge cases
• P2 (Medium): Secondary features, minor edge cases, UI/UX issues
• P3 (Low): Nice-to-have validations, cosmetic checks

Step 5: Create in Notion

Use the existing Test Case Template to create test case pages efficiently.

Template Information

• Template Page URL: https://www.notion.so/2d92cadfbbbc80659271c50ea2d52415
• Template Data Source: collection://2d92cadf-bbbc-80a5-b179-000b911e5f5e

Option A: Add to Existing Feature Page (Preferred)

If user provides an existing feature page URL with an inline database:

1. Fetch the target page to get the inline database data source:

   Notion:notion-fetch with the page URL
   

2. Get the data source URL from the inline database (look for data-source-url in the response)

3. Create test case pages using Notion:notion-create-pages:

   {
     "parent": {"data_source_id": "<data-source-id-from-step-2>"},
     "pages": [
       {
         "properties": {
           "Test Case ID": "SI-001",
           "Test Case Title": "Valid login with correct credentials",
           "Pre-Condition": "User exists with verified email",
           "Test Steps": "1) Enter whitelisted email → Next 2) Enter correct password → Submit",
           "Expected Result": "Login success → Redirect to workspace/onboarding",
           "Test Data": "Email: [email protected], Pass: ValidPass@123",
           "Post Condition": "Session active",
           "Priority": "P0"
         }
       }
     ]
   }
   

Option B: Create New Feature Page from Template

If user needs a new feature page for test cases:

1. Duplicate the template page using Notion:notion-duplicate-page:

   {
     "page_id": "2d92cadfbbbc80659271c50ea2d52415"
   }
   

2. Rename the duplicated page using Notion:notion-update-page with the feature name

3. Fetch the new page to get its inline database data source URL

4. Create test case pages in the new database using Notion:notion-create-pages

Database Schema (Exact Property Names)

| Property | Type | Values | |----------|------|--------| | Test Case ID | title | e.g., "SI-001" | | Test Case Title | text | Descriptive title | | Pre-Condition | text | Required state before test | | Test Steps | text | Numbered steps | | Expected Result | text | What should happen | | Test Data | text | Specific test data | | Post Condition | text | State after test | | Priority | select | P0, P1, P2, P3 | | Status by Dev | status | Not started, Failed, Passed | | Status by QA | status | Not started, Failed, Passed |

Important:

• Use exact property names: "Pre-Condition" (with hyphen, capital C), "Post Condition" (space, capital C)
• Status fields default to "Not started" - no need to set them
• Create test cases in batches of 10-20 to avoid timeouts

Test Case Writing Guidelines

Test Steps Format

• Use numbered steps: 1) Action → Result 2) Action → Result
• Use arrows (→) to show flow between action and immediate result
• Keep steps atomic and verifiable
• Include UI element identifiers when helpful

Test Data Examples

• Use realistic but clearly test data: [email protected], ValidPass@123
• For sensitive data: use placeholders like [valid_token], [user_email]
• Include both valid and invalid examples as needed

Security Test Patterns

Reference references/security-tests.md for common security test patterns including:

• SQL injection payloads
• XSS vectors
• Authentication bypass techniques

Common UI Test Scenarios

Reference references/ui-test-patterns.md for:

• Form validation patterns
• Navigation flow tests
• Session management tests
• Accessibility considerations

Example Output

For a "Password Reset" feature, generate test cases like:

| ID | Title | Pre-Condition | Test Steps | Expected Result | Test Data | Post Condition | Priority | |----|-------|---------------|------------|-----------------|-----------|----------------|----------| | PR-001 | Valid password reset request | User exists with verified email | 1) Click "Forgot Password" 2) Enter registered email → Submit | Success message shown, reset email sent | Email: [email protected] | Reset token generated | P0 | | PR-002 | Reset with invalid email format | None | 1) Click "Forgot Password" 2) Enter invalid email → Submit | Validation error: "Invalid email format" | Email: invalid-email | No email sent | P1 | | PR-003 | SQL injection in email field | None | 1) Enter malicious input in email field → Submit | Input sanitized, appropriate error shown | Email: [email protected]' OR 1=1-- | No bypass, no data leak | P0 |