HP0-M31 Quality Center Certification Preparation 3 - Test Plan Module

TEST PLAN

1. Developing a clear and concise test plan is fundamental to successful application testing. A good test plan enables you to assess the quality of your application at any point in the application management process.
2. Developing a test plan consists of the following: Define Testing Strategy, Define Test Subjects, Design Tests, Create Requirements Coverage, Design Test Steps, Automate Tests, Analyze Test Plan, Establish Baseline.
3. The test plan tree is a graphical representation of your test plan. It is a hierarchical list of tests organized according to topic, which describes the set of tests you will implement in order to meet your quality requirements.
4. You can link a test to specific defects.
5. You can include parameters in your manual tests. This enables you to run the same test repeatedly and assign the parameters different values.
6. Link each test in the test plan tree with a requirement or requirements in the requirements tree. By defining requirements coverage for a test, you can keep track of the relationship between the tests in your test plan and your original requirements.
7. For manual tests you define steps, execute them on your application, and record the results of each step. Use manual tests in cases where the test requires a response by the tester. Manual tests include usability tests, onetime tests, tests that need to be run immediately, tests requiring knowledge of the application, and tests without predictable results.
8. You can include a step that calls another manual test. This is useful if you have common steps that you want to perform as part of other tests.
9. Automating a test allows unattended execution of the test at high speed. It also makes the test reusable and repeatable.
10. We automate functional, benchmark, unit, stress and load tests, as well as tests requiring detailed information about applications. 
11. (Lets read more)
12. Factors influencing test automation include frequency of execution, volume of data input, length of execution time, and complexity.
13. For automated tests, you can first design test steps and automate them by generating a test script. The test script can be for WinRunner, QuickTest Professional, LoadRunner, QAInspect, or Visual API-XP.
14. You can also create automated system tests that provide system information for a machine, capture a desktop image, or restart a machine.
15. Review your test plan to determine how well it meets the goals that you defined at the beginning of the application management process. Then, analyze your test plan by generating reports and graphs.
16. To best ensure the success of the application management process, analyze your test plan throughout the process. Review the plan, and determine whether or not it matches your testing goals. Make adjustments to your test plan accordingly.
17. After your test plan has been reviewed and approved, you can create a baseline. A baseline provides you with a snapshot of your test plan at a specific point in time. You can use a baseline to mark any significant milestone in the application life cycle. The baseline then serves as a point of reference against which changes can be compared.
18. Parameters can be incorporated in the test’s design steps.
19. Live Analysis tab - A graphical representation of test data related to the selected subject folder in the test plan tree.
20. To find a specific test by Test ID in the test plan tree, choose Tests > Go to Test, and type the test ID.
21. The Versions menu is available in a version control enabled project. It contains commands that enable you to check in and check out tests, undo a checkout, or view all the tests you have checked out.
22. You can access the Test Plan menu bar from the Test Plan module by pressing the shortcut key F9.
23. The Test Grid displays all the tests in a Quality Center project. Each row displays a separate test record. Each column represents a separate data item.
24. You can copy several automated tests and paste them in another project, or you can delete several tests at once. In addition, you can save the grid information in several formats, including a text file, Word document, HTML document, XML document, and Excel spreadsheet.
25. To find a specific test by Test ID in the Test Grid, choose Test > Go to Test, and type the test ID. To display the test ID, select the Test ID column using the Select Columns dialog box.
26. Status - The planning status of the test. The default status is Design.
27. Template - Indicates whether the manual test or QuickTest Professional test is a test template. The value in this column is Y if the test is a test template; N or empty otherwise.
28. You can add user-defined fields and change the label of any of the fields in the Test Grid. You can also customize project lists.
29. You can use the Script Editor to restrict and dynamically change the fields and values in the Test Grid.
30. The Test Plan module enables you to divide your application according to functionality.
31. You divide your application into units, or subjects, by creating a test plan tree. This is a graphical representation of your test plan, displaying your tests according to the hierarchical relationship of their functions.
32. After you define subjects in the tree, you decide which tests to create for each subject and add them to the tree. At this stage, you define basic information about the test, such as its name, status, and the designer. You can also attach a file, URL, application snapshot or system information to illustrate a test. Afterwards, you define the test steps. Test steps contain detailed instructions on how to execute a test and evaluate the results.
33. There are a number of methods for organizing your test plan by subject. For example, you could define subjects according to:

a)      Application functionality—such as editing, file operations, and reporting

b)      Type of testing—such as functional, user interface, performance, and load

34. Developing and editing a test plan tree requires appropriate user permissions.
35. You define a hierarchical framework for your test plan by creating a test plan tree that may contain folders and subfolders.
36. In addition to creating a test plan tree directly in Quality Center, you can also import test plan data from Microsoft Word or Microsoft Excel to your Quality Center project.
37. A folder name cannot include the following characters: \ ^ *
38. Each test should have a distinct objective, such as verifying a specific function or system requirement. The tests you define should be based on the goals you set at the beginning of the application management process.
39. You can automatically create tests based directly on your requirements in the Requirements module.
40. If you have installed the QuickTest Professional Add-in on your machine, the Create New Test dialog box includes the Template box.
41. A test name cannot include the following characters: \ / : " ? < > | * % '
42. You create your new test based on another QuickTest test, defined as a template test. The template test is copied to your new test, without the test results.
43. To set the QuickTest add-ins that Quality Center associates with a new QuickTest test, choose a template test that lists the appropriate add-ins. Alternatively, use the default template test provided on your Quality Center client. This test loads the Web and ActiveX add-ins by default.
44. To set a QuickTest Professional test as a template test, right-click the test in the test plan tree, and choose Mark as Template Test.
45. You can change the label of any of the test detail fields. You can also add user-defined fields to the test details.

46. You can send email about a test to other users in your project. This enables you to routinely inform development and quality assurance personnel about the status of your tests. A Go To Test link is included in the email, enabling the recipient to go directly to the test.
47. By default, Quality Center sends email in HTML format. To send email as plain text instead, edit the MAIL_FORMAT parameter in the Site Configuration tab in Site Administration.
48. You can automatically send the email to a specific user type. This can be any test column with a user name value, including user-defined fields. Click the Send by Email arrow and choose an option.
49. You can search for a folder or test in the test plan tree. If you have applied filters to the test plan tree, the search is restricted to the tests currently displayed.
50. You can copy tests within the same project or between projects.
51. You can copy tests and subject folders within the same project.
52. You can copy tests from one project to another. If the tests contain calls to other tests, or if the tests are dependent on test resources, you can instruct Quality Center to copy them using one of the following methods:

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

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

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

53. To copy tests across projects, both projects must use the same Quality Center version and patch level.
54. Copy tests/subject folders and link to existing related entities. uality Center copies the tests or subject folders and pastes them into the target project. The copied tests or subject folders are linked to existing test resources and called tests with the same name and path. If a related test
55. resource or a test does not exist in the target project, Quality Center copies it to the target project.
56. Copy tests/subject folders and related entities. Quality Center copies the tests or subject 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.
57. Copy tests/subject folders without copying related entities. Quality Center copies the tests or subject 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.
58. You can copy a test and paste its URL as a link. The test 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 up Quality Center and takes you to the test. If you are not already logged in, Quality Center first prompts for login details.
59. By default, subjects are displayed in a test plan tree in alphabetical order. You can sort the folders in the test plan tree and create a custom sort according to your needs. You must have project administrator permissions to create a custom sort.
60. You can rename or delete subject folders and tests in the test plan tree.
61. You can rename a folder or a test.
62. You can delete a folder or test from the test plan tree. When you delete a folder, you can choose to delete the folder only, or the folder, its subfolders, and tests.
63. If you choose to delete a folder and tests, all subfolders and tests under the selected folder are deleted permanently.
64. If you delete a test, the test and test script are deleted permanently.
65. If dependencies are defined for a test, deleting the test may impact these dependencies.
66. Deleting a test deletes all previous versions of the test.
67. To keep track of the relationship between your requirements and tests, you add links between them.
68. In the Test Plan module, you create requirements coverage by selecting requirements to link to a test. Alternatively, in the Requirements module, you create test coverage by selecting tests to link to a requirement. A test can cover more than one requirement, and a requirement can be covered by more than one test.
69. You can also create coverage between test instances and requirements. To enable this feature use the ALLOW_REQ_COVERAGE_BY_TEST_INSTANCE parameter in Site Administration.
70. You can link requirements and tests to defects. This can help you ensure compliance with your testing needs throughout the application management process.
71. If a requirement changes, you can immediately identify which tests and defects are affected,
72. and who is responsible.
73. During test planning, when you select a test in the test plan tree, the test’s requirements coverage is displayed in the Req Coverage tab. The coverage grid lists the requirements that are covered by the selected test. You can view, add, and remove requirements from the coverage grid. The columns in the Req Coverage tab display data for the covered requirements.
74. Coverage Type - The type of coverage. The value in this column can be “Test” or “Test Instance”.
75. You can set column appearance and order in the coverage grid. You can view requirements in the coverage grid with their full path. In addition, you can instruct Quality Center to go to a requirement in the requirements tree.
76. To add requirements coverage to a test, you select one or more requirements from the requirements tree. By default you cannot add coverage for the following requirement types: Business, Folder, and Group.
77. Coverage is available only for the following requirement types: Functional, Testing, and Undefined.
78. Requirements coverage is created automatically when you convert a requirement to a test. Therefore, even if you have not yet added requirements coverage, it may already exist.
79. Test coverage is created automatically when you generate a test from a requirement. Therefore, even if you have not yet added test coverage, it may already exist.
80. You can also define requirements coverage by dragging a requirement in the requirements tree to the coverage grid. The requirement is added to the coverage grid without its child requirements.
81. You can remove requirements from a test’s requirements coverage.
82. You can link tests to requirements using the Requirements module. When you select a requirement in the requirements tree, the requirement’s test coverage is displayed in the Test Coverage tab. The coverage grid lists the tests that cover the selected requirement. You can view, add, and remove tests from the coverage grid. The columns in the Test Coverage grid display data for the tests that cover the requirement.
83. You can filter the coverage grid, and show or hide full coverage. You can also instruct Quality Center to go to a test in the test plan tree.
84. You can also define test coverage by dragging a test or a test folder from the Test Plan Tree tab to the coverage grid.
85. You can remove tests from a requirement’s test coverage.
86. In the Requirements module, you can use the Coverage Analysis view to examine the status of your requirements. This enables you to understand the breakdown of child requirements according to test coverage. You can set the coverage analysis by cycle, enabling you to view in the analysis only the coverage of runs that are assigned to specific cycles.
87. Direct Cover Status - The current status of the requirement, determined according to the status of the tests associated with the requirement. For example, if the direct cover status is “Not Completed”, then one or more tests covered by the requirement have not been completed.
88. Coverage Analysis - This column graphically displays the direct cover status of the requirement and its children. Requirements which do not match the current filter, or requirements with direct cover status “N/A” are not counted in the analysis.
89. You build tests in the Test Plan module by defining design steps: detailed, step-by-step instructions on how to execute a test. A step includes the actions to perform on your application, the input to enter, and the expected output. You define steps for a test after you add the test to the test plan tree and define basic test information.
90. You can create design steps for both manual and automated tests. For a manual test, you complete test planning and design once you finish creating the steps. Using your plan, you can begin execution immediately. Automated tests require that you create automated test scripts using HP testing tools, or custom, or third-party testing tools.
91. You can create a design step that calls another manual test. This is useful if you have common steps that you often want to perform as parts of other tests.
92. You add design steps to a test using the Design Step Editor.
93. You can copy steps from an existing test.
94. If you add an attachment to a design step, a copy of the attachment is made every time the test is run.
95. In a test, you can include a design step that calls a manual test. When you run the calling test, it includes the steps and parameters from the called test. This is useful if you have common steps you often want to perform as part of other tests.
96. To easily identify tests that you will call from other tests, you can mark the called tests as template tests.
97. Template tests often include test parameters. These are useful if you want to run the template test with different data according to the type of test that is calling it.
98. You can mark a manual test in the test plan tree as a template test. You do not need to mark a test as a template test to be able to call it. Marking a test as a template test makes selecting the template test easier when you call it from another test.
99. The manual test icon changes from gray to white if a test is changed to a template test.
100. In a test, you can include a step that calls another manual test. When you run the calling test, its design steps include the steps from the called test.
101. You can edit existing design steps or add new ones.
102. You can navigate between steps in the Design Step Editor using shortcut keys. Use ALT+HOME to access the first step, ALT+LEFT to access the previous step, ALT+RIGHT to access the next step, and ALT+END to access the last step.
103. You can change the order of the steps in a test.
104. You can renumber your steps after you add, delete, or reorder steps in a test.
105. You can adjust the row size of the steps in a test. This enables you to view all the text in the Description or Expected Result columns if the text is long.
106. You can remove steps from a test.
107. You can copy design steps from another test in the same project. Parameters used in the design step test are copied to the target test.
108. You can copy design steps in a test from one project to another. If the design steps contain calls to other tests, you can instruct Quality Center to copy them using one of the following methods:

a)      Copy design steps and link them to existing tests in the target project. If a called test does not exist in the target project, Quality Center copies it to the target project.

b)      Copy design steps and called tests into the target project.

c)       Copy design steps without copying called tests into the target project. Parameters used in the design step test are copied to the target test.

109. To copy design steps across projects, both projects must use the same Quality Center version and patch level.
110. Copy design steps and link to existing related entities. Quality Center copies the design steps and pastes them into the target project. The copied design steps are linked to existing tests with the same name. If a called test does not exist in the target project, Quality Center copies it to the target project.
111. Copy design steps and related entities. Quality Center copies the design steps and called tests and pastes them into the target project. If a called test name already exists in the target project, the copied called test is renamed to resolve the duplicate test name.
112. Copy design steps without copying related entities. Quality Center copies the design steps without copying the called tests, and pastes them into the target project. The copied design steps are not linked to any called tests.
113. To increase the flexibility of manual tests, you can add parameters to design steps. This enables you to run the same test repeatedly with different data each time.
114. A test parameter is a variable that can be assigned a value outside the test from which it is defined.
115. Manual tests with parameters can be called from other tests. This is useful if you have common steps you often want to perform as part of other tests
116. To work with parameters in manual tests: Define parameters in a manual test, Add parameters to a design step. At different stages of designing your test, assign parameter values that are
117. used during test runs.
118. A parameter name may not include the following characters: ~ ? ’ < > %
119. If you rename the parameter, Quality Center creates a new parameter with the new name, in addition to the original parameter.
120. You can add a parameter to the description or expected results of a manual design step. You can use existing parameters, or define new parameters.
121. If you apply formatting to a parameter name in a design step, you must apply the same formatting to the entire parameter name, including the <<< and >>> characters. For example, if you want to italicize the parameter <<<password>>>, you must italicize the entire string <<<password>>> and not just the word password.
122. Before you run a test, Quality Center prompts you to assign actual values to the parameters included in the test. The actual value is the data that is used during the test run. You can take the parameter default values and use them as actual values.
123. Quality Center prompts you to assign actual values at three stages of designing your test. According to your testing policy, you can assign actual values at any of these stages:

a)      When you call a test with parameters. If you assign actual values to parameters when you call a test, the values are automatically applied to each test instance that you create from the calling test.

b)      When you create a test instance. If you assign actual values to parameters when you create a test instance, the values are automatically applied to each run of the test instance. You can also assign actual values to test instances within the test instance configuration.

c)       When you run a test. If you assign actual values to parameters for a test run, the values apply to that test run only. If you do not assign actual values at this stage, the test will run with null values.

124. At each of these stages, you can only assign values to parameters that have not already been assigned values.
125. If you delete a parameter that is included in a design step, the parameter in the design step is replaced by regular text, using the syntax: <parameter name>.
126. If you choose to automate a test, you can generate a test script and run the test using WinRunner, QuickTest Professional, LoadRunner, or Visual API-XP.
127. Tests that will run with each new version of your application are good candidates for automation. These include sanity tests that check basic functionality across an entire application. Each time there is a new version of the application, you run these tests to check the stability of the new
128. version, before proceeding to more in-depth testing.
129. Tests that use multiple data values for the same operation (data-driven tests) are also good candidates for automation. Running the same test manually— each time with a different set of input data—can be tedious and ineffective. By creating an automated data-driven test, you can run a single test with multiple sets of data.
130. It is also recommended that you automate tests that are run many times (stress tests) and tests that check a multi-user client/server system (load tests).
131. The more user involvement a test requires, the less appropriate it is to automate.
132. The following describes test cases that should not be automated:

a)      Usability tests—tests providing usage models that check how easy the application is to use.

b)      Tests that you only have to run once.

c)       Tests that you need to run immediately.

d)      Tests based on user intuition and knowledge of the application.

e)      Tests with no predictable results.

133. After you have created steps for a manual test, you can generate a test script skeleton in which you can write scripts to run the test as an automated test. Any text that appeared in the steps of the manual test is listed as comments in the generated test script. If the manual test has parameters, they are also listed as comment text.
134. The QUICKTEST_TEST test type is only available if you have installed the appropriate add-in from the HP Quality Center Add-ins page.
135. Using system tests, you can instruct Quality Center to provide system information for a machine, capture a desktop image, or restart a machine.
136. To run a system test, you must install the System Test Remote Agent Add-in and the HP Quality Center Connectivity Add-in on the machine where the test is to be run.
137. When running a system test, the following steps can be created:

a)      SysInfo. Collection of system information

b)      Snapshot. Capture of desktop image

c)       Reboot Start and Reboot Finish. Machine restart

138. You can view details for each of these steps after your system test has finished running. You can also view the system information that has been retrieved—such as CPU, memory, and processes running on the machine— and an image of the machine executing the system test.
139. To use the Restart the computer option, you must enable auto login on your machine. Choose Start > Programs > HP Quality Center SystemTest Agent > SystemTest Agent (configuration). The Auto Restart Settings dialog box opens. By default, User Name and Domain are read-only. Type your password and click OK.
140. To select a different user name, reopen the Auto Restart Settings dialog box. User Name and Domain are no longer read-only. Modify the values and click OK.
141. Once you have defined your system test and added it to a test set in the Test Lab module, you can run it. System tests can be run on your own machine, or on multiple remote host machines connected to your network.
142. You can manage a set of resources to be used by your tests in the Test Resources module.
143. You can organize your resources by defining a hierarchical test resource tree containing resource folders and resources. For each resource in the tree, you select and upload a set of resource files to the Quality Center repository. These files can be used by one or more tests.
144. You can define dependencies between resources and tests using QuickTest Professional. You can also define dependencies between resources and tests by writing your own application or script.
145. After you define dependencies, if you attempt to delete the resource, Quality Center warns you that this may affect tests that depend on it. When copying one of the tests that depend on the resource between projects, Quality Center enables you to choose to copy the resource as well as the test.
146. When a Quality Center project with Business Process Testing is connected to QuickTest Professional, a BPT Resources folder is created automatically in the tree. The BPT Resources folder contains all the QuickTest resources available for business components in the project.
147. You can add user-defined fields and change the label of any of the fields in the Test Resources module.
148. You can use the Script Editor to restrict and dynamically change the fields and values in the Test Resources module.
149. Using the Resource Viewer tab, you can upload files for each resource or folder in the test resource tree to the Quality Center repository. You can also download files to a local directory.
150. To view the resource content, you must install the relevant add-in or extension.
151. You can copy resources from one project to another. If the test resources are dependent on other test resources, or if the test resources contain calls to other tests, you can instruct Quality Center to copy them using one of the following methods:

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

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

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

152. To copy test resources across projects, both projects must use the same Quality Center version and patch level.
153. Copy resources and link to existing related entities. Quality Center copies the test resources or folders and pastes them into the target project. The copied test resources or folders are linked to existing test resources and called tests with the same name. If a related test resource or a test does not exist in the target project, Quality Center copies it to the target project.
154. Copy resources and related entities. Quality Center copies the test resources or 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.
155. Copy resources without copying related entities. Quality Center copies the test resources or 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.
156. You can copy a resource from the test resource tree and paste its URL as a link. The resource 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 up Quality Center and takes you to the resource file or folder. If you are not already logged in, Quality Center first prompts for login details.
157. You can send email about a resource to other users. This enables you to routinely inform development and quality assurance personnel about the status of your resources. A link is included in the email, enabling the recipient to go directly to the resource.
158. You can move a resource to a different location in the test resource tree. The root folder cannot be moved.
159. You can also move a resource to a different location in the test resource tree by dragging it.
160. You can rename a resource or a folder in the test resource tree.
161. You can delete resources and folders from the test resource tree. If other entities depend on the resource, deleting the resource may impact these related entities.
162. You can view a history of baselines in which the test resource appears. You can also compare two baseline versions.
163. You can view all previous versions of a test resource.
164. Dependencies define relationships between entities such as tests, components, and test resources. You can view the entities used by a selected entity, and the entities that a selected entity is using.
165. When analyzing the impact of a change proposed to a specific entity, the dependencies indicate the other entities that the change might affect.
166. Dependency relationships are displayed in the Dependencies tab. This tab is available from the Test Plan and Test Resources modules. Depending on your Quality Center license, you may also view the Dependencies tab from the Business Components module.
167. You can define dependencies between entities using other HP testing tools, for example, QuickTest Professional. You can also define dependencies between entities by writing your own application.
168. This tab contains the Used By and Using grids. The Used By grid displays entities that depend on a selected entity. The Using grid displays the entities that a selected entity depends on.
169. When checking out an old version of an entity, the dependencies tab does not display any dependencies to entities that no longer exist.
170. Owner / Related Type - The type of the associated entity that uses the selected entity. It includes the following types:

a)      Resource - A resource listed in the test resource tree.

b)      Test - A test listed in the test plan tree.

c)       Component - Depending on your Quality Center license, you may also view the component listed in the business component tree.