CreativeTech Wiki (internal)

Explore

Processes

QA Checkpoint Process

The QA Golden Rule

All work must go through the internal QA process before going to client.

How the QA Checkpoint Process Works

CHECKPOINTS: Each part of the work process has a testing step.

EVALUATE: All work is evaluated against a

QA Checklist⁠

and must pass our fundamental ad requirements at each internal step.

PROMOTE/DEMOTE: After work is evaluated, the work can be promoted to the checkpoint OR demoted back to the start of the process.

The Testing “flow”

⁠

Fundamental Ad Requirements

Functionality — The ad unit meets the criteria of the Jira ticket and the standards of the design.

Performance — The ad unit meets basic size/speed performance standards.

Accessibility — The ad unit meets

WCAG accessibility standards⁠

Checkpoints

Checkpoint 1 — Developer Testing

All devs are required to test their work before it is checked by any other testing resource. (It is a developer responsibility to release stable, working code. The developer is not to conflate the development and QA processes and use QA to find flaws in software.)

The developer should use the

QA Checklist⁠

for reference. You do not need to send or attach dev QA results to anything.

Once the ad passes developer testing, the developer must:

leave QA Notes on the Jira ticket;

AND, promote the ad to the next step. This can be done informally at standup, via Slack or on the Jira ticket.

Checkpoint 2 — Internal Testing

A tester is provisioned by the developer.

The tester should use the

QA Checklist⁠

If the ad passes internal testing, the tester should paste the Checklist link onto the Jira ticket and inform developer that the code has passed QA.

If the ad passes with minor changes, the tester should paste the Checklist link onto the Jira ticket, inform the developer and the developer needs to ensure minor issues are addressed and can promote the ad to the next step without re-engaging a tester.

If the ad fails with major changes, the tester will send the ad unit back to the developer for code revisions and then entire process must restart.

Once the ad passes internal testing, the developer must:

leave notes on the Jira ticket if applicable;

AND, promote the ad to the next step. This is done through communication with the external stakeholders.

NOTE: As changes occur as a result of testing, keep updating the QA doc until it passes.

Checkpoint 3 — External/UAT Testing

After the ad has been promoted to the external stakeholders, the next set of QA responsibilities lies on that external team. External teams are responsible for their own testing processes and standards.

It will be the responsibility of the developer to follow up regularly for status updates on work if that team is not already providing updates.

InfoSys is an “external” QA resource, and in a case where we choose to use them, the work should be internally tested first. That work would then be sent to external stakeholders.

The TIGHT DEADLINE RULE

In the cases that deadlines are tight, internal testing cannot be skipped BUT the developer may send an ad to both Checkpoints 1 & 2 at the same time. Regardless of external approval, you must get internal approval to go live.

QA Evaluation Guidelines

The developer is in charge of moving their work through the QA process AND ensuring that the work meets our internal standards before delivering work to external teams.

The developer must provide QA Notes in the comment section on each Jira ticket and include the following: summary of changes (if applicable), development issues, ticket inconsistencies, and potential issues.

At each QA creativeTECH checkpoint (dev and internal), the work must be evaluated against the

QA Checklist⁠

AND Browserstack.

At each QA creativeTECH checkpoint, if work is demoted with major changes the work must go through the entire process again. Minor changes can be promoted to the next step with changes at the discretion of the person performing QA.

If there are extensive External QA requests, please get external approval of changes before putting restarting the Internal QA process.

Testing notes must also be placed on each Jira ticket or as comments on the QA Checklist. If notes are communicated outside Jira, please copy/paste notes OR link to ticket.

Promotion/demotion of work must be indicated on ticket.

Notes

MAKE TESTING BETTER: All developers have editing access to the QA checklist. Add QA items that are missing.

The QA Golden Rule

How the QA Checkpoint Process Works

The Testing “flow”

Fundamental Ad Requirements

Checkpoints

Checkpoint 1 — Developer Testing

Checkpoint 2 — Internal Testing

Checkpoint 3 — External/UAT Testing

The TIGHT DEADLINE RULE

QA Evaluation Guidelines

Notes

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.