.png){kind=small}
ROLE/SERVICES
Product Design Lead · UX Engineering · Platform Analysis
LOCATION
USA 🇺🇸
YEAR
2025–2026
Summary
BanQu is a ten-year-old platform serving supply chains across 17+ user roles, so some of its complexity is intentional and some has simply built up over time. Testing hadn't really kept pace. Coverage was mostly unit tests plus a manual UAT that followed one scripted path per flow, even when there were several ways to complete the same task. That made it hard to see product risk before release. The product owner and I started with a simple question: could end-to-end testing also work as a product audit? Could it help us map which flows mattered, which ones broke, and where complexity was intentional versus accumulated? I architected the framework, and engineering and QA adopted it. It also led to something unexpected: an automated documentation pipeline, with 40+ trilingual client guides published to Zendesk.
SaaS Blockchain platform
The Challenge
Solution & Impact
Product Design Lead UX Engineering Playwright E2E Architecture UAT Strategy & Audit Risk Analysis & Roadmap Self-Initiated
Scope
BanQu is a multi-sided SaaS platform connecting supply chains, smallholder farmers, and financial institutions. It supports 17+ user roles with different permissions, forms with 50–100+ fields and conditional logic, blockchain transactions that can take 2.5 minutes, and an offline-first mobile experience for low-connectivity regions. It is a huge product surface, and before this work, very little of it had systematic proof that it worked the way we intended.
Manual UAT answered one basic question: does the scripted path still complete? It couldn't answer the questions we actually cared about. Does each of the 17 roles get the experience we designed? Do the other ways of completing a transaction work, or only the one we always test? Which paths are intentional, and which are complexity that accumulated over time? That distinction mattered because it helped us decide what deserved coverage in the first place. Standard QA checks whether something works. This framework also checked whether what was built matched what the product was supposed to do. I initiated the work, but it was never a solo project. The product owner and I scoped it together and used the framework as a UX audit. The engineering lead shaped the test strategy, with one rule that became the backbone of the system: “We already unit-test in code. Verify a component once end-to-end, then drive everything else through the API.” The dev team was trained on the framework and now extends it, and QA has started using it for day-to-day validation. For the documentation pipeline, I also pitched moving away from PowerPoints to the VP overseeing client-facing operations and enablement.
The framework was built around three types of testing. Role-based verification: critical flows run as real user types, so we verify that permissions actually work in context. Workflow testing: multi-step flows such as Farmer creates → Reviewer checks → Approver gates are verified end-to-end, with API-driven setup where it makes the tests faster and more stable. Condition-based testing: blockchain delays, session expiry, and offline-to-sync cycles are tested too, because those are conditions users actually experience.
The form engine (technical detail)
Forms can reach 50–100+ fields with conditional visibility, computed scores, and role-gated inputs. Hardcoding field names makes tests fragile: they either break every time a schema changes, or worse, keep passing while testing the wrong thing. completeFormFromSchema fetches the live schema and fills the form in multiple passes, handling conditionals, computed fields, and relationship pickers. A new form test is about 10 lines, and field renames don't break it. A typed API client covers the REST surface as well, so multi-step workflows can run end-to-end without forcing every step through the UI.
Tech Stack (technical detail)
Playwright (TypeScript) · role-based storageState for 17+ roles · global setup + auth wrappers · typed API client · multi-pass form engine. Adding a new role takes one line, and a new test is roughly ten. That was important because the framework needed to be easy for the team to extend without depending on me.
What I deliberately didn't build
Coverage is a budget. BanQu has surveys with up to 700 fields across ten survey types, so I chose not to automate every single one. Instead, I built one representative mini-survey that exercises every field type and behavior. The goal was to test the functionality once, not every instance of it. I used the same principle at the component level. If ten flows touch the same search bar, one flow verifies it and the other nine use the API. Repeating unit-level checks in end-to-end tests only makes the suite slower and harder to maintain.
While building the framework, I noticed we already had something useful: Playwright captures screenshots at each step, and the tests covered flows that many clients share. At the same time, client documentation still lived in manually maintained PowerPoints that varied by client, sat in different SharePoints, and went out of date as soon as the product changed. So the test suite became a documentation engine too. Generic guides such as login, password reset, and contact support are generated from the same runs that verify those flows. I also built a pipeline to migrate client-specific guides from the old decks into Zendesk. More than 40 guides are now live in English, French, and Spanish, with internal use underway and client rollout beginning. One concern was becoming too dependent on Zendesk, so I designed around that. Every guide also exists as Markdown, HTML, and PDF in the GitHub repo. Zendesk is the publishing target, not the source of truth. Generated guides stay tied to the tested product flow, which reduces drift, while migrated guides now live in one maintained repository instead of scattered PowerPoints.
How the pipeline works (technical detail)
Each meaningful test action is wrapped in articleStep(), which captures a screenshot and records step metadata; generateArticle() emits the article and a structured steps.json. For migrated guides, the pipeline parses each PowerPoint's XML for its images, composites the deck's own highlight callouts onto each screenshot so visual annotations survive conversion, validates structure and step text word-for-word against the source, then publishes as a draft — uploading images as hosted attachments and reinjecting them positionally, per locale, with trilingual-ready guides prioritized.
The audit surfaced eight structural risks. Five were infrastructure issues that shaped the first two roadmap phases, and three were product-level promises we still couldn't prove were being met.
The team adopted the framework because it came with a prioritized roadmap that made the tradeoffs visible. QA could move from reacting to whatever broke that week to asking which high-value product promise was still unverified. Engineering now extends the framework independently, QA uses it for day-to-day validation, and the documentation pipeline is already live and beginning to roll out to clients. One investment ended up improving both product quality and the way the team supports customers.
What got automated
+ Multi-Purchase, Revert Transaction — 12 areas total.
Coverage map
55 scenarios mapped — status of the highest-traffic areas at a glance.
Invite delivery gaps flagged
C5 role visibility, C7 export flagged
Single-field assertion only
Field behavior automated; Approver workflow uncovered
Pricing config automated; fixed-price enforcement not covered
Reject path absent
Go-offline→sync untested end-to-end