Defect Management

Defect Management Process

The primary goal of Defect Management is to detect and track the defects to closure, implementing the processes required for coordination between the teams for the defect prevention and defect closure. The Defect Management Approach defines

Defect Triage and Prioritization Process

o Stages of Defect

· Defect Discovery

· Defect Resolution

· Defect Tracking

o Defect Discovery

· Find a Defect

· Report Defect

· Acknowledge Defect

o Defect Resolution

· Prioritize: Determine the importance of fixing a particular defect.

· Categorize: Classify defects with end users.

· Fix: Developers fix defects in order of importance.

· Report: Developers notify all relevant parties how and when the defect was repaired.
Defect Tracking

§ Monitoring Defects from the time of recording until satisfactory resolution has been determined
Prioritization Process



Priority

Label

Description

Priority1

Critical

Priority 1 defects prevent the operation of the Site or Application


Priority2

Major

Priority 2 defects limit the ability to operate the business efficiently but a Loblaw’s approved workaround is defined.


Priority3

Minor

Minor defects that do not significantly affect the operation or appearance of the Sites.


Priority4

Trivial

Cosmetic defect which do not affect the flow of the workflow.


Table 4.1 Proirity

4.2 Defect Management Process



Figure 4.3 Stages of Defect



4.3 TEST STATUS REPORT
4.3.1 Daily Status Reports

The daily reports would be made by the testers which will be consolidated and submitted to the client. In these reports we would be updating the client regarding the daily proceedings with the various test cases i.e. which have been executed, which have not been executed and what all would be done on that day
4.3.2 Weekly Status Reports

These reports would be submitted by each track lead which would update the client regarding the work done on each of the tracks
4.3.3 Application Health Check Report

This would be submitted by the QA Manager telling the big picture regarding the overall work done.

4.4 OVERALL COMPLETION CRITERIA FOR TESTING



Figure 4.4 Completion Criteria

A critical aspect of monitoring the progress and acceptance of the end result of Testing for the Version 1.0 will be a clear understanding and agreement on completion criteria.

One key aspect of this is the successful identification and resolution of issues/defects.

Issues/defects are categorized as follows:

CRITICAL:

Causes system to crash or does not support critical functional requirements tied to Key Performance Parameters. No acceptable work-around. Unable to demonstrate completed business scenario.

HIGH:

Causes significant system degradation or a difficult work-around to support critical functional requirements tied to Key performance Parameters. Business scenario can be completed with difficulty.



MEDIUM:

Causes moderate system degradation or a work-around to support critical functional requirements tied to Key performance Parameters. Business scenario can be completed with moderate to minor impact to business process.

LOW

Causes minor system degradation or minor work-around to support critical functional requirements tied to Key performance Parameters. Business scenario can be completed with minor to no impact to business process.



Completion criteria for Pre-System Test have been established as following:

· Each business Test Case exercised

· Each required conversion, interface and enhancement completed

· No CRITICAL unresolved issues/defects, may allow HIGH if necessary, but have

· an action plan.

· Action plans exist for remaining HIGH, MEDIUM and LOW issues/defects

· Security and Privileges(Profiles) established and tested

Completion criteria for System Test have been established as following:

· Each business Test Case exercised

· Each required conversion, interface and enhancement completed

· No CRITICAL, HIGH and MEDIUM unresolved issues/defects remain

· Action plans exist for remaining LOW issues/defects

· Security and Privileges (Profiles) established and tested

Completion criteria for Beta Test have been established as following:

· Each business Test Case exercised and

· Each required conversion, interface and enhancement completed

· No CRITICAL, HIGH, MEDIUM and LOW unresolved issues/defects remain

· Security and Privileges (Profiles) established and tested

Business Users

A non-Sapient employee who serves as an independent observer/assessor of the system during testing. While acting as a Business User, the person represents others with the same functional specialty and provides input from that perspective. Input includes functional issues, any other business requirements and other documentation, and overall assessment of the system.

Business Users will be assigned to scenarios and testing sessions based on their skill set at Mercury Tours.

Changes

Changes to any of the testing documents will be done at the end of each testing cycle.

The only exception to this will be in the event of a change request event or change that is needed.

Test Scenarios

A test scenario is a string of business processes, which lead to an expected outcome.

Changes to the Test Scenarios must be submitted by the test team member to the Test Team Manager for signoff.

Communications

Communications between the entire Test Team and Mercury Tours POC is critical during testing. There may be many activities going on at one time and all resources will be called upon to assist in the successful execution of all testing cycles. It is everyone’s responsibility to review the issues database for progress on issues related to testing.

Testing Tool:

The following tools should be provided to the QA Team prior to commencement of testing:

1. Defect Logging and Tracking tool: Quality Center or JIRA

2. Selenium For Functional and Regression Testing



3. Apache Jmeter: For Load Testing.