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

‣

A More Details View of the QA Process and Stages

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

🧷QA Engineers and Emergencies

♿Accessibility

How to Perform an Accessibility Audit for Design

📓Handbook