It started in 2008, writing enterprise software from the ground up at Global Steel Philippines — requirements, development, deployment, user training, the whole lifecycle. I wasn't a tester yet, but I was already living with the consequences of every shortcut and every untested edge case, which turned out to be exactly the lesson that stuck.

By 2014 I'd moved to Accenture as a Tech-Functional Consultant, spending four years across Oracle EBS and Oracle HCM Cloud engagements for several Fortune 500 clients — building data extracts and reports, leading a large-scale PeopleSoft-to-Cloud data migration, and reviewing other developers' work before it ever reached testing. Reviewing code for a living, before QA ever touched it, taught me to think like a tester long before it was my job title: always asking what happens at the edges, not just whether the happy path works.

In 2021 I made that unofficial habit official, moving fully into QA as a Test Specialist at IBM on the Verizon Communications account — General Ledger, Accounts Payable, Accounts Receivable, Procurement, Order Management, Inventory. I wrote test plans and cases from scratch and leaned on SQL to validate backend data integrity directly, rather than trusting the UI to tell the whole story.

From 2022 to 2026 at ColletteHealth, I ran functional, regression, integration, and backward-compatibility testing at real scale, and grew into the subject matter expert for key product areas — the person developers and product owners checked with before a release went out, not after.

Since June 2026 I've been the first and only QA Engineer at IMR System, building the QA function from zero. I've expanded test coverage, established Playwright automation, designed AI-assisted testing workflows, and built custom test runners that generate detailed Excel reports with embedded screenshots — so nothing that gets tested is ever just a memory.

Testing isn't a checklist you run after the real work is done — it's part of the engineering. My development background means I don't just identify defects — I usually understand why they happened, where they originated, and what kind of solution is likely to resolve them. The dashboard and reporting system on this site exist because a bug report that just says "FAIL" doesn't help anyone — a QA Manager, an engineer, and a product owner all need the same evidence, explained in language each of them can act on.

Over the years I've found that my strongest contribution isn't simply finding bugs — it's improving the way teams think about quality. Whether that's designing better test coverage, building automation, improving reporting, or introducing new tooling, I enjoy creating systems that make quality easier to measure, maintain, and continuously improve.