bonjour, hi there! π
i'm mufida :)
|
I test software for a living β accessibility audits, manual QA, and now automated coverage with Playwright. Coming up as a developer first means I donβt just find bugs, I can read the source, write the tests, and build the tooling that catches them before they ship.
About Me
Hi, I'm Mufida β I test software to make sure it actually works, and I build software to understand how it breaks.
I'm currently an Accessibility QA Analyst at NEOGOV (~3 years), running WCAG 2.1/2.2 and Section 508 compliance audits β DHS Trusted Tester certified β and tracking findings in Jira and TestRail for a US-based product team.
Before that I trained as a full stack developer β Dean's Honour grad of Lambton College's Full Stack Software Development program β and I never stopped shipping code on the side. That's exactly why I'm moving into QA automation: I don't just click through an app looking for bugs, I can read the source, write Playwright suites against real APIs and UIs, and wire them into CI.
Lately that's meant writing real Playwright test suites β API tests, CRUD flows, auth flows, smoke tests β and hooking them into GitHub Actions for two of my own projects, because I wanted proof, not just a claim, that I can do this.
β¨ I don't just want to find what's broken β I want to understand it well enough to write the test that catches it next time.
Accessibility QA Analyst
NEOGOV
~3 years experience
WCAG & Section 508 Audits Β· Jira Β· TestRail Β· DHS Trusted Tester Certified
Software Developer
Previous Experience
2+ years experience
Full Stack Development β the technical foundation behind my automation work
Post-Graduate Diploma
Full Stack Software Development
Lambton College, Toronto, Canada
Dean's Honour List
Bachelor's Degree
Computer Engineering
Philippines
Skills & Technologies
A toolkit built around testing software thoroughly β and understanding the code well enough to know where it breaks.
{ Test Automation & QA }
{ Frontend }
{ Backend }
{ Database }
{ Tools & Platforms }
// Currently leveling up in
How I Think About Testing
Two personal projects, two different Playwright suites β because not everything should be tested the same way.
Expensure β Full Suite
28 tests covering auth, dashboard, and transaction flows. Runs in CI on every push and pull request against an ephemeral MongoDB instance. Built with fixtures over Page Object Model, a hybrid API+UI pattern for fast setup, collision-safe test data per run, and rate-limit-budget-aware negative tests.
Expensure β Production Smoke Suite
6 read-only checks against the live deployment. Deliberately kept separate from the main suite β single worker, no parallelism, run manually post-deploy so it can never touch production data by accident.
Email API Service
12 API-only tests via Playwright's request fixture β no browser involved. Covers validation, rate limiting, and error handling. Runs weekly via GitHub Actions plus on-demand β a regression/health-check suite, not a per-PR gate.
βThis project uses two separate Playwright suites, run differently and for different reasons. The split matters more than the test count: it's the difference between βwrote some testsβ and thinking about blast radius, environments, and what's safe to automate where.β
β from Expensure's TESTING_STRATEGY.md
No axe-core accessibility checks or visual regression yet in either suite β that's next on the list.
(Plus ongoing Playwright practice through codegen katas outside these two repos.)
Featured Projects
A selection of projects that showcase my skills in full-stack development and problem-solving β two of them with real Playwright test suites and CI behind them.

Expense Tracker with Gemini AI
A full-stack expense tracking app that uses Gemini AI to categorize transactions and surface financial insights. Now backed by a 28-test Playwright suite β auth, CRUD, and dashboard flows, plus a separate read-only smoke suite for production β wired into CI with fixtures-based, collision-safe test data.



Email API Service
A backend service handling contact form submissions with dual email-provider support β Gmail SMTP integration, rate limiting, input validation, and automated confirmation emails. Covered by a 12-test Playwright API suite (validation, rate-limit enforcement, error handling) that runs on a weekly schedule via GitHub Actions and can also be triggered on demand.
Get In Touch
I'm currently open to new opportunities and collaborations. Whether you have a question, a project idea, or just want to say hi β I'd love to hear from you!
