laxmanhalaki/Dealer_Onboarding_Backend
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
5ddbe525e6
Dealer_Onboarding_Backend/docs/TEST_CASES.md

204 lines
12 KiB
Markdown
Raw Blame History

# Dealer Offboarding — Test Cases & QA Tracker
> **Location:** `/backend/docs/TEST_CASES.md`
> **Last Updated:** 2026-04-20
> **Modules Covered:** Termination, Resignation, F&F Settlement, Constitutional Change, Relocation
> **Status Legend:** ✅ Fixed | ❌ Open | 🔄 In Progress | ⚠️ Known Issue
---
## 1. Termination Module
### 1.1 Push to F&F Action
| # | Test Case | Expected Behaviour | Status | Notes |
|---|---|---|---|---|
| T-01 | Click "Push to F&F" when stage is `NBH Evaluation` | Backend returns **400** — `Cannot trigger F&F from NBH Evaluation. Complete CEO and Legal approvals first.` | ✅ Fixed | Backend gate added in `termination.controller.ts` |
| T-02 | Click "Push to F&F" when stage is `Legal - Termination Letter` | F&F settlement created successfully; termination status → `F&F Initiated`; stage → `Terminated` | ✅ Fixed | Stage lock + correct status applied |
| T-03 | Click "Push to F&F" multiple times on the same record | Only one F&F record created (idempotency check via `db.FnF.findOne`) | ✅ Fixed | `TerminationWorkflowService.initiateFnF` resolves existing record |
| T-04 | After "Push to F&F", verify "Approve" button visibility | Approve button **must be hidden** — workflow locked | ✅ Fixed | `isSettlementPhase` flag disables all approval actions |
| T-05 | "Push to F&F" button visible to ASM role | Button **must not be visible** to ASM | ✅ Fixed | Role restricted to `DD Lead, DD Head, NBH, DD Admin, Super Admin` |
| T-06 | "Push to F&F" button visible at early stages (e.g. ZBH Review) | Button **must be hidden** until stage is `Legal - Termination Letter` or `Terminated` | ✅ Fixed | Frontend `canPushToFnF` condition updated |
| T-07 | After "Push to F&F", another approver tries to approve | Action rejected — buttons completely hidden | ✅ Fixed | `isSettlementPhase` + `isFinalState` guard |
---
### 1.2 Stage Approval Flow
| # | Test Case | Expected Behaviour | Status | Notes |
|---|---|---|---|---|
| T-08 | Sending `action: "pushfnf"` via API when ticket is mid-flow | Previously fell into generic "Approve" block and advanced stage incorrectly | ✅ Fixed | Explicit `pushfnf` handler added |
| T-09 | RBM approves at `RBM Review` | Stage advances to `ZBH Review` | ✅ | Standard flow |
| T-10 | NBH at `NBH Evaluation` clicks "Issue SCN" | Stage advances to `Show Cause Notice` | ✅ | `canIssueSCN` permission guarded |
| T-11 | ASM tries to Approve/Send Back | Buttons **must not be visible** — ASM is Create/View/Comment only | ✅ | SRS §8.3.4 enforced |
---
### 1.3 Progress Timeline / Status Display
| # | Test Case | Expected Behaviour | Status | Notes |
|---|---|---|---|---|
| T-12 | Termination reaches `Dealer Terminated` stage | All stages including "Dealer Terminated" show **green checkmark** | ✅ Fixed | `isSuccessFinal` flag added to `getProgressStatus()` |
| T-13 | Termination status is `F&F Initiated` | All completed stages show green; "Dealer Terminated" shows green | ✅ Fixed | `F&F Initiated`, `Settled` included in `isSuccessFinal` |
| T-14 | Termination is `Rejected` | Shows all stages up to rejection point; no misleading pending | ✅ | `isTerminal` logic handles rejected states |
---
## 2. Resignation Module
### 2.1 Push to F&F Action
| # | Test Case | Expected Behaviour | Status | Notes |
|---|---|---|---|---|
| R-01 | Click "Push to F&F" before Legal stage | Backend returns **400** — `Cannot trigger F&F from [stage]. Move request to Legal stage first.` | ✅ | Gate in `resignation.controller.ts` |
| R-02 | Click "Push to F&F" at Legal stage without a Legal-stage document | Backend returns **400** — `Legal-stage acceptance/communication document is required first.` | ✅ | Document gate enforced |
| R-03 | Click "Push to F&F" at Legal stage with document present | F&F initiated; stage → `F&F Initiated` | ✅ | |
| R-04 | Dealer role attempts to withdraw after reaching NBH stage | Withdraw button **must be hidden** | ✅ | `isPastNBH` guard in `canWithdraw` |
| R-05 | "Push to F&F" visible to ASM role | Button **must NOT be visible** | ✅ | Role whitelist enforced |
---
## 3. F&F Settlement Module
### 3.1 Document Management
| # | Test Case | Expected Behaviour | Status | Notes |
|---|---|---|---|---|
| F-01 | Upload document via F&F Details page | File stored, mapped in `clearanceDocuments`, appears in Submitted Documents table | ✅ Fixed | Multipart upload implemented in `settlement.controller.ts` |
| F-02 | Download uploaded F&F document | Forces direct file download (not new tab) | ✅ Fixed | Programmatic Blob fetch + hidden `<a>` tag |
| F-03 | Preview uploaded F&F document | ❌ Open | Pending implementation |
### 3.2 Status Display
| # | Test Case | Expected Behaviour | Status | Notes |
|---|---|---|---|---|
| F-04 | F&F Status badge text readability | White text on green/amber badges | ✅ Fixed | `text-white` applied in `FinanceFnFPage.tsx` |
---
## 4. Constitutional Change Module
### 4.1 Document Verification Permissions
| # | Test Case | Expected Behaviour | Status | Notes |
|---|---|---|---|---|
| C-01 | ASM sees "Verify" button on uploaded documents | Button **must NOT be visible** to ASM | ✅ Fixed | Role whitelist: `DD Lead, DD Head, NBH, Legal Admin, DD Admin, Super Admin` |
| C-02 | ASM sees "Reject" button on uploaded documents | Button **must NOT be visible** to ASM | ✅ Fixed | Same role whitelist |
| C-03 | DD Lead sees "Verify" button on uploaded documents | Button **must be visible** | ✅ | |
| C-04 | NBH sees "Verify" button | Button **must be visible** | ✅ | |
| C-05 | Dealer role sees "Verify" button | Button **must NOT be visible** | ✅ | |
### 5. Sequential Approval Visibility (LOI/LOA Edge Case)
- **ID:** TC-ONB-005
- **Description:** Verify that NBH does not receive approval notifications or see action buttons for LOI/LOA until DD Head has completed their review.
- **Pre-conditions:** Application is in `LOI_APPROVAL` stage.
- **Steps:**
1. Log in as **NBH** stakeholder.
2. Access the application in `LOI Approval` stage.
3. Verify that "Approve LOI" button is **NOT** visible.
4. Log in as **DD Head** and Approve the LOI.
5. Verify NBH receives a system notification/email **ONLY AFTER** DD Head's action.
6. Log in as **NBH** and verify "Approve LOI" button is now visible.
- **Expected Result:** Proper sequential handover; NBH is not disturbed by early notifications or blank action screens.
---
## 5. Relocation Module
### 5.1 Document Verification Permissions
| # | Test Case | Expected Behaviour | Status | Notes |
|---|---|---|---|---|
| RL-01 | ASM sees "Verify" button on relocation documents | Button **must NOT be visible** | ✅ Fixed | Same role whitelist applied in `RelocationRequestDetails.tsx` |
| RL-02 | ASM sees "Reject" button on relocation documents | Button **must NOT be visible** | ✅ Fixed | |
| RL-03 | DD Admin sees "Verify" button | Button **must be visible** | ✅ | |
---
## 6. Role-Based Access Control (RBAC) Cross-Module
| # | Test Case | Expected Behaviour | Status | Notes |
|---|---|---|---|---|
| RBAC-01 | ASM document verify access — Constitutional Change | ❌ Hidden ✅ Fixed | See C-01 |
| RBAC-02 | ASM document verify access — Relocation | ❌ Hidden ✅ Fixed | See RL-01 |
| RBAC-03 | ASM workflow approve buttons — Termination | ASM sees no Approve/Send Back | ✅ | SRS §8.3.4 |
| RBAC-04 | Dealer sees full termination workflow details | Dealer is **read-only** | ✅ | |
| RBAC-05 | National roles access F&F data | ✅ Permitted | ✅ | Permission added |
---
## 7. Pending / Open Test Cases
> Items that still require QA testing or implementation.
| # | Test Case | Module | Priority | Notes |
|---|---|---|---|---|
| P-01 | F&F Document Preview modal | F&F | Medium | Upload/Download done; Preview pending |
| P-02 | SLA breach notification triggers | All modules | High | SLA configuration not yet built |
| P-03 | WhatsApp notification on SCN issued | Termination | High | Awaiting API dependency |
| P-04 | In-app notification on F&F initiation | F&F | Medium | |
| P-05 | Audit log context sweep across all modules | All modules | Medium | Ensure all actions are logged with correct entity context |
| P-06 | Admin SLA Matrix configuration | Admin Dashboard | High | Pending implementation |
---
## 8. Regression Checklist (Run after every release)
- [ ] Termination: "Push to F&F" rejected before Legal stage (T-01)
- [ ] Termination: Progress timeline shows all green on completion (T-12)
- [ ] Termination: "Push to F&F" button hidden at early stages (T-06)
- [ ] Resignation: Dealer withdrawal blocked after NBH (R-04)
- [ ] Constitutional: ASM cannot verify documents (C-01, C-02)
- [ ] Relocation: ASM cannot verify documents (RL-01, RL-02)
- [ ] F&F: Document download forces save to disk (F-02)
- [ ] F&F: Status badges show white text (F-04)
---
## 9. In-App & Email Notification Coverage
> All notifications flow through `notifyStakeholdersOnTransition()` in `workflow-email-notifications.ts`.
### 9.1 Root Cause (Fixed)
Old code only notified `nextActor` and `dealer`. ASM was silently skipped after the initial submission email.
**Fix applied:** `workflow-email-notifications.ts` now covers 4 notification paths:
1. **Next Actor** → `Action Required` (system + email)
2. **ASM on Send Back** → `Case Returned for Clarification` (system + email)
3. **Dealer** → status update (system always; email only on terminal events)
4. **Key Observers** (DD Lead, DD Head, NBH, DD Admin) → `Case Closed` (system only, on reject/revoke/complete)
### 9.2 Notification Test Cases
| # | Scenario | Who Should Be Notified | Channel | Status |
|---|---|---|---|---|
| N-01 | Constitutional change submitted | All participants incl. ASM | email + in-app | ✅ (submit hook) |
| N-02 | ASM approves → moves to ZM/RBM | ZM + RBM | email + in-app | ✅ Fixed |
| N-03 | ZBH approves → moves to DD Lead | DD Lead | email + in-app | ✅ Fixed |
| N-04 | Any approver sends back | ASM | email + in-app | ✅ Fixed |
| N-05 | Request rejected | Dealer (email + in-app), DD Lead/Head/NBH/DD Admin (in-app only) | mixed | ✅ Fixed |
| N-06 | Request revoked | Dealer (email + in-app), key observers (in-app only) | mixed | ✅ Fixed |
| N-07 | Request completed (legal approved) | Dealer (email + in-app), key observers (in-app only) | mixed | ✅ Fixed |
| N-08 | Relocation submitted | Dealer (email), ASM (email + in-app) | email + in-app | ✅ Already existed |
| N-09 | Resignation submitted | All participants incl. ASM | email + in-app | ✅ Already existed |
| N-10 | ZM/RBM joint: first approver approves | Other co-approver (ZM or RBM) | in-app | ✅ Verified |
| N-11 | Termination pushed to F&F | DD Admin, Finance | in-app | ✅ Verified |
| N-12 | ASM who submitted gets status update on any stage change | ASM | in-app | ✅ Verified |
### 9.3 Known Remaining Gaps (Open)
| ID | Scenario | Channels | Status |
|----|----------|----------|--------|
| N-G1 | ZM/RBM co-approver notification for partner approvals | System, Email, WhatsApp | **Verified (v2.1)** |
| N-G2 | F&F initiation notification to DD Admin/Finance | System, Email, WhatsApp | **Verified (v2.1)** |
| N-G3 | Dealer withdrawal from resignation notification to ASM | System, Email, WhatsApp | **Verified (v2.1)** |
| N-G4 | Interview Scheduling acknowledgment to Dealer | Email, WhatsApp | **Verified (v2.1)** |
| N-G5 | Interview Panelist assignment notification | Email, WhatsApp | **Verified (v2.1)** |
> [!NOTE]
> All WhatsApp notifications now dynamically resolve phone numbers from the participant's user record or the application record as per SRS §1.1.1.
---
*This file is maintained as a living document. Add new test cases as bugs are found or features are added.*
Reference in New Issue View Git Blame Copy Permalink