QA & Project’s Lifecycle

QA & Project’s Lifecycle

Important Concepts


This document details how QA Engineers interact with the process of creating a new build, but can also be applied to Support Projects. Project Managers are especially encouraged to read this.



QA Engineers are per-project, not per-team.

  • QA engineers are assigned to a project once the client signs off and the project begins.
    • Project Managers should report new projects to the Head of the QA Department so that schedules and availability of all QA engineers can be considered before a QA engineer is assigned to a project
  • This gives QA a chance to quip any concerns at the kickoff of a project, as well as just adding it to our schedules so everyone else knows who's got room for more testing.
  • QA Engineers have access to all projects within Cantilever so that we can easily cover for one another in case of emergency. However, QA Engineers unsubscribe from projects that they are not the Lead on so as to minimize unnecessary inbox notifications.
    • If a support or substitute QA engineer is needed to work on a project, the engineer must be tagged within a to-do comment thread to be notified of being needed within project. It would also be good practice to send them a message to ensure they've seen the assignment.
    • QA Engineers are also encouraged to check their List of Assignments to be aware of any tasks that may pop up unexpectedl

Design Audit


QA Engineers work with the lead designer and have access to Design Resources while design and assets are getting built.

  • This is the bulk of the design accessibility audit phase, and is looking less like a single-trip audit and more of an oversight.
  • The goal here is that QA can red flag any design choices that are liable to become accessibility problems later, both in the sense of "this is a WCAG violation, can we redesign it", and "a note about this needs to be passed on to developers to make sure X and Y practices are done".
  • This is probably not going to be perfectly smooth the first time, but this really seems to be the best place to spot issues before they become problems.

For more information on how to actually run a Design audit, refer to:

Creating Site Documentation

QA Engineers will help highlight anything that needs special attention in QA documentation.

  • The developer writes the initial Project Documentation
  • If the developer for a project is pressed for time, the QA Engineer for a project may help them write up the checklist for the things that are intuitive.
  • Any time a feature is changed, the developer making the change should update the documentation and checklist as well.
  • Updating QA Documentation is an ongoing process and will continue into the QA phase of the project — often by the QA engineer on a project. It is important to note whitelisted behaviors that might otherwise seem like bugs so as to prevent non-issues from being reported multiple times. (This is especially pertinent if a project is passed from one QA engineer to another.)



Once a project reaches development, it's familiar territory: Things are developed, we do development QA pass - ideally with our new access procedures in there too - fix, review, deploy, party; if the project is a new build, see you in support. Here's what that looks like:

Assignment of QA Tasks During Project Cycle

The cycle of QA tasks required should look something like the following:

  1. Initial QA task: Assigned to QA Engineer
  2. Fixes for bugs found during initial QA: Assigned to Developer
  3. Review fixes of bugs found during initial QA: Assigned to QA Engineer

Steps 2-3 will likely involve a lot of passing back-and-forth of issues. It is recommended that the PM assign "Bug Fixes" to both the Developer and QA Engineer.

QA Process and Stages

  1. The QA engineer is assigned the QA task.
  2. The QA engineer reports issues and assigns them to be fixed.
  3. The developer either fixes the issue or marks it as a non-issue and then passes it back to the QA engineer. Non-issues should be explained why they are not issues.
  4. The QA engineer's next task depends on the developer's response to the reported bug:
    1. If the developer fixes the issue, then the QA engineer verifies the fix.
      1. If the bug has been fixed, the QA engineer reports that the fix has been verified before closing the task.
      2. If the bug remains, then the QA engineer reports as such and passes it back to the developer.
      3. This repeats itself until the issue is verified as fixed.

    2. If the developer whitelists the issue, then the QA engineer makes note of it in the pertinent section of the Project Documentation. The update is reported in the thread of the issue before the task is closed.
      1. The QA engineer may assign the task back to the developer if they need their documentation entry to be reviewed. If the developer approves of the entry, then they can close out the task. If the entry needs to be revised, then it needs to be passed back to the QA engineer and updated before the task can be closed out. That being said, there are times when it might make more sense for the developer to provide the revision.

Issues should not be closed until the QA engineer has verified a fix or updated the Project Documentation. In rare circumstances, if/when a QA engineer is not available, these may be done by a developer or project manager.