An sound error management process ensures maximum efficiency for defect recognition and resolution during software development and deployment to production.
Objectives and Benefits
- Maintain a defect tracking system to reliably monitor defects and fixes.
- Preserve a history of defects and their fixes.
- Ensure prompt and efficient identification and notification of defects
- 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:
- Development team leader
- Project manager
- QA team lead
- 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:
- A user is unable to complete a transaction because of a consistent crash during processing
- 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:
- A value that is not defaulting correctly must be input manually.
- 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