Error Management in quality testing

An sound error management process ensures maximum efficiency for defect recognition and resolution during software development and deployment to production.

Objectives and Benefits

  1. Maintain a defect tracking system to reliably monitor defects and fixes.
  2. Preserve a history of defects and their fixes.
  3. Ensure prompt and efficient identification and notification of defects
  4. Provide timely fixes and deployment

Workflow Diagram: Defect Tracking

Error Review Team

The above workflow addresses only defects that are identified during development; it does not address the identification and resolution of production defects that are reported to or discovered. Production defects are errors that are identified in “live,” released software.

Because these defects hold high priority and need the most attention, an error review team (ERT) must be assigned to all live products. An ERT provides a prompt and efficient response to defect recognition in a production environment and ensures a timely resolution. The team will consist of the following members:

  1. Development team leader
  2. Project manager
  3. QA team lead
  4. Client representative

ERT Plan of action

When a defect in a production application is reported, the project ERT executes the following plan of action within four hours from the time the bug is reported:

1. All members of the ERT team are notified as soon as the defect is reported.

2. An immediate meeting is called with ERT and the client to discuss the details of the error, the environment, and the steps necessary to reproduce the defect. Known errors are reviewed to ensure that the defect is not a duplicate.

3. The defect is reproduced in-house or in a staging environment.

4. If valid, the defect is entered in the defect tracking system as OPEN.

5. The client is notified of the validity of the error.

6. Prioritization of valid errors is conducted.

7. Appropriate developers are notified.

8. A short-term resolution is discussed. (“How can we get the system functional ASAP?”)

9. A long-term resolution is discussed. (“What permanent changes need to implemented to prevent errors like this?”)

10. Client is contacted with the short- and long-term resolutions and the timelines.

11. The short-term resolution is implemented (Defect is marked FIXED in defect tracker with the resolution). Upon verification of the defect fix, the defect is marked as VERFIED and deployed to production. Upon successful deployment and confirmation from the client, the defect is marked CLOSED.

12. Long-term resolution is implemented, verified, and deployed.

Verification and Classification of Errors

The ERT plan of action calls for the team to classify and prioritize the error once it confirms the validity of a production defect. Valid errors will be classified as follows:

Critical: a serious error that is either a showstopper or of such importance as to radically affect the functionality of the system. Examples include:

  1. A user is unable to complete a transaction because of a consistent crash during processing
  2. Incorrect data is being passed resulting in heavy corruption or system crashes

Major: an error where a less important element of functionality is affected, or data which does not have a major impact is corrupted or lost. Examples include:

  1. A value that is not defaulting correctly must be input manually.
  2. A process is not being completed as intended, but there is an alternative method of completing the process

Minor: a minor error that does not hinder functionality. These types of errors are mainly cosmetic bugs.

Once the defect is classified and the development team has been notified, developers should provide a fix for “critical” errors within 24 hours. This is the turn-around time from when the defect is discussed at the ERT review meeting to when fix is released to the system test environment. (In the event that a critical error prevents the system from functioning, the turn-around should be significantly less.) ”Major” errors should be turned around in 36 hours; and ”minor” errors should be turned around in 48 hours.

RELATED POST
SOFTWARE QUALITY ASSURANCE AND CONTROL

SOFTWARE QUALITY AND COST ASPECT

STABLE PROCESS OF SOFTWARE TESTING

STABLE PROCESS OF SOFTWARE TESTING PART TWO


DEFECTS IN SOFTWARE TESTING

REDUCTION OF DEFECTS IN SOFTWARE TESTING

SOFTWARE TESTING AND EFFECTING FACTORS

SCOPE OF SOFTWARE TESTING

TESTING LIFE CYCLE PART ONE

TESTING LIFE CYCLE PART TWO

TESTING LIFE CYCLE PART THREE

SOFTWARE TESTING AND CONSTRAINTS WITH IN IT

TESTING CONSTRAINTS PART TWO

LIFE CYCLE TESTING

TEST METRICS

Independent Software Testing

Test Process

Testing verification and validation

Functional and structural testing

Static and dynamic testing

V model testing

Eleven steps of V model testing

Structural testing

Execution testing technique

Recovery Testing technique


Operation testing technique


Compliance software testing technique

Security testing technique
Here i am adding the further topics list on software testing subject and the topics may be scattered and you can find under different groups.

MAJOR SYSTEM FAILURES IN THE HISTORY

WHAT IS A SOFTWARE BUG ?

ROLE OF A TESTER

SOFTWARE TESTING INTRODUCTION PART ONE

TESTING INTRODUCTION PART TWO

TESTING INTRODUCTION PART THREE

TESTING INTRODUCTIONS PART FOUR

SOFTWARE TESTING FUNDAMENTALS

SOFTWARE TESTING FUNDAMENTALS PART TWO

SOFTWARE TESTING FUNDAMENTALS PART THREE

No comments:

Post a Comment