W/ William Lu
All cases

Case study

BTSE CEX Product Quality Case Study

Read source on GitHub ↗
On this page

The product-quality problem

A centralized crypto exchange moves value through connected Wallet, trading, commission, and conversion flows. A defect can start in one screen and affect a balance, order, fee, or payout somewhere else. I tested those connections at BTSE across Wallet, Referral and Affiliate, Spot, Futures, Convert, fees, funding, liquidation, and KYC.

During my three months at BTSE, I found three significant logic issues in trading, referral commission, and conversion flows that could affect amount calculations, and escalated them to the relevant teams for priority handling. The original reports stayed in BTSE's internal systems. I did not retain proprietary copies after leaving the company.

How I tested the flows

I started with product behavior, then checked the data path behind it.

  • I mapped the user flow and tested normal values before moving to boundary and negative cases.
  • I compared behavior across assets, browsers, entry points, and connected product flows.
  • I used Browser DevTools for E2E Web API and WebSocket inspection.
  • I used TestRail for Wallet, Referral and Affiliate, and Convert cases.
  • I used SQL through TablePlus to validate Wallet balances, collateral details, fund transfers, order and trade history, fees, and settlement data.
  • I built spreadsheet calculations to compare expected and observed results. For fees, funding, and liquidation, I used BTSE's published formulas. For commissions, I confirmed the expected allocation with my QA mentor.

These checks used browser network records and API data. I did not directly inspect server logs at BTSE.

Three risk findings

Product flow Failure signal Validation approach Product-quality risk Recorded outcome
Futures and Spot Boundary inputs produced inconsistent pricing or left the UI without a usable result Reproduced with normal controls, multiple assets, three browsers, and API-response inspection A shared boundary-handling weakness could affect more than one trading surface QA and Engineering accepted the issue; it remained open while the team focused on release work
Referral and Affiliate Commission values exceeded the expected allocation under a deeper, active account hierarchy Built a multi-account model, generated trades, collected admin results, and compared them with spreadsheet calculations A low-frequency path could become material as affiliate activity grew Management kept it behind release work; the issue remained open and the final TestRail review did not finish before my employment ended
Convert Boundary inputs left the UI without a usable result across different entry points and asset pairs Restarted the browser, tested three browsers, changed source and target assets, and inspected the Convert API response A Convert failure could affect other product flows that depended on the same service Engineering accepted the issue; it remained open, with no outage or fix evidence

Product-quality decisions

I assessed each finding by product risk and affected scope.

  1. I checked scope before severity. A reproducible result across products, assets, or entry points carried more weight than one failed screen.
  2. I used expected-versus-observed comparisons for financial logic. The comparison made commission, fee, funding, and liquidation errors reviewable.
  3. I separated evidence from impact. I could show the defect and the affected flow. I had no evidence for an outage, a completed fix, or a prevented loss, so I did not claim them.
  4. I documented the test model. The internal Wiki and TestRail records gave the team reproduction steps, coverage, and a starting point for future testing.

Reusable test controls

The following controls describe the test approach I would carry into another CEX. They do not describe confirmed BTSE remediation.

  • Define accepted boundaries for each input and provide consistent, actionable error responses across the UI and API.
  • Test values on both sides of each boundary, then repeat them across assets and connected flows.
  • Reconcile total commission allocation across hierarchy levels and activity patterns.
  • Compare order, position, currency, fee, and settlement state before and after each transaction.
  • Cover order states from pending or open through filled, canceled, rejected, and triggered outcomes.
  • Keep KYC state testing separate from AML screening and compliance ownership.

Evidence limits

  • The three findings are based on my direct work and recollection. Original employer records are no longer accessible.
  • The case study does not disclose exact thresholds, internal account topology, transaction values, customer data, identifiers, or response content.
  • It does not claim a fix, production outage, avoided loss, or validated financial impact.
  • BTSE work did not include Postman, Swagger, direct server-log analysis, AML screening, smart-contract testing, or chain-node operation.
  • Current public BTSE formulas cannot prove which formula version was in use during Sep–Nov 2024.

Period: Sep 2024–Nov 2024
Role: Senior QA Engineer, Nogle／BTSE
Public navigation: Portfolio | Public QA resume

Source: Based on my direct work and recollection. Original employer records are no longer available for independent verification. Confidential details are omitted.