# SLA Testing Plan for Complaints

## Overview
This document provides a comprehensive testing plan for the SLA (Service Level Agreement) system in the PX360 complaint management system.

## System Components

### 1. Complaint Model SLA Fields
- `due_at` - SLA deadline calculated based on severity/priority
- `is_overdue` - Boolean flag for overdue status
- `reminder_sent_at` - Timestamp for first SLA reminder
- `second_reminder_sent_at` - Timestamp for second SLA reminder
- `escalated_at` - Timestamp when complaint was escalated
- `metadata['escalation_level']` - Current escalation level

### 2. ComplaintSLAConfig Model
Configures SLA per hospital, severity, and priority:
- `sla_hours` - Hours until SLA deadline
- `reminder_hours_before` - Send first reminder X hours before deadline
- `second_reminder_enabled` - Enable second reminder
- `second_reminder_hours_before` - Send second reminder X hours before deadline
- `thank_you_email_enabled` - Send thank you email on closure

### 3. EscalationRule Model
Configures automatic escalation:
- `escalation_level` - Current escalation level (1, 2, 3...)
- `max_escalation_level` - Maximum level before stopping
- `trigger_on_overdue` - Trigger when overdue
- `trigger_hours_overdue` - Trigger X hours after overdue
- `reminder_escalation_enabled` - Enable escalation after reminder
- `reminder_escalation_hours` - Escalate X hours after reminder
- `escalate_to_role` - Who to escalate to (department_manager, hospital_admin, px_admin, ceo, specific_user)

### 4. Celery Tasks
- `send_sla_reminders` - Hourly task to send first and second reminders
- `check_overdue_complaints` - Every 15 minutes to check and mark overdue
- `escalate_complaint_auto` - Triggered when complaint becomes overdue
- `escalate_after_reminder` - Triggered after reminder if no action

## Test Scenarios

### Scenario 1: SLA Deadline Calculation
**Objective**: Verify SLA deadline is calculated correctly on complaint creation

**Steps**:
1. Configure ComplaintSLAConfig for hospital:
   - Severity: Medium, Priority: Medium
   - SLA hours: 48
2. Create a complaint with medium severity and priority
3. Verify `due_at` is set to 48 hours from creation time
4. Verify `is_overdue` is False
5. Verify `reminder_sent_at` is None
6. Verify `second_reminder_sent_at` is None

**Expected Result**:
- `due_at = created_at + 48 hours`
- `is_overdue = False`
- Reminder timestamps are None

### Scenario 2: First SLA Reminder
**Objective**: Verify first reminder is sent at configured time

**Prerequisites**:
- ComplaintSLAConfig with `reminder_hours_before = 24`
- Complaint due in 26 hours (triggers reminder at 24 hours before)

**Steps**:
1. Create complaint due in 26 hours
2. Wait until 24 hours before deadline
3. Run `send_sla_reminders` task
4. Verify:
   - Email sent to assigned user or department manager
   - `reminder_sent_at` is set
   - ComplaintUpdate created with update_type='note'
   - Audit log created for SLA reminder sent

**Expected Result**:
- Email sent successfully
- `reminder_sent_at` populated
- Timeline entry shows "SLA reminder sent"
- Hours remaining in email = 24

### Scenario 3: Second SLA Reminder
**Objective**: Verify second reminder is sent at configured time

**Prerequisites**:
- ComplaintSLAConfig with:
  - `second_reminder_enabled = True`
  - `second_reminder_hours_before = 6`
- First reminder already sent
- Complaint due in 7 hours

**Steps**:
1. Create complaint due in 7 hours
2. Ensure first reminder already sent
3. Wait until 6 hours before deadline
4. Run `send_sla_reminders` task
5. Verify:
   - Second email sent with URGENT subject
   - `second_reminder_sent_at` is set
   - ComplaintUpdate created
   - Audit log created
   - `escalate_after_reminder` task triggered

**Expected Result**:
- Second email sent successfully
- `second_reminder_sent_at` populated
- Timeline entry shows "SECOND SLA reminder sent"
- Escalation check triggered

### Scenario 4: Overdue Detection
**Objective**: Verify complaints are marked as overdue past deadline

**Steps**:
1. Create complaint due in 1 hour
2. Wait until due_at passes
3. Run `check_overdue_complaints` task
4. Verify:
   - `is_overdue` changed to True
   - `escalate_complaint_auto` task triggered

**Expected Result**:
- `is_overdue = True`
- Automatic escalation initiated
- Warning logged about overdue complaint

### Scenario 5: Overdue Escalation (Level 1)
**Objective**: Verify first level escalation works

**Prerequisites**:
- EscalationRule configured:
  - `escalation_level = 1`
  - `trigger_on_overdue = True`
  - `trigger_hours_overdue = 0` (immediate)
  - `escalate_to_role = department_manager`

**Steps**:
1. Create complaint due in 1 hour
2. Wait until overdue
3. Run `escalate_complaint_auto` task
4. Verify:
   - Assigned to department manager
   - `escalated_at` is set
   - `metadata['escalation_level'] = 1`
   - ComplaintUpdate created with update_type='escalation'
   - Notification sent
   - Audit log created

**Expected Result**:
- Reassigned to department manager
- Escalation level set to 1
- Timeline shows escalation details
- Email notification sent

### Scenario 6: Reminder-Based Escalation (Level 2)
**Objective**: Verify escalation after reminder if no action

**Prerequisites**:
- EscalationRule configured:
  - `escalation_level = 2`
  - `trigger_on_overdue = False`
  - `reminder_escalation_enabled = True`
  - `reminder_escalation_hours = 12`
  - `escalate_to_role = hospital_admin`
- First reminder sent 13+ hours ago
- No updates to complaint since reminder

**Steps**:
1. Create complaint with first reminder sent 13 hours ago
2. Run `escalate_after_reminder` task
3. Verify:
   - Assigned to hospital admin
   - `escalated_at` updated
   - `metadata['escalation_level'] = 2`
   - ComplaintUpdate created
   - Metadata includes `reminder_escalation` info

**Expected Result**:
- Escalated to hospital admin
- Escalation level incremented to 2
- Timeline shows "Reminder-based escalation"
- Hours since reminder logged

### Scenario 7: Multi-Level Escalation
**Objective**: Verify multiple escalation levels work sequentially

**Prerequisites**:
- 3 escalation rules configured:
  - Level 1: Department Manager (immediate overdue)
  - Level 2: Hospital Admin (12 hours after reminder)
  - Level 3: PX Admin (24 hours after level 2)

**Steps**:
1. Create complaint due in 1 hour
2. Trigger level 1 escalation (immediate overdue)
3. Wait 13 hours after reminder
4. Trigger level 2 escalation (reminder-based)
5. Wait 24 hours more
6. Trigger level 3 escalation (reminder-based)
7. Verify:
   - Escalation level increments correctly
   - Assigned user changes at each level
   - Timeline shows all escalations
   - Metadata tracks escalation history

**Expected Result**:
- Level 1 → Department Manager
- Level 2 → Hospital Admin
- Level 3 → PX Admin
- Each escalation logged correctly

### Scenario 8: Max Escalation Level
**Objective**: Verify escalation stops at max level

**Prerequisites**:
- EscalationRule with `max_escalation_level = 3`
- Complaint already escalated to level 3

**Steps**:
1. Trigger escalation on level 3 complaint
2. Verify:
   - No further escalation occurs
   - Log message: "reached max escalation level 3"
   - Complaint remains with level 3 assignee

**Expected Result**:
- Escalation stops at max level
- No reassignment occurs
- Warning logged

### Scenario 9: Thank You Email on Closure
**Objective**: Verify thank you email sent when complaint is closed

**Prerequisites**:
- ComplaintSLAConfig with `thank_you_email_enabled = True`
- Patient has email/phone

**Steps**:
1. Create complaint with resolved status
2. Change status to closed
3. Verify:
   - Thank you email sent to patient
   - Email contains complaint details
   - Timeline entry created
   - Audit log created

**Expected Result**:
- Thank you email sent
- Patient notification received
- Timeline shows thank you sent

### Scenario 10: Resolution Satisfaction Survey
**Objective**: Verify survey is sent when complaint is closed

**Steps**:
1. Create complaint with patient
2. Resolve complaint
3. Close complaint
4. Verify:
   - SurveyInstance created
   - Survey linked to complaint
   - `resolution_survey_sent_at` is set
   - SMS/email sent to patient
   - Survey status = 'active'

**Expected Result**:
- Survey created and linked
- Patient receives survey invitation
- Timeline shows "Resolution satisfaction survey sent"

### Scenario 11: Low Survey Score Threshold
**Objective**: Verify PX Action created for low survey scores

**Prerequisites**:
- ComplaintThreshold configured:
  - `threshold_type = resolution_survey_score`
  - `threshold_value = 50`
  - `comparison_operator = lt` (less than)
  - `action_type = create_px_action`

**Steps**:
1. Close complaint (triggers survey)
2. Complete survey with score 30
3. Run `check_resolution_survey_threshold` task
4. Verify:
   - PXAction created
   - Action title includes "Low Resolution Satisfaction"
   - Action linked to complaint
   - Survey score in metadata
   - Threshold value in metadata
   - Audit log created

**Expected Result**:
- PX Action created automatically
- Action shows low satisfaction details
- Audit trail exists

### Scenario 12: Bilingual Email Content
**Objective**: Verify emails are sent in both English and Arabic

**Steps**:
1. Trigger SLA reminder
2. Check email content:
   - Contains English text
   - Contains Arabic translation
   - Both languages properly formatted
   - RTL direction for Arabic text

**Expected Result**:
- Bilingual email sent
- Both languages readable
- Proper formatting maintained

### Scenario 13: No Assignee Reminder Handling
**Objective**: Verify reminder sent to department manager if no assignee

**Prerequisites**:
- Complaint has no assigned_to user
- Department has manager configured

**Steps**:
1. Create complaint without assignee
2. Set department with manager
3. Trigger SLA reminder
4. Verify:
   - Reminder sent to department manager
   - No error for missing assignee
   - Timeline entry shows recipient

**Expected Result**:
- Department manager receives reminder
- No assignment needed for reminder
- System handles gracefully

### Scenario 14: Multiple Reminders Not Sent
**Objective**: Verify reminders are not sent multiple times

**Steps**:
1. Create complaint due in 24 hours
2. Trigger first reminder
3. Immediately trigger reminder task again
4. Verify:
   - Second trigger skips already-sent reminder
   - Only one email sent
   - `reminder_sent_at` not updated again

**Expected Result**:
- Reminders sent only once
- Task checks timestamps before sending
- No duplicate emails

### Scenario 15: SLA Configuration Not Found
**Objective**: Verify fallback to default SLA when no config exists

**Prerequisites**:
- No ComplaintSLAConfig for hospital/severity/priority
- settings.SLA_DEFAULTS configured

**Steps**:
1. Create complaint with medium severity/priority
2. Verify `due_at` calculated
3. Check calculation used default value from settings

**Expected Result**:
- SLA calculated from defaults
- Complaint creation successful
- Warning logged about missing config

## Test Execution

### Automated Testing
Run the automated test script:
```bash
python test_sla_functionality.py
```

This script tests:
- SLA configuration setup
- First reminder logic
- Second reminder logic
- Escalation rules
- Timeline tracking

### Manual Testing

#### Using Django Admin
1. Create ComplaintSLAConfig for test hospital
2. Create EscalationRule(s) for test hospital
3. Create test complaint
4. Manually update `due_at` to trigger reminders
5. Run Celery tasks manually
6. Verify emails received
7. Check complaint timeline
8. Verify escalation in database

#### Using API
1. Create complaint via API
2. Update complaint status to closed
3. Trigger survey threshold check
4. Verify PX Action created via API
5. Check audit logs

### Testing with Real Time
For production testing:
1. Configure Celery Beat to run tasks on schedule
2. Create complaints with various due times
3. Monitor logs for task execution
4. Verify emails sent at correct times
5. Check escalation behavior
6. Monitor for errors

## Data Requirements

### Required Test Data
1. Hospital with active status
2. Department with manager assigned
3. Users with different roles:
   - Hospital Admin
   - Department Manager
   - PX Admin
   - Regular Staff
4. Patient with phone/email
5. ComplaintCategory configured
6. ComplaintSLAConfig for multiple severity/priority combos
7. EscalationRules for different levels
8. ComplaintThreshold for survey scores

### Configuration Checklist
- [ ] Email backend configured (SMTP or console)
- [ ] SMS service configured (for surveys)
- [ ] Celery worker running
- [ ] Celery Beat scheduler running
- [ ] SITE_URL configured in settings
- [ ] SLA_DEFAULTS configured in settings
- [ ] NotificationService methods available
- [ ] Audit logging enabled

## Success Criteria

### Functional Requirements
- [ ] SLA calculated correctly for all severity/priority combinations
- [ ] First reminder sent at configured time
- [ ] Second reminder sent at configured time
- [ ] Overdue detection works correctly
- [ ] Level 1 escalation triggers on overdue
- [ ] Level 2+ escalation triggers after reminder
- [ ] Max escalation level respected
- [ ] Escalation targets correct users
- [ ] Timeline entries created for all events
- [ ] Audit logs created for all events
- [ ] Emails sent in both English and Arabic
- [ ] Survey sent on closure
- [ ] PX Action created for low survey scores
- [ ] Thank you email sent on closure

### Non-Functional Requirements
- [ ] Tasks execute within SLA time windows
- [ ] No duplicate emails sent
- [ ] System handles missing data gracefully
- [ ] Fallback to defaults works
- [ ] Error handling is robust
- [ ] Logging is comprehensive
- [ ] Performance is acceptable

## Monitoring & Logging

### Key Logs to Monitor
1. **SLA Reminders**:
   - "SLA reminder sent for complaint {id}"
   - "Second SLA reminder sent for complaint {id}"
   - Hours remaining values

2. **Overdue Detection**:
   - "Complaint {id} is overdue"
   - Hours overdue values

3. **Escalation**:
   - "Escalated complaint {id} to {user}"
   - "Reminder-based escalation triggered"
   - "reached max escalation level {level}"

4. **Surveys**:
   - "Resolution satisfaction survey sent"
   - "survey score {score} breaches threshold"

5. **Errors**:
   - Any ERROR level logs
   - Exception traces
   - Failed email sending

### Metrics to Track
- SLA breach rate
- Average time to resolution
- Escalation frequency by level
- Reminder effectiveness (action taken after reminder)
- Survey response rate
- PX Action creation rate

## Troubleshooting

### Common Issues

**Issue**: Reminders not sending
- Check: Celery worker running
- Check: Celery Beat scheduler running
- Check: Email backend configured
- Check: Complaint status (must be OPEN or IN_PROGRESS)
- Check: `reminder_sent_at` timestamp

**Issue**: Escalation not triggering
- Check: EscalationRule exists and is_active=True
- Check: Severity/priority filters match complaint
- Check: Hours overdue criteria met
- Check: Escalation target user exists
- Check: Already assigned to same user

**Issue**: Survey not sending
- Check: SurveyTemplate exists for hospital
- Check: Patient has phone/email
- Check: Complaint status changed to CLOSED
- Check: NotificationService.send_survey_invitation available

**Issue**: PX Action not created
- Check: ComplaintThreshold exists and is_active=True
- Check: Threshold comparison logic
- Check: Survey score breaches threshold
- Check: Action type configured correctly

## Conclusion

This comprehensive SLA testing plan covers all aspects of the SLA system including:
- SLA calculation and deadline tracking
- First and second reminders
- Overdue detection and escalation
- Multi-level escalation with max level
- Resolution satisfaction surveys
- Threshold-based PX Action creation
- Bilingual email support
- Timeline and audit logging
- Edge cases and error handling

Follow this plan to ensure the SLA system functions correctly in production.
