Marketing Planning Module - Use Cases, Test Cases & Exit Criteria¶
Document Overview¶
This document provides comprehensive use cases, test cases, and acceptance criteria for the Marketing Planning module. It serves as the basis for User Acceptance Testing (UAT) and defines the exit criteria for each implementation phase.
1. Use Cases¶
1.1 Campaign Management Use Cases¶
UC-CAM-001: Create New Campaign¶
| Field | Description |
|---|---|
| ID | UC-CAM-001 |
| Name | Create New Campaign |
| Actor | Team Member (Agent/Admin) |
| Preconditions | User is logged in and has appropriate permissions |
| Description | User creates a new marketing campaign/project |
Main Flow: 1. User clicks "+" button in the campaign sidebar 2. System displays "Create Campaign" modal 3. User enters: - Campaign name (required) - Description (optional) - Goals (optional) - Targeted approach (optional) - Start date (optional) - End date (optional) 4. User clicks "Create Campaign" 5. System validates input (campaign name must not be empty) 6. System creates campaign with status "CREATED" 7. System logs the creation event 8. System refreshes campaign tree 9. System displays success message
Alternative Flow - Validation Error: - 5a. Campaign name is empty - 5a1. System displays warning "Campaign name is required" - 5a2. User corrects input - 5a3. Return to step 4
Postconditions: - New campaign exists in database with status "CREATED" - Change log entry created for campaign creation - Campaign appears in sidebar tree
UC-CAM-002: View Campaign Details¶
| Field | Description |
|---|---|
| ID | UC-CAM-002 |
| Name | View Campaign Details |
| Actor | Team Member |
| Preconditions | At least one campaign exists |
Main Flow: 1. User clicks on a campaign in the sidebar tree 2. System loads campaign data including activities 3. System populates campaign header area with: - Campaign name - Description - Status badge - Date range (if set) 4. System expands campaign node to show activities 5. If activities exist, system auto-selects first activity 6. System enables campaign action buttons
Postconditions: - Campaign details displayed in header area - Activities visible in tree - First activity loaded (if exists)
UC-CAM-003: Update Campaign Information¶
| Field | Description |
|---|---|
| ID | UC-CAM-003 |
| Name | Update Campaign Information |
| Actor | Team Member |
| Preconditions | Campaign is selected and not in "ENDED" status |
Main Flow: 1. User modifies campaign fields (name, description, goals, dates) 2. User clicks "Save" or equivalent action 3. System validates changes 4. System updates campaign in database 5. System logs the change 6. System displays success message 7. System refreshes campaign header
Alternative Flow - Unsaved Changes Warning: - 1a. User selects different campaign without saving - 1a1. System prompts "You have unsaved changes. Discard them?" - 1a2. User confirms discard → changes lost, new campaign loaded - 1a3. User cancels → stays on current campaign
Postconditions: - Campaign updated in database - Change log entry created - UI reflects updated information
UC-CAM-004: Change Campaign Status¶
| Field | Description |
|---|---|
| ID | UC-CAM-004 |
| Name | Change Campaign Status |
| Actor | Team Member |
| Preconditions | Campaign is selected |
Main Flow: 1. User clicks "Campaign Status" dropdown 2. System shows available status transitions based on current status 3. User selects new status 4. System validates transition is allowed 5. System updates campaign status 6. System logs status change 7. System sends WhatsApp notification to campaign creator 8. System refreshes UI with new status badge
Alternative Flow - Invalid Transition: - 4a. Transition not allowed (e.g., CREATED → COMPLETED_SCHEDULED) - 4a1. System displays error "Invalid status transition" - 4a2. Status remains unchanged
Alternative Flow - Activities Not Approved: - 4b. Attempting WORK_IN_PROGRESS → COMPLETED_SCHEDULED but activities not all approved - 4b1. System displays error "Cannot complete campaign: Activity 'X' is not approved" - 4b2. Status remains unchanged
Valid Status Transitions: | From | To | |------|-----| | CREATED | WORK_IN_PROGRESS | | WORK_IN_PROGRESS | COMPLETED_SCHEDULED (if all activities approved) | | COMPLETED_SCHEDULED | STARTED | | STARTED | ONGOING, PAUSED, ENDED | | ONGOING | PAUSED, ENDED | | PAUSED | ONGOING, ENDED |
Postconditions: - Campaign status updated - Change log entry created with old and new status - WhatsApp notification sent
1.2 Activity Management Use Cases¶
UC-ACT-001: Create New Activity¶
| Field | Description |
|---|---|
| ID | UC-ACT-001 |
| Name | Create New Activity |
| Actor | Team Member |
| Preconditions | Campaign is selected |
Main Flow: 1. User clicks "New Activity" button 2. System prompts for activity name 3. User enters activity name 4. System creates activity with: - Default type (INSTAGRAM_REEL) - Status "CREATED" - Link to current campaign 5. System logs creation event 6. System refreshes tree and selects new activity 7. System displays activity in workspace for editing
Postconditions: - New activity exists with status "CREATED" - Activity linked to campaign - Activity appears in tree under campaign
UC-ACT-002: Edit Activity Details¶
| Field | Description |
|---|---|
| ID | UC-ACT-002 |
| Name | Edit Activity Details |
| Actor | Team Member |
| Preconditions | Activity is selected and status is not "APPROVED" |
Main Flow: 1. User modifies activity fields: - Activity name - Activity type (dropdown) - Start date - Due date - Description/Goals - Story text (rich text editor) 2. User clicks "Save" 3. System validates input 4. System updates activity 5. System logs changes 6. System displays success message
Alternative Flow - Approved Activity: - 1a. Activity status is "APPROVED" - 1a1. All form fields are disabled - 1a2. "Approved" indicator is displayed - 1a3. User cannot make changes
Postconditions: - Activity updated in database - Change log entries created - Dirty flag cleared
UC-ACT-003: Assign Activity to Team Members¶
| Field | Description |
|---|---|
| ID | UC-ACT-003 |
| Name | Assign Activity to Team Members |
| Actor | Team Member |
| Preconditions | Activity is selected, team members exist |
Main Flow: 1. User selects one or more team members from "Assigned To" dropdown 2. User clicks "Save" 3. System creates assignment records 4. If activity status is "CREATED", system changes to "ASSIGNED" 5. System logs assignment changes 6. System displays success message
Postconditions: - Assignment records created in mkt_activityassignment - Activity status changed to "ASSIGNED" if was "CREATED" - Assignees displayed in activity form
UC-ACT-004: Send Activity for Review¶
| Field | Description |
|---|---|
| ID | UC-ACT-004 |
| Name | Send Activity for Review |
| Actor | Team Member |
| Preconditions | Activity status is "WORK_IN_PROGRESS" |
Main Flow: 1. User clicks "Send for Review" button 2. System displays reviewer selection modal 3. User selects a reviewer (admin or reviewer role) 4. User clicks "Send" 5. System validates activity is in WORK_IN_PROGRESS status 6. System updates activity: - Status → "SENT_FOR_REVIEW" - Reviewer ID set 7. System logs status change 8. System sends WhatsApp notification to reviewer 9. System refreshes UI
Alternative Flow - Wrong Status: - 5a. Activity not in WORK_IN_PROGRESS - 5a1. System displays error "Activity must be in WORK_IN_PROGRESS status" - 5a2. Modal remains open
Postconditions: - Activity status is "SENT_FOR_REVIEW" - Reviewer assigned to activity - WhatsApp notification sent to reviewer - Change log entry created
UC-ACT-005: Approve Activity¶
| Field | Description |
|---|---|
| ID | UC-ACT-005 |
| Name | Approve Activity |
| Actor | Reviewer/Admin |
| Preconditions | Activity status is "SENT_FOR_REVIEW", user is the assigned reviewer or admin |
Main Flow: 1. User clicks "Approve" button 2. System changes activity status to "APPROVED" 3. System logs status change 4. System sends WhatsApp notification to activity creator 5. System disables activity form fields 6. System displays "Approved" indicator 7. System refreshes tree with new status badge
Postconditions: - Activity status is "APPROVED" - Activity cannot be edited - WhatsApp notification sent to creator - Visual indicator shown
UC-ACT-006: Return Activity for Revision¶
| Field | Description |
|---|---|
| ID | UC-ACT-006 |
| Name | Return Activity for Revision |
| Actor | Reviewer/Admin |
| Preconditions | Activity status is "SENT_FOR_REVIEW" |
Main Flow: 1. User clicks "Return" button 2. System prompts for optional reason 3. User enters reason (optional) and confirms 4. System changes activity status to "WORK_IN_PROGRESS" 5. System logs status change with reason 6. System sends WhatsApp notification to activity creator 7. System enables activity form fields 8. System refreshes tree
Postconditions: - Activity status is "WORK_IN_PROGRESS" - Activity can be edited again - WhatsApp notification sent to creator
UC-ACT-007: Revoke Approved Activity (Admin Only)¶
| Field | Description |
|---|---|
| ID | UC-ACT-007 |
| Name | Revoke Approved Activity |
| Actor | Admin |
| Preconditions | Activity status is "APPROVED", user has admin role |
Main Flow: 1. Admin changes activity status back to "WORK_IN_PROGRESS" 2. System validates user has admin role 3. System updates activity status 4. System checks parent campaign status 5. If campaign was "COMPLETED_SCHEDULED", system changes it to "WORK_IN_PROGRESS" 6. System logs both status changes 7. System sends WhatsApp notifications 8. System enables activity form fields
Postconditions: - Activity status is "WORK_IN_PROGRESS" - Campaign status updated if necessary - Change logs created for both entities - Notifications sent
1.3 Media Management Use Cases¶
UC-MED-001: Add Media via URL¶
| Field | Description |
|---|---|
| ID | UC-MED-001 |
| Name | Add Media via URL |
| Actor | Team Member |
| Preconditions | Activity selected, status not "APPROVED" |
Main Flow: 1. User clicks "Add Media" button 2. System displays media form modal with three mode tabs: Upload, URL, Existing 3. User selects "URL" tab 4. User enters: - Media type (Image/Video/Graphic) - Media URL (required) - File name (optional) - Description (optional) 5. User clicks "Add" 6. System validates URL is not empty 7. System creates media record linked to activity 8. System refreshes media gallery 9. System displays success message
Alternative Flow - Missing URL: - 6a. Media URL is empty - 6a1. System displays warning "Media URL is required" - 6a2. User corrects input
Postconditions: - Media record created in database - Media appears in gallery - Activity shows updated media list
UC-MED-002: Upload Media File¶
| Field | Description |
|---|---|
| ID | UC-MED-002 |
| Name | Upload Media File to Campaign CDN |
| Actor | Team Member |
| Preconditions | Activity selected, campaign exists, status not "APPROVED" |
Main Flow:
1. User clicks "Add Media" button
2. System displays media form modal
3. User selects a file via the file input (image, PDF, audio, or video)
4. User optionally enters a filename (auto-populated from file name if blank)
5. User clicks "Upload" button
6. System sends multipart request to POST /media/marketing/upload with file, campaignId, and basename
7. Backend detects MIME type from file bytes (not extension), validates against allowed types
8. Backend checks file size against per-type limit (image: 20 MB, PDF: 10 MB, audio: 50 MB, video: 500 MB)
9. Backend stores file as-is on S3 under campaigns/{slug}-{campaignId}/ prefix
10. System displays upload progress bar
11. On success, CDN URL is populated into the Media URL field
12. User clicks "Add" to save the media record (existing URL-based flow)
13. System refreshes media gallery
Alternative Flow - Invalid File Type: - 7a. MIME type not in any configured file type group - 7a1. Backend returns error "File type not allowed" - 7a2. System displays error notification
Alternative Flow - File Too Large: - 8a. File exceeds per-type maximum - 8a1. Backend returns error with type-specific limit - 8a2. System displays error notification
Postconditions: - File stored in S3 bucket under campaign prefix - CDN URL returned and populated into media URL field - Media record saved via standard media/write endpoint - Media appears in gallery
UC-MED-003: Upload Media File (Superseded)¶
Note: This use case described a presigned URL flow for large files (>=20MB). The actual implementation uses server-side streaming for all file sizes via
POST /media/marketing/upload. The Jetty multipart limit is set to 500 MB to accommodate video files. Per-type size limits are enforced server-side before S3 upload. This use case is retained for reference but UC-MED-002 covers the implemented flow.
UC-MED-004: Add Existing Media from Other Activities¶
| Field | Description |
|---|---|
| ID | UC-MED-004 |
| Name | Add Existing Media from Other Activities |
| Actor | Team Member |
| Preconditions | Activity selected, status not "APPROVED", other activities have media |
Main Flow: 1. User clicks "Add Media" button 2. System displays media form modal 3. User selects "Existing" tab 4. System loads and displays media from other activities in a grid 5. User can filter by: - Scope: "Same Campaign" or "All Campaigns" - Media type: All, Images, Videos, Graphics 6. User clicks on a media item to select it 7. System highlights selected item and shows preview 8. User clicks "Add Selected" 9. System creates link record associating media with current activity 10. System refreshes media gallery 11. System displays success message
Alternative Flow - No Existing Media: - 4a. No media found matching filters - 4a1. System displays "No reusable media found" message - 4a2. User can change filters or switch to Upload/URL mode
Alternative Flow - Media Already Linked: - 9a. Media is already linked to this activity - 9a1. System displays warning "Media is already linked to this activity" - 9a2. Link not duplicated
Postconditions: - Link record created (no file duplication) - Media appears in gallery - Same media now linked to multiple activities
UC-MED-005: Remove Media Artifact¶
| Field | Description |
|---|---|
| ID | UC-MED-005 |
| Name | Remove Media Artifact |
| Actor | Team Member |
| Preconditions | Activity has media, status not "APPROVED" |
Main Flow: 1. User clicks remove button on media item 2. System prompts for confirmation "Remove this media from the activity?" 3. User confirms removal 4. System checks if media is shared with other activities 5. If shared: System removes link record only (file preserved) 6. If not shared: System removes link record and optionally deletes file from S3 7. System refreshes media gallery 8. System displays success message
Alternative Flow - Cancelled: - 3a. User cancels - 3a1. No action taken
Postconditions: - Link record deleted - Media gallery updated - If media was shared: file remains in S3 for other activities - If media was not shared: file may be deleted from S3
1.4 Audience Segment Management Use Cases¶
UC-AUD-001: Add Audience Segment to Activity¶
| Field | Description |
|---|---|
| ID | UC-AUD-001 |
| Name | Add Audience Segment |
| Actor | Team Member |
| Preconditions | Activity selected, audience segments exist |
Main Flow: 1. User selects audience segment from dropdown 2. System checks if segment already added 3. System adds segment to activity's audience list 4. System displays segment as tag 5. Activity marked as dirty (needs save)
Alternative Flow - Already Added: - 2a. Segment already in list - 2a1. System displays info "Audience segment already added" - 2a2. No duplicate created
Postconditions: - Audience segment linked to activity (in memory) - Tag displayed in UI - Changes saved when activity is saved
1.5 Navigation Use Cases¶
UC-NAV-001: Navigate Between Activities with Unsaved Changes¶
| Field | Description |
|---|---|
| ID | UC-NAV-001 |
| Name | Navigate with Unsaved Changes |
| Actor | Team Member |
| Preconditions | Activity has unsaved changes |
Main Flow: 1. User clicks on different activity or campaign 2. System detects unsaved changes 3. System prompts "You have unsaved changes. Discard them?" 4. User chooses: - Confirm: Changes discarded, navigation proceeds - Cancel: User stays on current activity
Postconditions: - If confirmed: New item loaded, changes lost - If cancelled: User remains on current item
1.6 Notification Use Cases¶
UC-NOT-001: WhatsApp Status Change Notification¶
| Field | Description |
|---|---|
| ID | UC-NOT-001 |
| Name | Status Change Notification |
| Actor | System |
| Trigger | Campaign or Activity status changes |
Main Flow: 1. System detects status change 2. System identifies notification recipients: - Campaign creator - Activity creator (if activity change) 3. System retrieves WhatsApp numbers from team member records 4. System sends WhatsApp message with: - Entity type (Campaign/Activity) - Entity name - Old status - New status - Timestamp 5. System marks notification as sent in changelog
Postconditions: - WhatsApp messages delivered - Changelog updated with notification status
UC-NOT-002: Review Request Notification¶
| Field | Description |
|---|---|
| ID | UC-NOT-002 |
| Name | Review Request Notification |
| Actor | System |
| Trigger | Activity sent for review |
Main Flow: 1. System identifies assigned reviewer 2. System retrieves reviewer's WhatsApp number 3. System sends message with: - Activity name - Campaign name - Requester name - Link/instructions to review
Postconditions: - Reviewer notified via WhatsApp
2. Test Cases¶
2.1 Campaign Test Cases¶
TC-CAM-001: Create Campaign - Happy Path¶
| Field | Value |
|---|---|
| Test ID | TC-CAM-001 |
| Use Case | UC-CAM-001 |
| Priority | High |
| Type | Functional |
Preconditions: - User logged in with agent or admin role - Marketing Planning page loaded
Test Steps: | Step | Action | Expected Result | |------|--------|-----------------| | 1 | Click "+" button in sidebar | Create Campaign modal opens | | 2 | Enter "Summer Sale 2025" in Campaign Name | Field populated | | 3 | Enter "Promote summer collection" in Description | Field populated | | 4 | Enter "Increase sales by 20%" in Goals | Field populated | | 5 | Select start date: 2025-06-01 | Date selected | | 6 | Select end date: 2025-08-31 | Date selected | | 7 | Click "Create Campaign" | Modal closes, success message displayed | | 8 | Verify sidebar | New campaign appears in tree | | 9 | Click on new campaign | Campaign header shows all entered data | | 10 | Check database | Record exists with status "CREATED" |
Expected Result: Campaign created successfully with all fields populated
TC-CAM-002: Create Campaign - Validation Error¶
| Field | Value |
|---|---|
| Test ID | TC-CAM-002 |
| Use Case | UC-CAM-001 |
| Priority | High |
| Type | Negative |
Test Steps: | Step | Action | Expected Result | |------|--------|-----------------| | 1 | Click "+" button in sidebar | Modal opens | | 2 | Leave Campaign Name empty | Field empty | | 3 | Click "Create Campaign" | Warning displayed: "Campaign name is required" | | 4 | Modal remains open | User can correct input |
TC-CAM-003: Campaign Status Transition - Valid¶
| Field | Value |
|---|---|
| Test ID | TC-CAM-003 |
| Use Case | UC-CAM-004 |
| Priority | High |
| Type | Functional |
Preconditions: - Campaign exists with status "CREATED"
Test Steps: | Step | Action | Expected Result | |------|--------|-----------------| | 1 | Select campaign | Campaign loaded | | 2 | Click Campaign Status dropdown | Dropdown opens | | 3 | Select "Start Work" (WORK_IN_PROGRESS) | Status changes | | 4 | Verify status badge | Shows "Work in Progress" | | 5 | Check database | Status updated to WORK_IN_PROGRESS | | 6 | Check changelog | Entry exists for status change |
TC-CAM-004: Campaign Status Transition - Invalid¶
| Field | Value |
|---|---|
| Test ID | TC-CAM-004 |
| Use Case | UC-CAM-004 |
| Priority | High |
| Type | Negative |
Preconditions: - Campaign exists with status "CREATED"
Test Steps: | Step | Action | Expected Result | |------|--------|-----------------| | 1 | Attempt to change status directly to "COMPLETED_SCHEDULED" via API | Error returned | | 2 | Verify error message | "Invalid status transition from CREATED to COMPLETED_SCHEDULED" | | 3 | Check database | Status remains "CREATED" |
TC-CAM-005: Complete Campaign - Activities Not Approved¶
| Field | Value |
|---|---|
| Test ID | TC-CAM-005 |
| Use Case | UC-CAM-004 |
| Priority | High |
| Type | Negative |
Preconditions: - Campaign in WORK_IN_PROGRESS status - Campaign has 2 activities: one APPROVED, one WORK_IN_PROGRESS
Test Steps: | Step | Action | Expected Result | |------|--------|-----------------| | 1 | Attempt to change campaign to "COMPLETED_SCHEDULED" | Error displayed | | 2 | Verify error | "Cannot complete campaign: Activity 'X' is not approved" | | 3 | Status remains | WORK_IN_PROGRESS |
2.2 Activity Test Cases¶
TC-ACT-001: Create Activity¶
| Field | Value |
|---|---|
| Test ID | TC-ACT-001 |
| Use Case | UC-ACT-001 |
| Priority | High |
| Type | Functional |
Preconditions: - Campaign selected
Test Steps: | Step | Action | Expected Result | |------|--------|-----------------| | 1 | Click "New Activity" | Prompt appears | | 2 | Enter "Instagram Launch Post" | Name entered | | 3 | Confirm | Activity created | | 4 | Verify tree | Activity appears under campaign | | 5 | Verify workspace | Activity form populated with defaults | | 6 | Verify status | "CREATED" | | 7 | Verify default type | INSTAGRAM_REEL |
TC-ACT-002: Edit Activity Details¶
| Field | Value |
|---|---|
| Test ID | TC-ACT-002 |
| Use Case | UC-ACT-002 |
| Priority | High |
| Type | Functional |
Preconditions: - Activity exists with status "WORK_IN_PROGRESS"
Test Steps: | Step | Action | Expected Result | |------|--------|-----------------| | 1 | Select activity | Form populated | | 2 | Change name to "Updated Name" | Field updated | | 3 | Change type to "FACEBOOK_REEL" | Dropdown changed | | 4 | Enter due date | Date set | | 5 | Enter description | Text entered | | 6 | Enter story text in rich editor | HTML content created | | 7 | Click Save | Success message | | 8 | Reload page | All changes persisted |
TC-ACT-003: Edit Approved Activity - Blocked¶
| Field | Value |
|---|---|
| Test ID | TC-ACT-003 |
| Use Case | UC-ACT-002 |
| Priority | High |
| Type | Negative |
Preconditions: - Activity exists with status "APPROVED"
Test Steps: | Step | Action | Expected Result | |------|--------|-----------------| | 1 | Select approved activity | Form populated | | 2 | Verify "Approved" indicator | Visible at top | | 3 | Try to edit name field | Field is disabled | | 4 | Try to edit description | Field is disabled | | 5 | Try to edit rich text | Editor is disabled | | 6 | Verify Save button | Disabled |
TC-ACT-004: Send for Review - Happy Path¶
| Field | Value |
|---|---|
| Test ID | TC-ACT-004 |
| Use Case | UC-ACT-004 |
| Priority | High |
| Type | Functional |
Preconditions: - Activity in WORK_IN_PROGRESS status - At least one reviewer exists
Test Steps: | Step | Action | Expected Result | |------|--------|-----------------| | 1 | Click "Send for Review" | Modal opens | | 2 | Select reviewer from dropdown | Reviewer selected | | 3 | Click "Send" | Modal closes | | 4 | Verify status | "SENT_FOR_REVIEW" | | 5 | Verify changelog | Entry with reviewer ID | | 6 | Verify notification | WhatsApp sent to reviewer |
TC-ACT-005: Approve Activity¶
| Field | Value |
|---|---|
| Test ID | TC-ACT-005 |
| Use Case | UC-ACT-005 |
| Priority | High |
| Type | Functional |
Preconditions: - Activity in SENT_FOR_REVIEW status - User is assigned reviewer or admin
Test Steps: | Step | Action | Expected Result | |------|--------|-----------------| | 1 | Select activity pending review | Form loads | | 2 | Verify "Approve" button visible | Button present | | 3 | Click "Approve" | Status changes | | 4 | Verify status | "APPROVED" | | 5 | Verify indicator | "Approved" banner shown | | 6 | Verify form | All fields disabled | | 7 | Verify notification | WhatsApp sent to creator |
TC-ACT-006: Return Activity¶
| Field | Value |
|---|---|
| Test ID | TC-ACT-006 |
| Use Case | UC-ACT-006 |
| Priority | High |
| Type | Functional |
Test Steps: | Step | Action | Expected Result | |------|--------|-----------------| | 1 | Select activity in SENT_FOR_REVIEW | Form loads | | 2 | Click "Return" | Prompt for reason | | 3 | Enter "Needs more detail in description" | Reason entered | | 4 | Confirm | Status changes | | 5 | Verify status | "WORK_IN_PROGRESS" | | 6 | Verify form | Fields enabled again | | 7 | Verify changelog | Entry includes reason |
TC-ACT-007: Revoke Approved Activity Cascades to Campaign¶
| Field | Value |
|---|---|
| Test ID | TC-ACT-007 |
| Use Case | UC-ACT-007 |
| Priority | High |
| Type | Functional |
Preconditions: - Campaign in COMPLETED_SCHEDULED status - All activities APPROVED - User is admin
Test Steps: | Step | Action | Expected Result | |------|--------|-----------------| | 1 | Select an approved activity | Form loads | | 2 | As admin, change status to WORK_IN_PROGRESS | Status changes | | 3 | Verify activity status | WORK_IN_PROGRESS | | 4 | Verify campaign status | Automatically changed to WORK_IN_PROGRESS | | 5 | Verify changelog | Two entries (activity + campaign) |
2.3 Media Test Cases¶
TC-MED-001: Add Image Media via URL¶
| Field | Value |
|---|---|
| Test ID | TC-MED-001 |
| Use Case | UC-MED-001 |
| Priority | Medium |
| Type | Functional |
Test Steps: | Step | Action | Expected Result | |------|--------|-----------------| | 1 | Click "Add Media" | Modal opens with three tabs | | 2 | Click "URL" tab | URL input section displayed | | 3 | Select type "Image" | Type selected | | 4 | Enter URL: "https://example.com/image.jpg" | URL entered | | 5 | Enter filename: "promo-banner.jpg" | Filename entered | | 6 | Click "Add" | Modal closes | | 7 | Verify gallery | Image thumbnail appears | | 8 | Verify database | Record created with correct fields |
TC-MED-002: Add Media via URL - Empty URL¶
| Field | Value |
|---|---|
| Test ID | TC-MED-002 |
| Use Case | UC-MED-001 |
| Priority | Medium |
| Type | Negative |
Test Steps: | Step | Action | Expected Result | |------|--------|-----------------| | 1 | Click "Add Media" | Modal opens | | 2 | Click "URL" tab | URL section displayed | | 3 | Leave URL empty | Field empty | | 4 | Click "Add" | Warning: "Please enter a media URL" | | 5 | Modal stays open | User can correct |
TC-MED-003: Add Media to Approved Activity - Blocked¶
| Field | Value |
|---|---|
| Test ID | TC-MED-003 |
| Use Case | UC-MED-001, UC-MED-002 |
| Priority | Medium |
| Type | Negative |
Preconditions: - Activity is APPROVED
Test Steps: | Step | Action | Expected Result | |------|--------|-----------------| | 1 | Select approved activity | Form loads | | 2 | Verify "Add Media" button | Not visible or disabled | | 3 | Attempt via API | Error: "Cannot add media to approved activity" |
TC-MED-004: Upload Small Image File¶
| Field | Value |
|---|---|
| Test ID | TC-MED-004 |
| Use Case | UC-MED-002 |
| Priority | High |
| Type | Functional |
Preconditions: - S3 upload is enabled and configured - Activity selected, status not APPROVED
Test Steps: | Step | Action | Expected Result | |------|--------|-----------------| | 1 | Click "Add Media" | Modal opens with Upload tab selected | | 2 | Select type "Image" | Type selected | | 3 | Click dropzone | File picker opens | | 4 | Select 5MB JPG file | File name and size displayed | | 5 | Enter description: "Product photo" | Description entered | | 6 | Click "Upload" | Progress bar appears | | 7 | Wait for upload | Progress reaches 100% | | 8 | Verify modal closes | Success message displayed | | 9 | Verify gallery | Image thumbnail appears (loaded from CDN URL) | | 10 | Click thumbnail in gallery | Media opens in new browser tab | | 11 | Verify S3 | File exists in bucket | | 12 | Verify database | Record has S3 public URL |
TC-MED-005: Upload Large Video File via Pre-signed URL¶
| Field | Value |
|---|---|
| Test ID | TC-MED-005 |
| Use Case | UC-MED-003 |
| Priority | High |
| Type | Functional |
Preconditions: - S3 upload is enabled and configured - Activity selected, status not APPROVED
Test Steps: | Step | Action | Expected Result | |------|--------|-----------------| | 1 | Click "Add Media" | Modal opens | | 2 | Select type "Video" | Type selected | | 3 | Drag 50MB MP4 file to dropzone | File name and size displayed | | 4 | Click "Upload" | Progress bar appears | | 5 | Verify network tab | Direct PUT to S3 URL (not API server) | | 6 | Wait for upload | Progress reaches 100% | | 7 | Verify confirmation request | API call to /media/confirm | | 8 | Verify modal closes | Success message displayed | | 9 | Verify gallery | Video item appears | | 10 | Verify S3 | File exists in bucket | | 11 | Verify database | Record has S3 public URL |
TC-MED-006: Upload Invalid File Type¶
| Field | Value |
|---|---|
| Test ID | TC-MED-006 |
| Use Case | UC-MED-002 |
| Priority | Medium |
| Type | Negative |
Test Steps: | Step | Action | Expected Result | |------|--------|-----------------| | 1 | Click "Add Media" | Modal opens | | 2 | Select type "Image" | Type selected | | 3 | Select .exe file | Warning: "File type not allowed for selected media type" | | 4 | File not accepted | Dropzone remains empty |
TC-MED-007: Upload File Exceeds Size Limit¶
| Field | Value |
|---|---|
| Test ID | TC-MED-007 |
| Use Case | UC-MED-002, UC-MED-003 |
| Priority | Medium |
| Type | Negative |
Test Steps: | Step | Action | Expected Result | |------|--------|-----------------| | 1 | Click "Add Media" | Modal opens | | 2 | Select type "Video" | Type selected | | 3 | Select 300MB video file | Warning: "File too large. Maximum size is 250MB" | | 4 | File not accepted | Dropzone remains empty |
TC-MED-008: Drag and Drop Upload¶
| Field | Value |
|---|---|
| Test ID | TC-MED-008 |
| Use Case | UC-MED-002 |
| Priority | Medium |
| Type | Functional |
Test Steps: | Step | Action | Expected Result | |------|--------|-----------------| | 1 | Click "Add Media" | Modal opens | | 2 | Drag image file over dropzone | Dropzone highlights (visual feedback) | | 3 | Drop file | File accepted, name and size displayed | | 4 | Click "Upload" | Upload proceeds normally | | 5 | Verify success | File uploaded to S3 |
TC-MED-009: Select Existing Media from Same Campaign¶
| Field | Value |
|---|---|
| Test ID | TC-MED-009 |
| Use Case | UC-MED-004 |
| Priority | High |
| Type | Functional |
Preconditions: - Campaign has multiple activities - Another activity in the campaign has media attached
Test Steps: | Step | Action | Expected Result | |------|--------|-----------------| | 1 | Click "Add Media" | Modal opens | | 2 | Click "Existing" tab | Grid of existing media displayed | | 3 | Verify filter is "Same Campaign" | Default filter applied | | 4 | Verify media from other activities visible | Grid populated | | 5 | Click on a media item | Item highlighted, preview shown | | 6 | Click "Add Selected" | Modal closes | | 7 | Verify gallery | Media appears in current activity | | 8 | Verify original activity | Media still appears there too | | 9 | Verify database | Link record created (not duplicate media) |
TC-MED-010: Select Existing Media from All Campaigns¶
| Field | Value |
|---|---|
| Test ID | TC-MED-010 |
| Use Case | UC-MED-004 |
| Priority | Medium |
| Type | Functional |
Preconditions: - Multiple campaigns exist with media
Test Steps: | Step | Action | Expected Result | |------|--------|-----------------| | 1 | Click "Add Media" | Modal opens | | 2 | Click "Existing" tab | Grid displayed | | 3 | Change filter to "All Campaigns" | Grid refreshes | | 4 | Verify media from other campaigns visible | More items shown | | 5 | Select media from different campaign | Item highlighted | | 6 | Click "Add Selected" | Media linked to current activity |
TC-MED-011: Filter Existing Media by Type¶
| Field | Value |
|---|---|
| Test ID | TC-MED-011 |
| Use Case | UC-MED-004 |
| Priority | Low |
| Type | Functional |
Preconditions: - Existing media includes images and videos
Test Steps: | Step | Action | Expected Result | |------|--------|-----------------| | 1 | Click "Add Media" → "Existing" tab | Grid displayed | | 2 | Select type filter "Images" | Only images shown | | 3 | Select type filter "Videos" | Only videos shown | | 4 | Select type filter "All Types" | All media shown |
TC-MED-012: No Existing Media Available¶
| Field | Value |
|---|---|
| Test ID | TC-MED-012 |
| Use Case | UC-MED-004 |
| Priority | Low |
| Type | Functional |
Preconditions: - No other activities have media
Test Steps: | Step | Action | Expected Result | |------|--------|-----------------| | 1 | Click "Add Media" → "Existing" tab | Empty state displayed | | 2 | Verify message | "No reusable media found" | | 3 | User can switch to Upload or URL tab | Other tabs functional |
TC-MED-013: Remove Shared Media¶
| Field | Value |
|---|---|
| Test ID | TC-MED-013 |
| Use Case | UC-MED-005 |
| Priority | High |
| Type | Functional |
Preconditions: - Media is linked to two activities (Activity A and Activity B)
Test Steps: | Step | Action | Expected Result | |------|--------|-----------------| | 1 | Select Activity A | Form loads | | 2 | Click remove on shared media | Confirmation prompt | | 3 | Confirm removal | Media removed from Activity A | | 4 | Verify Activity A gallery | Media no longer shown | | 5 | Select Activity B | Form loads | | 6 | Verify Activity B gallery | Media still present | | 7 | Verify S3 | File still exists (not deleted) |
TC-MED-014: Remove Non-Shared Media¶
| Field | Value |
|---|---|
| Test ID | TC-MED-014 |
| Use Case | UC-MED-005 |
| Priority | Medium |
| Type | Functional |
Preconditions: - Media is linked to only one activity
Test Steps: | Step | Action | Expected Result | |------|--------|-----------------| | 1 | Select activity with unique media | Form loads | | 2 | Click remove on media | Confirmation prompt | | 3 | Confirm removal | Media removed | | 4 | Verify gallery | Media no longer shown | | 5 | Verify database | Media record deleted | | 6 | Verify S3 (optional) | File may be deleted |
TC-MED-015: Upload Progress Display¶
| Field | Value |
|---|---|
| Test ID | TC-MED-015 |
| Use Case | UC-MED-002, UC-MED-003 |
| Priority | Medium |
| Type | UI |
Test Steps: | Step | Action | Expected Result | |------|--------|-----------------| | 1 | Start uploading a 15MB file | Progress bar appears | | 2 | Observe progress | Percentage updates smoothly | | 3 | Verify final state | 100% shown before completion message | | 4 | Verify progress bar hidden | After modal closes |
2.4 Navigation Test Cases¶
TC-NAV-001: Unsaved Changes Warning¶
| Field | Value |
|---|---|
| Test ID | TC-NAV-001 |
| Use Case | UC-NAV-001 |
| Priority | High |
| Type | Functional |
Test Steps: | Step | Action | Expected Result | |------|--------|-----------------| | 1 | Select activity | Form loads | | 2 | Modify activity name | Field changed | | 3 | Click on different activity | Confirmation prompt appears | | 4 | Click "Cancel" | Stay on current activity | | 5 | Verify change | Modification still present | | 6 | Click different activity again | Prompt appears | | 7 | Click "Confirm" | Navigate away | | 8 | Return to original | Change is lost |
2.5 Assignment Test Cases¶
TC-ASN-001: Assign Activity - Status Transition¶
| Field | Value |
|---|---|
| Test ID | TC-ASN-001 |
| Use Case | UC-ACT-003 |
| Priority | High |
| Type | Functional |
Preconditions: - Activity in CREATED status
Test Steps: | Step | Action | Expected Result | |------|--------|-----------------| | 1 | Select activity with CREATED status | Form loads | | 2 | Select team member from assignees | Member selected | | 3 | Click Save | Saved successfully | | 4 | Verify status | Changed to "ASSIGNED" | | 5 | Verify assignment record | Created in database |
TC-ASN-002: Multiple Assignees¶
| Field | Value |
|---|---|
| Test ID | TC-ASN-002 |
| Use Case | UC-ACT-003 |
| Priority | Medium |
| Type | Functional |
Test Steps: | Step | Action | Expected Result | |------|--------|-----------------| | 1 | Select activity | Form loads | | 2 | Select multiple team members (3) | All selected | | 3 | Save activity | Success | | 4 | Verify database | 3 assignment records created | | 5 | Reload activity | All 3 members shown as assigned |
2.6 Notification Test Cases¶
TC-NOT-001: WhatsApp on Status Change¶
| Field | Value |
|---|---|
| Test ID | TC-NOT-001 |
| Use Case | UC-NOT-001 |
| Priority | High |
| Type | Integration |
Test Steps: | Step | Action | Expected Result | |------|--------|-----------------| | 1 | Create campaign by User A | Campaign created | | 2 | As User B, change campaign status | Status changed | | 3 | Verify WhatsApp API call | API called with User A's number | | 4 | Verify message content | Contains campaign name, old/new status | | 5 | Verify changelog | notificationsent = true |
TC-NOT-002: Review Request Notification¶
| Field | Value |
|---|---|
| Test ID | TC-NOT-002 |
| Use Case | UC-NOT-002 |
| Priority | High |
| Type | Integration |
Test Steps: | Step | Action | Expected Result | |------|--------|-----------------| | 1 | Send activity for review to Reviewer X | Status changes | | 2 | Verify WhatsApp API call | Called with Reviewer X's number | | 3 | Verify message | Contains activity name, requester info |
2.7 API Test Cases¶
TC-API-001: Campaign CRUD Operations¶
| Field | Value |
|---|---|
| Test ID | TC-API-001 |
| Priority | High |
| Type | API |
Test Steps: | Step | Action | Expected Result | |------|--------|-----------------| | 1 | POST /marketing/campaign/create | 200 OK, campaign returned | | 2 | POST /marketing/campaign/list | 200 OK, list includes new campaign | | 3 | POST /marketing/campaign/read | 200 OK, campaign details returned | | 4 | POST /marketing/campaign/update | 200 OK, changes persisted | | 5 | POST /marketing/campaign/changeStatus | 200 OK, status updated |
TC-API-002: API Authentication Required¶
| Field | Value |
|---|---|
| Test ID | TC-API-002 |
| Priority | High |
| Type | Security |
Test Steps: | Step | Action | Expected Result | |------|--------|-----------------| | 1 | Call /marketing/campaign/list without session | 401 Unauthorized | | 2 | Call with invalid session | 401 Unauthorized | | 3 | Call with valid session | 200 OK |
TC-API-003: API Role Authorization¶
| Field | Value |
|---|---|
| Test ID | TC-API-003 |
| Priority | High |
| Type | Security |
Test Steps: | Step | Action | Expected Result | |------|--------|-----------------| | 1 | Call /marketing/activity/approve as agent | 403 Forbidden | | 2 | Call /marketing/activity/approve as admin | 200 OK | | 3 | Call /marketing/activity/approve as reviewer | 200 OK |
2.8 UI Test Cases¶
TC-UI-001: Page Layout and Responsiveness¶
| Field | Value |
|---|---|
| Test ID | TC-UI-001 |
| Priority | Medium |
| Type | UI |
Test Steps: | Step | Action | Expected Result | |------|--------|-----------------| | 1 | Load marketing planning page | Page renders correctly | | 2 | Verify sidebar (25% width) | Campaign tree visible | | 3 | Verify main area (75% width) | Header and workspace visible | | 4 | Verify header height (~20%) | Campaign info displayed | | 5 | Verify workspace height (~80%) | Activity form displayed | | 6 | Resize browser to 1024px | Layout adjusts appropriately |
TC-UI-002: Rich Text Editor Functionality¶
| Field | Value |
|---|---|
| Test ID | TC-UI-002 |
| Priority | Medium |
| Type | UI |
Test Steps: | Step | Action | Expected Result | |------|--------|-----------------| | 1 | Click in story text editor | Editor focused | | 2 | Type "Hello World" | Text appears | | 3 | Select text, click Bold | Text becomes bold | | 4 | Add bullet list | List formatted | | 5 | Add link | Link created | | 6 | Save activity | HTML preserved | | 7 | Reload | Formatting intact |
TC-UI-003: Status Badge Colors¶
| Field | Value |
|---|---|
| Test ID | TC-UI-003 |
| Priority | Low |
| Type | UI |
Test Steps: | Step | Action | Expected Result | |------|--------|-----------------| | 1 | View CREATED status | Gray badge | | 2 | View ASSIGNED status | Blue badge | | 3 | View WORK_IN_PROGRESS status | Yellow badge | | 4 | View SENT_FOR_REVIEW status | Green badge | | 5 | View APPROVED status | Dark green badge | | 6 | View CANCELLED status | Red badge |
3. Exit Criteria¶
3.1 Phase 1: Database & Backend Core¶
| Criterion | Verification Method |
|---|---|
| All 8 database tables created | SQL query confirms tables exist |
| Sequences created for each table | Sequence test returns next value |
| All 8 database entities compile | Gradle build succeeds |
| All 8 canonical entities compile | Gradle build succeeds |
| Entity XML configuration valid | Application starts without XML errors |
| tourlinq-config.xml includes marketing entities | XInclude resolved correctly |
Exit Gate: Application starts successfully with new entities registered
3.2 Phase 2: Business Logic¶
| Criterion | Verification Method |
|---|---|
| MarketingFacade compiles | Gradle build succeeds |
| Campaign CRUD operations work | Unit tests pass: TC-CAM-001 through TC-CAM-005 |
| Activity CRUD operations work | Unit tests pass: TC-ACT-001 through TC-ACT-007 |
| Status transition validation works | Unit tests pass for valid/invalid transitions |
| Assignment operations work | Unit tests pass: TC-ASN-001, TC-ASN-002 |
| Media operations work | Unit tests pass: TC-MED-001 through TC-MED-003 |
| Change logging works | Changelog records created for all operations |
| Campaign-Activity cascade works | TC-ACT-007 passes |
Exit Gate: All facade unit tests pass (>95% pass rate)
3.3 Phase 3: REST API¶
| Criterion | Verification Method |
|---|---|
| MarketingApi compiles | Gradle build succeeds |
| All endpoints accessible | API smoke tests pass |
| Authentication enforced | TC-API-002 passes |
| Role authorization works | TC-API-003 passes |
| Campaign endpoints work | TC-API-001 passes |
| Activity endpoints work | API integration tests pass |
| Media endpoints work | API integration tests pass |
| Error handling works | Invalid requests return proper error responses |
Exit Gate: All API integration tests pass, Postman collection validates all endpoints
3.4 Phase 4: Frontend¶
| Criterion | Verification Method |
|---|---|
| Page loads without JavaScript errors | Browser console clean |
| Page integrated in tqweb-adm | Menu link works, header/footer display |
| Campaign tree renders | Visual inspection, data loads |
| Activity workspace renders | Visual inspection, forms work |
| Rich text editor works | TC-UI-002 passes |
| Media gallery works | Add/remove media functions |
| Status transitions work from UI | All status buttons functional |
| Save/discard prompts work | TC-NAV-001 passes |
| Form validation works | Required fields enforced |
Exit Gate: All UI test cases pass, manual UAT sign-off
3.5 Phase 5: Notifications¶
| Criterion | Verification Method |
|---|---|
| WhatsApp service configured | Configuration loaded |
| Status change notifications sent | TC-NOT-001 passes |
| Review request notifications sent | TC-NOT-002 passes |
| Approval notifications sent | Integration test passes |
| Notification failures handled gracefully | Error logging, no crashes |
| Notification status tracked | Changelog notificationsent updated |
Exit Gate: All notification tests pass in staging environment
3.6 Phase 6: Final Release (Core Module)¶
| Criterion | Verification Method |
|---|---|
| All previous phase criteria met | Phase sign-offs complete |
| End-to-end test scenarios pass | E2E test suite (>95% pass) |
| Performance acceptable | Page load <3 seconds, API response <500ms |
| No critical/high severity bugs | Bug tracker clean |
| User documentation complete | Documentation reviewed |
| Training materials available | Training docs delivered |
| Rollback plan documented | Rollback procedure tested |
Exit Gate: Product Owner sign-off, deployment approval
3.7 Phase 7: Media Upload & Reuse¶
| Criterion | Verification Method |
|---|---|
| AWS S3 SDK integrated | Gradle build succeeds with new dependency |
| S3 configuration properties added | Configuration loads without errors |
| S3UploadService implemented | Unit tests pass |
| Small file upload works (<20MB) | TC-MED-004 passes |
| Large file upload works (>=20MB) | TC-MED-005 passes |
| Pre-signed URL generation works | API returns valid pre-signed URL |
| Upload progress displayed | TC-MED-015 passes |
| File type validation works | TC-MED-006 passes |
| File size validation works | TC-MED-007 passes |
| Drag-and-drop upload works | TC-MED-008 passes |
| Media link table created | Database migration succeeds |
| Existing media selection works | TC-MED-009, TC-MED-010 pass |
| Media filtering works | TC-MED-011 passes |
| Empty state handled | TC-MED-012 passes |
| Shared media removal preserves file | TC-MED-013 passes |
| Non-shared media removal cleans up | TC-MED-014 passes |
| S3 bucket configured | Bucket accessible with correct permissions |
| CORS configured for direct uploads | Browser uploads to S3 succeed |
Exit Gate: All media upload and reuse tests pass, S3 integration verified in staging
4. End-to-End Test Scenarios¶
E2E-001: Complete Campaign Workflow¶
Scenario: Create a campaign, add activities, get approvals, and launch
Steps: 1. User A creates campaign "Black Friday 2025" 2. User A adds activity "Instagram Announcement" (type: INSTAGRAM_REEL) 3. User A adds activity "Facebook Event" (type: FACEBOOK_STORY) 4. User A assigns activities to User B 5. User B edits Instagram activity: adds description, story text, media 6. User B sends Instagram activity for review to User C 7. User C receives WhatsApp notification 8. User C approves Instagram activity 9. User B receives WhatsApp notification 10. Repeat steps 5-9 for Facebook activity 11. User A changes campaign status to COMPLETED_SCHEDULED (succeeds because all approved) 12. User A changes campaign status to STARTED 13. Verify all data persisted correctly 14. Verify all changelog entries exist
Expected Result: Campaign successfully moves through all stages
E2E-002: Activity Rejection and Revision Cycle¶
Scenario: Activity sent for review, returned, revised, re-submitted, approved
Steps: 1. Create campaign and activity 2. Complete activity content 3. Send for review to Reviewer 4. Reviewer returns activity with reason "Add more hashtags" 5. Verify status back to WORK_IN_PROGRESS 6. Creator edits activity with requested changes 7. Send for review again 8. Reviewer approves 9. Verify final status is APPROVED 10. Verify changelog shows full history
Expected Result: Activity goes through rejection/revision cycle successfully
E2E-003: Admin Revokes Approved Activity¶
Scenario: Admin revokes an approved activity, affecting campaign status
Steps: 1. Create campaign with 2 activities 2. Get both activities approved 3. Mark campaign as COMPLETED_SCHEDULED 4. Admin revokes one activity (back to WORK_IN_PROGRESS) 5. Verify campaign status automatically changes to WORK_IN_PROGRESS 6. Verify notifications sent 7. Re-approve the activity 8. Mark campaign as COMPLETED_SCHEDULED again
Expected Result: Cascade behavior works correctly both ways
E2E-004: Concurrent User Editing¶
Scenario: Two users try to edit the same activity
Steps: 1. User A loads activity in browser 2. User B loads same activity in different browser 3. User A makes changes and saves 4. User B makes different changes and saves 5. Verify conflict handling (last write wins or conflict detection) 6. Verify changelog captures both edits
Expected Result: System handles concurrent edits gracefully
E2E-005: Media Upload and Reuse Workflow¶
Scenario: Upload media to one activity, then reuse it in another activity
Steps: 1. Create campaign "Product Launch 2025" 2. Add activity "Instagram Post" to campaign 3. Click "Add Media" and select Upload tab 4. Upload 10MB product image (JPG) 5. Verify upload progress bar shows 6. Verify image appears in activity media gallery 7. Add another activity "Facebook Ad" to same campaign 8. Click "Add Media" and select "Existing" tab 9. Verify product image from Instagram Post is visible 10. Select the existing image 11. Click "Add Selected" 12. Verify image appears in Facebook Ad gallery 13. Verify database shows link record (not duplicate media) 14. Remove media from Instagram Post 15. Verify media still appears in Facebook Ad 16. Verify S3 file still exists
Expected Result: Media is uploaded once and shared between activities without duplication
E2E-006: Large Video Upload with Pre-signed URL¶
Scenario: Upload a large video file using pre-signed URL flow
Steps: 1. Select an activity for editing 2. Click "Add Media" with Upload tab 3. Select type "Video" 4. Select 100MB MP4 video file 5. Click Upload 6. Verify progress bar appears and updates 7. (Use browser dev tools) Verify upload goes directly to S3, not API server 8. Wait for upload to complete 9. Verify confirmation call to backend 10. Verify video appears in media gallery 11. Verify video URL is accessible 12. Verify file exists in S3 bucket
Expected Result: Large video uploads directly to S3 and is properly registered
5. Acceptance Criteria Summary¶
Functional Acceptance Criteria¶
| ID | Criteria | Test Cases |
|---|---|---|
| FAC-001 | Users can create, view, edit campaigns | TC-CAM-001, TC-CAM-002, TC-CAM-003 |
| FAC-002 | Campaign status follows defined workflow | TC-CAM-003, TC-CAM-004, TC-CAM-005 |
| FAC-003 | Users can create, view, edit activities | TC-ACT-001, TC-ACT-002, TC-ACT-003 |
| FAC-004 | Activity status follows defined workflow | TC-ACT-004, TC-ACT-005, TC-ACT-006 |
| FAC-005 | Approved activities cannot be edited | TC-ACT-003, TC-MED-003 |
| FAC-006 | Activities can be assigned to team members | TC-ASN-001, TC-ASN-002 |
| FAC-007 | Media artifacts can be added via URL | TC-MED-001, TC-MED-002 |
| FAC-007a | Media artifacts can be uploaded to S3 | TC-MED-004, TC-MED-005, TC-MED-006, TC-MED-007, TC-MED-008 |
| FAC-007b | Existing media can be reused across activities | TC-MED-009, TC-MED-010, TC-MED-011, TC-MED-012 |
| FAC-007c | Media can be removed with sharing protection | TC-MED-013, TC-MED-014 |
| FAC-008 | Audience segments can be linked to activities | UC-AUD-001 tests |
| FAC-009 | Rich text editor works for story text | TC-UI-002 |
| FAC-010 | WhatsApp notifications sent on status changes | TC-NOT-001, TC-NOT-002 |
| FAC-011 | All changes logged to changelog | All tests verify logging |
| FAC-012 | Unsaved changes prompt on navigation | TC-NAV-001 |
Non-Functional Acceptance Criteria¶
| ID | Criteria | Measurement |
|---|---|---|
| NFAC-001 | Page load time < 3 seconds | Performance test |
| NFAC-002 | API response time < 500ms | Performance test |
| NFAC-003 | System handles 50 concurrent users | Load test |
| NFAC-004 | 99.9% uptime during business hours | Monitoring |
| NFAC-005 | All user input validated | Security test |
| NFAC-006 | Session authentication enforced | TC-API-002 |
| NFAC-007 | Role-based access control enforced | TC-API-003 |
6. Traceability Matrix¶
| Requirement | Use Cases | Test Cases | Exit Criteria |
|---|---|---|---|
| Campaign CRUD | UC-CAM-001, UC-CAM-002, UC-CAM-003 | TC-CAM-001, TC-CAM-002, TC-CAM-003 | Phase 2 |
| Campaign Status Workflow | UC-CAM-004 | TC-CAM-003, TC-CAM-004, TC-CAM-005 | Phase 2 |
| Activity CRUD | UC-ACT-001, UC-ACT-002 | TC-ACT-001, TC-ACT-002, TC-ACT-003 | Phase 2 |
| Activity Assignment | UC-ACT-003 | TC-ASN-001, TC-ASN-002 | Phase 2 |
| Review/Approval Workflow | UC-ACT-004, UC-ACT-005, UC-ACT-006 | TC-ACT-004, TC-ACT-005, TC-ACT-006 | Phase 2 |
| Admin Revoke | UC-ACT-007 | TC-ACT-007 | Phase 2 |
| Media Management (URL) | UC-MED-001 | TC-MED-001, TC-MED-002, TC-MED-003 | Phase 2 |
| Media Upload (S3) | UC-MED-002, UC-MED-003 | TC-MED-004, TC-MED-005, TC-MED-006, TC-MED-007, TC-MED-008, TC-MED-015 | Phase 7 |
| Media Reuse | UC-MED-004 | TC-MED-009, TC-MED-010, TC-MED-011, TC-MED-012 | Phase 7 |
| Media Removal (Shared) | UC-MED-005 | TC-MED-013, TC-MED-014 | Phase 7 |
| WhatsApp Notifications | UC-NOT-001, UC-NOT-002 | TC-NOT-001, TC-NOT-002 | Phase 5 |
| Navigation/UX | UC-NAV-001 | TC-NAV-001 | Phase 4 |
| API Security | - | TC-API-002, TC-API-003 | Phase 3 |
| UI/Layout | - | TC-UI-001, TC-UI-002, TC-UI-003 | Phase 4 |
7. Risk Assessment¶
| Risk | Impact | Probability | Mitigation |
|---|---|---|---|
| WhatsApp API rate limits | Medium | Medium | Implement queue-based sending with backoff |
| Concurrent edit conflicts | Low | Medium | Add optimistic locking or conflict detection |
| Rich text editor XSS | High | Low | Sanitize HTML on server side before storage |
| Large media galleries slow UI | Medium | Medium | Implement pagination/lazy loading |
| Status transition bugs | High | Low | Thorough unit testing of state machine |
| Mobile responsiveness issues | Medium | Medium | Test on multiple screen sizes |
| S3 bucket misconfiguration | High | Low | Use infrastructure-as-code, security reviews |
| Large file upload timeouts | Medium | Medium | Pre-signed URLs for files >20MB, progress display |
| S3 credentials exposure | High | Low | Use IAM roles, never hardcode credentials |
| Orphaned files in S3 | Low | Medium | Track media links, periodic cleanup job |
| Pre-signed URL abuse | Medium | Low | Short expiry (15 min), file validation after upload |
| Upload malicious files | High | Low | File type validation, magic byte checking, size limits |
| S3 storage costs | Low | Low | Monitor usage, implement retention policies |
8. Sign-Off¶
| Role | Name | Date | Signature |
|---|---|---|---|
| Product Owner | |||
| Development Lead | |||
| QA Lead | |||
| UX Designer | |||
| Operations |
Document Version: 1.2 Created: 2025-12-14 Last Updated: 2026-04-03
Broadcast Use Cases (TQ-109)¶
UC-B1: Create WhatsApp Broadcast Activity¶
Actor: Team member (agent/admin) Precondition: Campaign exists Flow: 1. User creates a new activity with type "WhatsApp Broadcast" 2. System creates the activity and auto-creates a linked broadcast record in DRAFT status 3. Broadcast panel appears in the activity workspace
UC-B2: Configure Broadcast¶
Actor: Team member (agent/admin) Precondition: Broadcast activity exists in DRAFT or READY status Flow: 1. User enters WhatsApp template CSID and name (or email subject and template for email) 2. User writes message body with optional merge tags ({{name}}) 3. User optionally selects an attached media item from the activity's media 4. User clicks Save to persist the configuration
UC-B3: Preview Audience¶
Actor: Team member (agent/admin) Precondition: Activity has audience segments linked Flow: 1. User clicks "Preview Audience" 2. System queries CRM for matching contacts and returns total count + 10 sample rows 3. User reviews the count and sample to verify the target audience
UC-B4: Build Recipient List¶
Actor: Team member (agent/admin) Precondition: Broadcast in DRAFT or READY status, audience segments linked Flow: 1. User clicks "Build Recipient List" and confirms 2. System clears any existing recipients, queries CRM, deduplicates, checks opt-out register 3. System persists recipient records and updates broadcast to READY status 4. Recipient count is displayed in the broadcast panel
UC-B5: Send Broadcast¶
Actor: Admin only Precondition: Activity is APPROVED, broadcast is READY, recipients > 0 Flow: 1. User clicks "Send Broadcast" and confirms with recipient count 2. System triggers async send via BroadcastService 3. Broadcast status moves to SENDING, then SENT or FAILED upon completion 4. Delivery stats update in real-time via Twilio callbacks (WhatsApp) or on send completion (email)
UC-B6: WhatsApp Opt-Out (STOP)¶
Actor: Message recipient (external) Flow: 1. Recipient sends "STOP" to the WhatsApp business number 2. Twilio forwards the inbound message to the webhook 3. System adds the sender's phone to the opt-out register 4. Future broadcasts skip this contact
UC-B7: Email Unsubscribe¶
Actor: Email recipient (external) Flow: 1. Recipient clicks "Unsubscribe" link in the broadcast email (or email client uses List-Unsubscribe header) 2. System adds the email to the opt-out register 3. Confirmation page is displayed 4. Future broadcasts skip this contact