Manual Testing and QA in Canada

About Manual Testing and QA

We run manual QA on every website and app we build, so we offer it as a standalone service too. Send us a staging URL or a build and we write a test plan, run functional, regression, exploratory, cross-browser, and cross-device passes, then hand back bug reports your developers can actually act on. Flat quote against a written scope, GST included, back in 24 hours.

What the engagement includes

• A clear title and a one-line summary of exactly what is wrong.
• Numbered steps to reproduce, from a known starting point, so anyone can follow the same path to the same failure.
• Expected result versus actual result, side by side, so the defect is unambiguous and not a matter of opinion.
• The environment it happened in: browser and version, device, OS, screen size, and the specific build or URL.
• A screenshot or screen recording, plus the relevant console or network error where it helps pin down the cause.
• A severity and priority call, so your team fixes the checkout blocker before the cosmetic misalignment.
• Everything logged in your tracker (Jira, Trello, GitHub Issues, Linear, or a shared sheet), in the format your team already uses, not a PDF nobody opens.

Bank change controls, the new federal ICT accessibility rules and Ontario's active offer in Canadian manual testing

At a federally regulated bank or insurer, a manual test cycle is part of a control OSFI expects to see rather than a courtesy before release. Guideline B-13 on technology and cyber risk management, in effect since 1 January 2024, says changes to technology assets in production should be documented, assessed, tested, approved, implemented and verified in a controlled manner, that patches should be tested before they reach production, and that duties should be segregated so the same person cannot develop, authorise, execute and move code or releases between production and non-production environments. It also asks for traceability and integrity of the change record and of the asset being changed. For a testing team that turns several habits into requirements. The person who signs off a test run is never the person who wrote the change, and our testers do not hold the deployment rights that would let them promote a build themselves, so the separation the guideline describes shows in the access model rather than in a policy document. Each run is tied to the exact build or release identifier it exercised, with the environment, the data set and the tester recorded, because a pass against a build nobody can identify afterwards is not evidence of anything. Emergency changes are where this usually breaks: a hotfix goes out overnight with a promise to test it later, and the change record shows the gap. So the emergency path is agreed before it is needed, with a short targeted script run before release and the full regression set run afterwards inside a window your change board sets. Patch cycles get their own regression pack rather than borrowing the feature one, because a library or operating system patch fails in different places from new code. How B-13 applies to your institution, and what your own change standard demands, is for your technology risk function to confirm.

Federal accessibility law has moved from planning to conformance, and the evidence it asks for is test output. The Regulations Amending the Accessible Canada Regulations, registered on 5 December 2025 as SOR/2025-255, add a part on information and communication technologies built on CAN/ASC-EN 301 549 as amended from time to time. From 5 December 2027, web pages of a federal public sector entity, public and employee-facing, that are created or updated after that date must conform, to the extent feasible, to clauses 4 to 7 and 9 of that standard. From 5 December 2028 the web page duty reaches private federally regulated entities averaging 100 or more employees, and public-facing mobile apps and downloadable documents are added for the federal public sector and for private entities averaging 500 or more. Two provisions turn testing into a record. An entity that conducts or obtains a conformity assessment must keep the report, gap analysis included, for four years, and from December 2028 the larger entities must obtain a conformity assessment with a gap analysis as part of procuring a web page or mobile app. The accessibility statement published every 12 months has to describe where conformity is not met and the plan for closing the gap. Automated scanners cover only part of the success criteria; whether focus order makes sense, whether a screen reader announces a status change or whether an error message can be understood needs a person using assistive technology. So our accessibility runs are organised by EN 301 549 clause rather than by page, record the assistive technology and versions used, mark each criterion as passed, failed or not applicable with a reason, and produce the gap analysis in a form your accessibility statement can quote and your records can keep for the four years. Whether your organisation is covered, and from which date, is for your own counsel.

If the service is delivered for an Ontario ministry or provincial agency, French has to be tested as a journey rather than as a set of translated screens. Since 1 April 2023, Ontario Regulation 544/22 under the French Language Services Act has prescribed what an active offer requires: a person greeted in English, including virtually through electronic means, must also be greeted in French; an English document about services, email included, needs a French version provided at the same time and in the same format; websites and web content about services must be available in both languages; and where a service runs over several steps, someone who asked for French must keep being served in French at every step without having to ask again. Ontario Regulation 284/11 makes the agency responsible for ensuring that a third party delivering a service to the public on its behalf does so in accordance with the Act, which is how the duty reaches the company that built and runs the portal. The multi-step rule is the one functional testing usually misses, because each screen passes on its own and the defect sits between them. The language choice is held in the page but not in the session, a return from a payment or identity provider lands in English, a confirmation email is produced by a background job that never knew the choice, a PDF arrives with French text under English headings, or a session timeout sends the user to a sign-in page in the default language. So the French run of the regression suite is written as end-to-end journeys that start in French and are never switched, with checks at every hand-off to an outside system and on every message the journey sends, including when each one arrives compared with its English counterpart. Whether your service falls under the Act is for your counsel or the ministry you are delivering for.

How we work with Canadian clients

Two things shape Canadian projects more than anything technical. The first is language: if you serve Quebec, French is a legal requirement rather than a nice addition, and the rules tightened considerably under Bill 96. The French version has to be available on equal terms with the English one, which is a design constraint from the first wireframe rather than a translation task at the end.

The second is anti-spam law. CASL is stricter than most teams expect, and the penalties are real. Consent has to be express or clearly implied, records of it have to be kept, and every commercial message needs a working unsubscribe and accurate sender identification. We build those into the product rather than leaving them to whoever configures the mailing tool later, because that is where the exposure usually sits.

Questions Canadian clients ask

Manual Testing and QA: common questions

Other markets we work in