HP0-M31 Quality Center Certification Preparation 4 - Test Lab Module

TEST EXECUTION

1. Fields and functionality related to release management and baselining are not available in the Test Lab module if you are working with the Starter Edition.
2. We run the manual and automated tests in your project in order to locate defects and assess quality.
3. Executing tests consists of the following: Create Test Sets, Schedule Runs, Run Tests Manually, Run Tests Automatically, Analyze Test Results.
4. You can organize test execution by creating test sets.
5. A test set is a group of tests in a Quality Center project designed to achieve specific testing goals.
6. A test sets tree enables you to organize your application management process by grouping test sets in folders and organizing them in different hierarchical levels in the Test Lab module.              
7. The test sets tree can contain folders at the main level and subfolders below the main folders. For each folder in the test sets tree, you define a test set and add test instances to it. You start a test sets tree by adding a folder to the Root folder.
8. After you have created test sets, you assign test set folders to cycles defined in the releases tree in the Releases module.
9. A cycle represents a development and QA cycle based on the project timeline.
10. Quality Center enables you to control the execution of tests in a test set. You can set conditions, and schedule the date and time for executing your tests. You can also set the sequence in which to execute the tests. 
11. (Lets read more)
12. Once you have defined test sets, you can begin executing the tests. You can select all the tests in a test set, or specific tests. Your selection can include both automated and manual tests.
13. When you run a test manually, you execute the test steps that you defined during test planning. You pass or fail each step, depending on whether the application’s actual results match the expected output. When you run a manual test, email is sent to a designated tester, requesting that they run the manual test.
14. When you run an automated test, the selected testing tool opens automatically, runs the test, and exports the test results to Quality Center. You can also run an automated system test to provide system information, capture a desktop image, or restart a machine.
15. If a defect has been detected, you can create a new defect and link it to the test run, or link an already-existing defect with the test run.
16. You can validate test results regularly by viewing run data and by generating reports and graphs.
17. Execution Flow tab - In the Execution Flow, your test data is organized and displayed in a diagram. You use the Execution Flow to control the way your tests are executed. You can specify when and under what conditions you want a test to be executed.
18. Automation tab - Displays email notification rules and On Failure instructions for the test set currently selected in the test sets tree.
19. Select Tests pane - Displays tests in the right pane to enable you to add tests to a test set. To open this pane, click the Select Tests button. The Select Tests pane contains two tabs. The Test Plan Tree tab displays the test plan tree. The Requirements Tree tab displays tests according to associated requirements.
20. Live Analysis tab - A graphical representation of test data related to the selected test set folder in the test set tree.
21. Right-click a test in the Execution Grid or Execution Flow, and choose Go to Test in Test Plan Tree to open the Test Plan module and highlight the selected test in the test plan tree.
22. You can access the Test Lab menu bar from the Test Lab module by pressing the shortcut key F9.
23. The Test Lab module includes the following toolbars: Test Set and Select Tests. In addition, you can use the toolbars in the Execution Grid tab and Execution Flow tab.
24. In the Execution Grid, your test data is organized and displayed in a grid. Each line in the grid displays a separate test record.
25. Run - If you select a manual test, opens the Manual Runner dialog box to run the test. If you select an automated test, opens the Automatic Runner dialog box to run the test. It also includes the following options:
26. Run Manually - Runs an automated test manually.
27. Continue Manual Run - Resumes a manual test run.
28. Run Test Set - Opens the Automatic Runner dialog box to run the test set. Test sets can include both manual and automated tests
29. The Execution Grid displays test planning and test run data columns.
30. Status - The status of the last test run. Execution status can be one of the following: Failed, N/A, No Run, Not Completed, Passed.
31. You can add user-defined fields and change the label of any of the fields in the Execution Grid.
32. You can use the Script Editor to restrict and dynamically change the fields and values in the Execution Grid.
33. Add Time Dependency to Flow. Adds a time dependency icon to the  diagram. To create a time dependency for a test, link the arrow from the icon to a test in the Execution Flow. The default time dependency is the Quality Center server’s current date and time.
34. Categories of test sets are as follows:

34. By default, the uppermost level in a test sets tree is the Root folder.
35. You cannot delete the Root folder or add test sets directly to it. Under the Root folder, the Unattached folder contains all test sets no longer associated with a folder. You cannot add a test set to the Unattached folder. When you delete a folder, you can instruct the Test Lab module to move the folder's test sets to the Unattached folder or to permanently delete the test sets.
36. A folder name cannot include the following characters: \ ^ *
37. A test set name cannot include the following characters: \ ^ , " *
38. Quality Center Starter Edition: Assigning test set folders to cycles is unavailable.
39. Total test instances - The total number of test instances in the selected test set folder.
40. Remaining test instances to run - The total number of test instances in the selected test set folder that have not yet run.
41. Quality Center Enterprise and Premier Editions: In Baseline, select a baseline to which to pin the test set.
42. In ITG Request Id, add the IT Governance request ID. This is relevant only when integrating with an IT Governance tool.
43. In the Automation tab, click the Notifications link to instruct Quality Center to send email to specified users if certain events occur. Click the On Failure link to set rules for the automated tests in the test set in the event of a test failure.
44. After you have defined a test set, you can add manual and automated tests from the test plan tree, or tests covering requirements from the requirements tree, to the test set. You can also include instances of the same test in different test sets or add more than one instance to the same test set.
45. You can also add tests by double-clicking or dragging a folder or test in the test plan tree to the Execution Grid or Execution Flow.
46. You can also add tests by double-clicking or dragging a test or requirement in the Requirements Tree tab to the Execution Grid or Execution Flow.
47. If any of the tests you are adding are already in the test set, the Create Test Instance dialog box opens. It displays the tests that already exist in the test set and how many instances there are. Select the tests you still want to add to the test set and click Create.
48. If the test you are adding has parameters that have not been assigned actual values, the Parameters of Test dialog box opens. Assign actual values for the parameters. These values will be used for all test runs of the test.
49. To add all tests that cover a selected requirement, select the requirement and click the Add Tests Covering Requirement button. To add all tests that cover a selected requirement and its children, select the requirement. Click the Add Tests Covering Requirement arrow and choose Add Tests Covering Requirement and Children.
50. You can instruct Quality Center to send email to a specified user if any of the following events occur for a test set:

a.       Any test in the test set fails. A test in the test set fails due to reasons other than the test logic itself. Environmental failure could include, for example, function calls not returning, access violations, version incompatibility between application components, a missing DLL, inadequate permissions, and many other reasons.

b.            All tests in the test set that were run have finished running. Note that this does    not include tests that were not run.

51. To send an email to a user, the user must have a valid email address set up in their user properties.
52. You can set On Failure rules for a test set which instruct Quality Center in the event that an automated test in the test set fails. This includes instructions on how many times the test should be rerun, and the cleanup test that should be run before the test is rerun. For any automated test in the test set, you can change the default On Failure rules.
53. On the final failure of any test in the test set, you can instruct Quality Center to: Do nothing, Stop the test set, Run the test set again a specified number of times.
54. You can also use the Run Events view in the Test Instance Properties dialog box to set the On Failure rules for a test in a test set.
55. You can search for a folder or test set in the test sets tree. If you have applied filters to the test sets tree, the Test Lab module restricts the search to the test sets currently displayed.
56. In the Value To Find box, type the name (or part of the name) of the folder or test set. You cannot use the asterisk (*) wildcard. Note that the search is not case sensitive.
57. You can replace field values in the Execution Grid using the Replace command.
58. To replace the found item and find the next occurrence, click Replace. To replace all occurrences of the value in the grid, click Replace All.
59. You can remove tests from a test set.
60. You can copy a test set within the same project. Test run information is not copied.
61. You can copy test sets from one project to another. If the test sets contain calls to other tests, or if the test sets are dependent on test resources, you can instruct Quality Center to copy them using one of the following methods:

a.       Copy test sets and link them to existing called tests and related test resources in the target project. If a called test or a related test resource does not exist in the target project, Quality Center copies it to the target project.

b.      Copy test sets along with called tests and related test resources into the target project.

c.       Copy test sets without copying called tests and related test resources into the target project.  

62. To copy test sets or test set folders across projects, both projects must use the same Quality Center version and patch level. When copying test sets or test set folders, test run information is not copied.
63. Copy test sets/test set folders and link to existing related entities. Quality Center copies the test sets or test set folders and pastes them into the target project. The copied test sets or test set folders are linked to existing test resources and called tests with the same name and path. If a related test resource or a test does not exist in the target project, Quality Center copies it to the target project.
64. Copy test sets/test set folders and related entities. Quality Center copies the test sets or test set folders along with the related test resources and called tests, and pastes them into the target project. If a related test resource or a called test already exists in the target project, the copied related test resource or called test is renamed to resolve the duplicate name.
65. Copy test sets/test set folders and related entities. Quality Center copies the test sets or test set folders without copying the related test resources or called tests, and pastes them into the target project. The copied items are not linked to any related entities.
66. You can copy a test set and paste its URL as a link. The test set itself is not copied. Instead, you can paste the address into another location, such as an email or a document. Clicking on the link opens Quality Center and takes you to the test set.
67. You can rename a test set or test set folder. Note that you cannot rename the default test set.
68. You can delete a folder and move all of its test sets to the Unattached folder, or you can permanently delete a folder with all its test sets.
69. Select Delete folders only to delete the folder and move all test sets to the the Unattached folder. The Unattached folder contains all test sets that are no longer associated with a folder.
70. Select Delete folders and test sets to permanently delete the folder and all its test sets.
71. You can delete a test set from a project. Note that you cannot delete the default test set.
72. Resetting a test set changes the status of all the tests in the test set to No Run. When resetting a test set, you can also decide if you want to delete the test run results.
73. To instruct the Test Lab module not to delete the test run results for the test set, clear the Delete all the test run results in test set check box.
74. You can use the Purge Runs wizard to delete old test run results in your project.

You can also drag the test sets between lists.

75. The Test Lab module enables you to control the execution of the tests in a test set.
76. In the Execution Flow, you can specify a date and time, and set conditions for executing a test. A condition is based on the results of another specified test in the Execution Flow. By setting conditions, you can instruct the Test Lab module to postpone execution of the current test until the other specified test has either finished running or passed. You can also set the sequence in which to execute the tests.
77. In the Execution Flow, a test set is represented by the Test Set  icon. Eachtest in the diagram is represented by a test icon.
78. A dashed line  arrow indicates that the test is to be executed after the previous test, with no conditions.
79. A solid line  arrow indicates a condition and can be blue or green.
80. If the solid line is blue, it indicates that the test is to be executed only if the previous test has status Finished.
81. If the solid line is green, it indicates that the test is to be executed only if the previous test has status Passed.
82. When a test is time-dependent, a Time Dependency  icon is added to the diagram.
83. The Execution Flow tab enables you to watch the execution process as it happens and to control the way your tests are executed. You can specify under what conditions you want a test to be executed (execution conditions) and when (time dependency).
84. In the Test box, select the test on which you want the current test to be dependent.

a.       Select Finished (default) to instruct the Test Lab module to execute the current test only after the specified test has finished executing.

b.      Select Passed to instruct the Test Lab module to execute the current test only if the specified test has finished executing and has passed.

85. You can also add a condition directly in the Execution Flow. Click a test icon (not the test name) and drag the arrow to another test. By default, the condition is set to Finished. To change the condition, double-click the condition arrow and select Passed.
86. You can schedule the test run date and time by clicking the Add Time Dependency To Flow button, and linking the arrow from the icon to a test. Double-click the icon to set the time in the Time Dependency dialog box. The default time dependency is the Quality Center server’s current date and time.
87. You can modify and delete conditions and time dependency information for a test run schedule.
88. You can delete a single condition or all conditions connected to a test. You can delete all execution conditions and time dependencies in a test set.
89. You can modify the date and time of a scheduled test run. You can delete a specified time dependency.
90. Deleting All Conditions and Dependencies -  You can delete all execution conditions and time dependencies in a test set.
91. If your test set includes both execution conditions and time dependencies, the Remove All Execution Conditions dialog box opens. Choose one of the following options:

a.       Run conditions and time dependencies. Removes the execution conditions and time dependencies from your test set.

b.      Run conditions only. Removes the execution conditions from your test set.

c.       Time dependencies only. Removes the time dependencies from your test set.

92. You can change the way the Execution Flow is displayed. This includes zooming in and out of the diagram, rearranging the tests in a hierarchical layout, refreshing the diagram, and displaying full test names in the diagram. You can also copy the diagram to the Clipboard.
93. Choose Tests > Flow > Show Full Test Names to display full test names in the Execution Flow diagram. By default, long names are truncated.
94. When you run tests manually, you follow the test steps and perform operations on the application under test. You pass or fail each step, depending on whether the actual application results match the expected output. You can run both manual and automated tests manually.
95. You can execute tests more than once in the same set. Each execution is considered a new test run.
96. After test execution is complete, you can view a summary of test results in the Test Lab module. The updated status for each test run appears in the Execution Grid. Results for each test step appear in the Last Run Result pane. You can view more detailed results in the Test Instance Properties dialog box.
97. While executing a test manually you can modify the test steps. You can choose to save the modifications in the original test in the Test Plan module and the test instance in the Test Lab module. Alternatively, you can save them for the current test run only.
98. You can also resume a manual test run that was paused during execution. The Continue Manual Run command continues the last run of the elected test. If you want to resume running a previous run, click the Test Instance Properties button, select All Runs on the sidebar and choose the test run you want to resume. Click the Continue button.
99. Click the Operating System Info link to display operating system information. The Operating System Information dialog box opens. You can edit the following operating system information: Operating System, OS Service Pack, OS Build Number.
100. You can conveniently read each test step and record the results using the compact view display of this dialog box. To open this display, click the Compact View button. To return to the steps grid, click the Back to Steps Grid button. The Test Lab module enables you to update changes made to called tests in the current test run only. The called tests are not affected.
101. You can run tests automatically, directly from Quality Center. You can choose to run tests on your machine or on remote hosts.
102. A host is any machine connected to your network on which a testing tool has already been installed.
103. When you run a manual test from the Automatic Runner dialog box, Quality Center notifies a designated tester by email to run the test on a specified host.
104. You can also run an automated system test to provide system information, capture a desktop image, or restart a machine.
105. When you run an automated test, Quality Center opens the selected testing tool automatically, runs the test, and exports the test results to Quality Center.
106. Before running a test on a remote host, you must first set up hosts in the Host Manager dialog box.
107. To run the same test concurrently on multiple remote hosts, add multiple instances of the test to your test set.
108. To run several test sets concurrently on multiple remote hosts, open a new Automatic Runner dialog box instance for each test set.
109. To enable Quality Center to run QuickTest Professional or WinRunner tests on a remote host, open the relevant application on the remote host and select the required option.
110. If you run a WinRunner test in batch mode, each test that is called from the batch test is considered a separate test, and not part of the batch test itself. Any test called from the batch test that is not already included in the test set is added to the test set at the end of the test run.
111. Before running a QuickTest test, Quality Center loads the QuickTest add-ins that are associated with the selected test. You must ensure that you run the test on a machine on which the required QuickTest add-ins are installed.
112. When you run QuickTest Professional tests from the Test Lab module, they are automatically run in Fast mode. They cannot be run in Normal mode.
113. If you select a host group, Quality Center runs the test on the first available host in the group, not on every host in the group. (Run on Host > select Host)
114. For an automated test, Quality Center opens the selected testing tool automatically and runs the test. Test execution commences only when the selected host becomes available to run tests.
115. If you selected Enable Log before you started the test run, you can view the Execution Log by choosing Run > View Execution Log.
116. The Execution Log contains details about the executed tests, such as the project name, user name, and test set name. For each test, the log includes the date and time of the run, the host, and a description of the run.
117. You can only view the Execution Log if you selected Enable Log in the Automatic Runner dialog box before you executed the test.
118. To synchronize the hosts in the Available Hosts list with the hosts in the Network Neighborhood directory, click the Get Hosts on the Network arrow and choose Synchronize Hosts in the Project with Hosts on Net. Quality Center adds hosts found in the Network Neighborhood directory and deletes hosts that were not found in the Network Neighborhood directory.
119. You can change the order of the tests in the Execution Grid. Quality Center runs the tests according to the specified order, grouped by host type.
120. When determining the order for running tests, Quality Center first checks the Execution Flow. The order you define in the Execution Grid is only used if there are no conditions set in the Execution Flow.
121. You can also drag the tests up or down.
122. After running test instances, you analyze the test results to determine which test instances failed, and which steps caused the failure.
123. Use the Test Instance Properties dialog box to view test run details, compare the results of the most recent test run with previous runs, manage attachments, view test run configuration information, view linked defects, and view a history of test run changes.
124. You can change the label of any of the fields in the Details tab. You can also add user-defined fields to the Details view.

  

125. You can view or set the test parameter values for a manual test instance or an automated test instance in the Configuration view. You can set actual parameter values for manual test instances. Actual values that you assign for parameters in the test instance are used for all test runs of the test instance.
126. When defining the WinRunnerCommandLine parameter, you must specify the path within quotes. For example: -ini “C:\program files\wrun.ini”
127. If you change the failure rules in the Run Events view, your changes are implemented in the next test run. You can also set On Failure rules for a test by choosing Test Sets > Automation > On Failure and clicking the Settings per Test button.
128. If coverage between test instances and requirements is enabled with the ALLOW_REQ_COVERAGE_BY_TEST_INSTANCE parameter, click Linkage and Coverage on the sidebar.