Documentation Index
Fetch the complete documentation index at: https://docs-terra.withunify.org/llms.txt
Use this file to discover all available pages before exploring further.
3-Day Manual Testing Framework
Environment: the active QA deployment URL (see /operations/deployment-workflow)
Duration: 3 days (Wed, Thurs, Fri)
Tester: ___________________
Date: ___________________
Testing Instructions
How to Use These Scripts
- Execute tests in order - Start with Day 1, then Day 2, then Day 3
- Record results - Mark each test as PASS/FAIL/BLOCKED
- Document bugs - Use the Bug Report Template at the end
- Take screenshots - Capture any errors or unexpected behavior
- Ask questions - Flag any unclear requirements immediately
Test Result Codes
- ✅ PASS - Test completed successfully, actual matches expected
- ❌ FAIL - Test failed, bug found
- ⚠️ BLOCKED - Cannot complete due to dependency/environment issue
- ⏭️ SKIP - Intentionally skipped (note reason)
DAY 1: Core Functionality (Critical Path)
Focus: Authentication, form creation, publishing, submission
Time Estimate: 6-8 hours
TS-001: User Authentication Flow
Objective: Verify users can log in and access the system
Priority: Critical
Prerequisites: Valid WorkOS account credentials
Test Steps
| Step | Action | Expected Result | Actual Result | Status |
|---|
| 1 | Navigate to the active QA deployment URL | Landing page loads, shows login button | | |
| 2 | Click “Login” or “Sign In” button | Redirected to WorkOS login page | | |
| 3 | Enter valid email and password | Credentials accepted | | |
| 4 | Complete authentication | Redirected to Terra dashboard at / | | |
| 5 | Verify session persists | User remains logged in on page refresh | | |
| 6 | Verify user role displayed | User role badge visible in header/nav | | |
| 7 | Open new tab with staging URL | Session carries over, no re-login required | | |
| 8 | Click logout | User logged out, redirected to login page | | |
| 9 | Try accessing /forms while logged out | Redirected to /login with returnTo parameter | | |
| 10 | Log back in | Redirected to originally requested URL | | |
Test Data:
- Email: [Your test account email]
- Password: [Your test account password]
Notes:
Record any issues with authentication flow, redirects, or session handling
Objective: Verify form creation and publishing workflow
Priority: Critical
Prerequisites: Authenticated as admin user
Test Steps
| Step | Action | Expected Result | Actual Result | Status |
|---|
| 1 | Navigate to dashboard / | Dashboard loads with “Create Program” button | | |
| 2 | Click “Create Program” button | Redirected to form builder or creation dialog | | |
| 3 | Enter form title: “QA Test Form 1” | Title saved | | |
| 4 | Add description: “Testing form creation flow” | Description saved | | |
| 5 | Add a text field labeled “First Name” | Field appears in builder | | |
| 6 | Mark field as required | Required indicator shows | | |
| 7 | Add a number field labeled “Age” | Field appears in builder | | |
| 8 | Add a choice field “Favorite Color” with options: Red, Blue, Green | Field with options appears | | |
| 9 | Click save/auto-save | Form saved as draft | | |
| 10 | Navigate to /forms | New form appears in list with “Draft” status | | |
| 11 | Open form settings | Settings page loads | | |
| 12 | Set form slug: “qa-test-1” | Slug saved | | |
| 13 | Click “Publish” button | Publishing confirmation dialog appears | | |
| 14 | Confirm publish | Form status changes to “Published” | | |
| 15 | Verify form slug | Form accessible at /f/qa-test-1 | | |
Test Data:
- Form title: “QA Test Form 1”
- Form slug: “qa-test-1”
- Fields: First Name (text, required), Age (number), Favorite Color (choice)
Notes:
Record any issues with form builder, saving, or publishing
Objective: Verify anonymous users can submit public forms
Priority: Critical
Prerequisites: TS-002 completed (published form exists)
Test Steps
| Step | Action | Expected Result | Actual Result | Status |
|---|
| 1 | Open incognito/private browser window | Clean session started | | |
| 2 | Navigate to /f/qa-test-1 | Form loads without login requirement | | |
| 3 | Verify form title displays | ”QA Test Form 1” shows at top | | |
| 4 | Verify all fields render | First Name, Age, Favorite Color visible | | |
| 5 | Leave First Name empty, click Submit | Validation error: “First Name is required” | | |
| 6 | Fill First Name: “Test User” | Value entered | | |
| 7 | Fill Age: “25” | Value entered | | |
| 8 | Select Favorite Color: “Blue” | Option selected | | |
| 9 | Click Submit | Form submits, loading indicator shows | | |
| 10 | Verify success message | ”Thank you” or success confirmation displays | | |
| 11 | Verify cannot submit again | Form shows “submitted” state or redirects | | |
Test Data:
- First Name: “Test User”
- Age: 25
- Favorite Color: Blue
Notes:
Record submission ID if shown, note any validation or submission errors
TS-004: View Submissions in Admin Dashboard
Objective: Verify admins can view form submissions
Priority: Critical
Prerequisites: TS-003 completed (submission exists)
Test Steps
| Step | Action | Expected Result | Actual Result | Status |
|---|
| 1 | Log in as admin | Dashboard loads | | |
| 2 | Navigate to /forms | Forms list displays | | |
| 3 | Find “QA Test Form 1” | Form shows in list | | |
| 4 | Verify submission count shows “1” | Count displays correctly | | |
| 5 | Click on form to view details | Form detail page loads | | |
| 6 | Navigate to Submissions tab/page | Submissions list loads | | |
| 7 | Verify submission appears in list | One submission visible with timestamp | | |
| 8 | Click on submission to view details | Submission detail page opens | | |
| 9 | Verify all submitted data displays | First Name: “Test User”, Age: 25, Color: Blue | | |
| 10 | Verify submission metadata | Status, date/time, reference ID visible | | |
Notes:
Record submission reference ID, note any data discrepancies
Objective: Verify form status changes work correctly
Priority: Critical
Prerequisites: TS-002 completed
Test Steps
| Step | Action | Expected Result | Actual Result | Status |
|---|
| 1 | Navigate to form settings for “QA Test Form 1” | Settings page loads | | |
| 2 | Locate Status dropdown/toggle | Current status shows “Published” | | |
| 3 | Change status to “Closed” | Status updates to Closed | | |
| 4 | Save changes | Settings saved successfully | | |
| 5 | Open incognito window, visit /f/qa-test-1 | Form shows “This form is closed” message | | |
| 6 | Verify cannot submit | Submit button disabled or hidden | | |
| 7 | Return to admin, change status to “Published” | Status updates to Published | | |
| 8 | Refresh public form in incognito | Form is accessible again, can submit | | |
Notes:
Document any issues with status changes or public form behavior
TS-006: Multiple Field Types
Objective: Test all major form field types render and validate
Priority: High
Prerequisites: Authenticated as admin
Test Steps
| Step | Action | Expected Result | Actual Result | Status |
|---|
| 1 | Create new form “QA Field Types Test” | Form created | | |
| 2 | Add text field “Full Name” (required) | Field added | | |
| 3 | Add number field “Phone Number” (required) | Field added | | |
| 4 | Add date field “Date of Birth” (required) | Field added | | |
| 5 | Add choice/select “Employment Status” with options: Employed, Unemployed, Student | Field added | | |
| 6 | Add file upload field “Resume” | Field added | | |
| 7 | Add signature field “Signature” | Field added | | |
| 8 | Save and publish form with slug “qa-field-types” | Form published | | |
| 9 | Visit /f/qa-field-types in incognito | All fields render correctly | | |
| 10 | Test text field: enter “John Doe” | Value accepted | | |
| 11 | Test number field: enter “5551234567” | Value accepted | | |
| 12 | Test date field: select a date | Date picker works, date selected | | |
| 13 | Test choice field: select “Employed” | Option selected | | |
| 14 | Test file upload: upload small PDF (< 5MB) | File uploads, shows filename | | |
| 15 | Test signature: draw signature | Signature captured | | |
| 16 | Submit form with all fields filled | Submission successful | | |
| 17 | Verify submission in admin | All field values display correctly | | |
Test Data:
- Full Name: “John Doe”
- Phone: “5551234567”
- DOB: “1990-01-01”
- Employment: “Employed”
- Resume: test.pdf (prepare small PDF file)
- Signature: [Draw simple signature]
Notes:
Test each field type’s validation, note any rendering or submission issues
Objective: Verify client-side and server-side validation
Priority: High
Prerequisites: TS-006 form exists
Test Steps
| Step | Action | Expected Result | Actual Result | Status |
|---|
| 1 | Visit /f/qa-field-types | Form loads | | |
| 2 | Click Submit without filling any fields | Validation errors show for all required fields | | |
| 3 | Fill Full Name: “Test” | Error clears for that field | | |
| 4 | Fill Phone: “abc” (letters) | Error: “Must be a number” or similar | | |
| 5 | Fill Phone: “1234567890” (valid) | Error clears | | |
| 6 | Try invalid date format in DOB | Validation error or date picker enforces format | | |
| 7 | Select valid date | Error clears | | |
| 8 | Try uploading 100MB file (if possible) | Error: “File too large” | | |
| 9 | Upload valid file < 5MB | File accepted | | |
| 10 | Fill all fields correctly and submit | Form submits successfully | | |
Notes:
Document validation messages, ensure both client and server validation work
Objective: Verify share links work and track responses
Priority: High
Prerequisites: Published form exists
Test Steps
| Step | Action | Expected Result | Actual Result | Status |
|---|
| 1 | Navigate to form settings for “QA Test Form 1” | Settings loads | | |
| 2 | Go to Share Links section | Share links page loads | | |
| 3 | Click “Create Share Link” | Creation dialog opens | | |
| 4 | Enter name: “Email Campaign 1” | Name entered | | |
| 5 | Set UTM parameters: utm_source=email, utm_medium=campaign | Parameters saved | | |
| 6 | Save share link | Link created, unique URL generated | | |
| 7 | Copy share link URL | URL copied to clipboard | | |
| 8 | Open incognito window, paste share link | Form loads with share link tracking | | |
| 9 | Fill and submit form | Submission successful | | |
| 10 | Return to admin, view share link stats | Response count shows “1” | | |
| 11 | Set response limit: “2” | Limit saved | | |
| 12 | Submit form via share link again (incognito) | Second submission successful | | |
| 13 | Try submitting third time | Shows “limit reached” message | | |
| 14 | Set share link status to “Closed” | Status updated | | |
| 15 | Try accessing share link | Shows “link closed” message | | |
Test Data:
- Link name: “Email Campaign 1”
- UTM source: “email”
- UTM medium: “campaign”
- Response limit: 2
Notes:
Record share link URL, verify tracking accuracy
TS-009: Draft Submissions
Objective: Verify users can save and resume draft applications
Priority: High
Prerequisites: Authenticated user (non-admin)
Test Steps
| Step | Action | Expected Result | Actual Result | Status |
|---|
| 1 | Create form “QA Draft Test” with 5+ fields | Form created and published | | |
| 2 | Log in as regular user (not admin) | Logged in to portal | | |
| 3 | Navigate to portal /portal | Portal dashboard loads | | |
| 4 | Click “Start New Application” | Form selection dialog or redirects to form | | |
| 5 | Select “QA Draft Test” form | Form loads in application mode | | |
| 6 | Fill first 2 fields only | Values entered | | |
| 7 | Click “Save Draft” or navigate away | Draft auto-saved | | |
| 8 | Return to portal dashboard | Application shows as “Draft” status | | |
| 9 | Click “Continue Application” | Redirects to form with saved values | | |
| 10 | Verify previously filled fields have values | Fields 1-2 are pre-filled | | |
| 11 | Fill remaining fields | All fields completed | | |
| 12 | Submit application | Status changes to “Submitted” | | |
| 13 | Verify cannot edit submitted application | Application is read-only | | |
Notes:
Test auto-save functionality, verify draft persistence
TS-010: Basic Email Notifications
Objective: Verify email notifications send on form submission
Priority: High
Prerequisites: Form with notifications configured
Test Steps
| Step | Action | Expected Result | Actual Result | Status |
|---|
| 1 | Create form “QA Notifications Test” | Form created | | |
| 2 | Add email field “Your Email” (required) | Field added | | |
| 3 | Go to form settings > Notifications | Notifications page loads | | |
| 4 | Enable “Email on Submission” | Toggle enabled | | |
| 5 | Add recipient email: [your test email] | Recipient added | | |
| 6 | Enable “Send confirmation to submitter” | Toggle enabled | | |
| 7 | Save notification settings | Settings saved | | |
| 8 | Publish form | Form published | | |
| 9 | Submit form with email: [your email] | Form submitted | | |
| 10 | Check inbox for admin notification | Email received with submission details | | |
| 11 | Check inbox for submitter confirmation | Confirmation email received | | |
| 12 | Verify email contains correct data | All submitted values appear in email | | |
Test Data:
- Test email address: [Use your email]
Notes:
Check spam folder if emails not received, note delivery time
DAY 2: Advanced Features & Settings
Focus: Form settings, integrations, team management, portal
Time Estimate: 6-8 hours
Objective: Test conditional logic and field dependencies
Priority: High
Prerequisites: Authenticated as admin
Test Steps
| Step | Action | Expected Result | Actual Result | Status |
|---|
| 1 | Create form “QA Conditional Logic Test” | Form created | | |
| 2 | Add choice field “Are you employed?” Options: Yes, No | Field added | | |
| 3 | Add text field “Employer Name” | Field added | | |
| 4 | Set condition: Show “Employer Name” only if “Are you employed?” = “Yes” | Condition configured | | |
| 5 | Add another field “Reason for unemployment” | Field added | | |
| 6 | Set condition: Show “Reason” only if employed = “No” | Condition configured | | |
| 7 | Publish form | Form published | | |
| 8 | Visit form in incognito | Form loads | | |
| 9 | Verify “Employer Name” and “Reason” are hidden | Only “Are you employed?” visible | | |
| 10 | Select “Yes” for employment | ”Employer Name” field appears | | |
| 11 | Verify “Reason” remains hidden | Only employer field visible | | |
| 12 | Change to “No" | "Employer Name” hides, “Reason” appears | | |
| 13 | Fill “Reason” and submit | Form submits successfully | | |
| 14 | Verify submission shows correct conditional data | Only “No” and reason recorded | | |
Notes:
Test various conditional scenarios, note any logic failures
TS-012: Workspaces/Folders Management
Objective: Verify workspace organization features
Priority: Medium
Prerequisites: Multiple forms exist
Test Steps
| Step | Action | Expected Result | Actual Result | Status |
|---|
| 1 | Navigate to forms list /forms | Forms list loads | | |
| 2 | Click “Create Workspace” or similar | Creation dialog opens | | |
| 3 | Enter name: “QA Workspace 1” | Name entered | | |
| 4 | Select color: Blue | Color selected | | |
| 5 | Save workspace | Workspace created, appears in sidebar | | |
| 6 | Drag form “QA Test Form 1” into workspace | Form moves to workspace | | |
| 7 | Verify form appears under workspace | Form listed in workspace | | |
| 8 | Click workspace to filter | Only forms in workspace display | | |
| 9 | Create another workspace “QA Workspace 2” | Workspace created | | |
| 10 | Move form to different workspace | Form moves successfully | | |
| 11 | Rename workspace to “QA Renamed” | Name updates | | |
| 12 | Delete workspace | Confirmation dialog appears | | |
| 13 | Confirm deletion | Workspace deleted, forms move to uncategorized | | |
Notes:
Test drag-and-drop, verify workspace persistence
TS-013: Team Member Management
Objective: Verify team collaboration features
Priority: High
Prerequisites: At least 2 test accounts available
Test Steps
| Step | Action | Expected Result | Actual Result | Status |
|---|
| 1 | Open form settings for “QA Test Form 1” | Settings loads | | |
| 2 | Navigate to Team tab | Team management page loads | | |
| 3 | Click “Add Team Member” | Invitation dialog opens | | |
| 4 | Enter email: [second test account] | Email entered | | |
| 5 | Select role: “Editor” | Role selected | | |
| 6 | Send invitation | Invitation sent, pending status shows | | |
| 7 | Log in as second account | Dashboard loads | | |
| 8 | Check for invitation notification | Invitation appears in notifications/inbox | | |
| 9 | Accept invitation | Invitation accepted | | |
| 10 | Verify form appears in forms list | ”QA Test Form 1” visible | | |
| 11 | Open form as editor | Can view and edit form | | |
| 12 | Try accessing form settings as editor | Settings accessible based on editor permissions | | |
| 13 | Log back in as owner | Original account | | |
| 14 | Change team member role to “Viewer” | Role updated | | |
| 15 | Log in as second account again | Dashboard loads | | |
| 16 | Try editing form | Edit button disabled or shows read-only | | |
| 17 | Log back in as owner, remove team member | Member removed from team | | |
| 18 | Log in as removed account | Dashboard loads | | |
| 19 | Verify form no longer appears | ”QA Test Form 1” not in list | | |
Test Data:
- Team member email: [Second test account]
- Roles: Editor, Viewer
Notes:
Test different role permissions, verify access control
Objective: Verify version history and restore functionality
Priority: Medium
Prerequisites: Form with some edit history
Test Steps
| Step | Action | Expected Result | Actual Result | Status |
|---|
| 1 | Open “QA Test Form 1” in editor | Form loads | | |
| 2 | Make edit: Change title to “Version 2 Title” | Title changed | | |
| 3 | Save changes | Auto-saved or manual save | | |
| 4 | Make another edit: Add new field “Version 2 Field” | Field added | | |
| 5 | Save again | Changes saved | | |
| 6 | Navigate to Settings > Versions | Version history page loads | | |
| 7 | Verify version list shows 2+ versions | Multiple versions with timestamps | | |
| 8 | Click on earlier version to preview | Preview shows original form state | | |
| 9 | Click “Restore this version” | Confirmation dialog appears | | |
| 10 | Confirm restore | Form reverts to earlier version | | |
| 11 | Verify title is back to “QA Test Form 1” | Original title restored | | |
| 12 | Verify “Version 2 Field” is removed | Field no longer present | | |
| 13 | Check version history | New “restore” version created | | |
Notes:
Verify version timestamps are accurate, test restore functionality
Objective: Verify forms can be exported and imported
Priority: Medium
Prerequisites: At least one published form
Test Steps
| Step | Action | Expected Result | Actual Result | Status |
|---|
| 1 | Navigate to form settings for “QA Test Form 1” | Settings loads | | |
| 2 | Go to Export/Data section | Export page loads | | |
| 3 | Click “Export Form as JSON” | Download dialog appears | | |
| 4 | Download file | JSON file saved locally | | |
| 5 | Open JSON file in text editor | Valid JSON structure visible | | |
| 6 | Navigate to forms list | Forms list loads | | |
| 7 | Click “Import Form” button | Import dialog opens | | |
| 8 | Select “Import from File” | File upload dialog appears | | |
| 9 | Upload the exported JSON file | File uploads | | |
| 10 | Verify import preview shows form structure | All fields and settings visible | | |
| 11 | Confirm import | New form created with name “Copy of QA Test Form 1” | | |
| 12 | Open imported form | Form loads with all original fields | | |
| 13 | Verify all settings carried over | Title, description, fields match original | | |
Notes:
Save exported JSON file, verify data integrity after import
TS-016: Airtable Integration
Objective: Test Airtable sync functionality
Priority: Medium
Prerequisites: Airtable account with test base, form with submissions
Test Steps
| Step | Action | Expected Result | Actual Result | Status |
|---|
| 1 | Navigate to form settings > Integrations | Integrations page loads | | |
| 2 | Find Airtable integration card | Airtable option visible | | |
| 3 | Click “Connect Airtable” | OAuth flow initiated | | |
| 4 | Authorize Airtable access | Redirected back to Terra | | |
| 5 | Select Airtable base: [test base] | Base selected | | |
| 6 | Select table: [test table] | Table selected | | |
| 7 | Map form fields to Airtable columns | Field mappings configured | | |
| 8 | Enable auto-sync | Toggle enabled | | |
| 9 | Save integration settings | Settings saved | | |
| 10 | Submit new form response | Submission successful | | |
| 11 | Wait 1-2 minutes for sync | Sync processing | | |
| 12 | Check Airtable base | New record appears in table | | |
| 13 | Verify all mapped fields synced correctly | Data matches submission | | |
| 14 | View sync history in Terra | Sync log shows successful sync | | |
Test Data:
- Airtable base: [Your test base name]
- Airtable table: [Your test table name]
Notes:
May skip if no Airtable account available - mark as SKIP with reason
TS-017: Plaid Bank Verification
Objective: Test Plaid bank account verification field
Priority: Medium
Prerequisites: Plaid integration configured
Test Steps
| Step | Action | Expected Result | Actual Result | Status |
|---|
| 1 | Create form “QA Plaid Test” | Form created | | |
| 2 | Add Plaid Bank Verification field | Field added to form | | |
| 3 | Configure field settings | Settings saved | | |
| 4 | Publish form | Form published | | |
| 5 | Visit form in incognito | Form loads | | |
| 6 | Click on bank verification field | Plaid Link modal opens | | |
| 7 | Select test bank “Plaid Bank” | Bank selected | | |
| 8 | Enter test credentials (user_good / pass_good) | Credentials accepted | | |
| 9 | Select test account | Account selected | | |
| 10 | Complete Plaid flow | Modal closes, success message shows | | |
| 11 | Submit form | Form submits with bank verification | | |
| 12 | View submission in admin | Bank account details visible | | |
Test Data:
- Plaid test credentials: user_good / pass_good (Plaid Sandbox)
Notes:
Uses Plaid Sandbox environment for testing - may skip if not configured
TS-018: Webhook Configuration and Testing
Objective: Verify webhooks trigger on form submission
Priority: Medium
Prerequisites: Webhook testing tool (webhook.site or similar)
Test Steps
| Step | Action | Expected Result | Actual Result | Status |
|---|
| 1 | Go to webhook.site and copy unique URL | URL copied | | |
| 2 | Navigate to form settings > Webhooks | Webhooks page loads | | |
| 3 | Click “Add Webhook” | Webhook form appears | | |
| 4 | Enter webhook URL from webhook.site | URL entered | | |
| 5 | Select event: “On Form Submission” | Event selected | | |
| 6 | Save webhook | Webhook created | | |
| 7 | Submit test form | Submission successful | | |
| 8 | Check webhook.site for incoming request | Request received | | |
| 9 | Verify webhook payload contains submission data | All fields present in JSON payload | | |
| 10 | View webhook delivery history in Terra | Shows successful delivery with timestamp | | |
| 11 | Change webhook URL to invalid URL | URL updated | | |
| 12 | Submit another form | Submission successful | | |
| 13 | Check webhook history | Shows failed delivery with error | | |
| 14 | Try manual retry | Retry fails again (expected) | | |
Test Data:
- Webhook URL: [Get from webhook.site]
Notes:
Examine webhook payload structure, verify all data included
TS-019: Portal - Application Management
Objective: Test portal application workflows
Priority: High
Prerequisites: Published form, authenticated non-admin user
Test Steps
| Step | Action | Expected Result | Actual Result | Status |
|---|
| 1 | Log in as regular user (not admin) | Logged in | | |
| 2 | Navigate to /portal | Portal dashboard loads | | |
| 3 | Verify “My Applications” section exists | Section visible | | |
| 4 | Click “Start New Application” | Form selection or new application flow starts | | |
| 5 | Select form to apply to | Form loads in application mode | | |
| 6 | Fill out form partially | Values entered | | |
| 7 | Click “Save Draft” | Draft saved, returned to portal | | |
| 8 | Verify draft appears in applications list | Status shows “Draft” | | |
| 9 | Click “Continue” on draft | Returns to form with saved values | | |
| 10 | Complete and submit application | Status changes to “Submitted” | | |
| 11 | Verify application now read-only | Cannot edit after submission | | |
| 12 | Check submitted applications section | Application appears with “Submitted” status | | |
| 13 | View application details | All submitted data visible | | |
Notes:
Test portal navigation, verify draft auto-save behavior
TS-020: Admin - Submission Status Management
Objective: Verify admins can update submission statuses
Priority: High
Prerequisites: Form with submissions
Test Steps
| Step | Action | Expected Result | Actual Result | Status |
|---|
| 1 | Log in as admin | Dashboard loads | | |
| 2 | Navigate to form submissions | Submissions list loads | | |
| 3 | Select a submission | Submission detail page opens | | |
| 4 | Locate status dropdown | Shows current status “Submitted” | | |
| 5 | Change status to “Approved” | Status updates | | |
| 6 | Add status note: “Meets all requirements” | Note added | | |
| 7 | Save status change | Change saved successfully | | |
| 8 | Verify status history updated | New status entry with timestamp appears | | |
| 9 | If applicant is logged in, verify they see status update | Status reflects in portal | | |
| 10 | Change status to “Rejected” | Status updates | | |
| 11 | Add rejection note: “Missing documentation” | Note added | | |
| 12 | Save changes | Change saved | | |
Notes:
Test all status transitions, verify notifications if configured
Objective: Verify analytics display correctly
Priority: Medium
Prerequisites: Form with several submissions
Test Steps
| Step | Action | Expected Result | Actual Result | Status |
|---|
| 1 | Navigate to form settings > Insights | Analytics page loads | | |
| 2 | Verify total submissions count | Shows accurate count | | |
| 3 | Verify completion rate displays | Percentage shown (e.g., “85%“) | | |
| 4 | Check time filter options | Can select: 24h, 7d, 30d, All | | |
| 5 | Select “Last 7 days” | Charts update to show 7-day data | | |
| 6 | View submission timeline chart | Line/bar chart shows daily submissions | | |
| 7 | View field drop-off analysis | Shows which fields users abandon | | |
| 8 | Verify visitor count (if tracked) | Shows unique visitors | | |
| 9 | Export analytics data | CSV download starts | | |
Notes:
May show limited data with few submissions - verify calculations are correct
TS-022: Mobile Responsiveness
Objective: Verify Terra works on mobile devices
Priority: High
Prerequisites: Access to mobile device or browser dev tools
Test Steps
| Step | Action | Expected Result | Actual Result | Status |
|---|
| 1 | Open browser dev tools, toggle mobile view | Mobile viewport activated | | |
| 2 | Set viewport to iPhone SE (375x667) | Viewport resized | | |
| 3 | Navigate to staging Terra | Landing page loads, fits screen | | |
| 4 | Log in | Login flow works on mobile | | |
| 5 | View dashboard | Dashboard adapts to mobile layout | | |
| 6 | Navigate to forms list | Forms list uses mobile layout, readable | | |
| 7 | Open a form | Form editor/builder adapts to mobile (or shows desktop notice) | | |
| 8 | Visit public form /f/qa-test-1 | Form renders well on mobile | | |
| 9 | Fill out form fields | All inputs accessible and usable | | |
| 10 | Submit form | Submission works on mobile | | |
| 11 | Test portal on mobile | Portal layout adapts to small screen | | |
| 12 | Test with Android viewport (360x800) | Similar results on Android size | | |
Notes:
Test on actual device if available, note any layout issues
DAY 3: Edge Cases, Security, & Final Testing
Focus: Error handling, permissions, edge cases, security
Time Estimate: 6-8 hours
Objective: Test form locking when multiple users edit
Priority: High
Prerequisites: 2 user accounts, same form access
Test Steps
| Step | Action | Expected Result | Actual Result | Status |
|---|
| 1 | Log in as User A | Dashboard loads | | |
| 2 | Open form “QA Test Form 1” in editor | Form loads, editing enabled | | |
| 3 | Log in as User B (different browser/incognito) | Dashboard loads | | |
| 4 | User B opens same form in editor | Warning: “Another user is editing” or form locked | | |
| 5 | Verify User B cannot edit | Form read-only or shows lock message | | |
| 6 | User A makes a change and saves | Change saved | | |
| 7 | User A closes editor or logs out | Form lock released | | |
| 8 | Wait 5 minutes (lock timeout) | Lock expires | | |
| 9 | User B refreshes page | Form now editable for User B | | |
| 10 | User B makes changes | Changes saved successfully | | |
Notes:
Test 5-minute heartbeat timeout, verify lock indicator shows who’s editing
TS-024: Permission and Access Control
Objective: Verify non-admin users cannot access admin features
Priority: Critical
Prerequisites: Regular user account (non-admin)
Test Steps
| Step | Action | Expected Result | Actual Result | Status |
|---|
| 1 | Log in as non-admin user | Portal loads | | |
| 2 | Try navigating to /forms directly | Redirected to /portal or 403 error | | |
| 3 | Try navigating to /settings | Redirected or 403 error | | |
| 4 | Try URL /forms/[formId]/edit | Access denied | | |
| 5 | Try URL /forms/[formId]/submissions | Access denied | | |
| 6 | Verify portal access works | Can view own applications | | |
| 7 | Verify can submit public forms | Submission works | | |
| 8 | Log out and log in as admin | Admin dashboard loads | | |
| 9 | Verify admin CAN access /forms | Forms list loads | | |
| 10 | Verify admin CAN access settings | Settings pages load | | |
Notes:
Critical security test - all admin routes must be protected
Objective: Test form deletion and archival workflows
Priority: Medium
Prerequisites: Test form that can be deleted
Test Steps
| Step | Action | Expected Result | Actual Result | Status |
|---|
| 1 | Navigate to forms list | Forms list loads | | |
| 2 | Find form to archive | Form visible | | |
| 3 | Open form options menu | Menu opens | | |
| 4 | Select “Archive” | Confirmation dialog appears | | |
| 5 | Confirm archive | Form archived, removed from main list | | |
| 6 | Filter to show archived forms | Archived forms visible | | |
| 7 | Find archived form | Form shown with “Archived” status | | |
| 8 | Select “Restore” | Confirmation dialog appears | | |
| 9 | Confirm restore | Form returns to active list | | |
| 10 | Now test deletion: Select “Delete” | Deletion confirmation dialog appears | | |
| 11 | Confirm deletion | Form permanently deleted | | |
| 12 | Verify form no longer in any list | Form not found | | |
| 13 | Try accessing deleted form URL | 404 error or “Form not found” message | | |
| 14 | Verify public form URL also gone | /f/[slug] shows 404 | | |
Notes:
Be careful deleting forms - use test forms only
Objective: Test handling of large submissions with many fields
Priority: Medium
Prerequisites: Form with 20+ fields
Test Steps
| Step | Action | Expected Result | Actual Result | Status |
|---|
| 1 | Create form “QA Large Form” with 25+ fields | Form created | | |
| 2 | Include various field types | Text, number, date, choice, file, signature, etc. | | |
| 3 | Publish form | Form published | | |
| 4 | Visit public form | All fields render | | |
| 5 | Fill out all 25 fields | All values entered | | |
| 6 | Upload 3 files (small PDFs) | Files upload successfully | | |
| 7 | Submit form | Submission processes (may take a few seconds) | | |
| 8 | Verify success message | Submission confirmed | | |
| 9 | View submission in admin | All 25 fields display correctly | | |
| 10 | Verify all uploaded files accessible | Can view/download all files | | |
Notes:
Monitor performance, note any timeouts or errors
TS-027: File Upload Security
Objective: Test file upload validation and security
Priority: High
Prerequisites: Form with file upload field
Test Steps
| Step | Action | Expected Result | Actual Result | Status |
|---|
| 1 | Visit form with file upload | Form loads | | |
| 2 | Try uploading .exe file | Rejected: “File type not allowed” | | |
| 3 | Try uploading .php file | Rejected | | |
| 4 | Try uploading valid PDF | File accepted | | |
| 5 | Try uploading valid image (PNG/JPG) | File accepted | | |
| 6 | Try uploading file > 10MB | Rejected: “File too large” | | |
| 7 | Upload valid file and submit | Submission successful | | |
| 8 | View submission in admin | File link present | | |
| 9 | Click file link | File downloads securely | | |
| 10 | Check file URL structure | Uses signed/secure URLs, not direct paths | | |
| 11 | Try accessing file URL after logout | Access denied or URL expired | | |
Test Data:
- Prepare: small.pdf (< 5MB), large.pdf (> 10MB), test.exe, test.php, image.png
Notes:
Critical security test - verify file type validation works
Objective: Test automatic form opening and closing
Priority: Medium
Prerequisites: Form with open/close dates
Test Steps
| Step | Action | Expected Result | Actual Result | Status |
|---|
| 1 | Create form “QA Scheduling Test” | Form created | | |
| 2 | Go to form settings > Details | Settings page loads | | |
| 3 | Set “Opens At” to tomorrow’s date | Date saved | | |
| 4 | Publish form | Form published | | |
| 5 | Visit public form URL | Shows “Coming Soon” or scheduled message | | |
| 6 | Verify admin can preview with ?preview=draft | Admin sees form preview | | |
| 7 | Change “Opens At” to current time - 1 hour (past) | Date saved | | |
| 8 | Visit public form | Form is now accessible | | |
| 9 | Set “Closes At” to current time + 1 hour (future) | Date saved | | |
| 10 | Verify form still accessible | Form loads | | |
| 11 | Set “Closes At” to current time - 1 hour (past) | Date saved | | |
| 12 | Visit public form | Shows “Form closed” message | | |
Notes:
Test various date/time combinations, verify timezone handling
TS-029: Response Capacity Limit
Objective: Test form closes when capacity reached
Priority: Medium
Prerequisites: New form
Test Steps
| Step | Action | Expected Result | Actual Result | Status |
|---|
| 1 | Create form “QA Capacity Test” | Form created | | |
| 2 | Set response capacity to “3” in settings | Capacity set | | |
| 3 | Publish form | Form published | | |
| 4 | Submit form (submission #1) | Successful | | |
| 5 | Submit form again (submission #2) | Successful | | |
| 6 | Submit form third time (submission #3) | Successful | | |
| 7 | Try submitting fourth time (submission #4) | Form shows “Capacity reached” or similar | | |
| 8 | Verify form status auto-changed to Closed | Status is “Closed” in admin | | |
Notes:
May need to use different browsers/incognito for multiple submissions
TS-030: XSS and Injection Prevention
Objective: Verify forms protect against XSS attacks
Priority: Critical
Prerequisites: Form with text fields
Test Steps
| Step | Action | Expected Result | Actual Result | Status |
|---|
| 1 | Visit form with text field | Form loads | | |
| 2 | Enter XSS payload: <script>alert('xss')</script> | Value entered | | |
| 3 | Submit form | Form submits | | |
| 4 | View submission in admin | Script tag visible as text, NOT executed | | |
| 5 | Verify no alert popup occurred | No popup | | |
| 6 | Try payload in form title (admin): <img src=x onerror=alert(1)> | Title saved | | |
| 7 | View form in public | Title displays as text, no script execution | | |
| 8 | Try SQL injection in text field: '; DROP TABLE forms; -- | Value entered | | |
| 9 | Submit form | Form submits normally | | |
| 10 | Verify form still exists | No database damage occurred | | |
Test Data:
- XSS payloads:
<script>alert('xss')</script>, <img src=x onerror=alert(1)>
- SQL payload:
'; DROP TABLE forms; --
Notes:
Critical security test - all payloads must be safely sanitized
TS-031: Session Timeout and Re-authentication
Objective: Test session expiration handling
Priority: Medium
Prerequisites: Authenticated user
Test Steps
| Step | Action | Expected Result | Actual Result | Status |
|---|
| 1 | Log in to Terra | Session created | | |
| 2 | Note login time | Time recorded | | |
| 3 | Leave browser idle for 30+ minutes | Session may expire (depends on timeout setting) | | |
| 4 | Try navigating to protected page | Redirected to login if expired | | |
| 5 | Log back in | Session restored | | |
| 6 | Try performing action (e.g., save form) immediately | Action succeeds | | |
| 7 | Open dev tools, delete session cookie | Cookie removed | | |
| 8 | Refresh page | Redirected to login | | |
Notes:
Session timeout duration may vary - document observed behavior
Objective: Test creating copy of existing form
Priority: Medium
Prerequisites: Published form with fields
Test Steps
| Step | Action | Expected Result | Actual Result | Status |
|---|
| 1 | Navigate to forms list | Forms list loads | | |
| 2 | Find “QA Test Form 1” | Form visible | | |
| 3 | Click form options menu | Menu opens | | |
| 4 | Select “Duplicate” | Duplication process starts | | |
| 5 | Verify new form created | ”Copy of QA Test Form 1” appears in list | | |
| 6 | Open duplicated form | Form loads | | |
| 7 | Verify all fields copied | All original fields present | | |
| 8 | Verify settings copied | Title, description, etc. match (with “Copy of”) | | |
| 9 | Verify duplicate has unique slug | Slug is different from original | | |
| 10 | Verify submissions NOT copied | Duplicate has 0 submissions | | |
Notes:
Confirm duplicate is truly independent (editing one doesn’t affect the other)
TS-033: Multi-language Support
Objective: Test form translations and language switching
Priority: Medium
Prerequisites: Form configured for multiple languages
Test Steps
| Step | Action | Expected Result | Actual Result | Status |
|---|
| 1 | Create form “QA Translation Test” | Form created | | |
| 2 | Add fields with English labels | Fields added | | |
| 3 | Go to Settings > Translations | Translations page loads | | |
| 4 | Add Spanish translation | Spanish added as available language | | |
| 5 | Translate form title to Spanish | Translation saved | | |
| 6 | Translate field labels to Spanish | All labels translated | | |
| 7 | Enable language switcher | Switcher enabled | | |
| 8 | Publish form | Form published | | |
| 9 | Visit public form | Language switcher visible | | |
| 10 | Verify default language is English | English labels display | | |
| 11 | Switch to Spanish | All labels change to Spanish | | |
| 12 | Fill and submit form in Spanish | Submission successful | | |
| 13 | View submission in admin | Shows language used (if tracked) | | |
Test Data:
- English: “First Name” → Spanish: “Nombre”
- English: “Email” → Spanish: “Correo electrónico”
Notes:
Test with multiple languages if supported, verify RTL languages if applicable
TS-034: Email Deliverability
Objective: Test email notifications reach inbox
Priority: High
Prerequisites: Form with email notifications configured
Test Steps
| Step | Action | Expected Result | Actual Result | Status |
|---|
| 1 | Configure form notifications | Notifications enabled | | |
| 2 | Set admin email recipient | Email saved | | |
| 3 | Enable submitter confirmation email | Setting enabled | | |
| 4 | Submit test form with valid email | Form submitted | | |
| 5 | Check admin inbox (within 1 min) | Notification email received | | |
| 6 | Verify email sender address | From: noreply@terra.withunify.org or similar | | |
| 7 | Verify email subject line | Subject indicates form submission | | |
| 8 | Verify email body contains data | All submitted values in email | | |
| 9 | Check submitter inbox | Confirmation email received | | |
| 10 | Verify no emails in spam folder | Emails in inbox, not spam | | |
| 11 | Click any links in email | Links work, go to correct pages | | |
Notes:
Check spam/junk folders, note delivery time in minutes
TS-035: Draft Auto-Save Behavior
Objective: Test auto-save functionality for drafts
Priority: Medium
Prerequisites: Authenticated user in portal
Test Steps
| Step | Action | Expected Result | Actual Result | Status |
|---|
| 1 | Log in to portal | Portal loads | | |
| 2 | Start new application | Form loads | | |
| 3 | Fill first field | Value entered | | |
| 4 | Wait 10 seconds (auto-save interval) | “Saving…” or “Draft saved” indicator appears | | |
| 5 | Fill second field | Value entered | | |
| 6 | Close browser tab immediately (no manual save) | Tab closed | | |
| 7 | Reopen portal in new tab | Portal loads | | |
| 8 | Find draft application | Draft appears in list | | |
| 9 | Open draft | Form loads | | |
| 10 | Verify both fields have saved values | Values present | | |
Notes:
Test auto-save timing, verify no data loss on abrupt close
TS-036: Submission Export
Objective: Test exporting submissions as CSV/JSON
Priority: Medium
Prerequisites: Form with 3+ submissions
Test Steps
| Step | Action | Expected Result | Actual Result | Status |
|---|
| 1 | Navigate to form submissions | Submissions list loads | | |
| 2 | Go to Export section (or click Export button) | Export dialog opens | | |
| 3 | Select format: CSV | Format selected | | |
| 4 | Select date range: All time | Range selected | | |
| 5 | Select all fields to export | All fields checked | | |
| 6 | Click “Export” | Download starts | | |
| 7 | Open CSV file | File opens in Excel/Google Sheets | | |
| 8 | Verify all submissions present | Row count matches submission count | | |
| 9 | Verify all columns present | Each field has column | | |
| 10 | Verify data accuracy | Spot check values match admin view | | |
| 11 | Repeat export with JSON format | JSON file downloads | | |
| 12 | Open JSON in text editor | Valid JSON structure | | |
Notes:
Test different date ranges and field selections
TS-037: Applicant Profile and Vault
Objective: Test applicant profile and data vault features
Priority: Medium
Prerequisites: User account with portal access
Test Steps
| Step | Action | Expected Result | Actual Result | Status |
|---|
| 1 | Log in to portal as applicant | Portal loads | | |
| 2 | Navigate to Profile section | Profile page loads | | |
| 3 | Fill out profile information | Fields available for editing | | |
| 4 | Save profile | Profile saved successfully | | |
| 5 | Navigate to “Vault” or saved info section | Vault page loads | | |
| 6 | Add reusable information (e.g., address, education) | Data saved to vault | | |
| 7 | Start new application | Form loads | | |
| 8 | Verify vault data prefills form fields | Matching fields auto-filled | | |
| 9 | Edit prefilled value | Can modify prefilled data | | |
| 10 | Submit application | Submission successful | | |
| 11 | Return to vault | Vault data unchanged | | |
Notes:
Test vault data persistence, verify prefill matching logic
TS-038: Admin Audit Log
Objective: Verify admin actions are logged
Priority: Medium
Prerequisites: Admin account
Test Steps
| Step | Action | Expected Result | Actual Result | Status |
|---|
| 1 | Log in as admin | Dashboard loads | | |
| 2 | Perform various actions: | | | |
- Create form
- Edit form settings
- Delete submission
- Add team member | Actions completed | | |
| 3 | Navigate to Settings > Audit Log | Audit log page loads | | |
| 4 | Verify recent actions appear | All performed actions logged | | |
| 5 | Check log entry details | Shows: timestamp, user, action, resource | | |
| 6 | Filter by action type | Filter works | | |
| 7 | Search for specific form name | Search returns relevant logs | | |
| 8 | Export audit log | CSV download starts | | |
Notes:
Verify sensitive actions (deletes, permission changes) are logged
TS-039: Error Handling and User Feedback
Objective: Test error messages are clear and helpful
Priority: High
Prerequisites: Various test scenarios
Test Steps
| Step | Action | Expected Result | Actual Result | Status |
|---|
| 1 | Try submitting form without required fields | Clear error: “This field is required” | | |
| 2 | Try invalid email format | Error: “Please enter a valid email” | | |
| 3 | Try accessing non-existent form /f/fake-slug | 404 page with helpful message | | |
| 4 | Simulate network error during submission | Error message with retry option | | |
| 5 | Try uploading oversized file | Error: “File size exceeds 10MB limit” | | |
| 6 | Try setting form close date before open date | Validation error prevents save | | |
| 7 | Try duplicate form slug | Error: “This slug is already in use” | | |
| 8 | Try deleting form with team members | Warning or confirmation dialog | | |
Notes:
All errors should be user-friendly, actionable, and not expose technical details
Objective: Test system performance under realistic load
Priority: Medium
Prerequisites: Form with many submissions
Test Steps
| Step | Action | Expected Result | Actual Result | Status |
|---|
| 1 | Navigate to form with 100+ submissions | Page loads in < 3 seconds | | |
| 2 | Paginate through submissions | Pagination smooth, no lag | | |
| 3 | Sort submissions by date | Sorting completes quickly | | |
| 4 | Search submissions | Search results return quickly | | |
| 5 | Load form with 50+ fields in builder | Form loads in reasonable time (< 5 sec) | | |
| 6 | Make edit to large form and save | Save completes in < 3 seconds | | |
| 7 | Submit large form with 10 files | Submission completes (may take 10-30 sec) | | |
| 8 | Load dashboard with 20+ forms | Dashboard loads in < 3 seconds | | |
Notes:
Record load times, note any timeouts or performance issues
Bug Report Template
Use this template to document any bugs found during testing.
BUG-XXX: [Brief Description]
Test Script: [TS-XXX that revealed bug]
Date Found: [Date]
Severity: [Critical / High / Medium / Low]
Environment: the active QA deployment URL
Steps to Reproduce
- [Step 1]
- [Step 2]
- [Step 3]
Expected Result
[What should happen]
Actual Result
[What actually happened]
Screenshots/Videos
[Attach or link to screenshots]
Additional Notes
[Any other relevant information]
Daily Testing Summary
Day 1 Summary
Date: _______________
Tests Completed: ___ / 10
Pass Rate: ___%
Bugs Found: ___
Blockers: ___
Notes:
[Key findings, observations, questions]
Day 2 Summary
Date: _______________
Tests Completed: ___ / 12
Pass Rate: ___%
Bugs Found: ___
Blockers: ___
Notes:
[Key findings, observations, questions]
Day 3 Summary
Date: _______________
Tests Completed: ___ / 18
Pass Rate: ___%
Bugs Found: ___
Blockers: ___
Notes:
[Key findings, observations, questions]
Final QA Report
Total Tests Executed: ___ / 40
Overall Pass Rate: ___%
Total Bugs Found: ___
Critical Bugs: ___
High Priority Bugs: ___
Medium/Low Bugs: ___
Recommendations
[List top recommendations for production readiness]
Areas Not Tested
[List any areas that were skipped or blocked]
Sign-off
Tester Name: ___________________
Date: ___________________
Signature: ___________________