Theme

QA Process & Procedures

Written by

in

(синяя звезда) Overview

The QA process in development is an important step to ensure the quality and functionality of a product.
It involves testing and verifying that the product meets the specified requirements and specifications.
This documentation provides an overview of the QA process including PM, QA, Dev responsibilities.

(синяя звезда) Preparation for the Project’s start (pre-development stage)

  • QA should be assigned to the Project as a dev team by PM, i.m.
    — Added to the Project’s group chat/channel in the Slack
    — Added to the Jira Project
    — Added to Time Doctor
    — Involved in the Estimation phase, QA time should be added to the separate column in the Estimation file

Estimation should include time spent on preparing QA & PM’s documentation

  • PM should create Project Passport & Requirements documentation

  • PM should discuss with the Client his preferences regards QA Approaches & Supported browsers and devices and pass it to the QA
    (Examples (синяя звезда) )

QA Approaches (examples):

  • Fully design matching – all elements are a must, fonts, global styles, sizes, spacing

  • Design-based testing – spacings are valid up to X1.5, elements can be excluded/changed/replaced, global styles should be followed, this approach needs additional discussion with PM to define the detailing level of testing

  • Based on the above information, QA should prepare QA Documentation (Supported browsers and devices, Test Strategy, Test Cases*, Bug Report Instructions) in the Confluence Project’s space
    *Test Cases is a new procedure, which would not be applied to all project just yet

Supported browsers and devices, Test Strategy documentations should be approved by PM, each team member & Client as well*
* It’s PM’s responsibility to bring & present it to the Client

  • PM should add all tasks divided by Epics/Stories describing main functionalities of the project
    — All Issue details should be written in English and well described
    — For all Issues, where it’s needed, should be added Acceptance criteria in the “QA Scope” field
    (Examples)

(синяя звезда) Development + QA stages

  • QA should test the whole Epic/Story, when FE+BE is completed (avoid FE or BE testing first – required for the new Projects, which were done from scratch), in the all other cases (Support, CR, specific functionality) – Task/Epic/Story

  • After Task/Epic/Story is completed and initially tested by the Dev, Dev (in some cases PM) should assign it for the QA and change status for “Ready for Testing / QA“

  • All Bug tasks should be created by the example of this template and linked to the certain Task/Epic/Story

  • After the Bug is fixed, it is tested once more by the Dev, and afterwards sent to QA for Bug verification

  • After the testing is successfully done, Task/Epic/Story should be transferred to the “QA Approved“ status by QA

  • The Task/Epic/Story could be considered as “Done”, when it’s uploaded to the production by Dev

  • For all Issues in status “Done“, the verification on production is a MUST
    QA could use Regression or Smoke testing on production depending on Project needs

(синяя звезда) General Communication orders:

  • Daily meetings w/ team, including QA

  • Retrospective after each Sprint, once in 1-2 weeks (depends on project’s needs)

  • Priorities of Projects for testing should be communicate each week on the PM meeting / Workload planning or directly in the #pm channel during the week by PM

There should be not more than 2 projects for the QA a day to test

// Should be added to Test Strategy template for OneLine projects

For all ONELINE projects, make sure that the information about CHE IT is deleted, i.m.

  • Information about devs, check site – here

  • Personal emails in the contact form configurations, admins emails

  • Names of users in the admin panel

Comments

Leave a Reply

More posts