Test Director

14/11/2023

Strictly Confidential: For Bank of AmericaSentry Insurance and Accenture Use Only

CLMS Test Director User Manual

Life Cycle of Test Director User Manual

Testing Center of Excellence

24/11/2023



Table of Contents

Test Director Manual.......................................................................................................1Introduction......................................................................................................................3Life Cycle of a Defect.......................................................................................................3Defect Field Descriptions..............................................................................................44Basic Test Director Administration..............................................................................98Login to Test Director....................................................................................................98Change Password......................................................................................................1110Defect Functionality..................................................................................................1211Entering a Defect.......................................................................................................1211Updating a Defect......................................................................................................1514Creating a Defect Filter.............................................................................................1815Test Script Functionality...........................................................................................2220Creating a Test Set....................................................................................................2220Executing a Test Script.............................................................................................2523Adding a Defect while Executing a Test Script.......................................................3028Tying a Mod to a Script.............................................................................................3533Importing a Test Script..............................................................................................3937

34/11/2023



IntroductionThe purpose of this document is to describe to Test Executers, Code Fixers, and Defect team leads how to use Test Director to execute scripts and manage defects. As a defect tracker, Test Director will become the primary means by which the program records activity and passes information across teams. It is critical that all team members follow good defect etiquette such as attaching relevant screenshots and adding a comment to the defect anytime they update information or move it to a new state.

The document includes a high level description of Defect lifecycle to provide a process framework in which test director will be used. It covers test director screens to be used on the TCoECLMS project starting with the most generic and moving into test executer specific functionality.

Life Cycle of a Defect

Defect Found – When a defect is found the tester will begin by logging a new defect. See the Entering a Defect section below for instructions on how to log a defect. See also the Defect Field Description section for a detailed description of each field.

1. New – When a tester initially finds a defect they will fail the step of their script (when appropriate) and add a new defect with the status of New, populating the required fields.

The Defect Lead will take all Defects with the status of New and after ensuring that they are written properly (priority, complexity, completeness) they will do one of three things.

1. Assign the Defect to the Assignment Lead (See step 5)2. Reject as a Duplicate (This will require tester agreement)3. Reject as “system working as designed” 4. Request Review by Business/App Leads

2. Rejected – Triage Team decides the defect is not a problem or there has been a conscious decision to do nothing about this defect. This step will require the defect lead obtain agreement from the authoring tester and can also be reached after review from the Assignment Lead.

3. Duplicate – Triage Team decides that the is a duplicate of another defect. The defect that will be worked on is referenced on the duplicate defect. This step will require the

44/11/2023



defect lead obtain agreement from the authoring tester and can also be reached after review from the Assignment Lead.

4. Review / In Watch ListReview - If the Defect Lead and Test Executor are unable to agree on a rejected status for the Defect or the Defect represents a scope issue, they will escalate the defect to the Business/Application leads by changing its Status to “Review.” The Defect lead will facilitate the discussion with the Bus/App leads and change the defect status accordingly (review defects can move to Assigned, Rejected, or CRI status).

5. CRI – If a defect is a scope change or an item that requires program leadership attention the Defect Lead will move it into CRI Status. From there the test execution project manager will open a corresponding Clearquest item.

6. Assigned / Open - Defect Lead has assigned defect to an Assignment Lead (Team Lead). The Assignment Lead will then assign the claim to a fixer on there team to fix the defect.

7. In Process / In Coding – The Fixer receives the defect in Assigned status and updates the status to In Process to signify that they have started working on the defect.

8. Fixed - Fixer has fixed and unit tested the defect. The defect is now ready for the Build Coordination team to review to promote in the next build.

9. Build Pending / In CIT – During the Build Coordination meeting each fixed defect will be approved to go into the build. If approved the status will be updated to Build Pending by the build coordinator for the specific development area (i.e. Application).

10. Retest / Ready for Retest– Defect has been fixed and migrated to the applicable environment. Defect is ready for testing or is in process of being tested. The build executor for the given defect will update the status.

11. Closed - Fix has been validated in applicable environment by person who detected the defect. Only the team member who created a defect may close it (i.e. Test Executor)

12. Reopen - Defect has been fixed but did not pass the appropriate tests. Status is updated to Reopen where defect Lead will reexamine and reassign to the proper Assignment Lead.

Defect Field Descriptions

54/11/2023



Page 1 Fields and Descriptions

Summary (Required): The summary should give a high level description that is descriptive of what the defect represents. Include enough detail to make the detail unique as the summary serves as the defect title in subsequent meetings and conversations. Tip: Use the component name, field, and verb to describe error in summary. (Example: “Participant Component Presents Add Line Menu Button for Non-Claimant Participants”)

Description: The description should elaborate on how the tester found the defect and why they think it is a defect (i.e. How did the actual results differ from the expected results?). Tip: In describing a defect, think about what the first question or questions a defect lead or developer might ask to understand the problem. Defect descriptions are one place where it is better to err toward providing too much information rather than too little.

Status (Required): This describes the status that the defect is within the lifecycle of the defect. See the Lifecycle of a defect section above more details.

Priority (Required): This field indicates the priority that the defect is to be fixed. This will be entered by the tester and likely remain unchanged throughout the Defect lifecycle. Below are the definitions of each level of Priority:

Low – Fixing the defect adds value, but does not impact the required functions or features of the application. For example, the defect is cosmetic in nature and may or may not be fixed.

Medium – The defect is not preventing testers from proceeding, but it does represent a problem with the code. Tester is able to find a work around from business function perspective to complete the script.

High – The defect is preventing testers from proceeding. The defect must be fixed as soon as possible (the intended target for this fix will be the next build). Tester is unable to find a work around from a business function perspective to complete the script

64/11/2023



Critical - The defect is preventing one or more testers from successfully executing scripts and is raising design issues that may affect scope or require rework. The defect affects multiple components and must be fixed as soon as possible (the intended target for this fix will be the next build).

Layer/ Test Phase (Required): This describes the layer Claim Components the defect occurs in. Here are the definitions of each valid layer:

Application – Data: The defect is a result of the application data model or data. Application – Desktop: The defect is a result of application code for the desktop. Application – Financials: The defect is a result of application code for financials.Conversion: The defect is a result of data conversion.Integration – CLMS App: The defect is a result of an CLMS Application Interface. Integration – Legacy: The defect is a result of Legacy Interfaces.Integration – Middleware: the defect is a result of middleware.

Business Component / Component (Required): The name of the component that the error is occurring in. Tip: Not necessarily the component script that is being run when the defect is found.

Detected in VersionTest Phase (Required): The versionTest Phase in which the defect is found. Tip: AT executers will select AT as the phase.

Environment: The environment in which the defect was found. Tip: Only applicable if AT is selected as Test Phase.

Detected on Date (Required): The date when the defect was detected.

Detected By : The name of the person who detected the defect. Select name from a directory.

Detected Pass: If the defect is detected while running a script. This field records the pass of the script when the defect was detected.

Assigned To: The person to whom the defect is assigned. Tip: This should be done by the Defect lead and the Assignment leads. See the lifecycle of a defect section for more details on assignments.

Wave / Test Cycle: The Assembly Test Wave that the component is in. Tip: See the Assembly Test Execution Score card to determine the wave.

Complexity / Business Priority: The estimated complexity the defect will be to fix. Valid values are:

Easy –

74/11/2023



Defect is display related (Misspelled label or error message, incorrect code values or descriptions in combo box)

Defect is a simple validation performing incorrectly (Date less than current date, required field not marked)

Defect is contained within a component and does not involve an interface

Medium – Any runtime errors where the system redirects the tester to an error page Simple errors involving data from an interface (No data returned or single incorrect value

returned) Simple business rules involving more than one component or interface are not behaving

as expected (invalid Loss Coverage code based on USLHW setting on participant

Hard – Results of a complex business rule that requires data from multiple interfaces,

components, or reference tables are different than expected and diagnosis will be multi layered with likely business consultation

Page 2 Fields and Descriptions:

Estimated Fix Time: The amount of time In Days that the fixer estimates the defect will take to fix.

DBCR: If the fix requires a DBCR enter the DBCR number here.

Release: The release in which the defect occurs. This is to account for future releases of CTCoELMS. Currently the only valid value is “TCoECLMS 1. “

Impacted Scripts(s): The scripts that are impacted by the defect (manually entered in the following format A89, A71 ptp6770-ini, ptp6772-PaymentAddress-AccountType-Check).

84/11/2023



Tip: This will be helpful for the Defect Leads to determine the complexity and priority of the defect.

Closing Date: The date the defect is closed.

Actual Fix Time: The actual time that it took the fixer to fix the defect.

Last Modified: The date that the last modification was made to the defect.

Retested By: The name of the person who retested the defect.

Change Mgmt Impact: This field denotes whether the defect results in a training issue for the change management team.

Files Changed Page: Fixers will enter files they changed to fix the defect in this field.

Basic Test Director Administration

94/11/2023



This section describes how to do basic test director administration such as logging in and changing a password.

Login to Test Director1) Launch Mercury Test Director by going to the intranet hyperlink for Bank of America. e

following link:a. http://shoaps17/tdbin/start_a.htm

2) Select Domain of TCoEPROD 1

3) Select TCoECLMS from the Project Drop down menu.

4) Enter your User ID – First and Last Name (i.e. John Smith)

5) Enter your Password – This will be blank on your first login

6) Click Login button

http://shoaps17/tdbin/start_a.htm

104/11/2023



7) Upon first login change your password (See Change Password section)

Change Password

1) Click on Tools2) Change Password3) Type in New Password4) Click OK button

Change Password

Tip: Change password the first time you enter Test Director.

Defect FunctionalityThe following sections of the document describe defect functionality in test director. This will be the primary function of Test Director and used by testers, fixers, and coordinators across all work streams.

Entering a Defect

114/11/2023



1) Click on the Defects button on the Menu bar

2) Click on the Add New Defect Button

3) Enter the following fields with values applicable to your defect. For a thorough description of what each defect fields means and what should be entered see the Defect Fields section of this document.

Page 1

124/11/2023



Page 2

4) To attach any applicable Screen shots (Application Defects) or Flat files/XML (Integration Defects) or Wave files (VGS applications), , click the ‘Paperclip’ icon on the attachment menu bar and browse for the file on your PC or the network. To attach a URL, click the ‘Globe’ icon on the attachment menu bar and enter a URL.

5) Click on the Submit button and close the Add new Defect page by clicking close. The new defect will be seen in the defects grid with a new Defect ID. Record the Defect ID for your Records.

134/11/2023



Updating a Defect


2) From The Defects Grid select the Defect you would like to update and double click on it. The Defect Details Screen will display all of the fields for the selected defect.

3) Update the field that needs to be updated on the details tab and click the “Description” button to Add a comment describing the changes made to the Defect. While this is not a required step in test director, TCoECLMS team members should always add a comment when saving any changes to a defect report.

144/11/2023



4) To attach any applicable Screen shots (Application Defects) or Flat files/XML (Integration Defects) click the “Attachments Button” followed by the ‘Paperclip’ icon on the attachment screen and browse for the file on your PC or the network. To attach a URL, click the ‘Globe’ icon on the attachment screen and enter a URL.

5) Click OK to commit all changes to the database.

Creating a Defect Filter

154/11/2023




2) Select the Set Filter/Sort button.

3) Select the empty field next to the value you want to filter by.

4) Click on the … button.

5) Enter the Condition that you want to filter by. Do this by selecting the operand and then selecting the values provide to you for that field.

164/11/2023



6) Click the OK button.

7) Add any additional Filters that you would like. When they are added click the OK button on the Filter Screen.

174/11/2023



8) The Defects Grid will now only show the defects that match the filter entered.

Test Script FunctionalityThis section details test script functionality in Test Director. This functionality will be used solely by members of the test execution team.

Creating a Test Set1) Click on the Test Lab tab on the bright green menu bar

2) Expand the Assembly Test folder in the Test Sets Tree

184/11/2023



3) Select appropriate folder Desktop or Financials

4) Click on the Create a new folder button (blue folder with a green plus sign)

5) Create Test set folder for desired component if none exists by entering a Name for the new folder and clicking ok (Folder Name should be the Component Name)

6) Create a Test Set folder for each cycle and pass if none exist (example: Cycle 1 Pass 1 folder, Cycle 2 Pass 1 folder, Cycle 3 Pass 1 Folder)

7) Highlight the appropriate component folder by clicking on it.

194/11/2023



8) Click the Create New Test set button

9) Name the Test set “Run #.” Do this for each run in each Cycle.

10) Highlight desired Test set by clicking on it.

11) Test Plan Tree should on the right side of the screen.

12) If it does not appear, click the Select Tests button

204/11/2023



13) Expand Assembly Test folder to the desired script you are looking to set up

14) Highlight folder and click the arrow to copy the scripts into the test set

15) Steps should appear in the Execution Grid window

The scripts are now ready to be executed

Executing a Test Script1) Click on the Test Lab tab on the bright green menu bar


214/11/2023



3) Select appropriate folder for desired script

4) Test Set appears in the execution grid

5) Click Run Test Set

224/11/2023



6) Manual Test Run message box appears

7) Select Manual Runner and click OK

8) Manual Runner Window appears

9) Click Exec Steps

10) List of steps displays

234/11/2023



11) Perform action in the description section within the Claim Aapplication.

12) Verify against Expected results

13) Place execution notes in Actual column as needed

14) If expected results are correct, click the pass selected button in the upper menu bar (footprints with green checkmark) (screen shot)

15) If expected results fail, click the fail selected button in the upper menu bar (footprints with the red ‘x’)

16) When finished with the run, click the End Run button

244/11/2023



17) The next section in the Run will appear

18) Continue Running until all steps are completed (repeat steps 9-17)

19) Manual Runner window will close and the Test Lab will reappear displaying pass or failed sections of the selected Test Set based upon what you entered.

254/11/2023



20) Execute each component until each cycle, run, and step passes

Adding a Defect while Executing a Test Script

1) Click on the Test Lab tab on the bright green menu bar


264/11/2023



3) Select appropriate folder for desired script

4) Test Set appears in the execution grid

5) Click Run Test Set

274/11/2023



6) Manual Test Run message box appears

7) Select Manual Runner and click OK

8) Manual Runner Window appears

9) Click Exec Steps

10) List of steps displays

284/11/2023



11) Perform action in the description section within the Claim A application.

12) Verify against Expected results

13) Place execution notes in Actual column as needed

14) If expected results are correct, click the pass selected button in the upper menu bar (footprints with green checkmark) (screen shot)

15) If expected results fail, click the fail selected button in the upper menu bar (footprints with the red ‘x’)

16) When finished with the run, click the End Run button

294/11/2023



17) The next section in the Run will appear

18) Continue Running until all steps are completed (repeat steps 9-17)

19) Manual Runner window will close and the Test Lab will reappear displaying pass or failed sections of the selected Test Set based upon what you entered.

304/11/2023



20) Execute each component until each cycle, run, and step passes

21) Click on the Add Defect button to add a defect associated with this Test ScriptSee Entering a defect section for details on entering a defect

22) The Defect Screen will appear as below. The Description will be pre-populated with script information. Enter a defect as you normally would (See Entering a Defect section for instructions on how to enter the defect)

314/11/2023



Tying a Mod to a Script

1) Click on the Test Plan tab on the bright green menu bar

2) From the Test Plan Tree Select the Component – Script – Cycle – Run - Section to which you would like to tie the MOD

324/11/2023



3) Click Reqs Coverage tab

4) Click the Select Reqq button

5) Requirements Tree appears to the right

6) Select the appropriate MOD from the Component

334/11/2023



7) Click the Add to Coverage button (see upper left of figure above)

8) MOD is tied to the desired section

344/11/2023



Importing a Test Script

1.) Download the Excel Import Add-in from the following path: N:\S_Pmo\Mercury\Upgrade 8.0\TDMSExcelAddin provided by the client.

2.) Change the existing base test scripts in Excel according to the steps below:a. Ensure all Expected Results for a particular Step are contained within one cell.

i. Utilizing the ‘Alt + Enter’ function will display the Expected Results on separate lines in Test Director.

ii. If there are a lot of lines to consolidate to one cell, you can copy all cells to notepad and then copy back into one cell in Excel.

** Note: The following column designations are necessary for the proper import of information from Excel to TestDirectorb. Insert two columns between existing columns C & D

i. In the new column D, populate the folder structure for the Test Plan in the following format for each business transaction tested: Component\Script\Cycle\Run. (ex: Payments\A101\ ptp6772-PaymentAddress-AccountType-Check \Cycle 1\Run 2).

ii. The business transaction names (i.e. Launch Claim Folder, Add Payment Detail PTP or Promised to Pay) that were originally in column D and highlighted in gray should be moved to the new column E. Column E should only contain business transaction names. Columns F, G, and H should only contain the Steps, Descriptions, and Expected Results, respectively.

iii. See attached script for example of a changed script:

354/11/2023



Option Vocabulary DTMF Action Conf.

Yes “Yes”,“Yes, please”,“Yes, I do”

1 Go to: ptp6772-PaymentAddress-AccountType-Check Never

No “No”,“No, thanks”,“No, thank you”,“No, I don’t”,“No, I do not”

2 Play “Exit, noaddr”, and then go to: pl2100-d-AccSelection-SingleOrMultiAccount-Check

Never

Requirement name or state name. Note that the first few alphabets ‘ptp’ refers to the module name “Promise To Pay”Dialog module – both caller and IVRU talk

Play prompt – only IVRU talks

Branch on condition– decision is taken on where to go next

Database call – fetch data and backend transactions

From which state are we coming to this stateThe type of requirementName of the specific requirement – it cant get more specific than thisThese are the wordings that are spoken – the actual dialogues The alias to the specific requirement name. Usually only this is used to indicate a particular row. For eg. Ptp6770.a , ptp6770.b, ptp6770.c etc.

3.) After all necessary changes are made to the test scripts in Excel, highlight all information you wish to import without the column headings.

4.) Choose Tools > Export to TestDirector. The TestDirector Export Wizard – Step 1 of 8 dialog box opens.

364/11/2023



Type the TestDirector server and virtual directory name as shown above in window: <http://shoaps17/tdbin/>

5.) Click Next. The TestDirector Export Wizard – Step 2 of 8 dialog box opens.

Select the appropriate domain and project name. Domain: To be determinedPROD1Project Name: TCLMSoE


http://shoaps17/tdbin/

374/11/2023



Type your user name and password.


Select a data type. (For test scripts, you will select “Tests”.)


384/11/2023



Select the “TCoECLMS Test Script Import” map that is already created.


This window shows you the standard mapping that was already created from TestDirector fields to Excel columns. The Excel column designations should have already

394/11/2023



been set up in your spreadsheet according to Steps 2-4 above. If your Excel spreadsheet has not been properly set up, the import will not be successful.

10.)Click Next. The TestDirector Export Wizard – Step 7 or 8 will show you the percentage completion of synchronization to TestDirector.

11.)If you have successfully exported your worksheet to TestDirector, the TestDirector Export Wizard – Step 8 of 8 dialog box opens.

Click Finish.

12.)Go to TestDirector and view the Test Plan Tree that was automatically created from the test script.

404/11/2023



13.)Select the folder for your component and drag it into the appropriate folder, either Desktop or Financials

Note: Templates and screen shots covered in this tutorial are examples for clarification purposes only, the correct maps/templates used by the client (Bank of America) will be communicated to the team upon completion of the first phase (Scripts up date).

For further information, refer to the contact below:

Abbes SeqqatOctel: 370/5251Cell: (704)458-5624mailto:[email protected]

mailto:[email protected]

Test Director

Documents

Transcript of Test Director