WebInclusiveby Giuseppe Stumbo

QA and testing: verify journeys before release

After a change, can someone still book, submit a form or make a purchase? I assess the functionality and accessibility of the agreed journeys on the specified build. I document defects, fixes and regressions to help your team make its release decision.

The service at a glance

Who it helps, what you receive and what to prepare for the initial discussion.

When you need it
For QA teams, developers and release owners, before a release or after changes and fixes.
What I do
I run functional scenarios for the agreed tasks, accessibility checks relevant to the release, defect retests and regression tests in the defined environments.
What you receive
Reproducible bug reports, test and retest results, unresolved defects and residual risks to inform the release decision.
What we need from you
An identifiable stable build, test access and data, expected results, a list of changes and a technical contact.
Scope
Functional QA checks the expected outcome of a task; an accessibility audit assesses applicable requirements; usability testing with users observes the experience of participants. These activities have distinct objectives and outcomes. QA covers agreed scenarios and does not automatically include a full audit or user sessions.
How we continue
Send the build, changes and deadline: we will define the scenarios to test. Your team makes the release decision; after fixes, we agree retesting and regression checks.

What you receive from QA and testing

You receive a record of the work on the tested build: scenarios, bug reports, test results and residual risks. We agree in advance on journeys, environments, retest cycles and report language, including target markets and interface languages to test.

  • Coverage

    Test plan and reusable scenarios

    Scenarios for the agreed journeys, with steps, expected results and test environments. The team can repeat them on later releases.

    • Planned version or build, browsers, devices and assistive technologies.
    • Journeys, error cases, acceptance criteria and coverage limits.

  • Defects

    Reproducible bug reports

    Reports usable in the team’s tools to assign, fix and verify each defect.

    • Steps, expected and observed results, environment and evidence.
    • User impact, severity and remediation priority.
    Draft QA bug report — fictional example
    Status and identifier
    QA-DEMO-001. A simulated report to validate: no actual test performed and no fix verified.
    Example build and environment
    Build DEMO-02, Windows 11, Firefox and NVDA. An actual report specifies the exact system, browser and assistive technology versions.
    Preconditions and steps
    Open the demo basket containing “Blue mug” and “Green mug”. Tab to the two remove buttons and listen to their names.
    Simulated behaviour
    Both buttons are announced as “Remove”, without identifying the item.
    Expected result
    Each button exposes a name identifying the action and item, for example “Remove Blue mug from basket”.
    Impact and proposed priority
    Screen reader users cannot reliably distinguish which item will be removed. Proposed severity: high; priority to be agreed during triage.
    Evidence to collect
    Exact environment versions, detected accessible names and references to the two controls. Attach reproduction evidence: none is available in this draft.
    Retesting and regression testing to perform
    Check the names after the fix and remove each item separately. Check that the correct item is removed and that focus, totals and basket updates remain usable. Result: not performed.

  • Results

    Summary of tests, retesting and residual risks

    Results for the tested build to support the team’s release decision.

    • Tests passed, failed and not performed, with any blockers.
    • Within the agreed cycles: verified fixes, reopened defects and regression test results.
    • Issues still open and residual risks within the examined scope.

Know what works after a change

Before releasing, you want to understand which tests have been performed and which issues remain. We start with the product version, supported environments and the journeys that matter most to people.

Every defect report identifies the build, environment, reproduction steps and expected and observed results. Retesting (confirmation testing) checks that a defect has been fixed; regression testing checks for unintended effects of changes on the agreed journeys. Open issues and residual risks remain documented to inform the release decision. I also work with US and international teams, agreeing on target markets and product requirements.

  • A button that appears but never receives keyboard focus.
  • A confirmation message that appears visually without being announced.
  • A validation error that does not identify which field to correct.
  • A step that works with a mouse but blocks keyboard or screen reader users.

  1. Navigation

    Menus, skip links, landmarks and focus order.

  2. Content

    Readable headings, links, tables and dynamic states.

  3. Forms

    Fields, instructions, validation and error messages.

  4. Transactions

    Checkout, confirmations, receipts and post-submission steps.

Release-related checks

I build tests around product operations and their error cases. Functionality, mobile behaviour and assistive technologies are checked in the agreed scenarios.

  • Core

    Functional and regression testing

    Tests are built around journeys that matter to the business, using reusable scenarios and focused checks of actual behaviour.

    • Checks of critical tasks and their error cases.
    • End-to-end scenarios and acceptance tests when the risk requires them.
    • Support for test cases, scenarios and Gherkin BDD.

  • Mobile

    Mobile QA for iOS and Android, responsive and cross-browser testing

    Quality on real devices, browser compatibility, layout adaptation and consistent behaviour on smartphones and tablets.

    • Mobile QA on iOS and Android.
    • Responsive and cross-browser testing.
    • Sessions on real devices and in representative environments.

  • Assistive

    Screen readers, keyboards and post-fix validation

    Keyboard and assistive technology checks observe the product in actual use, beyond a conformance checklist.

    • Screen reader and assistive navigation testing.
    • Defect documentation aligned with the rest of QA.
    • Post-fix validation and pre-release support.

From bug report to fix verification

A report is useful when the team can reproduce the issue, assign it and know how to verify its solution. Each step stays connected to tests and acceptance criteria.

  1. Scenarios

    Map critical tasks

    We choose the operations people need to complete: navigating, searching, signing in, purchasing, completing forms and using dynamic components.

    • Focus on tasks that matter most to users and the business.
    • Checks designed to find issues before production.
    • Closer alignment with actual product behaviour.

  2. Defects

    Write reproducible bug reports

    I write bug reports so the person responsible can repeat the steps: expected and observed results, environment, impact and priority are in the same report.

    • More useful reports for development and stakeholders.
    • Less ambiguity when validating fixes.
    • Tracking each fix through to final retesting.

  3. Release

    Integrate checks into the workflow

    I bring defect reports and the backlog into tools the team already uses, such as Jira and Confluence. In Agile or Scrum processes, we also agree on quality gates: checks and criteria to evaluate before release.

    • Easier integration into existing processes.
    • Better alignment between functional QA and accessibility.
    • Practical support for pre-release quality gates.

Frequently asked questions

How I prepare tests, document defects and verify fixes with the team.

Are accessibility barriers bugs?

Yes. When they prevent or make it difficult to complete a task, they should be managed as product quality defects: reproducible, assignable and retestable.

How long does a testing session take?

It depends on the journeys, platforms, configurations and verification of fixes required. An estimate is prepared after agreeing the scope and test environments.

Which testing tools do you use?

I combine automated tools (axe, Lighthouse, WAVE, Pa11y) with manual checks using keyboards, screen readers and real devices.

Let’s prepare checks for your release

Specify the version, supported platforms and planned release date. If particular journeys concern you, we can start there.