Case Study · Fintech

Prop Firm CRM Testing: 240+ Playwright Tests in 14 Parallel Jobs

Q: How do you make a Playwright suite run faster in CI?

Split it. Here each run logs in once, creates one shared Qase run and then runs the CRM tests as 14 parallel jobs, one per test folder. All 241 tests finish in 10 to 12 minutes.

Q: Can AI help with failing tests?

Yes, as a first pass. In this pipeline, a final job uses AI to analyze failures, posts them to Slack and proposes locator fixes, so the team starts from a diagnosis instead of a raw log.

Q: How do you chain API requests in Postman?

With scripts. Pre-request scripts generate unique values, and post-response scripts save the IDs an API returns as collection variables, so the next request can use them.

Playwright and TypeScript tests for a prop trading firm's CRM, run in 14 parallel GitHub Actions jobs, with failures analyzed by AI and posted to Slack.

Book a Free QA Strategy Call All Case Studies

engagement / prop-firm-crmOngoing

Client: Proprietary trading firm, unnamed
Scope: The firm's CRM and a second dashboard product, plus their backend APIs
Team: 2 SprintSynergy QA engineers, alongside 10 frontend and backend developers
Engagement: 2.5+ years, ongoing
Test Management: Qase
Pipelines: GitHub Actions: on push to main, daily, on demand and after each frontend deployment
Stack: PlaywrightTypeScriptGitHub ActionsQasePostmanSwaggerJiraSlack

Failures Analyzed by AI and Posted to Slack

530+Manual Test Cases

240+Automated Tests in Playwright

14Parallel CI Jobs per Run

2Products Covered

The Result

What the Firm Has Now

Releases with no blocker or critical bugs. None has reached production: a critical bug found in testing is fixed before the build is delivered. Some releases ship with no known bugs; when minor bugs get through, it is typically 2 to 4 in a release, each logged and tracked. Tests run on every push to main, every morning and after each frontend deployment, so a broken change is caught before it reaches the firm's team.
Failures arrive already analyzed. The AI step posts its findings and proposed locator fixes to Slack, so the team starts from a diagnosis instead of a raw log.
The suite runs as 14 parallel jobs, not one long queue, so 240+ tests finish in 10 to 12 minutes.
A partnership of 2.5+ years, still running.

Overview

A CRM Tested on Every Deployment

For more than two and a half years, SprintSynergy has handled QA for a proprietary trading firm. The work covers the firm's CRM, where its team manages accounts, users, coupons and templates, and a second, smaller dashboard product. Every test case lives in Qase: 530+ manual and 240+ automated. The automated suite is written in Playwright with TypeScript and runs in GitHub Actions on every push to main, every morning, on demand and after each frontend deployment. Each run splits the CRM tests into 14 parallel jobs, and a final job uses AI to analyze any failures, posts them to Slack and proposes locator fixes. The backend APIs are tested in Postman.

GitHub Actions · Playwright Tests

1 · Triggers

Push to MainDaily ScheduleManual RunFrontend Deployed

2 · Setup

Shared Qase RunOne Login

3 · Tests in Parallel

CRM 1CRM 2CRM 3CRM 4CRM 5CRM 6CRM 7CRM 8CRM 9CRM 10CRM 11CRM 12CRM 13CRM 14

Second Product

4 · Final Job, Runs Even When Tests Fail

Merge ReportsAI Failure AnalysisPost to SlackPropose Locator Fixes

The Pipeline, Simplified

The Problem

Records Staff Act On All Day

A prop firm's CRM holds the records behind its users: personal details, tax numbers and the coupons and templates the firm runs. Staff filter and edit these records all day. A form that saves bad data, or a filter that quietly resets, means people act on the wrong information.

The tests also have to keep up with the product. They need to run as soon as new frontend code is live, finish fast enough to be useful and point straight at what broke.

What We Tested

Two Products and Their APIs

The CRM: accounts and users, personal information, coupons and templates, through 500+ manual and 200+ automated test cases.
The Second Dashboard Product: 22 manual test cases, all of them automated.
Backend APIs: the endpoints behind each page, in Postman, against the CRM's QA environment and the second product's environment.

How We Built It

Parallel Runs and AI Triage

Qase as the One Home for Test CasesAll 530+ manual and 240+ automated cases live there, and automated runs report their results back to it.
A Playwright framework in TypeScript on the page object modelEach page is a class that holds its locators and actions. Spec files only describe the test steps.
A GitHub Actions Workflow with Four TriggersA push to main, a daily scheduled run, a manual run and a frontend deployment event, so the tests start as soon as new frontend code is live.
Parallel RunsEach run creates one shared Qase run and logs in once. The CRM tests then run as 14 parallel jobs, one per test folder, beside a separate job for the second product. All 241 automated tests finish in 10 to 12 minutes.
AI failure analysisA final job runs even when tests fail. It merges the reports, uses AI to analyze the failures, posts them to Slack and proposes locator fixes. The Playwright report and traces are kept as GitHub artifacts.
API Tests in PostmanOne collection, with one folder per page and one request per endpoint, and request formats taken from Swagger. Pre-request scripts generate unique values, and post-response scripts save the IDs an API returns for the next request.
One Bug TemplateEvery bug goes into Jira with an [FE] or [BE] prefix and the same fields: summary, description, steps to reproduce, actual and expected result, environment and a screenshot or video.

What We Found

Three Recent Bugs

CRM · Personal Information[FE]

Invalid Phone Numbers and Tax Numbers Saved

The Personal Information form accepted a phone number too short for the country's dial code, and a tax number (TIN) made of special characters or random text. Both were saved and shown again when the user was reopened. The firm's records would hold contact and tax details that could not be right.

CRM · Accounts and Users

Filters Lost After a Mode Switch

On Accounts and Users, turning Prime mode on and off again cleared the filters. The table showed unfiltered data while staff expected a filtered list.

CRM · Accounts, Coupons, Templates

Slow Edit Windows

On Accounts, Coupons and Templates, the edit window showed its data only after a delay.

In Place Now

Running Today

530+ manual and 240+ automated test cases in Qase, across the CRM and a second dashboard product.
A Playwright and TypeScript framework on the page object model.
A GitHub Actions workflow that runs on push, daily, on demand and after each frontend deployment, with 14 parallel CRM jobs and a job for the second product.
AI failure analysis, with Slack alerts and proposed locator fixes.
A Postman collection for the backend APIs, built from Swagger, with chained requests.
One Jira bug template, with [FE] and [BE] prefixes.

Questions

Frequently Asked Questions

How do you test a prop firm CRM?

We test the CRM the firm's team works in, by hand and with automation. Here that means 530+ manual and 240+ automated test cases in Qase, Playwright tests in GitHub Actions and Postman tests for the backend APIs.

How do you make a Playwright suite run faster in CI?

Can AI help with failing tests?

How do you chain API requests in Postman?

More Case Studies

All Case Studies

E-Commerce

Want Failing Tests Explained Before You Open the Log?

Book a free 30-minute QA strategy call. A written QA plan follows within 48 hours.

Book a Free QA Strategy Call