QA Roles and Responsibilities:

QA is a set of “activities focused on providing confidence that quality requirements will

be fulfilled.”

QA Analyst

Understand the Acceptance Criteria

Actively participate in Scrum rituals

Create Test Cases(Regression, Smoke,

Feature, Integration, etc.)

Create QA Jira Tasks and subtasks

Execute Test Cases

File defects and retest

Capture Test Evidence

Follow Mobiquity’s Testing guidelines

QA Lead

Accountable for all QA activities (left and below)

Create Test Plans, seek approvals, execute the Test

Plans

Coordinate the Testing Effort

Test Suites and Work

Assignments

Approve Test Scenarios & Test Cases

Triage Defects

Produce and Socialize Quality Metrics

Provide Test Execution & Summary Reports

Adhere to Timelines

Communicate Project Risks & Blockers

Procure Test Devices

Attend Project Status Calls

Advise on Go

no

go before releases

QA Process

-

Testing Phases

One misconception in software testing is that it is often perceived as just “

Implementation

and Execution

” (write test cases and execute test cases). However, a mature Testing Process

starts with the appropriate level of Planning.

1.

Start

Project initiation Activities

Resource alignment

Access and tools setup

●

Jira

●

qTest

●

Project Wiki page

●

Test devices/equipment

●

Requirements specification document

●

Visual design document

●

Others

Summary

: Provide a

-

one

-

line summation of the actual

incident so others can understand what the incident is and

how it was discovered.

Description:

Provide thorough details on the incident. Include

any information that is not already included in the defect

summary. Avoid just copying and pasting the defect

summary in the description. Include additional information

such as:

●

Pre

-

requisites:

List any pre

-

conditions

●

Steps to reproduce:

●

Test Data:

User Credentials, Account Numbers, Roles, etc.

●

Actual result:

What you see

●

Expected result:

What you expect to see based on the

acceptance criteria

●

Test Case:

List the Test Case(s) affected by this issue

Defect

Documentation

How a defect is documented is crucial to the project.

Environment

: Provide details related to the test

environment, platform (iOS, Android, Web, Server,

etc.), build number, Operating Systems and

versions, Browsers and versions, Database version,

Device information, etc.

Attachments

: A defect must have at least one

attachment. For example: Logs, Gifs, Videos,

Screenshots, Charles Proxy sessions, cURL, etc.

Severity:

The impact a defect has on the

functionality of the application.

●

S1

-

ShowStopper

●

S2

-

Severe

●

S3

-

High

●

S4

-

Medium

●

S5

-

Low

25

25 / 30

Before

●

UAT Test Plan is up to date and approved

●

UAT Entry Criteria is met and known

issues have been communicated

●

UAT Kickoff meeting with the Client to set

expectations

●

Smoke Test cases and Test Suites are set

●

Business users are aware on how to

execute test cases and log defects

●

‘Customer Bug’ Type is used to log

customer reported defects

UAT

During

●

Run Smoke tests on every new UAT build

generated

●

QA Lead to attend daily defect triage call

●

Ensure any defect filed by the Client is indeed

a defect and not enhancement/change

requirement

●

Agree on a Severity and a Priority. Not every

Customer Bug is a P1 or S1.

●

Reproduce every defect filed

●

Retest the defect and impacted regression

after a defect is fixed

●

Share Daily Test Execution Report

After

●

QA Lead to calculate Defect Escape

Ratio (DER)

●

Share RCA Report if DER is above

Quality Goal (20%)

●

Creates UAT Summary Report

User Acceptance Testing

21 / 30