© 2012 IBM Corporation Rational Insight | Back to Basis Series Work on a Defect from QA Liu Xue Ning

© 2012 IBM Corporation

Rational Insight | Back to Basis Series

Work on a Defect from QA

Liu Xue Ning



Overall Defect Tracking Process

• Green are recommended, general state transition

• Add comments to ask question and provide answer

New

Closed

Resolved

In Progress

Resolve

Untriage

Start Working

Reopen Close

Verified Set Resolved

Triage

Reopened

Create

Triaged

Resolve

Start Working

Stop Working

Resolve

Reopen

Resolve

Start Working

Triage

Verify

Reopen

Close

Component Lead

Dev

Tester



Defect

• Fill in all mandatory Fields When Submitting a defect

• Draft the summary to describe the problem in one simple sentence

• Search for potential duplicate by click button right up.

• Check the duplication list to ensure duplicate or not. If not duplicate, continue.

• Add Found in build in the link panel

• Add attachment and / or add subscribers

• Link the work item that this defect found by the change set delivered into

• Comment with test cases id if the defect is found by test case execution

• Component Leader should triage the blocker/critical/major defect in 1 days after creation

• Fill in the cause of defect from QA perspective

• Fill in the case of defect when start working on it

• Monitor the defect status after open it. Make sure the DEV take over the defect timely

• Screen the comments added, answer questions from DEV and other stakeholders, and provide more detail information like reproduce steps, logs and others



Open Defect – What to Input in RTC

Mandatory:

• Summary: Short sentence to descripe the defect

• Type: defect

• Severity: Blocker, Critical, Major, Normal, Minor

• File Against: The component the defect related

Optional

• Description: list the detail steps to reproduce the defect

• Found in Version: release number

• Fould in Build: build number

• How Found: FVT \ SVT \ Unit Test…

• OS:

• Browser:

• DBVendor:



All mandatory Fields When Submitting a defect• Left: Original Mandatory field Right: Updated Mandatory field highlighted in

Red circle



All mandatory Fields When Submitting a defect –Con’d



Summary

• Draft the summary to describe the problem in one simple sentence

• Search for potential duplicate by click button right up.

• Check the duplication list to ensure duplicate or not. If not duplicate, continue.



Add Found in build in the link panel

• Connect to Rational Insight Private project area

• Search the build under Builds->Install-Insight-Offering

• Select the build on which you find the defect

• Drag the build number in to link panel and marked as “Add as Reported against builds”

• Tips: Dev can add the change sets about the defect resolving and the builds which delivered the fixed codes



Fill in the Fields• Select severity:

– blocker: for a blocking defect;

– critical: equals to DS1

– Major: equals to DS2

– Normal: equals to DS3

– Minor: equals to DS4

• Found in Version

– select the build stream you're testing, e.g. 1.0.0.2, 1.0.1

• Found in Build

– Input the build number

• DB

– Newly supported field

– Fill “Not applicable when it is not related with browser instead of “Unassigned”

• OS


• Browser


• File Against

– Component / subcomponent



Fill in the Fields – con’d• How Found

– The defect should be found when it is introduced. It is used to differentiate the defect founding stage to see the gap.

How Found CommentsAdHoc testing Not intention to test, found during development, daily using.Development Found during development stageFVT Found duing FVT testingGVT Found duing GVT testingBVT Found duing BVT testingSVT Found duing SVT testingUnit Testing Found duing UT testingUn-assignedAPAR Found by Customer



Fill in the Fields – con’d

• Testing Category

– It is used to differentiated the testing defect distribution.

Testing category Comments

Performance testing

Performance testing is the process of determining the speed or effectiveness of a computer, network, software program or device. This process can involve quantitative tests done in a lab, such as measuring the response time or the number of MIPS (millions of instructions per second) at which a system functions. Qualitative attributes such as reliability, scalability and interoperability may also be evaluated. Performance testing is often done in conjunction with stress testing.

Documentation Doc defectFunction Focus on Insight functionIntegration Focus on Insight/Other product integration

Robustness

Robustness has been defined by the Food and Drug Administration as "the degree to which a software system or component can function correctly in the presence of invalid inputs or stressful environmental conditions."

Un-assigned



Description

• Draft description, please include the related detailed test environment and reproduce steps

– Configuration:

– *******(OS, Application server, browser, etc.)

– ********* (problem description with several sentences.)

– Steps to Reproduce:

– 1.

– 2.

– 3.

– Expected Result: ****

– Actual Result: *****

– See attachment. (if any)

– ****** (Cause or analysis if any)



Verify and Close Resolved Work Item

RTC Fields

Purpose Roles

Close QA are only responsible for verification of defect and enhancement. Task should be closed by Dev self.

The QA assigned to verify the work item is set using the Verified By field.

If pass, Close the work item, Input the build ID which you used to verify defect in Discussion field

By default, work item submitter should be responsible for verification after work item resolved.

When closing a defect QA must validate it in the original configuration that the defect was reported. If you validate it in an additional configuration, provide this information in the Discussion field

When closing a defect which no test case covered, add new test case to test suite to avoid regression problem, or revise current test case, add verification point accordingly

QA

Reopen If failed, Reopen work item, post the build ID in Discussion section. Dev



Resolve a Work ItemIn

Progress

Resolve

ResolvedDeveloper

RTC Fields Purpose Roles

State Select Resolved from the State property drop-down list.

This action should only be taken once the code change has been checked in and delivered to the build stream and component build included the fix. The owner of the defect should remain with the developer who resolved it.

Resolve comments should be filled

Owner

Resolution Choose one of the resolution from drop-down list.

“Duplicate” need to specify the work item duplicated in links section.

“Won’t Fix” indicate that this is an issue but won’t be fixed for some reason.

“Works for Me” means it works as designed

“Invalid” indicate that it is an invalid defect

Owner

Time Spent Fill in the total time spent on this work item. Owner

Discussion Enter a comment in the Discussion section that further explains your actions, including (a) Resolution of this work item (b) How to verify the fix if developer think QA may not know it

Owner

Release Note Mark it as Needed if this work item needs to be recorded by technote Owner/CL/QA

Root Cause If resolution data is later than due date, Owner need to fill in questionnaire for root cause analysis.

If close data is later than Iteration end date, Verifier need to fill in questionnaire for root cause analysis

Owner/QA

Documents

© 2012 IBM Corporation Rational Insight | Back to Basis Series Work on a Defect from QA Liu Xue Ning