of 21 /21
http://cheyat.com/qa/hp-alm- online-training-tutorials HP ALM Online Training

HP ALM Online training by Cheyat Technologies

Embed Size (px)

Text of HP ALM Online training by Cheyat Technologies

PowerPoint Presentation

http://cheyat.com/qa/hp-alm-online-training-tutorialsHP ALM Online Training

1These slides belong to the training course:LoadRunner 6.5 for the Web, version 3 - LRWEB6.5/03

ALM Work Flow Requirement through Deployment2

PredictabilityHeightened repeatabilityImproved qualityReady accommodation of change


Why Testing3

Why Test management4How do I know my release readinessHow do I manage my requirementsHow do I track my test coverageHow do I monitor my Release progressHow do I assess the severity and priority of my defectsHow do I base line my test artifacts

5Why Test Management Tools



88ALM Stakeholders

Project Managers

Business Analysts

Development Team

Testing Team

Dashboard and Analysis ViewReleaseRequirement

Dashboard and Analysis ViewReleaseRequirement

Dashboard and Analysis ViewReleaseRequirementTestingDefect

DashboardDefectTrack release progressVisibility into key project milestonesFull trending analysis and insight into application projectsClearly communicate to all stakeholdersDefine and track multiple requirement typesBi-directional traceability from requirements to requirements, tests and defectsLeverage existing assets in MS Word

Create test cases to adequately test the requirements

Manage and control execution of manual and automated tests

Create defects from manually or directly from the execution of manual and automated tests

Improve developer efficiency

Consistent defect management process across all projects and initiatives

Integrated into developers IDE


DomainProjectsAFG_Projects_ AllAFG_ RFC_ AllAFG_Bug Fix &Routine_ All__Root FolderProject NameSub FolderReq 1Req NRoot FolderProject ATest CaseTest case 1Test case NDefectsDefectsReportingReporting__RFC_LOB_2015RFC 1RFC NRFC_LOB_2015Test case 1Test case NRegression Test case 1Regression Test case N__Bug Fix_LOB_015Bug Fix_LOB_015Test case 1Test case NRegression Test case 1Regression Test case N

HP ALM Login EntitiesRequirements ModuleTest Plan/Test Lab moduleDefects moduleReporting module


JanDecRFC 1RFC NBug Fix 1Bug Fix NJanDecBug Fix 1Bug Fix N

Testing Process An Overview (SOLMAN HP ALM)SOLMANHP ALM 12

SAP TAOComponent based AutomationHP SprinterManual TestingHP UFTTest Automation ToolRequirementsDefects to process in SOLMANBusiness BlueprintsTest PlanningTest ExecutionBusiness ProcessesTest ObjectsTest RequirementsTest CasesTest sets to runTest ResultsTest Results to SOLMANDefectsDefects ModuleManual Feed or Import from ExcelReq/Test casesAutomation Testing

Testing Process Details (SOLMAN HP ALM)Requirements Module

The Requirements can be loaded to HP ALM in any of the following three waysImport are Export the business blueprint and test objects from SOLMAN SOLAR02Note: Only the Business Processes/scenarios that has test object or transactions assigned to it can be export or import to HP ALMCapture the functional requirements in the defined excel spreadsheet and import the same to HP ALMCreate the required folder tree and enter requirements into that based on the functional requirements documentOnce the Requirements are imported to the HP ALM then we can update/delete the requirement on accessing to the respective requirement

Test Plan ModuleThe test cases can be loaded to HP ALM in any of the following two waysDirectly enter the test cases and define the test steps in the Test plan moduleWrite the test cases in the defined excel spreadsheet and import the same to HP ALM test plan moduleEach test case will be mapped to the corresponding requirements by editing the test case

Test Lab ModuleThe corresponding test cases need to be mapped pull to the Test lab module as a Test set for the test execution These test case need to be executed either Manually or Automated run for the automated cases.The test results must be transferred to SOLMAN SOLAR01/SOLAR02

Testing Process Details (SOLMAN HP ALM) contd.


Defects ModuleDuring the test execution the defects can be logged when the testing scenario is fail to meet the expected resultDefects falling under two types:Defect: It is a regular defect that is been identified as to be processed in the HP ALM only by both Testing an Development team and it goes though the defect lifecycle process in ALMSAP related Defect: It is a defect that is been identified as to be processed in the SOLMAN by the development team and it goes through the defect lifecycle process in SOLMAN (Defect Fix) and ALM (Defect logging, resetting and Closing )These can be viewed in the CRM_DNO_MONITOR or SM_WORKCENTER or CRM_ORDER transactions codes in SOLMAN

Testing Process Details (SOLMAN HP ALM) contd.HP ALMSOLMANNewNewFixedClosedForwardedReceived from HPQCProposed SolutionConfirmed Assign responsibility to SAP

Defect Workflow


HP ALM Implementation Case Study

Client is one of the largest company that offers a comprehensive array of financial services to retail and institutional clients, which includes annuities, retirement plans, life insurance, mutual funds, managed accounts, alternative investments, direct banking, institutional investment management, employee benefits, and financial planning.

Client ProfileClient RequirementsThe client was looking to implement HP ALM to address the following: Manage and create traceability between requirements, tests artifacts and defectsStandardize process across application lifecycleFacilitate collaboration and communication between multiple, distributed teamsManage and execute automated testingMake informed go/no go decisionsProvide a scalable architectureProject BackgroundCognizant focused on deploying integratedQuality management across the application lifecycle to focus and prioritize testing resources at all phases and find and manage defects earlier in the lifecycle when they are less costly to fix. By taking a systematic, risk-based, managed approach to 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 based on risk. And with quality metrics and centralized reporting, they were able to make informed decisions about application releases. Cognizant Solution ApproachThe Client wanted to assure quality with systematic automation testing conducted over the course of one year before rolling out. This massive project carried with it significant risk, as errors and downtime could erode customer trust or even lead to business losses.

Benefits achieved using HP ALMReduced cost through centralized management and enforcement of consistent workflows and processesIncreased efficiency by reducing duplication of effort and sharing best practicesIncreased visibility to quality status, requirement coverage and defect trends in aggregate across projects and initiativesAchieved significant savings by tracking key metrics against project milestones within Project Planning and Tracking of HP Application ManagementBusiness Benefits achievedThe Client was able to minimize business risk in this important project.A quality assurance process has been created for building next generation systems.Quantitative measures of IT quality and performance have been established to support increased business efficiencyTop New Features in ALMBenefits gain from ALMProject Planning & TrackingRequirements TemplatesProject/Template ReportsTraceability MatrixEmbedded Web Scorecards & GraphsBusiness Process Modeling IntegrationTest Configurations

Reduced cost through centralized management and enforcement of consistent workflows and processesReduced cost and increased efficiency by reducing duplication of effort and sharing best practicesIncreased visibility to quality status, requirement coverage and defect trends in aggregate across projects and initiativesOthers

HP ALM Implementation Case Study

CategoryDescriptionDefectWhen 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 releaseIssueWhen 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 IssueNew ReqWhen 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.

Defect Categories

StatusResponsibilityTarget OwnerDescriptionNewTesterTest Lead 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 RejectedTest LeadTest 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.RejectedTest LeadTest Lead 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 defectTester's misunderstanding of requirements or test scripts.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.DeferredTest LeadTest Lead Test Lead will Defer a defect when it is analyzed and Not In-scope on functionality Not in current scope but in future releases.When these defects are need to be picked up and assign in future release then the test lead can change the defect status to AssignedAssignedTest LeadFunctional/ DEV teamWhen 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.Req. for infoFunctional/DEVteamTest LeadOnce 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 DeveloperFixedFunctional/ DEV teamTest LeadAfter 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 retestRetestTest LeadTesterOnce 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.ReopenTesterFunctional/ DEV teamWhen 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.Successfully TestedTesterTest LeadWhen 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 leadClosedTest LeadNATest lead will verify the Successfully tested defects and changes the status to ClosedAny new issues identified during retest should be created as a new defect rather than reopening the current defect.

Defect Statuses & Descriptions

Priority LevelBusiness ImpactTesting ImpactP1This has severe impact to the customer and continuing to operate may not be possible. This must be fixed immediately.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 resolvedP2This is major impact to the customer but does not halt operations. This must be fixed as soon as possible and before the release of the current version in development.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. P3This has major impact to the customer. The problem should be addressed and fixed with the current version release if time permits, or a patch to the release issued, if possible.The failure impacts non-critical aspects of the system, behavior of functionality under specific conditions. During testing this will result in test case failure, but will not block the execution of the other test cases.P4This has minor impact to the customer. The flaw is usually cosmetic to the customer in nature and only needs to be fixed when there is sufficient time.Cosmetic problem. During testing this will result in test case failure, but will not block the execution of the other test cases.

Defect Priority levels

Priority is an outcome of subjective evaluation of how important an issue to the business. Other tasks in the queue and schedule are factors that may impact the decision of prioritizing the Defect. It is relative, it shifts, and it is always a business decision.

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.

Reports and Graphs