Qa Standard Operating Procedures (Sop)

You might also like

Download as pdf or txt
Download as pdf or txt
You are on page 1of 3

QA STANDARD OPERATING PROCEDURES (SOP)

Scope Appraisal
1.1 Review client Requirement
1.2 Learn the Software Application
1.3 Prepare Function Decomposition
1.4 Prepare Screen Hierarchy
1.5 Prepare workflow Diagram
1.6 Identify the vulnerable modules
1.7 Estimate the efforts involved
1.8 Allocate the Resources
Environment Setup
2.1 Identify the environment types

Operating Systems
Browsers
2.2 Analyze the process involved

Online QA
Offline QA
2.3 Review the client Instructions
Bug Reporting
External Bug Reporting
Internal Bug Reporting
Test Case Management
External Tool
Internal Tool
Documents Repository
External Location
Internal Location
QA Daily Cycle.
3.1 Segment the list of Regression Test cases
3.2 Sequence the Regression Test Cases

Module by module
Release / Client Priorities
3.3 Identify Bugs
3.4 Prioritize Bugs
3.5 Report Bugs
3.6 Write Test Cases
3.7 Record Test Case in Test Case Repository
3.8 Record the steps to reproduce to accompany the bug
3.9 Associate Test Case to the Bug
3.1 Summarize and Classify the bugs
New Bugs
Reopen Bugs
Closed Bugs
Need More Clarification Bugs
Assign new bugs to the developer
Daily Status Submission.
4.1 Report the QA Status

Email
Scrum Meetings
4.2 Report QA Team Members worked
4.3 Report the QA Environment tested
4.4 Report Bugs summary with classification
4.5 Defend the New bugs discovered
4.6 Explain why the items require more information
4.7 Provide the path of the recorded videos
QA Team Status
5.2 Consolidate and report the list of bugs identified
5.3 Summarize and classify the bugs
5.4 Report which module is vulnerable to defects
5.5 Report which bug is repeating in every cycle
5.6 Status of the QA Cycle
5.7 Number of unresolved items
5.8 Any suggestions or comments on the applicationMonthly Summary for invoicing
6.1 Number of cycles executed
6.2 Number of Environments tested
6.3 Number of Test Cases Executed
6.4 Number of New bugs identified
6.5 Number of Bugs Reopened
6.6 Number of Items that required clarification
6.7 Number of Bugs closed.
6.8 Modules that is found vulnerable
6.9 Present Application Status
Client Acceptance and Sign off.
7.1 Prepare QA Report
7.2 Prepare Bug Status Report
7.2.1 Number of new bugs

A part of the QA team will do regular QA testing and when they find any bug that are not
reported so far, they will report as new bug. The QA team will also write a new test case and
record that test case in the test case management tool and Associate the test case with the
bug.
7.2.2 Number of reopen bugs

When the QA team tests every test case that is recorded in the test case management
application likes Zephyr or Testopia and if they find that the bug is still open, the team will
record a supporting video that that the bug is still open with the version of the application,
include proper comments / description for the bug and mark it as Reopen.
7.2.3 Number of closed bugs

When the QA team tests every test case that is recorded in the test case management
application likes Zephyr or Testopia and if they confirm that the bug is closed, the team will
record a supporting video that the bug is closed, include proper comments / description for
the bug and mark it as closed.
7.2.4 Number of unresolved items

The number of unresolved items is the total number of bugs that are still open that is needed
to be addressed by the developers. The unresolved items will be listed with their severities so
that the severity statistics will help the client to estimate how much effort will be still required
by the development team to close the unresolved items.
7.2.5 Number of items that required more information

During testing, the QA team will review each item and if any item requires clarification it will
be flagged under needs more clarification. Once the developer or the QA person who
reported the bug provides clear instructions with steps to duplicate the bug, the bug will be
tested and marked as reopen or closed.
7.3 Application Status
7.3.1 Comparison of the bugs reported every month

A comparison report of the bugs for each month with their classification severity will be
prepared and submitted to the client in order to give a clear understanding on the application
status. If the average number of bugs are the same for every month for a long time, it means
that the application needs more attention to release.
7.3.2 If the bugs are less than the previous month, the code is getting hygienic.

The QA team will prepare a complete age wise comparison report, broken down into various
modules and the number of bugs in each module with the classification of bugs. This
comparison will give a clear picture about the code hygiene. If the number of bugs decreased
from the beginning of the QA, it means that the code is becoming hygiene and the QA team
will also suggest enhancement and features for the application. If the number of bugs are not
under acceptable criteria, it means that the code needs to be standardized and the application
needs more attention.
7.3.3 Modules that are vulnerable

The QA Team, since they have already worked in the entire application and has a complete
understanding on the application, based on their experience, the team will list the modules
that are more vulnerable. If possible the team will also suggest the remedies.
7.4 Client meeting
7.4.1 Defend the new bugs reported and their classification
Initiate Next Cycle.
8.1 Deallocate the resource and Prepare the team for next QA cycle

You might also like