>Session:Payment Flow Investigation>Charter:Explore boundary conditions intransaction processing>Oracle:User expectation vs. system behavior>Heuristic:"Follow the money">Finding:Rounding error at boundary>Risk:HIGH — affects all txns > $9,999.99
I'm Ben, a software tester. Not a "QA engineer," not a "quality assurance" role — a tester. I investigate software to find problems that matter, using the Rapid Software Testing methodology — a context-driven approach that treats testing as a skilled, human investigation rather than a scripted process.
That means applying heuristics and oracles to evaluate software, designing experiments under uncertainty, and communicating risk in terms stakeholders can act on. Every test session is an investigation, and every bug report tells a story.
Mountain America Credit Union
beatBread
Fast Enterprises
Utah State University
Investigations, findings, and the thinking behind the testing.
The existing integration test suite had grown to over 700 checks across the API layer, but neither testers nor developers had confidence in it. The suite was treated as a formality — run because it existed, not because it provided signal. Tests weren't catching real bugs.
Worked with one other tester to systematically audit the suite controller by controller. Applied a simple but effective heuristic: if we couldn't easily identify what value a check provided, it was modified or removed. Found many checks covering internal server error cases with no real risk attached, checks that were unclear in what they verified, and checks that were inadvertently validating multiple things at once. Performed a parallel refactor to improve code readability and navigability.
The majority of checks were impacted — modified, consolidated, or removed. The suite ended at a similar count, but with fundamentally different composition: each check now had a clear purpose tied to real user or business behavior rather than implementation details.
Team confidence in the suite increased significantly. Developers and testers began using the checks more frequently and actively. Results are now reported to a dashboard for visibility across the team.
A vendor-facing API hub that sends and receives disputes and receipts — handling credit-bureau dispute workflows and compliance-critical dispute notes governed by FCRA/FDCPA. The migration involved significant refactoring alongside a core banking transformation, including replacing unreliable asynchronous document processing queues with a scheduled synchronous endpoint. The risk: dispute notes routed to the wrong place would fail silently, creating compliance exposure with no immediate signal.
Authored a test strategy documenting critical paths, related systems, and known risks. Tested migrated features by comparing results between old and new core systems. Tested refactored behavior by comparing results before and after changes across environments. Spot-checked data mapping directly in the core systems to verify disputes and receipts landed where expected. Evaluated existing integration tests for reliability and found hardcoded test data that masked real risk.
Discovered a typo in the receipt retrieval endpoint that silently prevented it from functioning — a bug that would have caused a compliance failure if shipped. Identified hardcoded data in integration tests that gave false confidence in the API's behavior.
Prevented a potential FCRA/FDCPA compliance violation. Surfaced fragile test data that was undermining the team's ability to trust their checks.
As part of a credit-union-wide core banking transformation, member financial data was migrated from a legacy system to a new core. Defined mapping rules governed how data should translate between systems. Verification spanned multiple data types including HELOC expiration dates, construction loan notes, and credit card promotions. The stakes: incorrect mappings could silently lose member data with no indication anything was wrong.
Systematically verified data against mapping rules across both cores, ticket by ticket. For each data type, queried both legacy and new systems to confirm the mapping produced correct results. When initial queries returned no matching cases, investigated further rather than accepting "not applicable" — searched for similar cases with variations to test whether the expectation itself was correct.
During construction loan notes verification, initial results suggested no cases existed in either core that matched the mapping rule. Rather than closing the ticket, investigated adjacent cases in the legacy system and discovered the expected data format was wrong. At least four cases existed that should have been mapped but were never migrated. The data had been silently lost.
Prevented permanent loss of member construction loan data. Demonstrated that verification requires questioning the rules themselves, not just checking data against them.
Looking for a tester who investigates, not just executes? Let's talk.