HH/docs/SLA_TESTING_PLAN.md

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:

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.