QA (Quality Assurance) Overview

The primary intended audience of this article is any QA Engineer at Cantilever. However, Project Managers may also find it useful since it provides an insight into what QA Engineers do for (and expect from) the rest of their team when performing a QA test.

QA Engineer Tools

The basic set of tools for every QA Engineer at Cantilever includes:

Site Documentation
  • Refer to the documentation specific to your project, found in the
  • As a QA engineer, part of your responsibility is to ensure that this list is accurate and up-to-date.
  • Note: The Site Documentation functions as your QA checklist and is your best friend as a tester. It tells you exactly what to look for and what to test.
Any source material to be compared against
  • Sometimes, this may be comps on Figma, images, or even comparing different environments (IE. Staging versus Production)
Issues repository for where to report any issues may found
  • Cantilever primarily uses Asana. In rare cases, we may use GitLab or other repositories.
Task Details (provided by the person assigning the task)

As described in

, Cantilever has a template that includes information like:

  • Deadline for when the initial pass needs to be done by
  • Estimate of hours budgeted to complete the initial QA pass
  • Information on what kind of test to run (which browsers, if it’s a regression test, etc)
  • Information about what you are testing and where you are testing it (which environment, etc)
  • 🍄
    , in addition to any direct access you may have to various machines and browsers
  • Issue-Reporting template (You already have this: See below.)
Screen capture media app(s)

Suggested apps or tools that are useful for editing static screen captures or videos:

Types of Tests

You will always run one of two types of browser tests in a QA pass:

(Basic) Functionality Test

Only a single browser needs to be used. This is generally up to the preference of the tester.

Full Browser Test

Test on all browsers listed under the project's Browser Support list in a project's Dev Notes (found in the ). If there is any uncertainty on what browsers to test, simply ask the DRI!


A Word on Mobile Devices: For mobile devices, you can just check one of each type (iOS Safari and Android Chrome) unless you run into issues that you need to cross-check. This is pertinent especially for Androids: they used to be highly variant but now are pretty standardized.

Optional Testing Requested:

Regression Testing

This may be requested in either of these tests. Regression testing requests that the QA Engineer go back and make sure that no pre-existing things were broken by the newly released item.

Running QA Tests and Reporting Issues

  • Use the Project Documentation to guide testing in the appropriate browsers
Report issues clearly and in a consistent format
Ernesto (a former team member) made a really great template to use when reporting issues. Using this template is not required, but doing so provides an excellent structure for any beginner QA Engineer learning how to report issues. Anyone with TextExpander can use the following shortcodes to generate a template:
  • Shortcode for Markup Template used in Git repositories (GitLab, etc.): qatem
  • Shortcode for Template used within any repository that does not need/support markup: qatembc

Important: This template is meant to be a resource, not a rule. Fill out the sections that are pertinent to a report and delete the rest if they are not needed.

Naming/Labeling Issues

Names should toe the line between being overly generic and overly specific. It is important that issues have names that are quick to read (without being too generic) and that they convey the specificity of the issue (without being too wordy). A good rule of thumb is as follows:

  • Use the Project Documentation for noting the general area that is affected by the bug. As much as possible, refer to the Project Documentation for cues on what this area is called. List this area in brackets.
  • In as few words as possible, list the specific item that has a bug or action that needs to happen.
  • If the bug is browser-, device-, or layout-specific, add a dash and then list the specific thing.


  • Universal bug (or action item): [Area] Issue/Bug/Action
  • Type-specific bug
    • [Area - Browser(s)] Issue
    • [Area - Device] Issue
    • [Area - Layout] Issue
  1. From Project Documentation & Issues Reported:
  2. Left: Project Documentation
Right: Issues Reported
    Left: Project Documentation Right: Issues Reported

  3. From Project Documentation & Issues Reported:
  4. Left: Project Documentation 
Right: Issues Reported
    Left: Project Documentation Right: Issues Reported

A Word on Re-Testing (Fixed) Issues

It is always your judgment whether to re-test bug fixes as a functional test or as a full browser test. In most cases, a functional test is fine.

Most bugs are global and affect all browsers, therefore, a fix verified in one browser implies that it‘s fixed in all. Things that are aesthetic and not functional generally should be re-tested in a smattering of browsers though.


  • If a link is broken, that definitely only has to be re-tested in one browser.
  • If an icon is the wrong size, that’s worth looking at in a few browsers.

Browser-specific bugs should obviously be re-tested in the original browser.

Accessibility Audits

Accessibility audits are different from but related to QA tests. The purpose of an audit is to find areas where a site or feature is not in compliance with WCAG standards (WCAG AA is typically considered the threshold for "ADA Compliant"). The QA engineer may make recommendations to improve or fix these issues.

There are two different kinds of Audits:

Design Accessibility Audits

The purpose of a design audit is to find and address areas of non-compliance before they even make it to the development stage.

Related resources:

Development Accessibility Audits

The purpose of a development audit is to find and address areas of non-compliance in how the site or features function.

Related resources:

Read more about Cantilever's commitment to accessibility in
Read more about Cantilever's developing history with accessibility in

Prep for the Project Manager

Please note that a failure to properly create an assignment for the QA Engineer will result in a delay in QA testing being run. 🤷‍♂️🤷🏻‍♀️
Refer to:
a walk-through on how to create an assignment for a QA Engineer, including a list of all materials needed.
a walk-thru on what to expect during the QA phase of a project
information on which QA Engineer works on a particular project and what to do during emergencies when the QA Engineer assigned to your team is unable to test a project when needed


How to Create a QA Task