A defect at the QA stage is preventing testing on the Qlarius web application. The objective of this scenario is to prepare a fix and deploy if forward over the part of the application that is not working.
The QA manager raises a change request to track the defect.
The development team lead primes a task from the request.
A developer fixes the defect, delivers the fix and relates it to the task, builds the task, and captures the build outputs in Dimensions CM.
The team lead promotes and deploys the request and task to the SIT stage and deployment area, and then promotes them to the QA stage.
The QA manager deploys the request and task to the QA deployment area.
The following stream is used: QLARIUS:JAVA_BRANCHA_STR
There is a division of responsibilities between the employees at the following stage transitions:
SIT to QA
QA to PRE-PROD
A build is required at the DEV stage.
This scenario uses the following deployment areas:
Stage |
Deployment area |
Deploy by Default enabled for area? |
---|---|---|
DEV |
LCL_DEV_JBRNCHA_AREA03 |
Yes |
SIT |
LCL_SIT_JBRNCHA_AREA03 |
Yes |
QA |
LCL_QA_JBRNCHA_AREA03 |
No |
For a list of the promotion and deployment privileges required by the users see Scenario Privileges.
To run this scenario you must have successfully completed Scenario 3: Deploying Requests to Multiple Deployment Areas.
Log into the web client as any user.
Switch to the following stream: QLARIUS:JAVA_BRANCHA_STR
Browse the QA web application deployment area: in the My Current Project view expand Deployment Areas > QA Stage > LCL_QA_JBRNCHA_AREA03 > Qlarius Underwriter.
In the content pane make a note of the revision of AutoQuote.jar that is currently deployed in the QA deployment area.
Log out of the web client.
Action |
Procedure |
Tao, the QA manager, does some research and finds that the problem is in a single file, AutoQuote.jar, in the LCL_QA_JBRNCHA_AREA03 web application deployment area. Tao decides that the quickest solution is to prepare a fix and deploy it forward over the file that is causing the problem. |
|
The QA manager raises a change request to track the defect |
Tao raises a change request to fix and track the defect.
The New Request dialog box appears. The new request is added to Rita’s request inbox with the following ID: QLARIUS_CR_n By default the request is at the DEV stage when it is raised. |
The QA manager delegates the request to the team lead |
Tao delegates the request to the development team lead, Ted, whose team is responsible for maintaining Qlarius.
The Delegate wizard appears. The wizard closes automatically. Dimensions CM sends an email to Ted notifying him that a request has been added to his Request inbox. |
The QA manager actions the request to its next state |
Tao actions the request to its next state, UNDER WORK.
The Action wizard appears. The request is removed from Tao’s request inbox. |
The development team lead primes a child task from the request |
Ted reads the email, views the request in his Request inbox, and primes a child task from the request.
The Prime Request dialog box appears. The new child task is added to Ted’s request inbox with the following ID: QLARIUS_TASK_n By default the child task is at the DEV stage when it is raised. |
The development team lead delegates the task to a developer |
Ted delegates the child task to a developer, Dinesh.
The Delegate wizard appears. The wizard closes automatically. Dimensions CM sends an email to Dinesh notifying him that a task has been added to his Request inbox. |
The development team lead actions the task to its next state |
Ted actions the task to its next state, UNDER WORK.
The Action wizard appears. The child task is removed from Ted’s request inbox. |
The developer updates their work area from the stream |
Dinesh reads the email, checks his Request inbox, and updates his work area.
The Update from Stream wizard appears. Dinesh’s work area is updated. |
The developer fixes the defect |
In Dinesh’s local work area edit Autoquote.java. For the purpose of this scenario make a minor edit, for example, add a comment to the top of the item. |
The developer delivers the item and relates it to the task |
Dinesh delivers the fixed item to Dimensions CM and relates it to the task.
The Deliver to Stream wizard appears. The Select Request dialog box appears. |
The developer verifies that the item was automatically deployed to the DEV area |
Deploy by default is enabled for the DEV area so when Dinesh delivered the item it was automatically deployed. He checks that the item was successfully deployed.
a In the navigation pane click the filter button in the top right corner. b Select Show Current Stream. |
The developer builds the task and captures the outputs |
Dinesh builds the task in the DEV web application deployment area and captures the build outputs in Dimensions CM against the task.
The Run Build wizard appears. The Select Request wizard appears. a From the Product name list select QLARIUS. b From the Type name list select TASK. c Click Next. d Select the task that is delegated to Dinesh. e Click Finish. A summary of the build command that will be executed is displayed. |
The developer verifies that the build was successful |
Dinesh verifies that the build was successful and that the outputs were deployed to the DEV web application deployment area.
|
The developer delegates the task to the team lead for peer review |
Dinesh delegates the task to Ted for peer review.
The Delegate wizard appears. The wizard closes automatically. Dimensions CM sends an email to Ted notifying him that a task has been added to his Request inbox. |
The developer actions the task to its next state |
Dinesh actions the task to its next state, PEER REVIEW.
The Action wizard appears. The task is removed from Dinesh’s request inbox. |
The team lead does a peer review and actions the task to its final state |
Ted has read his email, seen the task in his Request inbox, done a peer review of the defect that Dinesh fixed, and is satisfied with the changes that he made. He actions the task to its final state, CLOSED.
The Action wizard appears. The task is removed from Ted’s Request inbox. |
The team lead promotes and deploys the request and the task to the SIT stage and area |
To perform system integration testing, Ted promotes and deploys the request and task to the SIT stage and web application deployment area.
The Promote wizard appears. A summary of the deployment activity and command that will be performed is displayed. |
The team lead verifies that promotion and deployment operations were successful
|
Ted verifies that promotion and deployment operations were successful and that the modified file was deployed to the SIT web application deployment area.
|
Ted performs system integration testing. |
|
The team lead promotes the request and task to the QA stage |
System integration testing has been completed successfully so Ted promotes the request and task to the QA stage. Deploy by Default is not enabled so the request and task cannot be automatically deployed to the QA deployment area.
The Promote wizard appears. Deploy by Default is not enabled so no deploy options are available. A summary of the promotion activity and command that will be performed is displayed. Dimensions CM sends an email to the QA manager, Tao, notifying her that a promotion has been performed. |
The team lead actions the request to its next state |
Ted actions the request to its next lifecycle state, IN TEST, so that QA can test the application.
The Action wizard appears. Note: The task is removed from Ted’s request inbox. |
The QA manager deploys the request and task to the QA deployment area |
Tao reads the email, checks her Request inbox, and deploys the request and task to the QA web application deployment area.
The Deploy wizard appears. A summary of the deployment activity and command that will be performed is displayed. |
The QA manager verifies that promotion and deployment operations were successful
|
Tao verifies that promotion and deployment operations were successful and that the modified file was deployed to the QA web application deployment area.
|
The QA team performs their tests. |
|
The QA manager actions the request to its final lifecycle state. |
QA testing has been completed successfully so Tao closes the enhancement request that she raised against the defect.
The Action wizard appears. The request is removed from Tao’s request inbox. |
End of scenario |
The tables below list the promotion and deployment privileges required by each user in the scenario.
Promotion privilege |
Privilege owner |
Required at these stages |
REQUEST_PROMOTE_NEXTSTAGE ITEM_PROMOTE_NEXTSTAGE |
Team lead |
DEV SIT |
Deployment privilege |
Privilege owner |
Required for these areas |
The DEV and SIT areas are deploy by default areas and no deployment privileges are required. |
||
REQUEST_DEPLOY ITEM_DEPLOY |
QA Manager |
LCL_QA_JBRNCHA_AREA02 |