Charon/docs/issues/manual_test_provider_security_notifications_pr1_pr2.md

title, status, priority, assignee, labels

title	status	priority	assignee	labels
Manual Test Plan - Provider Security Notifications (PR-1 + PR-2)	Open	High	QA	testing, frontend, backend, security

Test Goal

Manually verify that security notifications now follow provider-based event settings and that the Notifications/Security settings screens behave correctly for normal use and bug-hunt scenarios.

Scope

• Provider-based security notification events
• Notifications settings UX
• Security settings UX that triggers notification events
• Focused verification for completed PR-1 + PR-2 slices

Preconditions

• Charon is running and reachable in a browser.
• Tester can access Settings pages.
• At least one notification provider can be created/edited in UI.
• Optional but recommended: browser with a screen reader available for quick accessibility sanity checks.

Smoke Checklist (Fast Pass)

1) Provider Event Toggles - Basic Save/Reload

• Open notification provider settings.
• Enable one security event category, save, and confirm success message.
• Refresh the page.
• Confirm the saved value remains enabled after reload.
• Disable the same category, save, refresh, confirm it remains disabled.

2) Multi-Category Toggle Sanity

• Enable all security event categories for one provider.
• Save and refresh.
• Confirm all categories still show enabled.
• Disable all categories, save, refresh, confirm all are disabled.

3) Notifications/Security Settings Visibility

• Open Settings → Notifications and Security-related settings area.
• Confirm labels and controls are readable and actionable.
• Confirm no missing text keys (for example raw key names).
• Confirm no layout break at common desktop width.

Regression Checklist (Behavior Consistency)

4) Provider Isolation Regression

• Create or use two providers: Provider A and Provider B.
• Enable a security event on Provider A only.
• Save and reload.
• Confirm Provider B did not inherit Provider A settings.
• Flip the setup (A off, B on), save and reload.
• Confirm each provider keeps its own settings.

5) Existing Non-Security Notification Settings Regression

• Record a non-security setting value for a provider.
• Change only security event toggles.
• Save and reload.
• Confirm the recorded non-security setting did not unexpectedly change.

6) General Settings Navigation Regression

• Navigate away from notifications settings and come back.
• Confirm state shown matches the last saved values.
• Confirm no stale banner/toast remains after navigation.

Failure-Mode / Bug-Hunt Checklist

7) Save Failure Handling

• While editing toggles, trigger a failed save condition (for example, stop backend or disconnect network temporarily).
• Attempt to save.
• Confirm a clear error message is shown.
• Confirm UI does not falsely show success.
• Restore connectivity/service and retry save.
• Confirm successful retry works and values persist.

8) Rapid Toggle Stress

• Rapidly toggle categories on/off multiple times before saving.
• Save once.
• Refresh page.
• Confirm final persisted state matches what was shown at save time.
• Confirm no duplicated toasts or frozen controls.

9) Multi-Tab Race Check

• Open same settings screen in two browser tabs.
• In tab 1, change and save settings.
• In tab 2, without reload, change conflicting settings and save.
• Reload both tabs.
• Confirm final state is consistent and no corrupted UI state appears.

10) Empty/Minimal Provider Coverage

• Use a setup with only one provider enabled.
• Verify security event toggles still behave as expected.
• If provider is disabled, verify UI behavior is clear (not misleading about active notifications).

Accessibility Sanity Checklist

11) Keyboard Navigation

• Reach all controls using Tab and Shift+Tab only.
• Confirm visible focus indicator on each interactive control.
• Toggle checkboxes/switches using keyboard (Space/Enter where applicable).
• Confirm Save action is keyboard-operable.

12) Labels and Announcements

• Confirm each toggle has a clear visible label.
• Confirm status text and error/success messages are understandable.
• With a screen reader, verify key controls announce meaningful names and state (on/off, checked/unchecked).

Pass/Fail Criteria

• PASS when all smoke checks pass, no regression break is found, failure-mode behavior is clear and recoverable, and accessibility sanity checks pass.
• FAIL when saved values do not persist, providers unexpectedly affect each other, failures report misleading status, or keyboard/screen reader basics break.

Defect Logging Guidance

• For each defect, capture: page, provider name, action taken, expected vs actual result.
• Attach screenshot/video and browser info.
• Mark severity and whether issue is blocker for PR handoff.

Handoff Note

Use this checklist as the manual verification baseline for completed focused PR-1 + PR-2 work before final merge confirmation.