QA & Project’s Lifecycle
♻️

QA & Project’s Lifecycle

Important Concepts

Overview

💡
Project Managers are especially encouraged to read this.

This document details how QA Engineers interact with the process of creating a new build, but can also be applied to Support Projects.

A summary of the basic life cycle for a new project generally follows:

  • Lay Foundation (Prep for the Project)
  • Design (and Design Audit)
  • Create Site Documentation
  • Development
  • QA
  • Launch
  • Support (or Closure)

Accordingly, this article will walk through most of those steps from the QA engineer’s perspective.

☝
For an actual description of the build process, refer to

Foundation

🔑
As mentioned in
🧷
QA Engineers and Emergencies
, QA Engineers are per-project, not per-team.
  • QA engineers are assigned to a project once the client signs off and the project begins.
    • When a new project starts, the Strategist and PM on the project determine who the lead QA Engineer will be.
    • Ideally the QA engineer should be involved as early as Discovery, so they know what they will be checking when, and understand the full context by the time they start testing stuff.
  • 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 unexpectedly.

Design Audit

In the drive to make the internet hospitable, Cantilever strives to make websites that are accessible. Given that most accessibility problems start in design, Cantilever performs Accessibility Audits within this phase of a project so that we can identify and fix potential accessibility barriers before the designs are even approved.

🦄
QA Engineers work with the lead designer and have access to Design Resources while design and assets are getting built.
  • The goal during a Design Audit is that QA can 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:
    How to Perform an Accessibility Audit for Design

Creating Site Documentation

🐉
QA Engineers will help highlight anything that needs special attention in QA documentation.
  • The UX Designer writes the initial Project Documentation
  • Anyone in charge of writing the documentation is free to delegate some part of that responsibility to others. QA Engineers can especially be useful in writing up a checklist of expected behaviors that seem intuitive.
  • Any time a feature is changed, the developer making the change should update the documentation and checklist as well and then pass it to the QA Engineer for review or visa versa. (If the QA Engineer makes a change to the documentation, the Developer should be brought in to review the change.)
  • 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.)

Development

Once a project reaches development, it's familiar territory: Things are developed, we do a development QA pass that includes checking for accessibility - fix, review, deploy, party; if the project is a new build, see you in support.

QA

Here are two explanations breaking down what the QA Process looks like according to who gets assigned to what, and what people are expected to do.

‣

Assignments of QA Tasks During the 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 OR Update documentation regarding whitelisted issues: Assigned to QA Engineer
☝
Steps 2-3 may involve a lot of passing back-and-forth of issues. Refer to ‣ for the actual nuts and bolts of how this happens.
‣

A More Details View of the 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.
      • If the bug has been fixed, the QA engineer reports that the fix has been verified before closing the task.
      • If the bug remains, then the QA engineer reports as such and passes it back to the developer.

        • 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.
      • 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.

Launch

For new builds or larger projects that are getting released, the QA Engineer is often present for the launch.

  • The QA Engineer tests various areas on what is being launched
  • There may be specific pages, behaviors, visuals, or regression testing that the QA Engineer is tasked with checking either during or after a launch

Support

Tasks within the Support realm of development often look like a more truncated process of that which is used for a new website.

  • Any designs are reviewed by QA for accessibility, continuity with the website currently live on Production, or anything else specifically requested
  • Site documentation must be maintained and updated as appropriate
    • A proactive approach to maintaining the documentation for a project is important to prevent design creep
  • QA Engineers review development updates to make sure they match any comps, exhibit expected behaviors and functionalities, and again address any accessibility issues
  • Once all issues are cleared (via either fixing the bug or updating the documentation), the update is pushed to Production

References