Documente Academic
Documente Profesional
Documente Cultură
http://cheyat.com/qa/hp-alm-onli
ne-training-tutorials
Why Testing
Traditional tools
used for test
management
include:
Benefits
ALM Stakeholders
Project
Track release progress
Managers
Visibility into key project milestones
Development
Improve developer efficiency
Team
Dashboar
d
Defect
Business
Define
Analysts
and track multiple requirement types
Bi-directional traceability from requirements to
requirements, tests and defects
Leverage existing assets in MS Word
Testing Team
Create test cases to adequately test the requirements
Requirements Module
Domain
Projects
Root Folder
AFG_Projects
_ All
<LOB>_<Pr
oject
ID>_<Projec
t Name>
Project
Name
AFG_ RFC_
All
<LOB>_<RF
Cs>_<Year>
RFC_LOB_20
15
Jan
Sub Folder
Req 1
Root Folder
Project A
RFC_LOB_20
15
RFC N
Bug
Fix_LOB_015
Jan
Bug
Fix_LOB_015
Bug Fix 1
Bug Fix N
Bug Fix 1
Dec
Bug Fix N
Reporting
Defects
Reporting
Test case N
Defects
Reporting
Regression
Test case N
Dec
<LOB>_<Bug
Fix&
Routine>_<Ye
ar>
Defects
Test case 1
Regression
Test case 1
RFC N
RFC 1
AFG_Bug
Fix
&Routine_
All
Test case 1
Reporting
module
Test case N
Req N
RFC 1
Test Case
Defects
module
Test case 1
Test case N
Regression
Test case 1
Regression
Test case N
Defects
Reporting
Test Planning
Test Execution
Automation Testing
HP ALM 12
SOLMAN
Business
Processes
Test Objects
Requiremen
ts
Test Results to
SOLMAN
Defects Module
Defects to
process in
SOLMAN
Manual Feed or
Import from Excel
Req/Test cases
Test
Requirements
Test Cases
Test sets to run
Test Results
Defects
SAP TAO
Component based
Automation
HP UFT
Test Automation Tool
HP Sprinter
Manual Testing
HP ALM
Assign
responsibili
ty to SAP
SOLMAN
New
Forwarded
New
Received from
HPQC
Fixed
Proposed Solution
Closed
Confirmed
Defect Workflow
Project
Project Background
Background
Client
Client Requirements
Requirements
Cognizant
Cognizant Solution
Solution Approach
Approach
Cognizant
focused
on
deploying
integratedQuality
Facilitate
collaboration
communication
between
distributed teams
and
multiple,
defects earlier in the lifecycle when they are less costly to fix.
quality throughout the lifecycle, the result would lead to a fewer
issues in production and faster time to delivery.
The implementation allowed the Clients to prioritize testing
application releases.
Benefits
Benefits achieved
achieved using
using HP
HP ALM
ALM
Business
Business Benefits
Benefits achieved
achieved
The
Client
was
able
to
minimize
Top
Top New
New Features
Features in
in
ALM
ALM
Project Planning & Tracking
Requirements Templates
Project/Template Reports
Traceability Matrix
Embedded Web Scorecards &
Graphs
Business Process Modeling
Integration
Test Configurations
Defect Categories
Category
Defect
Issue
New Req
Description
When a defect is logged its categorized as Defect by default. It states that the defect is considered to be
analyzed and fixed for the current release
When a defect is identified and after reviewing ,it has few dependencies to be verified like test data, test
steps to be carried etc. hence the defect will be categorized as Issue
When a defect is logged in which the test carried to related to that defect is not mention in the requirement.
Then the defect is considered as a New Req and it goes through the Change request process as AFG we
following today.
Responsibility
Target Owner
New
Tester
Test Lead
Description
Tester/Business tester creates a defect during testing; the initial status of the defect will be in New status.
The New status defect will be assigned to Test Lea d for the Defect triage or analysis.
Pending
Rejected
Test Lead
Test Lead
Rejected
Test Lead
Test Lead
Deferred
Test Lead
Test Lead
Assigned
Test Lead
During defect meeting when the defect analysis results in to that the defect is not a valid one then test lead
changes the defect to Pending Reject status for the further discussion with the Functional team or Business
team.
Test lead will change the status of the defect to Rejected in following conditions:
Defect analysis results in to the decision that the system works as expected and its an invalid defect
Tester mistakenly logged a duplicate defect that was already raised, in case of duplicate defect; the new one is
marked as Rejected and if any useful information from the new defect is copied over to the old defect.
Test Lead will Defer a defect when it is analyzed and
Functional/DEV
team
Test Lead
Fixed
Functional/ DEV
team
Test Lead
Retest
Test Lead
Tester
Reopen
Tester
Successfully
Tested
Tester
Test Lead
Closed
Test Lead
NA
When a New defect is created by tester and it is considered as a valid defect, then the Test lead will assign to
the concern team (developer/Functional SME) and then the status will be changed to Assigned.
New defects will be picked first during the defect triage to decide the assignment.
Once the Defect is assigned to the Functional SME or the developer then they will look the defect and if any
clarification required on the defect then the clarification can be mentioned in defect comments and assign
back to the tester/test lead as "Req. for info".
Test Lead will consult tester and provide the necessary details for the defect and assign back to the same
Functional or Developer
After the defect is fixed, the status is changed to Fixed by Functional SME/Developer and assigned to Test lead for
the verification to proceed further for the retest
Once the test lead confirms that fixes are ready to test then changes the defect status to Retest and assigned to
the tester who is responsible for retest.
When the tester retest the defect and confirms that the fix does not resolve the defect completely, then changes
the status to Reopen and assign back the functional or development team.
When the tester retest the defect and confirms that the fix has worked fine, then defect the changes status to
Successfully Tested which will assign to test lead
Test lead will verify the Successfully tested defects and changes the status to Closed
Any new issues identified during retest should be created as a new defect rather than reopening the current defect.
Initial value for priority field will be set by the tester who creates the defects based on testing impact. During defect triage
meeting it business re-evaluates and updates the value, if needed.
DEV/business will participate in the defect triage meeting during the Testing (Functional/SIT/Regression) done by QA and will
assign / change the priority to new defects based on business impact.
Priority
Level
Business Impact
Testing Impact
P1
Defect is a blocking issue. The defect would impact the completion of testing
iteration if not resolved, and any testing cannot proceed until this defect is resolved
P2
Defect is severe. This impacts the general behavior of the application. A workaround
may exist but its use is unsatisfactory. Test cases will be blocked due to this defect.
P3
P4
Cosmetic problem. During testing this will result in test case failure, but will not
block the execution of the other test cases.
10
100
10
10
8
60
12
21
40
12
20
Deferred
21
10
80
Rejected
23
10
8
23
21
10
8
21
18
10
5
16
Closed
14
UT
SIT
UAT
Retest
12
Fixed
10
Assigned
New
No Run
Blocked
0
SIT
Fail
Pass
Not Completed
UT
18
UAT
Lab