1 / 38

ClearQuest Application Lifecycle Management Training

ClearQuest Application Lifecycle Management Training. Test Driven Development Practice Demo. Submitter Submit request Stakeholder is Owner. Project. Request. Category. Release. Developer. Developer Triages requests Add & plan Tasks Activate Task Set Tester as Owner Open Activities

katima
Download Presentation

ClearQuest Application Lifecycle Management Training

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ClearQuest Application Lifecycle Management Training Test Driven Development Practice Demo

  2. Submitter Submit request Stakeholder is Owner Project Request Category Release

  3. Developer • Developer • Triages requests • Add & plan Tasks • Activate Task • Set Tester as Owner • Open Activities Deliver change Complete Activities Tester Project Request Submitter Submit request Stakeholder is Owner Category Task Release Run Developer Test Implement Developer Test Implement Solution

  4. Release Engineer • Create Baseline • Run Build • Validate Build and Promote • Developer • Triages requests • Add & plan Tasks • Activate Task • Set Tester as Owner • Open Activities Deliver change Complete Activities Project Request Submitter Submit request Stakeholder is Owner Category Task Release Build Baseline

  5. Builder • Create Baseline • Run Build • Validate Build and Promote • Developer • Triages requests • Add & plan Tasks • Activate Task • Set Tester as Owner • OpenActivities Deliver change Complete Activities • Tester • Perform walkthrough • Complete Task Project Request Submitter Submit request Stakeholder is Owner Category Task Release Build Baseline

  6. Builder • Create Baseline • Run Build • Validate Build and Promote • Developer • Triages requests • Add & plan Tasks • Activate Task • Set Tester as Owner • Open Activities Deliver change Complete Activities • Tester • Perform walkthrough • Complete Task Project Request • Stakeholder • Accept/Reject Task Category Task Release Build Baseline

  7. Request Submitter • In Windows Eclipse client or CQ Web • Login as ‘TDDP_Stakeholder’ (Blank Password) • If doing Demo, In Eclipse, you can also pre-log in as TDDP_Developer, TDDP_Tester, TDDP_ReleaseEngineer • Click New Request icon • Choose CategoryTypeLabel ‘TDDP’ • Choose Category ‘Test Driven Development’ • Point out Project (If you set one on chosen Category) • Point out Phase (If you set one on chosen Project) • Point out Iteration (If you set one on chosen Phase) Note: If you do not set a Category->CurrentProject or if you do not choose a Category, the Request->Project will need to be chosen before you will see any choices in the Request->Type form Control • Enter Headline • Choose Type – choose ‘Defect’ • Choose Severity • Give (brief) tour of Request • Owner should be set to ‘Stakeholder’ • Click OK • All Queries in Public queries\Practices\Test Driven Development folder unless specified

  8. Creating Tasks and setting Developer Ownership Login as ‘TDDP_Developer’ (Blank Password) Execute ‘Triage Request’ query Category = ‘Test Driven Development’ Click on Request in Result Set grid Resize Display so Request->Tasks field shows Highlight the Request and Click UtilityCreateTask Note new Request->Task Defect Owner should be set to Role->Primary for Project= ‘Test Driven Development’, RoleLabel = ‘TDDP_Developer’ Triage Requests

  9. Developer • Execute query ‘Dev Lead’ • Category = ‘Test Driven Development’ • Click on Task in Result Set grid • Change_State ActivateTask • Set Owner = ‘TDDP:Tester’ then click Apply • Resize Display so Task->Activities field shows • Click UtilityCreateActivity • Note 3 new Submitted StateTask->Activities • Open ‘Implement Developer Test’ and set Owner = ‘TDDP:Developer’ • Open ‘Implement Solution’ and set Owner = ‘TDDP:Developer’ • Open ‘Run Developer Test’ and set Owner = ‘TDDP:Developer’ • ratl_mastership for all Activities should be WorkConfiguration->Role->Primary->ratl_mastership for a WorkConfiguration where Project= ‘Test Driven Development’, Record_Type =‘Activity’, Type = <Activity Type>

  10. Non-UCM Developer (non-UCM demo) • Execute query ‘Developer’ • Category = ‘Test Driven Development’ • Click on Task in Result Set grid • Resize Display so Task->Activities field shows • For each of the Activities: • Highlight Activity • Simulate doing work • For the ‘Implement Solution’ Activity only,highlight ID and Ctrl-C • For the ‘Implement Solution/Implement Developer Test/Run Developer Test’ • Dbl-Click then Choose Complete Action • Enter a Resolution Summary and Resolution Code • Click Apply

  11. Project Release Engineer Create Baseline of Code • Switch hats to become RE <Simulate Scripting> • Login as ‘TDDP_ReleaseEngineer’ (Blank Password) • Choose Menu Actions->New Baseline • Baseline = ‘<TOD> Baseline’ • PVOB = <TOD> PVOB’ • Project • ADD->Search <Highlight Project where Category = ‘Test Driven Development’ • Click Activities Tab, Activities field Add • Paste Copied Activity ID into Search Key Box and click Search • Highlight only record and click OK • Click OK on new Baseline

  12. Project Release Engineer (Build) Simulate Build script (non-UCM) • Login as ‘TDDP_ReleaseEngineer’ (if not already logged in as that UserID) • Menu Actions->NewBuild • Build= ‘<TOD>Build’ • On ALM Tab • Choose Project • ADD->Search • Highlight record for Project and click OK • Baseline click ADD • enter ‘<TOD>’ used to create Baseline • click->Search • Highlight Baseline created earlier and click OK • Build Status = ‘Passed’ • Owner should be automatically set to Role->Primary for Project= ‘Test Driven Development’, RoleLabel = ‘TDDP_ReleaseEngineer’ • Click OK on Build record

  13. Tester conducting Walkthrough and Completing Task • Tester Completing Task • Login as ‘TDDP_Tester’ (Blank Password) • Execute ‘Completing Tasks’ • Category = ‘Test Driven Development’ • Assess Activity States • At this point, you could use this Task and its Activities to arrange a Walkthrough • Note Build containing ‘Implement Solution’ fix (if Build was created) • Click Task Actions button and clickComplete • Enter ResolutionSummary and Resolution • Click Task Apply

  14. Request Submitter • Throughout the development cycle, I may be checking on the status of my Requests • Login as ‘TDDP_Stakeholder’ (Blank Password) • Execute ‘Requestor’ query • Category = ‘Use-Case Driven Development’ • Request State = ‘Opened’ • Task State = ‘Completed’ • Note States of Task and Task.Activities • Accept the work done on the Request

  15. Comments, Questions and Responses • Owner of a record is expected to be the only person directly modifying or state transitioning the record • This is not hard coded into the system, merely a suggested approach • If you wish to modify a record you are not the Owner of, do a QuestionOrComment Action • May indicate that you are just commenting or that you are Requesting a Response • You may Respond to a Question or Comment • You may also indicate that a Request is a Duplicate • MarkAsDuplicate • DuplicateComplete • Query Unanswered Questions

  16. Duplicates • In order to indicate that a Request is a Duplicate of another Request, we do the following: • 1) Request2 is seen as a duplicate of Request1. • 2) Select Request2. • 3) Choose the MarkAsDuplicate Action. (This creates a Comment on the Request->Comment Tab with ResponseRequested on Request2 and a Comment = "<<DOUBLE CLICK HERE, then select Modify action to provide duplicate information.>>".) • 4) DBl-Click the Comment and Modify it to update the Comment indicating that this is seen as a ‘Duplicate’. The DuplicateOf field will be Mandatory. Enter the ID of Request1 in the Comment->DuplicateOf field and Save the Comment • 5) The Owner of Request2 runs a query (Duplicates Needing Completion) or is notified of the DuplicateOf Comment with ResponseRequested by email. • 6)The Owner of Request2 decides if they agree that their Request is a ‘Duplicate’ of Request1. • 7) If they agree that their Request2 is a ‘Duplicate’ of Request1 they execute the Request->DuplicateComplete Action on Request2. This State transitions Request2 to ‘Completed’ State. • 8) The Owner of Request2 dbl-Clicks the Request->Comment and choose the Respond Action. • 9) They dbl-click the Comment->Response and Modify it to add their response and save it. • 10) If they do not think that Request2 is a ‘Duplicate’ of Request1, The Owner of Request2 dbl-Clicks the Request->Comment and chooses the Respond Action. • 11) They dbl-click the Comment->Response and Modify it to add their response saying that they do not agree for the following reasons and save their Response. They do not Complete the Request2 by Accepting it.

  17. Rejected, Unreproducible and WorksAsDesigned Requests • Perform steps on ‘Request Submitter’ Slide • Note the Request->ID for later use • Login as ‘TDDP_Developer’ • Execute \Public queries\Practices\Test Driven Development\Triage query • Click Utilities icon on Request • Choose Reject_Request (or Unreproducible or WorksAsDesigned) • A Task for the ‘ALL’ Project will appear in the Request->Task Form Control • It will be in the Completed State • No further Tasks will be permitted to be created • Any pre-existing Tasks will be Commented • Reverse this • Login as ‘TDDP_Tester’ • Access Request by Request->ID then ReOpen the Task • Change the Project to ‘Test Driven Development’ • Set Mandatory field values with Type = ‘Defect’, etc. • Click ‘OK’ button

  18. Rejected, Unreproducible and WorksAsDesigned Tasks • Login as ‘TDDP_Developer’ • Execute \Public queries\Practices\Test Driven Development\Dev Lead query • Note the Task->ID for later use • Click ChangeState icon and choose Complete Action on the Task just ReOpened • Set ResolutionCode = ‘Reject_Task’ • The Task will be state transitioned to the CompletedState • Any pre-existing Activities will be Commented (CQ ALM 1.1 only) • Reverse this • Login as ‘TDDP_Tester’ • Access Task by Task->ID then ReOpen the Task • Click ‘OK’ button

  19. Rejected, Unreproducible and WorksAsDesigned Activities • Login as ‘TDDP_Developer’ • Activate the Task just ReOpened • Set Owner = ‘TDDP_Tester’ • Do Utilities-> CreateActivity • Execute \Public queries\Practices\Test Driven Developer\Dev Lead query • Open the ‘Dev’ Activity and set ‘TDDP_Developer’ as the Owner • Login as ‘TDDP_Developer’ • Execute \Public queries\Practices\Test Driven Developer\Dev \Developer query • Click ChangeState icon and choose Complete Action on ‘Implement Solution’ Activity • Set ResolutionCode = ‘Reject_Activity’ • The Activity will be state transitioned to the CompletedState • To reverse this, ReOpen the Activity, Change the Project and reset auto-generated field values • Note: Commented records (CQ ALM 1.1 only) will now be out of synch, but few records, if any, will be effected

  20. ClearQuest Application Lifecycle Management Demo End of CQ ALM Training

More Related