ISTQB advanced certified experts like "Test Analyst" as well as "Technical Test Analyst" remain interested in precisely recording issues detected in their areas of operations.
A "Test Analyst" tries to approach the problem from the user's perspective e.g.
# What would this mean to the user?
# What would he do when he encounters this situation?
A "Technical Test Analyst" concentrates more on the technical aspects of the problem e.g.
# Why did it occur?
# On what platforms is it visible?
# Is it affected by environmental factors?
The above approach to software problems directly corresponds to the quality characteristics the tester is testing. If the problem is a performance issue and likely within the purview of the "Technical Test Analyst", investigation of the problem will be different than that conducted by a "Test Analyst" for a usability issue.
How the areas of "Test Managers" overlap with that of Test Analysts?
The defect reports come from the "Test Analyst" or the "Technical Test Analyst" who is performing the testing. We need to understand;
a) What a defect is? The fact remains that a defect requires a fix or some change in order to get resolved.
b) How defects are documented and handled across the life cycle?
c) How the defect-related information is used to create management reports? (Though it falls under the area of expertise of "Test Manager").
Standard Defects Management Process
According to IEEE 1044-1993, "Standard classification for software anomalies", and every defect passes through a classification process. This comprises of following four steps, each with three common activities. Here are the four steps:
Step-1: Recognition
Step-2: Investigation
Step-3: Action
Step-4: Disposition
Every step further comprises of following three activities:
Activity-a: Record
Activity-b: Classify
Activity-c: Identify impact
Following figure describes all these activities and different steps according to the IEEE 1044-1993 classification process.
Step 1: Recognition
Record: The test analyst or technical test analyst identifies a defect. The defect (also called an anomaly in this IEEE spec) is recorded by the person who found it. Information regarding the environment in which the problem occurred is also recorded at this time. Environmental information includes hardware, software, database, platform, firmware, and test support software.
Classify: The recognition of the defect is classified bellow according to the observed attributes for the defect:
# Project Activity: What was going on when the defect was found (e.g., analysis, review, audit, testing)?
# Project Phase: During what phase of the life cycle was the defect found (e.g., requirements, design, implementation, test)?
# Suspected Cause: What is the suspected culprit (e.g., product hardware, test system software, platform, third party)?
# Repeatability: How often can the defect be repeated (e.g.. one time, intermittent, reproducible)?
# State of the System: What happens when the problem occurs (e.g., system crash, correct input rejected)
# Resulting Status of the Product: What is the result of the problem (e.g., unusable, degraded, unaffected)
Identify Impact: Impact analysis occurs at this step and is re-verified at all the other steps as well. Impact analysis includes assessing the severity (impact to the system) and the priority (impact to the customer / business) as well as the impact to customer value, mission safety, project schedule, project cost, project risk, project quality / reliability, and society.
Step 2: Investigation
The analyst who identified the defect gathers further information about the defect in this step. This is where we look to see if there are any related issues. Solutions may be proposed at this time that may include taking no action at all.
Record: Supporting data items such as date received, investigator, estimated and actual start and end dates of the investigation, hours spent, and documents used in the investigation are all recorded into the defect report.
Classify: Classifying information is added based on information found during the investigation. In addition, any classification information entered in the previous step is reviewed and corrected as needed.
# Actual Cause: What is really causing the problem (e.g., product hardware, test system software, third-party data)?
# Source: What is the source of the problem (e.g., specifications, code, database, and reports)?
# Type: What type of a problem is this (e.g., logic problem, and computation problem)?
Identify Impact: The impact classification assignments previously made are reviewed and updated as a result of the investigation.
Step 3: Action
This is the step where we determine what to do with the defect. We discuss possible resolution strategies for the defect and any process or policy changes that may be required to prevent the occurrence of similar defects.
Record: At this point, we record the supporting data items, including the item to be fixed, the components within the item, a description of the fix, planned date for action, person assigned to the action, the planned date for the fix to be completed, and any reference documents affected.
Classify: Further mandatory information is added to the defect report as follows:
# Resolution: Does this problem need to be resolved and, if so, how quickly (e.g., immediate, eventual, no fix)?
# Corrective Action: Does something need to change to prevent this from happening again (e.g., departmental actions like implement training, corporate action, revise process)?
Identify Impact: The impact classification assignments previously made are reviewed and updated as a result of the action steps. Any changes made at this stage may require regression testing and retesting depending on the changes.
Step 4: Disposition
The defect moves to the disposition step at the point it is deemed to be resolved. Resolved could mean fixed, but it could also mean deferred, merged with another defect, moved to another project, addressed by a long-term corrective action, or otherwise put to rest.
Record: The appropriate supporting items are recorded for the defect. These items may include a description of the action that was implemented, the date the report was closed, the date the documentation was completed, the way in which the customer was notified, and the date of the notification and any referenced documents.
Classifying: Defects are completed using one of the following disposition classifications:
# Closed - Resolution implemented, not a problem, not in scope, vendor's problem, or a duplicate
# Deferred to a later release
# Merged with another problem
# Referred to another project
Identify Impact: The impact classification assignments previously made are reviewed and updated as a result of the disposition activities.
Summary of Defect Life Cycle – Defect Management Process
A "Test Analyst" tries to approach the problem from the user's perspective e.g.
# What would this mean to the user?
# What would he do when he encounters this situation?
A "Technical Test Analyst" concentrates more on the technical aspects of the problem e.g.
# Why did it occur?
# On what platforms is it visible?
# Is it affected by environmental factors?
The above approach to software problems directly corresponds to the quality characteristics the tester is testing. If the problem is a performance issue and likely within the purview of the "Technical Test Analyst", investigation of the problem will be different than that conducted by a "Test Analyst" for a usability issue.
How the areas of "Test Managers" overlap with that of Test Analysts?
The defect reports come from the "Test Analyst" or the "Technical Test Analyst" who is performing the testing. We need to understand;
a) What a defect is? The fact remains that a defect requires a fix or some change in order to get resolved.
b) How defects are documented and handled across the life cycle?
c) How the defect-related information is used to create management reports? (Though it falls under the area of expertise of "Test Manager").
Standard Defects Management Process
According to IEEE 1044-1993, "Standard classification for software anomalies", and every defect passes through a classification process. This comprises of following four steps, each with three common activities. Here are the four steps:
Step-1: Recognition
Step-2: Investigation
Step-3: Action
Step-4: Disposition
Every step further comprises of following three activities:
Activity-a: Record
Activity-b: Classify
Activity-c: Identify impact
Following figure describes all these activities and different steps according to the IEEE 1044-1993 classification process.
Step 1: Recognition
Record: The test analyst or technical test analyst identifies a defect. The defect (also called an anomaly in this IEEE spec) is recorded by the person who found it. Information regarding the environment in which the problem occurred is also recorded at this time. Environmental information includes hardware, software, database, platform, firmware, and test support software.
Classify: The recognition of the defect is classified bellow according to the observed attributes for the defect:
# Project Activity: What was going on when the defect was found (e.g., analysis, review, audit, testing)?
# Project Phase: During what phase of the life cycle was the defect found (e.g., requirements, design, implementation, test)?
# Suspected Cause: What is the suspected culprit (e.g., product hardware, test system software, platform, third party)?
# Repeatability: How often can the defect be repeated (e.g.. one time, intermittent, reproducible)?
# State of the System: What happens when the problem occurs (e.g., system crash, correct input rejected)
# Resulting Status of the Product: What is the result of the problem (e.g., unusable, degraded, unaffected)
Identify Impact: Impact analysis occurs at this step and is re-verified at all the other steps as well. Impact analysis includes assessing the severity (impact to the system) and the priority (impact to the customer / business) as well as the impact to customer value, mission safety, project schedule, project cost, project risk, project quality / reliability, and society.
Step 2: Investigation
The analyst who identified the defect gathers further information about the defect in this step. This is where we look to see if there are any related issues. Solutions may be proposed at this time that may include taking no action at all.
Record: Supporting data items such as date received, investigator, estimated and actual start and end dates of the investigation, hours spent, and documents used in the investigation are all recorded into the defect report.
Classify: Classifying information is added based on information found during the investigation. In addition, any classification information entered in the previous step is reviewed and corrected as needed.
# Actual Cause: What is really causing the problem (e.g., product hardware, test system software, third-party data)?
# Source: What is the source of the problem (e.g., specifications, code, database, and reports)?
# Type: What type of a problem is this (e.g., logic problem, and computation problem)?
Identify Impact: The impact classification assignments previously made are reviewed and updated as a result of the investigation.
Step 3: Action
This is the step where we determine what to do with the defect. We discuss possible resolution strategies for the defect and any process or policy changes that may be required to prevent the occurrence of similar defects.
Record: At this point, we record the supporting data items, including the item to be fixed, the components within the item, a description of the fix, planned date for action, person assigned to the action, the planned date for the fix to be completed, and any reference documents affected.
Classify: Further mandatory information is added to the defect report as follows:
# Resolution: Does this problem need to be resolved and, if so, how quickly (e.g., immediate, eventual, no fix)?
# Corrective Action: Does something need to change to prevent this from happening again (e.g., departmental actions like implement training, corporate action, revise process)?
Identify Impact: The impact classification assignments previously made are reviewed and updated as a result of the action steps. Any changes made at this stage may require regression testing and retesting depending on the changes.
Step 4: Disposition
The defect moves to the disposition step at the point it is deemed to be resolved. Resolved could mean fixed, but it could also mean deferred, merged with another defect, moved to another project, addressed by a long-term corrective action, or otherwise put to rest.
Record: The appropriate supporting items are recorded for the defect. These items may include a description of the action that was implemented, the date the report was closed, the date the documentation was completed, the way in which the customer was notified, and the date of the notification and any referenced documents.
Classifying: Defects are completed using one of the following disposition classifications:
# Closed - Resolution implemented, not a problem, not in scope, vendor's problem, or a duplicate
# Deferred to a later release
# Merged with another problem
# Referred to another project
Identify Impact: The impact classification assignments previously made are reviewed and updated as a result of the disposition activities.
Summary of Defect Life Cycle – Defect Management Process
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/11379785/viewspace-675901/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/11379785/viewspace-675901/
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
