🎯 Quality Assurance Assessment — Deliverable 01 of 05
GoSMS SMS Top-Up Feature
QA Test Plan & Assessment
MikeTango / QuickBooks Integration · Complete Test Strategy, Architecture Analysis & Failure Point Catalogue
Candidate
Sourav
Company
Mulah Technologies, MY
Role
QA Engineering Intern
Date
26 February 2026
Product
GoSMS
Company Under Test
MikeTango
Integration
QuickBooks Accounting
Version
v1.0 — Final
Section 1
Feature Overview & Description
Understanding what the feature does, who uses it, and why it matters
📋 1.1 Feature Description

The GoSMS SMS Top-Up feature is a multi-step, financially transactional workflow that enables a Finance Executive to allocate and credit SMS tokens to multiple business outlets under a selected Brand, within the GoSMS platform operated by MikeTango.

This is not a simple form submission. It is a financially consequential process that spans five architectural layers, integrates with an external accounting system (QuickBooks), and must maintain complete data integrity across a multi-entity, multi-company credit allocation model.

The feature directly impacts the financial standing of companies within the GoSMS ecosystem. Any failure — whether silent, partial, or unhandled — can result in financial discrepancy, duplicate invoicing, or incorrect credit allocation.

🔄 1.2 Core Workflow — 9 Sequential Steps
1
Finance Executive Authentication
Role-based access control validates the user is a Finance Executive with sufficient permissions to execute SMS top-ups. Unauthorised users are redirected to login.
Risk: Unauthorised access, session hijacking
2
Brand Selection
Finance Executive selects a Brand from a dropdown populated from the GoSMS database. The brand selection determines which outlets and companies are involved in the transaction.
Risk: Empty selection, stale dropdown data, DB fetch failure
3
Outlet Loading
System dynamically fetches all outlets belonging to the selected Brand. Each outlet is mapped internally to a Company — this mapping is the critical business logic that drives credit allocation.
Risk: Mapping drift, incomplete outlet list, DB failure
4
Top-Up Amount Entry
Finance Executive enters a top-up amount per outlet. The system aggregates totals by Company (not by outlet) for the QuickBooks quotation and DB credit operations.
Risk: Invalid input, negative values, overflow, injection attempts
5
Input Validation & Transaction ID Generation
Server-side and client-side validation of all fields. A unique Transaction ID (idempotency key) is generated and assigned before any external API calls are made. Submit button disabled immediately to prevent duplicate submission.
Risk: Client-side bypass, duplicate submission without ID
6
QuickBooks API Call — Quotation Generation
The system calls the QuickBooks API with the Transaction ID, Brand details, and per-company line items. A formal quotation is generated. This step must succeed before SMS credits are applied. Retry logic: 3 attempts with exponential backoff (2s, 5s, 10s).
Risk: API timeout, unreachable, 4xx/5xx errors, duplicate invoice, malformed response
7
Client Confirmation Email
System fetches the client email from QuickBooks records and sends a confirmation email with quotation details. Email failure is non-blocking — the transaction continues to the credit step regardless of email outcome. Failures are queued for retry.
Risk: SMTP failure, null/invalid email, stale email template content
8
SMS Credit — Atomic DB Write
An atomic database transaction credits SMS tokens to each Company based on its mapped outlets' total. Row-level locking prevents race conditions. If any write fails, the entire transaction is rolled back to the pre-transaction state.
Risk: Partial write, rollback failure, race condition, concurrent access
9
Transaction Logging & Success Confirmation
A complete audit log entry is created with Transaction ID, user ID, Brand, amounts per company, QuickBooks quotation reference, timestamp, and status. Finance Executive receives a success screen showing the Transaction ID and summary.
Risk: Missing audit fields, incorrect log status
Section 2
Key Actors & Responsibilities
All entities involved in the transaction and their roles
ActorRoleResponsibilitiesFailure Impact
Finance ExecutiveTransaction InitiatorSelects brand, enters top-up amounts, triggers submissionInitiating duplicate or invalid submission
GoSMS SystemOrchestratorValidation, mapping, API coordination, DB writes, loggingSilent failures, partial writes, unhandled exceptions
QuickBooks APIQuotation GeneratorCreates formal financial quotation, returns quotation IDAPI unavailability blocks entire credit flow
Email Service (SMTP)Notification LayerDelivers confirmation email to client with quotation detailsFailure is non-blocking — logged and retried
DatabaseCredit Store & Audit TrailAtomic credit writes per company, transaction log, rollbackPartial write = financial inconsistency — Critical defect
GoSMS AdminEscalation ReceiverReceives alerts for critical failures (rollback failures, API outages)Unalerted admin = undetected financial inconsistency
Section 3
Assumptions (A01–A10)
Documented assumptions that underpin the test strategy — must be validated with the development team before final execution
A01
Each Brand may contain multiple Outlets, and those Outlets may belong to different Companies. Credits are allocated at the Company level, not the Outlet level.
A02
The Outlet-to-Company mapping is maintained in the GoSMS database. This mapping is the source of truth for all credit allocation logic.
A03
QuickBooks quotation generation is a mandatory prerequisite to SMS credit allocation. Credits must not be applied if the quotation step fails.
A04
The system implements atomic database transactions — all company credit writes must succeed or all must be rolled back. Partial writes are a critical defect.
A05
Access to the SMS Top-Up feature is role-restricted to Finance Executives only. Other roles must be denied access.
A06
Client email address is sourced from the QuickBooks company record, not from the GoSMS database directly.
A07
Email delivery failure is non-blocking. The transaction proceeds to the credit step regardless of email outcome.
A08
A unique Transaction ID (idempotency key) must be generated per submission attempt, enabling duplicate detection at the QuickBooks API layer.
A09
The system supports concurrent access from multiple Finance Executive accounts and implements appropriate locking to prevent race conditions.
A10
Every transaction — success or failure — produces a complete audit log entry with Transaction ID, user, amounts, timestamp, and status for financial compliance.
Section 4
Test Strategy & Approach
How the 30 test cases are organised, prioritised, and executed
CategoryTC RangeCountPriority DistributionTest Focus
Functional — Happy PathTC01–TC0331 Critical1 High1 MediumFull E2E success, single outlet, max outlets volume
Input ValidationTC04–TC1297 High2 MediumEmpty fields, negative, zero, text, injection, decimal, overflow, mixed
Integration FailuresTC13–TC1754 Critical1 HighAPI unreachable, timeout, error codes, idempotency, malformed response
Email ServiceTC18–TC2033 MediumSMTP failure, invalid email, content accuracy
Database & TransactionsTC21–TC2554 Critical1 HighWrite failure, partial atomicity, rollback, audit log, admin escalation
Concurrency & DuplicatesTC26–TC2833 HighDouble-click, simultaneous users, resubmission after error
Multi-Company AllocationTC29–TC3022 CriticalCredit split accuracy, outlet-to-company mapping consistency
TOTALTC01–TC303010 Critical15 High5 MediumFull feature coverage across all 10 system states
Section 5
Failure Point Catalogue (FP01–FP24)
Every identified failure mode mapped to its architectural layer and severity
FP01
No Brand Selected
Layer 1 — UI | High
FP02
DB Failure on Brand Load
Layer 1 — UI | High
FP03
Empty Top-Up Field
Layer 1 — UI | High
FP04
Negative Amount Input
Layer 1 — UI | High
FP05
Text / Injection Input
Layer 1 — UI/Security | High
FP06
Zero Total Amount
Layer 2 — Business Logic | Medium
FP07
Decimal Precision Mismatch
Layer 2 — Business Logic | Medium
FP08
Integer Overflow / Large Number
Layer 2 — Business Logic | Medium
FP09
Incorrect Company Mapping
Layer 2 — Business Logic | CRITICAL
FP10
QuickBooks API Unreachable
Layer 3 — Integration | CRITICAL
FP11
API Request Timeout
Layer 3 — Integration | CRITICAL
FP12
API 4xx / 5xx Error Response
Layer 3 — Integration | CRITICAL
FP13
Duplicate Invoice Creation
Layer 3 — Integration | CRITICAL
FP14
Malformed API Response
Layer 3 — Integration | High
FP15
SMTP Service Unavailable
Layer 4 — Email | Medium
FP16
Null / Invalid Client Email
Layer 4 — Email | Medium
FP17
SMS Credit DB Write Failure
Layer 5 — Database | CRITICAL
FP18
Partial Write — Mid-Transaction
Layer 5 — Database | CRITICAL
FP19
Rollback Mechanism Failure
Layer 5 — Database | CRITICAL
FP20
Concurrent Write Collision
Layer 5 — Database | High
FP21
Double-Click Duplicate Submit
Layer 1 — UI | High
FP22
Incomplete Audit Log Entry
Layer 5 — Database | High
FP23
Stale Data in Email Template
Layer 4 — Email | Medium
FP24
Unauthorised Access Attempt
Layer 1 — Auth | High
Section 6
Test Environment & Tools
🔧 Environment Configuration

Test Environment: Staging environment mirroring production configuration — GoSMS application, QuickBooks Sandbox API, SMTP test server, and a dedicated test database instance.

Test Data: Brands with 1, 3, and 50 outlets across 1, 2, and 3 Companies respectively. Known Outlet-to-Company mapping in DB. Pre-recorded credit balances as baseline snapshots for DB comparison.

API Simulation: Network proxy (e.g., Charles Proxy / mocking layer) to simulate API timeouts, unreachable endpoints, and custom HTTP error responses (400, 401, 422, 500, 503).

Tools Used: Browser DevTools (Network tab for request count verification), Postman (server-side validation bypass testing), DB query access (direct SQL for balance snapshots), SMTP test server (Mailtrap or equivalent), and PM2 / Wrangler for service management.

Concurrency Testing: Two authenticated browser sessions opened simultaneously in separate browser instances for multi-user concurrent submission tests.