Testing
- API testing
- End-to-end testing
- Integration testing
- Unit/controller testing
- Regression testing
- Manual testing
- Test-case design
- Defect reporting
open to remote work
Irish Nicole Dimabuyu
Software QA Engineer , API & E2E Test Automation
Software QA Engineer with experience in API and browser test automation, manual testing, requirements analysis, and QA workflow design. Contributed tests using Cypress, Playwright, Jest, and Supertest across registration and event-management platforms.
01 / about
About
I’m a Software QA Engineer who works across API and browser-level test automation, manual testing, requirements analysis, and QA workflow design. My test contributions use Cypress, Playwright, Jest, and Supertest on registration and event-management platforms for BMI Global Education, the international student-fair organiser that is part of Times Higher Education.
My background spans QA, product management and UX design, which shapes how I work: I start from the specification, write down what “correct” means for each role, rule and failure path, and only then automate. When something breaks, I write it up so a developer can act on it — reproduction steps, expected versus actual behavior, and evidence.
My work is QA automation, specifications, documentation, and workflows. I don’t present it as implementing production features, and I’m deliberate about the difference between what I authored, what I verified, and what shipped. How I report my work →
- 01Product managementRequirements, user stories, acceptance criteria, agile tracking.
- 02UX designUser flows, prototypes and user research in Figma / FigJam.
- 03Specification-first testingSpecs and Given–When–Then scenarios before tests.
- 04Structured defect reportingReproducible reports with expected/actual behavior and evidence.
- 05AI-assisted QA deliveryCopilot Spaces and custom agents, with guardrails and disclosed attribution.
02 / highlights
Highlights
Repository-audit figures as of Q4 2026. Each is labelled by what it actually measures — these are authored or declared counts, not test-execution or pass results.
-
40 + 40
specifications and matching test-case documents authored
QA repo (eis-qa)
-
5
GitHub Actions QA workflows added or changed
QA repo · standards check, browser-test run, 3 documentation-sync workflows. Merge-blocking enforcement not verified.
-
77
retained test suites with test definitions (94 historically added)
API repo · suites, not individual cases; moves and placeholders excluded
-
declared
178
Cypress / browser E2E test cases across 27 suites
eis repo · declared cases; not execution results
-
532
authored commits, Q4 2025 – Q4 2026
QA repo (eis-qa) · includes 5 explicitly Copilot-coauthored
-
opened
170
bugs opened (150 closed)
146 in the eis repo (136 closed) · 24 general, api repo included (14 closed) · opened ≠ fixed; others’ fixes are not claimed
Private BMI Global Education repositories are not linked; descriptions are sanitized. Commit counts measure committed work, not test runs or business impact.
03 / skills
Skills
Automation & QA Tools
- Cypress
- Playwright
- Jest
- Supertest
- Postman
- GitHub Actions
Languages
- JavaScript
- TypeScript
- HTML
- CSS
- YAML (config)
- Markdown (docs)
Development & Databases
- React
- Node.js
- Express.js
- Tailwind CSS
- MongoDB
- MySQL
- REST APIs
Delivery & Collaboration
- Git
- GitHub Issues
- GitHub Projects
- GitHub Copilot
- ClickUp
- Productboard
- Slack
Product & Design
- Requirements analysis
- User stories
- Acceptance criteria
- User flows
- Figma
- FigJam
Where the tool evidence is
Counts are authored commits touching tool-related tests, helpers or setup — not tool executions or pass results, and they overlap.
| Tool | Where | Commit evidence |
|---|---|---|
| Cypress | eis repo; fairs-js repo | 106 in eis · 16 in fairs-js |
| Jest | api repo; QA repo | 210 in api · 13+ in QA repo |
| Supertest | api repo; QA repo | 157 in api · 13+ in QA repo |
| Playwright | QA repo | 3 commits (4 including support tooling) |
04 / featured work
Case studies
Eight stories in Situation → Task → Action → Result form. Where I haven’t measured an outcome, the result says so.
Moving bug and progress tracking from spreadsheets to GitHub Projects
- Situation
- The team tracked bugs and development progress in spreadsheets, separate from the repository issues and pull requests tied to the work. Frontend, backend, QA, staging validation, production validation and release status also needed to be told apart instead of sharing one overall status.
- Task
- Move tracking into GitHub Projects and organize a shared workspace that reflected the delivery process.
- Action
- Moved bug and progress tracking into the EIS Kanban project, with dedicated views for prioritization, team assignments, documentation, bugs, tasks, features and releases.
- Structured workflow stages: prioritization, revision, development, testing, approval, completion, blocked work and future releases.
- Added separate frontend, backend and QA progress fields, plus staging and production results, impact levels, affected users, release assignments and deadlines.
- Configured project lifecycle automation (including automatic sub-issue inclusion) and created status and release-impact reporting views.
- Result
- Issue details, development progress, QA validation and release information now sit in one repository-connected workspace.
Not claimed Administrative time savings and release-speed improvements were not measured.
Translating requirements into testable specifications
- Situation
- Features spanned different user roles, validation rules, dependencies and failure paths, so there needed to be a documented basis for what “correct” meant and which scenarios required testing. The administrator chatbot was one example: it needed explicit requirements for access, event-scoped answers, conversations and action confirmation.
- Task
- Translate requirements into specifications and matching test scenarios that could guide development and QA.
- Action
- Authored specifications describing expected behavior, user roles, validation, dependencies and error handling.
- Maintained matching test-case documents with preconditions and Given–When–Then scenarios, separating interface scenarios from API scenarios.
- Updated documentation and test expectations whenever agreed behavior or API contracts changed.
- For the chatbot, documented access, conversation, event-scoping and confirmation requirements before contributing integration and unit tests.
- Result
- Contributed to 40 specifications and 40 matching test-case documents in the QA repo. For the chatbot, specifications and scenarios were added in Q3 2026, followed by automated tests in Q4 2026 — a documented example of the specification-first approach.
Not claimed No reduction in misunderstandings or production defects was measured.
Strengthening migration regression coverage
- Situation
- Migration behavior needed testing beyond the successful path. Validation, failure responses and test-data restoration needed clear expectations in both the documentation and the automated tests.
- Task
- Strengthen migration regression coverage and align the documented behavior with the implementation contract.
- Action
- Added negative-case integration checks and refined fixtures and assertions to match expected request and response behavior.
- Improved diagnostics so failures are easier to investigate.
- Updated the migration specification’s validation and failure expectations and contributed test-data restoration scenarios.
- Treated specifications and tests as connected artifacts, updating them together instead of leaving conflicting expectations.
- Result
- Explicit validation, failure and restoration scenarios were added to the migration test artifacts and the supporting documentation was aligned. Recorded in the Q3 2026 migration testing and documentation changes.
Not claimed Successful production migrations or reduced migration incidents.
Improving Cypress test maintainability and synchronization
- Situation
- Configuration and booking tests depended on related records and interface readiness, and needed coordinated setup, reliable element selection and cleanup.
- Task
- Make the affected Cypress tests more reusable and improve how they handled dependencies and interface state.
- Action
- Introduced shared test data, consolidated reusable selectors and simplified dependent-service interactions.
- Contributed automated configuration setup and cleanup, and revised booking-test setup and catalogue-selection interactions.
- Added readiness-based waiting and retry behavior to the affected flows.
- Kept the work scoped to tests and supporting infrastructure, not production application fixes.
- Result
- The affected tests gained shared setup, reusable selectors, clearer dependency handling, cleanup and explicit readiness behavior. Configuration-test improvements are dated Q3 2026; readiness and retry improvements Q4 2026.
Not claimed No reduction in flaky-test failures was measured.
Automating QA documentation and traceability checks
- Situation
- Specifications, test cases and automated-test artifacts needed consistent metadata, structure, naming and matching identifiers. Written conventions alone gave no automated way to spot deviations.
- Task
- Turn those QA conventions into repeatable repository checks.
- Action
- Added validators for specification metadata and structure, naming conventions, and ID-based traceability between specifications and matching test artifacts.
- Added a combined checker, supporting authoring guidance and GitHub Actions configuration to run the checks on pushes and pull requests.
- Separately contributed documentation-synchronization workflows across the QA, application and API repositories, plus browser-test workflow support and report collection.
- Result
- Automated checks for documentation standards and artifact consistency exist in the QA repo, alongside configured documentation-transfer workflows across related repositories (in the API repo: six commits affecting three documentation workflows). Documentation checks validate conventions, synchronization workflows transfer material, and browser workflows support test execution — they are different things.
Not claimed Required merge-blocking enforcement was not verified; synchronization workflows are not quality gates.
Collaborating with Copilot on permissions testing
- Situation
- Permission data and hierarchical navigation needed to follow a consistent structure, ordering and set of relationships.
- Task
- Translate those expectations into automated integration coverage while collaborating with GitHub Copilot.
- Action
- Contributed tests covering permission-data structure, navigation hierarchy, ordering and consistency, plus related permissions documentation and test material.
- Explicitly credited Copilot as a coauthor on the relevant contribution.
- Kept the ownership claim on the tests and documentation, not on the underlying permissions implementation.
- Result
- A recorded Copilot-coauthored testing contribution in Q2 2026, which reached mainline in the API repo in the same quarter.
Not claimed This does not establish a delegated coding-agent task or formal approval of the production implementation.
Building browser coverage for a multi-step registration journey
- Situation
- A registration journey involved cookies, navigation, multiple form steps, validation and alternative paths.
- Task
- Contribute browser coverage and keep the scenarios maintained as the QA branch evolved.
- Action
- Added Cypress checks for cookies, navbar behavior, registration steps, validation and navigation.
- Later revised test data and navigation checks, added visual color and background assertions, and contributed direct-HTTP route-response checks.
- Documented TDD conventions, test-generation patterns, documentation standards and a code-review checklist.
- Kept scenarios explicitly skipped where they weren’t ready for active execution.
- Result
- The audited snapshot contained 216 E2E declarations: 199 enabled and 17 explicitly skipped (with extra conditional skips in some navbar tests). Four direct-HTTP route-response declarations expand to 717 potential cases through configured route data.
Not claimed Declarations are not passing results, and 717 is not a count of executed requests. The original (221) and replacement (216) registration suites are separate snapshots, not additive.
Verifying an agent-authored booking-date correction
- Situation
- Booking confirmations could show the date an item entered the cart rather than the checkout date. An agent-authored correction was available for testing.
- Task
- Verify the delivered correction and record the QA outcome — not implement the fix.
- Action
- Tested the correction against the expected checkout-date behavior and recorded “Passed” in the QA discussion.
- Kept the testing contribution separate from the agent’s implementation work.
- Result
- A QA pass was recorded in Q1 2026; the correction reached mainline in Q2 2026.
Not claimed This isn’t production sign-off — completed production retesting was not verified.
05 / ai-assisted qa
AI-assisted QA
Copilot Spaces and custom agent configurations designed with explicit guardrails: read the specification first, limit changes to QA artifacts, keep humans in control of validation.
GitHub Copilot Spaces · GitHub Issues
EIS – Bug Issues
A Copilot Space that turns informal bug descriptions, screenshots and supporting links into structured issue reports for an event-management platform.
- Feature-to-specification mappings connecting bug reports with relevant requirements.
- Consistent issue titles, module classifications and report sections.
- Given–When–Then scenarios, reproduction steps and expected versus actual behavior.
- Rules for organizing session-recording links, logs and screenshots; instructions for identifying relevant code references and creating issues on the project board.
Copilot · GitHub Actions · Playwright · Jest · Supertest
AI-Assisted QA Workflow & Custom Copilot Agents
A specification-first workflow connecting specifications, test cases and automated tests through shared identifiers and repository standards.
- Custom agent configurations for specs, test cases, unit, integration and Playwright E2E tests.
- Reusable prompts for spec updates, regression-impact analysis and test maintenance.
- Structured interviews and approval gates; unresolved technical questions deferred to developers.
- Agents classify assertions as stale, missing or valid after requirement changes.
- Actions configured for metadata, naming and ID-traceability checks; Playwright run configured after staging-deployment notifications, reports kept as artifacts.
Copilot · Cypress · GitHub Actions
AI-Assisted Cypress Auditing
A repository-specific Copilot workflow for Cypress coverage auditing and maintenance, comparing specs, test cases and existing tests before proposing changes.
- Coverage matrix and implementation plan required before test edits; specifications win when documents conflict.
- Coordinating auditor plus a read-only exploration subagent; final verification stays with the coordinator.
- Conventions for shared selectors, commands, helpers, fixtures and a selector catalog.
- Static validation by default; Cypress runs only when explicitly requested, blocked checks reported separately.
- Explicit limits on coverage claims — no unsupported “complete coverage”.
GitHub Projects · GitHub Issues · Copilot
EIS QA Issue Management & Release Tracking
An AI-assisted bug-reporting workflow and structured Projects board linking specification-based issues with development progress, QA validation and release tracking.
- Reports standardized with repro steps, expected/actual behavior, screenshots and developer checklists.
- Tracking fields for impact level, affected users, documentation, FE/BE/QA progress, staging and production results, releases and deadlines.
- Project automation for sub-issue inclusion and issue/PR lifecycle updates.
- Reporting views for status distribution, historical progress and release-level impact.
Specification & QA governance
How the team keeps specs, tests and AI work honest
The BMI engineering team governs delivery from the specification up, and has published case studies on QA governance and AI-assisted engineering. These are the team practices where my QA work fits. Each card separates the team practice from my part in it.
Specification-to-test traceability
Team practiceSpecifications, test cases and automated tests are matched to each other and checked automatically when they change.
My partAuthored 40 specifications and 40 matching test-case documents in the QA repo, and added validators for metadata, naming and ID-based traceability that run through GitHub Actions on pushes and pull requests.
Cross-repository sync
Team practiceSpecification and test content is kept consistent across the repositories it governs when any one of them changes.
My partContributed documentation-synchronization workflows across the QA, application and API repositories (six commits across three workflows in the API repo).
Guarded AI authoring
Team practiceAI agents interview the author on each new requirement before specs and tests are drafted, and are kept away from application code.
My partConfigured custom Copilot agents for specs, test cases and tests with structured interviews, approval gates and a limit of changing QA artifacts only; unresolved technical questions go to developers.
Specification-linked issue intake
Team practiceEngineering work is tied to a specification reference, an owner and test-coverage evidence.
My partDefined feature-to-specification mappings, contributed the bug-report and QA-request templates, and set up the board’s documentation tracking field. Tickets raised before spec-driven development began show “No Documentation” (277 on the board below).
Team practices are described in the engineering lead’s own case studies; I claim only the “My part” lines. Those lines are authored or configured work, and the sync workflows transfer documentation rather than block merges.
GitHub Projects · EIS board snapshot · Q4 2026
Tracking board by the numbers
The EIS Projects board held 356 items. Some charts leave out empty or housekeeping categories, so they don’t each add up to that total. I structured the board’s fields, views and reporting; the items themselves were raised and worked by the whole team, so these are team-wide board counts — not individual output, defect rates or quality measures. Bars are scaled within each chart. Muted rows are items where the field is empty.
Status
“To do” is items with no status set. The last row groups In Progress (4), Blocked / On Hold (4) and Next Season Release (4).
Ticket type
Impact level
Critical blocks a release or breaks core flows; Deferred is not prioritized now. Excludes 24 items with no impact level.
User type affected
The user types affected by the issue or feature.
Spec documentation
“No Documentation” items were raised before spec-driven development began; spec tracking hasn’t yet been applied to them.
Users affected
Recorded on 42 of the 356 items: issues reported or found through Smartlook session recordings. Some were change requests rather than defects.
Tickets per release window
Initial Deployment (Q3 2025) through Release 34 (Q4 2026), plus 79 items with no release assigned.
64Init
111
92
33
44
25
46
187
48
49
510
1011
812
713
314
515
216
417
118
419
120
1121
1122
723
824
625
626
1027
1128
929
630
631
432
533
434
Data table: tickets per release
| Release | Quarter | Tickets |
|---|---|---|
| Initial Deployment | Q3 2025 | 64 |
| Release 1 | Q3 2025 | 11 |
| Release 2 | Q3 2025 | 9 |
| Release 3 | Q4 2025 | 3 |
| Release 4 | Q4 2025 | 4 |
| Release 5 | Q4 2025 | 2 |
| Release 6 | Q4 2025 | 4 |
| Release 7 | Q4 2025 | 18 |
| Release 8 | Q1 2026 | 4 |
| Release 9 | Q1 2026 | 4 |
| Release 10 | Q1 2026 | 5 |
| Release 11 | Q1 2026 | 10 |
| Release 12 | Q1 2026 | 8 |
| Release 13 | Q1 2026 | 7 |
| Release 14 | Q1 2026 | 3 |
| Release 15 | Q1 2026 | 5 |
| Release 16 | Q1 2026 | 2 |
| Release 17 | Q2 2026 | 4 |
| Release 18 | Q2 2026 | 1 |
| Release 19 | Q2 2026 | 4 |
| Release 20 | Q2 2026 | 1 |
| Release 21 | Q2 2026 | 11 |
| Release 22 | Q2 2026 | 11 |
| Release 23 | Q3 2026 | 7 |
| Release 24 | Q3 2026 | 8 |
| Release 25 | Q3 2026 | 6 |
| Release 26 | Q3 2026 | 6 |
| Release 27 | Q3 2026 | 10 |
| Release 28 | Q3 2026 | 11 |
| Release 29 | Q3 2026 | 9 |
| Release 30 | Q3 2026 | 6 |
| Release 31 | Q3 2026 | 6 |
| Release 32 | Q3 2026 | 4 |
| Release 33 | Q3 2026 | 5 |
| Release 34 | Q4 2026 | 4 |
| No Release | — | 79 |
Process documentation · Specification-first testing · FE/BE/QA collaboration
Cross-Functional Team Workflow & Quality Gates
How a feature moves from requirements to production across frontend, backend and QA, with QA preparing specs and tests before code is written. Failed checks loop back to coding or spec revision.
Requirements
FEBEQA
Prototype and PRD are discussed; an AI questioning agent helps clarify API scope.
Specs & test cases
QA
QA drafts specs and test cases; the team reviews and finalizes them.
Test-first backend
QABE
QA prepares unit and integration tests before BE codes, then runs them when the API is ready.
Frontend build
FE
FE codes, tests locally, integrates with the backend and tests on staging.
E2E on staging
QA
QA runs end-to-end tests once the UI is ready.
Approval & launch
FEBE
FE presents the feature; once approved, FE and BE launch it.
Production testing
QA
QA tests after launch, the final validation step.
Feedback loopsA failed test returns work to coding or spec revision; a rejected approval returns to the QA spec update.
View the full workflow diagram
06 / experience
Experience
-
Software QA Engineer
Setup Phils Inc.
Client engagement: BMI Global Education, part of Times Higher Education
- Contributed API, integration, unit/controller, and browser-based tests using Jest, Supertest, Cypress, and Playwright across international education-fair registration and event-management platforms.
- Expanded regression coverage for authentication, role-based access, schedules, events, exhibitor workflows, bookings, reports, notifications, and data migration.
- Authored 40 specifications and 40 matching test-case documents in the QA repository, defining validation rules, dependencies, role permissions, and failure behavior.
- Improved test maintainability through shared fixtures, reusable selectors, role-aware setup, automated cleanup, and readiness-based browser interactions.
- Added GitHub Actions workflows for QA documentation metadata, naming, and artifact-traceability checks, browser-test execution and report collection, and cross-repository documentation synchronization.
- Migrated bug and progress tracking from spreadsheets to GitHub Projects, organizing frontend/backend/QA status, staging and production results, release assignments, automation, and reporting views.
- Designed GitHub Copilot Spaces and custom QA workflows for structured bug reporting, requirements clarification, test authoring, coverage-gap analysis, and regression triage.
- Documented reproducible defects and verified selected corrections in staging, including an agent-authored booking-date fix; maintained clear distinctions between QA verification, implementation ownership, and release approval.
-
Junior Product Manager
Top.legal GmbH
- Collaborated with customer success, design, and development teams to align feature requirements with user needs and business priorities.
- Gathered client feedback through interviews and surveys, synthesizing findings into product opportunities and roadmap recommendations.
- Developed and iterated on product solutions addressing user pain points.
- Tracked feature progress using agile practices and supported daily development prioritization.
- Created product requirements, user stories, and acceptance criteria to clarify scope and expected behavior.
- Supported QA testing and feature validation in collaboration with design and development teams.
-
Intern QA Engineer & UX Designer
Top.legal GmbH
- Maintained product documentation and test cases to support consistent testing and communication of expected functionality.
- Performed manual functional and system testing, documenting defects with reproduction steps, expected behavior, and supporting evidence.
- Managed defects and product backlog items in ClickUp, supporting issue prioritization and follow-up.
- Facilitated sprint planning and maintained the Kanban board to track work and team progress.
- Created user flows and prototypes informed by user research and product requirements.
- Maintained a change-request backlog for design and functional inconsistencies.
07 / platform context
Platform context
My work formed part of a team-maintained platform ecosystem supporting international education fairs organised by BMI Global Education (part of Times Higher Education).
Read this first These figures describe system usage by the team’s platform. They are not growth or outcomes attributable to my individual work.
For wider context, the BMI engineering team’s published AI-assisted engineering case study describes the fairs programme as 60–80 fairs a year across 18 countries, supported by 14 systems. Those are the client’s figures, not mine, and I worked on a subset of those systems.
-
360+
institution bookings across 31 fairs in nine countries, Spring 2026
EIS — institution booking & event management. I contributed QA and workflow improvements.
-
53,000+
sign-ups across 31 fairs in nine countries, Spring 2026
Registration platform & API. I contributed to it.
-
16,000+
door check-ins across participating fairs, Spring 2026
Badge-scanning system. I contributed to it.
-
81,000+
fair-matched scans, Spring 2026
Smart Scan app & API. I contributed to it.
-
140+
institution bookings for the Latin America fairs, Fall 2026 — as of Q4 2026
Regional example — EIS. I supported QA for it.
08 / education
Education & project
2019 – 2023
Bachelor of Science in Information Technology
City College of San Fernando Pampanga · San Fernando City, Philippines
- GWA 1.24
- Award Best in Capstone Project
Relevant coursework: Software and Web Development, User Experience Design, Project Management.
Selected project · 2019 – 2023
Full-Stack Capstone Web Application
City College of San Fernando Pampanga
- MongoDB
- Express.js
- React
- Node.js
- Developed a full-stack web application using the MERN stack, applying SDLC practices from requirements gathering through deployment.
- Defined information architecture and user flows, and designed interfaces with accessibility and privacy considerations.
- Refined design and functionality based on user-testing feedback.
- Received the Best in Capstone Project Award.
09 / transparency
How I report my work
QA is about evidence, so this portfolio holds itself to the same standard. Here is how to read the numbers and claims on this page.
-
Counts are authored or declared — not results
Suite, test-case and commit counts describe what was written and committed. They are not execution results, pass rates, coverage figures or business impact. Commit attribution doesn’t prove exclusively handwritten authorship.
-
Copilot co-authorship is disclosed
1 commit in the API repo, 5 in the QA repo and 11 in the eis repo (Q2 2026) explicitly credit Copilot as co-author. No delivered implementation from a task I delegated to a coding agent was verified (one assigned Copilot task from Q4 2025 closed unmerged), and the absence of an AI trailer doesn’t prove a commit was handwritten.
-
Verification ≠ implementation ≠ approval
When I test someone else’s change (or an agent’s), I claim the testing — a QA pass is not authorship of the fix, and not release sign-off. No formal PR approvals or release sign-offs by me were verified.
-
Private repositories, sanitized details
The BMI Global Education repositories are private, so they aren’t linked and descriptions are sanitized. Details of open bugs are withheld. Platform figures describe the team’s product, not my individual outcomes.
10 / contact
Let’s talk
Open to remote QA automation roles. The fastest way to reach me is email.
- Email ishdimabuyu@gmail.com
- Phone +63 991 503 4755
- LinkedIn linkedin.com/in/ish-dimabuyu ↗
- Location Malpitic, San Fernando, Pampanga, Philippines