Tsz Yin Chan (Jack)

Background

In my current role supporting KPMG Canada’s RPA team, part of my work involves testing new processes and change requests, coordinating UAT, and validating business logic before release. Within that context, I saw an opportunity to improve how QA EA test-plan workbooks were prepared.

Problem

Workbook preparation involved repeatable structure but still required significant manual setup. The challenge was not only efficiency, but also how to use AI assistance without weakening QA ownership over coverage, logic, and final quality.

Constraints

The output needed to remain reviewable and usable in a real QA workflow. Accuracy, formatting, hyperlinks, coverage, and business logic still required human validation, so the workflow could not simply rely on model output without control points.

Solution

I designed a structured Copilot-assisted workflow for draft workbook preparation using reusable prompts, template inputs, organized source views, and review checklists. The goal was to generate a more complete first draft while preserving QA control over logic, completeness, formatting, and final validation. Rather than replacing the QA process, the workflow was designed to support it with more structure and consistency.

Validation

The workflow was reviewed through QA ownership checkpoints, including coverage review, hyperlink and formatting checks, logic review, and final output validation. This kept the generated draft within a controlled review process rather than treating it as a finished deliverable.

What This Shows

This case reflects how I prefer to use AI in a controlled workflow, with clear human review points rather than treating generated output as final. It also shows that I am most interested in workflow design where structure and judgment both matter.

Background

At St. Teresa’s Hospital, I worked on a downtime-related pharmacy workflow that depended on data migration between source and target databases in a production-sensitive environment.

Problem

The process was manual, high-risk, and difficult to rely on during outage scenarios. It needed not only data copying, but also a way to keep target-side table structures aligned with the source system before migration.

Constraints

The workflow had to operate safely in a real operational environment, handle multiple tables in sequence, reduce human error, and surface failures clearly enough for support follow-up. This was not treated as a casual internal script.

Solution

I developed a VB.NET and T-SQL tool that loaded a configured table list, retrieved schema metadata from source and target databases, compared structural differences, and updated the target schema by creating missing tables or adding missing columns before copying data. The workflow was designed to make migration more repeatable and reliable rather than depending on manual intervention at each step.

Validation

The implementation used ordered processing, transaction-based schema updates, logging, and error alert handling to support safer execution. This aligned the solution with operational reliability rather than simple one-off automation.

What This Shows

This work reflects my preference for making fragile operational processes more repeatable and safer through structure, validation, and controlled execution. It also shows that I think beyond coding alone and pay attention to reliability in real use.

Background

In the same hospital environment, I encountered a long-standing issue affecting patient allergy data. Because clinicians relied on this information, the problem had implications beyond a typical bug and needed a dependable resolution.

Problem

The issue was difficult to reproduce consistently and had remained unresolved over time. The challenge was to move beyond surface symptoms, identify the true cause, and implement a fix that would restore reliable downstream data usage.

Constraints

This was a live healthcare context, so correctness and trust were essential. It was not enough to produce a temporary patch; the fix needed to be logically sound and validated in a way that reduced the risk of introducing new issues into a critical module.

Solution

I approached the issue through root cause analysis rather than symptom chasing. By tracing the data flow and reviewing API behavior, I identified that the logic was calling an incorrect endpoint for the scenario. I then modified the logic to use the correct API path and treated the work as a full quality cycle rather than a narrow code change.

Validation

After implementing the fix, I designed and executed regression testing to confirm not only that the issue was resolved, but also that related behavior remained stable. This helped restore data integrity and confidence in the affected workflow.

What This Shows

This case reinforced the importance of tracing issues to root cause instead of patching symptoms. It also reflects my focus on correctness and stability when a workflow is relied on by end users.