GoSMS — Complete Test Case Tables

TC01 Complete Valid End-to-End Transaction CRITICAL

Category

Functional — Happy Path

State Transition

S0→S1→S2→S3→S4→S5→S6→S7→S9

Precondition

Finance Executive is authenticated. Brand with ≥3 Outlets across 2+ Companies exists in DB. QuickBooks API live and connected. SMTP service active. Database accessible with write permissions.

Test Steps

1Navigate to the SMS Top-Up module as Finance Executive
2Select a valid Brand from the dropdown
3Verify all outlets for that Brand are displayed with correct names
4Enter valid positive integer top-up amounts for each outlet (e.g., 100, 200, 150)
5Verify the running total is correctly calculated and displayed
6Click Submit / Next
7Observe loading state — confirm Submit button is disabled
8Confirm QuickBooks receives API call with correct payload amount
9Verify quotation created in QuickBooks with correct total and client
10Confirm confirmation email received at client email address
11Query DB: verify each Company's SMS credit balance increased by correct amount per mapping
12Verify transaction audit log entry created with correct Transaction ID, amounts, and status=SUCCESS

Expected Result

Quotation created in QuickBooks matching exact total. Confirmation email received with accurate details. Each Company's SMS balance increases by the sum of its mapped outlets' amounts only. Transaction log entry exists with unique Transaction ID. Success screen displays with Transaction ID and correct summary. Submit button re-enabled.

Failure Point Ref

None — positive path

Notes / Edge Cases

Verify credit amounts at DB level, not just UI. Cross-check QuickBooks invoice amount against sum of all top-up inputs. This is the baseline regression test.

TC02 Valid Transaction — Single Outlet, Single Company HIGH

Category

Functional — Boundary Happy Path

State Transition

S0→S1→S2→S3→S4→S5→S6→S7→S9

Precondition

Brand with exactly 1 Outlet belonging to exactly 1 Company. All services active.

Test Steps

1Select the Brand with a single outlet
2Confirm exactly 1 outlet is displayed — no more
3Enter valid top-up amount: 500
4Submit and observe full flow
5Query DB: confirm only the single company balance changed

Expected Result

Quotation created for 500. Email sent. Only that one Company's balance increases by 500. No other company's balance is modified in any way.

Failure Point Ref

FP09 — Mapping

Notes

Validates mapping logic for the minimal case. Tests that no cross-contamination occurs when only one company is involved.

TC03 Valid Transaction — Maximum Outlets Per Brand MEDIUM

Category

Functional — Volume / Boundary

State Transition

S0→S1→S2→S3→S4→S5→S6→S7→S9

Precondition

Brand configured with maximum supported number of outlets (e.g. 50). All services active.

Test Steps

1Select Brand with maximum outlets — observe page load time
2Enter valid top-up amounts for every outlet
3Submit and observe full flow including aggregation time
4Verify all outlet credits appear in DB for their respective companies

Expected Result

All outlets' credits applied to correct companies. No page timeout. No aggregation error. Total correctly calculated across all outlets. No outlet silently skipped.

Failure Point Ref

FP07 — Aggregation

Notes

Also monitors UI performance — all outlets must render within an acceptable time threshold. Log aggregation time for performance baseline.

TC04No Brand Selected — Submit AttemptHIGH

Category

Input Validation

State Transition

S0→S8

Precondition

Finance Executive on Top-Up module. Brand dropdown at empty/default state.

Test Steps

1Leave Brand dropdown at default (empty/placeholder)
2Click Submit/Next
3Open browser DevTools → Network tab — observe requests

Expected Result

Submission blocked immediately. Inline error displayed: "Please select a Brand." Zero network requests fired to QuickBooks. No outlet list loads. No DB write occurs. Submit button remains active for retry.

Failure Point Ref

FP01

Notes

Critical first gate. Verify using DevTools that zero API calls are made. Error message must be visible without scrolling.

TC05Empty Top-Up Field — One or More Fields Left BlankHIGH

Category

Input Validation

State Transition

S3→S8

Precondition

Brand selected. Outlets loaded. At least 3 outlets visible.

Test Steps

1Enter valid amounts in all fields except the last → Submit
2Reset → Enter valid amounts in all except the first → Submit
3Reset → Enter valid amounts in all except a middle field → Submit

Expected Result

In all 3 variants: submission blocked. Only the empty field is highlighted in red. All other valid fields retain their entered values (not reset). Error message field-specific. No API call made.

Failure Point Ref

FP03

Notes

UX defect: resetting all fields on partial validation error is a separate logged defect. Test each position independently.

TC06Negative Number InputHIGH

Category

Input Validation

State Transition

S3→S8

Precondition

Brand selected. Outlets loaded.

Test Steps

1Enter -500 in a top-up field → Submit
2Repeat with -0.01
3Repeat with -1
4Attempt to bypass client-side by sending negative value directly via API tool (Postman)

Expected Result

All negative values rejected. Client-side: field highlighted, error shown. Server-side: negative value rejected even if client-side bypassed. Error: "Top-up amount must be a positive number." No API call to QuickBooks made.

Failure Point Ref

FP04

Notes

Server-side validation must be tested independently. A system relying only on client-side validation is a security defect.

TC07Zero Value in All FieldsHIGH

Category

Input Validation

State Transition

S3→S8

Test Steps

1Enter 0 in all top-up fields → Submit
2Enter valid value in one field, 0 in all others → Submit
3Verify total gate activates

Expected Result

For all-zeros: Error "Total top-up must be greater than zero." No API call. For mix (one value + zeros): if total > 0 then submission should proceed for non-zero fields. Verify business rule on this edge case.

Failure Point Ref

FP06

Notes

Clarify business rule: should outlets with 0 top-up be excluded or should zero entries be disallowed entirely? Document assumption before testing.

TC08Text / Alphabetic Input in Top-Up FieldHIGH

Category

Input Validation

State Transition

S3→S8

Test Steps

1Enter "abc" → Submit
2Enter "12abc" → Submit
3Enter "abc12" → Submit
4Enter "1e5" (scientific notation) → Submit

Expected Result

All text values rejected. Either: (a) Input field rejects non-numeric in real time (preferred), or (b) Validation error on submit: "Amount must be a numeric value." No API call. Scientific notation should be rejected or handled explicitly.

Failure Point Ref

FP05

Notes

Test "1e5" specifically — some numeric parsers accept scientific notation which could cause unexpected large values to pass through.

TC09Special Character / Injection AttemptHIGH

Category

Input Validation — Security

State Transition

S3→S8

Test Steps

1Enter <script>alert(1)</script> → Submit
2Enter 1; DROP TABLE credits;-- → Submit
3Enter ' OR '1'='1 → Submit
4Enter &<>" → Submit

Expected Result

All injected values rejected by both client-side and server-side validation. No script executes in browser. No SQL executes in DB. No API call made. Inputs are sanitised. System logs the attempt without crashing.

Failure Point Ref

FP05

Notes

Critical security test. Must be verified at server level. All DB operations must use parameterised queries. XSS must be prevented in rendering.

TC10Decimal Precision Edge CasesMEDIUM

Category

Input Validation — Boundary

State Transition

S3→S4 or S3→S8

Test Steps

1Enter 100.999 in one field → Submit
2Enter 0.001 in another → Submit
3Enter 99.999999 → Submit
4Verify QuickBooks invoice amount matches system total

Expected Result

System either (a) rounds to 2dp and notifies user before confirming, or (b) rejects with "Maximum 2 decimal places allowed." No silent rounding. QuickBooks invoice total exactly matches system-computed total. DB credit reflects same precision.

Failure Point Ref

FP07

Notes

Float precision mismatch between system total and QuickBooks invoice is a financial discrepancy defect. Document expected precision handling before test.

TC11Overflow / Extremely Large NumberMEDIUM

Category

Input Validation — Boundary

State Transition

S3→S8

Test Steps

1Enter 9999999999 (ten digits) → Submit
2Enter MAX+1 (one above business-defined limit) → Submit
3Enter MAX (at limit exactly) → Submit (should succeed)
4Enter MAX-1 (just below limit) → Submit (should succeed)

Expected Result

Values exceeding maximum: error message with maximum permitted value. MAX-1 and MAX accepted. MAX+1 rejected. No integer overflow or silent truncation. Server rejects overflow even if client-side accepts.

Failure Point Ref

FP08

Notes

Identify business-defined maximum with the team before executing. Test equivalence partition: below max, at max, above max.

TC12Mixed Valid and Invalid FieldsHIGH

Category

Input Validation — Mixed State

State Transition

S3→S8

Test Steps

1Enter valid amounts for outlets 1, 2, 3
2Enter "N/A" in outlet 4
3Submit → observe error handling
4Correct only the invalid field → resubmit

Expected Result

Only outlet 4 field highlighted as invalid. Outlets 1–3 retain their entered values. Error is field-specific. After correcting field 4 and resubmitting, transaction proceeds. Valid field values are never reset by partial validation failure.

Failure Point Ref

FP05

Notes

Resetting all fields on partial error is a UX defect — log separately. This tests the validation engine's field isolation behaviour.

TC13QuickBooks API — Completely UnreachableCRITICAL

Category

Integration Failure

State Transition

S4→S5→S8

Precondition

Valid form data. QuickBooks API endpoint blocked/offline. Record all company credit balances before test.

Test Steps

1Block QuickBooks API via network config or environment setting
2Complete valid form and submit
3Observe retry attempts (should see 3 attempts with delays)
4After all retries fail, observe user message
5Query DB — verify all company credit balances unchanged
6Verify no QuickBooks record created

Expected Result

3 retry attempts made with exponential backoff. After all fail: user sees "Unable to connect to QuickBooks — reference: [Transaction ID]." SMS credits NOT applied. DB balances unchanged from before test. Admin alert triggered. Error logged with Transaction ID.

Failure Point Ref

FP10

Notes

Verify DB state by querying before and after. Verify retry log shows exactly 3 attempts. Verify admin notification mechanism fires.

TC14QuickBooks API — Request TimeoutCRITICAL

Category

Integration Failure

State Transition

S4→S5→S8

Test Steps

1Simulate API response delay beyond configured timeout (e.g. 30s+)
2Submit valid form
3Observe loading indicator during wait
4Observe timeout handling after threshold reached
5Verify UI remains responsive during timeout wait (no freeze)

Expected Result

Loading indicator visible. UI remains responsive. On timeout: error displayed, retry triggered. After max retries: flow aborted, no SMS credits applied. Transaction logged as "Timeout — Aborted." Submit re-enabled.

Failure Point Ref

FP11

Notes

Confirm timeout threshold is configurable (environment variable), not hardcoded. Record the actual timeout value in the test report.

TC15QuickBooks API — Returns 4xx / 5xx Error ResponseCRITICAL

Category

Integration Failure

State Transition

S4→S5→S8

Test Steps

1Trigger HTTP 400 response from QuickBooks → observe system
2Trigger HTTP 401 (auth failure) → observe system
3Trigger HTTP 422 (unprocessable) → observe system
4Trigger HTTP 500 (server error) → observe system
5Trigger HTTP 503 (service unavailable) → observe system

Expected Result

For each error code: system parses response, does NOT proceed to email or credit steps. User shown specific error message including error code. No QuickBooks record persisted. Full error response logged with Transaction ID. No unhandled exception reaches user.

Failure Point Ref

FP12

Notes

Each error code should be tested separately. Log the actual error handling behaviour for each — some may need different user messages (e.g. 401 = "Authentication error, contact admin").

TC16Duplicate Quotation Prevention — IdempotencyCRITICAL

Category

Integration — Idempotency

State Transition

S4→S5 (idempotent) → S9

Test Steps

1Submit a valid transaction → note Transaction ID and Quotation ID
2Immediately resubmit with the same Transaction ID
3Check QuickBooks — count quotation records for this transaction
4Check DB — verify credits not doubled

Expected Result

Second submission detected as duplicate via Transaction ID. Existing quotation reference returned — no new invoice created. QuickBooks shows exactly 1 quotation. SMS credits not doubled. System returns the original quotation ID to the user.

Failure Point Ref

FP13

Notes

Verify QuickBooks record count directly in QuickBooks portal/API. This is the key financial integrity idempotency test.

TC17QuickBooks API — Malformed / Unexpected ResponseHIGH

Category

Integration Failure

State Transition

S4→S5→S8

Test Steps

1Simulate API returning malformed JSON (missing required fields)
2Simulate API returning HTML instead of JSON
3Simulate API returning empty response body

Expected Result

System does not crash or throw unhandled exception. Parsing failure caught gracefully. Error message shown to user. Full malformed response body logged. No SMS credits applied. Transaction marked as failed with Transaction ID.

Failure Point Ref

FP14

Notes

Prevents raw server errors reaching the user. Verify the error log contains the raw response for debugging.

TC18SMTP Service Unavailable During Email SendMEDIUM

Category

Email Failure — Non-Blocking

State Transition

S5→S6(fail)→S7→S9

Test Steps

1Disable SMTP service in environment
2Complete valid transaction through to quotation creation
3Observe email send attempt outcome
4Observe credit step — confirm it proceeds
5Verify email retry queue entry exists

Expected Result

Email failure caught and logged. Transaction CONTINUES to credit step without being blocked. Finance Executive sees non-critical warning: "Email delivery failed — credit applied. Email will be retried." Retry queue entry created. SMS credit correctly applied. Transaction logged as SUCCESS with email_status=PENDING_RETRY.

Failure Point Ref

FP15

Notes

Confirm email failure does NOT rollback credit. Verify retry queue entry is accessible. This validates the non-blocking architecture of the email step.

TC19Missing or Invalid Client Email in QuickBooks RecordMEDIUM

Category

Email Failure — Data Quality

State Transition

S5→S6(null)→S7→S9

Test Steps

1Set QuickBooks client email to empty string → run transaction
2Set client email to null → run transaction
3Set client email to whitespace only → run transaction
4Set client email to "@" (invalid format) → run transaction

Expected Result

For all variants: system catches null/invalid email before attempting send. No SMTP exception thrown. Logged: "No valid client email on record — Transaction ID: [X]." Admin notified. Transaction continues to credit step. No system crash.

Failure Point Ref

FP16

Notes

A null pointer exception from an empty email field is a defect. Test each variant separately and log the exact behaviour.

TC20Email Content Accuracy VerificationMEDIUM

Category

Email Content Validation

State Transition

S6→S9

Test Steps

1Run TC01 with known exact amounts
2Open received email
3Verify: Brand name, total amount, client name, Transaction ID, date
4Run a second transaction — verify email does not carry values from first

Expected Result

Email contains correct Brand name, total matching QuickBooks quotation exactly, correct client name, correct Transaction ID, current date. No data from a previous transaction is present. No placeholder text (e.g. "[AMOUNT]") visible in email body.

Failure Point Ref

FP23

Notes

Content validation — not just delivery. Stale data in email template is a medium-severity defect.

TC21SMS Credit DB Write — Complete FailureCRITICAL

Category

Database Failure

State Transition

S6→S7→S8

Precondition

Record all company credit balances before test. Valid form. Quotation created. Email sent. DB write for credit intentionally fails (simulate via DB kill or write-block).

Test Steps

1Record credit balances for all relevant companies
2Complete all steps through email successfully
3Force DB write failure on credit step
4Observe system response and user message
5Query DB — compare balances to pre-test snapshot

Expected Result

ROLLBACK triggered. ALL company credit balances identical to pre-test values. No partial write remains. Error: "Credit could not be applied. Contact support. Ref: [Transaction ID]." Transaction log: status=FAILED_ROLLED_BACK. QuickBooks quotation flagged for manual review.

Failure Point Ref

FP17

Notes

Must be verified at DB level with before/after snapshots. QuickBooks quotation remains — this should be documented as an orphaned record requiring manual handling.

TC22Partial Credit Applied — Mid-Transaction FailureCRITICAL

Category

Database Failure — Atomicity

State Transition

S7→S8 (mid-write)

Precondition

Brand with outlets across 3 Companies. All balances recorded before test. DB write configured to fail after Company A writes but before Company B.

Test Steps

1Record balances for all 3 companies
2Submit valid transaction
3Force write failure after Company A credited but before Company B
4Query all 3 company balances

Expected Result

ROLLBACK reverses Company A's credit. All 3 companies show UNCHANGED balances identical to pre-test snapshot. System returns error — does not show success. Partial state completely eliminated. Transaction logged as ROLLED_BACK.

Failure Point Ref

FP18

Notes

THE most critical atomicity test. Must be verified directly at DB level. A partial write surviving = Critical defect requiring immediate block on release.

TC23Rollback Verification — DB State ConfirmationCRITICAL

Category

Database Integrity

State Transition

S7→S8 (rollback)

Test Steps

1Take DB snapshot of all relevant company credit balances
2Run transaction — force credit failure
3ROLLBACK triggered
4Query all company balances and compare to snapshot
5Query transaction log for rollback entry

Expected Result

All company balances are byte-for-byte identical to pre-test snapshot. No residual writes. Transaction log entry: status=ROLLED_BACK, Transaction ID present, timestamp accurate. Log entry confirms which company writes were reversed.

Failure Point Ref

FP19

Notes

This test must be run at DB level only — UI cannot confirm rollback. Use SQL SELECT before and after to compare.

TC24Transaction Audit Log — Completeness VerificationHIGH

Category

Database Integrity — Audit

State Transition

S9 (success log)

Test Steps

1Run TC01 (full successful transaction)
2Query transaction log table in DB
3Verify all required fields are present and correct
4Run TC21 (failed transaction) → verify failure log entry also created

Expected Result

Success log contains: unique Transaction ID, Brand ID, total amount, QuickBooks quotation ID, timestamp, Finance Executive user ID, status=SUCCESS, per-company credit amounts. Failure log contains: Transaction ID, status=FAILED or ROLLED_BACK, error detail, timestamp.

Failure Point Ref

FP22

Notes

Audit log is required for financial compliance and reconciliation. Missing any required field = Medium severity defect.

TC25Rollback Mechanism Failure — Admin EscalationCRITICAL

Category

Database Integrity — Edge Case

State Transition

S7→S8→(rollback fails)→Admin Alert

Test Steps

1Force credit write failure
2Simultaneously force rollback mechanism failure
3Observe system response
4Verify admin escalation triggered

Expected Result

System detects rollback failure. Admin escalation alert sent immediately (email/alert). Transaction flagged for manual review with full Transaction ID and context. System does NOT show success to user. DB inconsistency logged with maximum detail for manual reconciliation.

Failure Point Ref

FP17, FP19

Notes

Extreme edge case but requires a fallback to exist. If no admin alert mechanism exists, this is a gap — log as a defect/recommendation.

TC26Double-Click Rapid Submit — UI Duplicate PreventionHIGH

Category

Concurrency — UI

State Transition

S3→S4 (single path only)

Test Steps

1Open browser DevTools Network tab
2Complete valid form
3Double-click Submit within 500ms
4Count API requests in Network tab
5Count QuickBooks quotations created
6Count DB credit entries written

Expected Result

Submit button disabled after first click. Exactly ONE API request sent to QuickBooks. Exactly ONE quotation created. Exactly ONE set of credits applied to companies. Button re-enabled only after full transaction result received.

Failure Point Ref

FP21

Notes

Verify via DevTools — count POST requests. Any count > 1 = High severity defect. Common and frequently overlooked in financial systems.

TC27Two Finance Executives Submit Simultaneously — Same BrandHIGH

Category

Concurrency — Multi-User

State Transition

S4→S9 (User A) | S4→S9 (User B) independently

Test Steps

1Open two authenticated Finance Executive sessions simultaneously
2Select same Brand in both sessions
3Enter different amounts in each session
4Submit both sessions within 2 seconds of each other
5Query DB: each company's balance should increase by the sum of BOTH submissions

Expected Result

Both transactions completed independently and correctly. No data collision. Each company's final balance = starting balance + User A amount + User B amount. Two distinct Transaction IDs. Two separate QuickBooks quotations. Both audit log entries created. No credit from one transaction applied to wrong company.

Failure Point Ref

FP20

Notes

Race condition detection: if both updates arrive simultaneously, row-level locking must prevent a lost update. Total DB balance must equal exact sum of both inputs.

TC28Resubmission After Error — No Duplicate ProcessingHIGH

Category

Concurrency — Retry Safety

State Transition

S4→S8 (first) → S4→S5→S9 (second)

Test Steps

1Force API failure on first submission → error shown → note Transaction ID 1
2Restore API → user clicks Submit again → note Transaction ID 2
3Verify Transaction IDs are different
4Verify only one QuickBooks quotation created
5Verify credits applied only once

Expected Result

Transaction IDs 1 and 2 are different. First transaction in log: status=FAILED. Second transaction: status=SUCCESS. Exactly one QuickBooks quotation. Credits applied once. No double-credit scenario.

Failure Point Ref

FP13, FP21

Notes

Tests the clean retry path. A new Transaction ID must be generated on each form submission attempt.

TC29Credits Split Correctly Across Multiple CompaniesCRITICAL

Category

Business Logic — Allocation

State Transition

S4→S5→S6→S7→S9

Precondition

Brand with 4 outlets: Outlet A + B → Company 1 | Outlet C → Company 2 | Outlet D → Company 3. Record all starting balances.

Test Steps

1Enter: Outlet A=100, Outlet B=200, Outlet C=300, Outlet D=400
2Submit → complete full flow
3Query Company 1 balance: expected +300
4Query Company 2 balance: expected +300
5Query Company 3 balance: expected +400
6Verify no other company was affected

Expected Result

Company 1: +300 (A+B). Company 2: +300 (C). Company 3: +400 (D). QuickBooks quotation total: 1000. No other company balance changed. Zero cross-contamination between companies.

Failure Point Ref

FP09

Notes

THE most critical business logic test. Must be verified at DB level — UI display alone is insufficient. Any mismatch = Critical defect. Release blocker.

TC30Outlet-to-Company Mapping Consistency CheckCRITICAL

Category

Business Logic — Data Integrity

State Transition

S1→S2→S7→S9

Precondition

Known mapping in DB. Known brand loaded in UI. DB query access available.

Test Steps

1Query DB: retrieve outlet-to-company mapping for test Brand
2Load same Brand in UI — compare outlet list to DB result
3Submit transaction with known amounts per outlet
4Query DB: verify each company credited matches exactly its DB-mapped outlets
5Verify no outlet present in DB is absent from UI (and vice versa)

Expected Result

UI outlet list matches DB mapping exactly — count and names identical. After submission: each company credited in DB corresponds exactly to its DB-mapped outlets. No credit directed to unmapped or incorrectly mapped company. Mapping used at transaction time matches DB snapshot taken at S4.

Failure Point Ref

FP09

Notes

Run after any data migration, Brand restructure, or outlet reassignment. Mapping drift is a silent financial risk. This is a regression test that should run on every release cycle.

📊 TEST CASE SUMMARY — ALL 30 TEST CASES

TC ID	Test Case Title	Priority	Category	State Covered	FP Ref
TC01	Complete Valid End-to-End Transaction	CRITICAL	Happy Path	S0→S9	—
TC02	Valid — Single Outlet / Single Company	HIGH	Happy Path	S0→S9	FP09
TC03	Valid — Maximum Outlets Per Brand	MEDIUM	Volume	S0→S9	FP07
TC04	No Brand Selected — Submit Attempt	HIGH	Input Validation	S0→S8	FP01
TC05	Empty Top-Up Field	HIGH	Input Validation	S3→S8	FP03
TC06	Negative Number Input	HIGH	Input Validation	S3→S8	FP04
TC07	Zero Value All Fields	HIGH	Input Validation	S3→S8	FP06
TC08	Text / Alphabetic Input	HIGH	Input Validation	S3→S8	FP05
TC09	Injection Attack Attempt	HIGH	Security	S3→S8	FP05
TC10	Decimal Precision Edge Cases	MEDIUM	Input Validation	S3→S4/S8	FP07
TC11	Overflow / Extremely Large Number	MEDIUM	Input Validation	S3→S8	FP08
TC12	Mixed Valid & Invalid Fields	HIGH	Input Validation	S3→S8	FP05
TC13	API Unreachable — Retry + Abort	CRITICAL	Integration	S5→S8	FP10
TC14	API Request Timeout	CRITICAL	Integration	S5→S8	FP11
TC15	API 4xx / 5xx Error Response	CRITICAL	Integration	S5→S8	FP12
TC16	Duplicate Quotation Prevention	CRITICAL	Integration	S5 idempotent	FP13
TC17	Malformed API Response	HIGH	Integration	S5→S8	FP14
TC18	SMTP Service Unavailable	MEDIUM	Email	S6→S8(email)→S9	FP15
TC19	Missing / Invalid Client Email	MEDIUM	Email	S6→S8(email)→S9	FP16
TC20	Email Content Accuracy	MEDIUM	Email	S6→S9	FP23
TC21	SMS Credit DB Write — Full Failure	CRITICAL	Database	S7→S8	FP17
TC22	Partial Credit Mid-Transaction	CRITICAL	Database	S7→S8	FP18
TC23	Rollback DB State Verification	CRITICAL	Database	S7→S8	FP19
TC24	Audit Log Completeness	HIGH	Database	S9	FP22
TC25	Rollback Mechanism Failure	CRITICAL	Database	S8→Admin	FP17, FP19
TC26	Double-Click Submit Prevention	HIGH	Concurrency	S4→S9 (×1)	FP21
TC27	Simultaneous Multi-User Submission	HIGH	Concurrency	S4→S9 (×2)	FP20
TC28	Resubmission After Error	HIGH	Concurrency	S8→S9	FP13, FP21
TC29	Credits Split Across Companies	CRITICAL	Allocation	S4→S9	FP09
TC30	Mapping Consistency Check	CRITICAL	Allocation	S2→S9	FP09
TOTAL: 30 Test Cases		10 CRITICAL \| 15 HIGH \| 5 MEDIUM \| All 10 States Covered

GoSMS SMS Top-Up — Complete Test Case Tables