QA Guide

Documentations

We love our documents and there are plenty of them. Our documents are a crucial part of our production life cycle, they help us log our activities and tests and it helps certain member of staff to carry out certain task using certain documentation. A good example would be IA Doc stack which is used by the QA for carrying out testing, whereas the Developers will be using this doc to build the site. This is why it is important to understand not only the structure but and when we use these documents. Here is a Project documentation map to help you.

Documentation Do’s and Dont’s

Do’s

• Use templates from the Template drive

• Make sure the document is always shared with the relevant people and saved in the correct folder e.g. Shared Company Documents > Life -cycle Documents > Site access documentations

• Know your header colours right and stick to the rules:

• • Blue:Mainly used for consultancy, these types of doc’s are usually shared with the client e.g proposal, SoW

  • Green:Mainly used for production, these types of doc’s can be shared with client if required to do so.

  • Red:Mainly used for HR but can be used for any other doc’s which is for strictly internal use e.g Site access, Appraisal doc. These document’s must notbe shared with the client at any time.

• Understand what NDA stands for Non-disclosure agreement and how it might affect the way you work on a project.

• Always follow the style guide for creating new docs.

• If you're asked to create new docs e.g guides/notes send to QA for format checking before circulating with internally/client.

Dont’s

• Do not create your own templates, if you're not sure which template to use always ask.

• Do not change the format or layout of a template, those formats/layouts are there for a reason. You are always welcome to leave suggestions on how we can improve templates. Just leave a comment :)

• Do not copy from old templates in your drive, they might not be updated.

• Never share documents marked inred headers with clients.

• Never take any documents marked as NDA outside the office.

QA Terminology

QA Request (Snagging and testing)

During this phase the deliverables will be checked by only the QA officer. They will draw up a snagging list which will be sent back to the team member requesting QA. Once all the amends are made the QA officer will open the team review.

QA Team review

This is when the deliverable is cleared from the QA request snags and is opened to all team members who are working on the project for review. The team checks to see if the deliverables fit within the budget and timescale, along with any foreseeable technical issues that might occur.

A standard project will go through 4 QA phases; IA, design, build and launch, one for each deliverable.

• IA QA is for the IAand the deliverables for this phase are:

• • Wireframes

  • IA docstack

  • UML

  • Build plan

• Design QA is for thedesignsand the deliverables for this phase are

• • Designs as pngs on basecamp to the client

  • Designs in Zeplin for the developer

  • Theme plan

• Build QAis for build and the deliverables for this phase are

• • Built and themed website
• Launch QAis for site launch

Requesting for QA

Do’s and Dont’s

Do’s

• All deliverables must be signed off by QA

• Always create a thread in basecamp/Zendesk for your QA request

• Always provide with the following information for the QA:

• • User Journey/Description of what needs to be tested

  • URL of the test site

  • Login credentials for the test site(please note these needs to be sent as a sites access doc or via Lastpass)

  • What is the expected test outcome

  • Any additional information which the QA might need to know before/during testing

• Always tick in the PM and QA to the relevant Basecamp thread

• Always anticipate the time for QA before confirming deadlines with clients

• Always provide advance notification to the QA and the digital strategist if their project is about go into QA team review.

• Make sure the QA and PM has access to the Bugherd project

Dont’s

• Do not send QA requests through emails

• Do not send deliverables out to client before the QA sign off unless they are draft

• Do not send login details via basecamp/zendesk thread

• PM’s/ Account Managers should not ber equesting for QA request. These should always be carried out by the member of the production team who is working on the task

• Do not raise QA exceptions yourself, these can onlybe raised by the QA, if you need to raise an exception with the management@ for your project always let the QA know