Introduction to Quality Center: Quality Center is a versatile tool brought out by HP, for managing the complete application testing process. When we say the management of the application testing process; it includes the process of customizing the test project, defining the releases, specifying requirements, planning of tests, execution of tests, tracking of defects, issuing of alerts on changes, and finally analyzing the results. It should not be misunderstood as a tool for testing the functionality of the applications. Not being a testing tool as such, it does not use any scripting language. Or in other words, we can’t write or execute any script in Quality Center. Quality center can be used to write functions in such way that enables us to open the Test script in a performance-testing tool like QuickTest Professional and when desired, we can save it in Quality center. Key Features of Quality Center: Following features render Quality Center as a most versatile test management tool. 1) Maintains a Common Repository 2) Offers Automatic Traceability Matrix 3) Excellent Bug Tracking facility 4) Offers Automatic Reports and Graphs generator How to use the Quality Center: Broadly we can bifurcate our process of using Quality Center into following four Modules or phases. 1) Requirements Module 2) Test Planning Module 3) Test Execution Module 4) Defects Management Module 1) Requirements Module: It comprises of clear identification & validation of all functional and performance requirements expected to be tested in our application. These requirements, once described with ample clarity provide the test team a solid foundation on which the entire testing process is based. The process involves listing out the entire Primary or Main Requirements (Say MR1, MR2, Mr3 etc.) along-with sub-requirements or Child Requirements (Say CR1, CR2, CR3 etc.). For the entire Requirement identified above, a Test is planned. For Manual Testing, the term “Test” refers to creation of a Test Case, while for an Automated Testing, the term “Test” refers to creation of a Test Script. Requirements Module of Quality Center offers facility of defining two types of Requirements Like 1) Defining New Requirement 2) Defining New Child Requirement The Requirement module displays the information through following fields: 1) Author: Displays the user name of the person who created the requirement. By default, this is the login user name. 2) Comments: Displays the comments about the requirement. 3) Creation Date: Means the date on which the requirement was created. By default, the creation date is set to the current database server date. 4) Creation Time: Means the time at which the requirement was created. By default, the creation time is set to the current database server time. 5) Description: A description of the requirement. 6) Direct Cover Status: The current status of the requirement. Various types of requirement status can be like Not Covered, Failed, Not Completed, Passed, No Run, N/A, Not direct cover etc. By default, the status is Not Covered. 7) Modified: Indicates the date the requirement was last changed. 8) Name: The requirement name. 9) Old Type: The type of obsolete requirement. 10) Priority: The priority of the requirement, ranging from low priority (level 1) to urgent priority (level 5). 11) Product: The component of the application on which the requirement is based. 2) Test Plan Module: It comprises of the prime activity i.e. creation of clear and concise Test Plans in line with the requirements formulated in the Requirements Phase. A nicely prepared test plan enables us to assess the quality of our application at any point in the testing process. Before proceeding ahead, with the help of Traceability Matrix, it is ensured that all the requirements have been duly addressed in the Test Plans. Addressing all the requirements, various Test Plans are created either manually or automatically. The process involves following key steps: a) Creation of a folder b) Creation of an empty test. c) Launching of the available functional testing tool like HP – Quickest Professional etc. d) Creation of the Test Scripts. e) Saving the Test Script in the empty script file already created. f) Repetition of above steps till creation of test plans covering all the test requirements gets completed. For maintaining an automatic traceability, it is essential that the tests in the test plan meet our original requirements. Hence links are added to keep track of the relationship between our requirements and the tests. A test can cover more than one requirement, and a requirement can be covered by more than one test, hence linking can be done accordingly. We can link requirements and tests to the defects. This can help you ensure compliance with our testing needs throughout the testing. If a requirement changes, we can immediately identify which tests and defects are affected, and who is responsible for it. 3) Test Lab Module: As the application undergoes changes, the manual and automated tests are run in our project with a view to identify the areas of defects and make judgement on the product quality. The flow of this module is as under a) Creation of Test Sets: A test set is a group of tests in a Quality Center project designed for achieving some particular testing objectives. The process begins with the identification of all the end-to-end scenarios, followed by creation of individual test Sets for every such end-to-end scenario. After creating the test sets, tests set folders are created and assigned to development and QA cycles based on the project timeline. b) Scheduling Test Runs: Quality Center enables us to control the execution of tests in a test set. We can set conditions, and schedule the date and time for executing our tests. We can define the sequence in which to execute the tests. For example, we can define to run “test2” only when “test1” has finished, and run “test3” only if “test1” has passed. c) Running of the Tests: After defining the test sets, we are ready to execute the tests. We can select all the tests in a test set, or some specific tests. Our selection can include both automated and manual tests. We can run either a single test or all the tests in the test set. # Running Tests Manually: When we run a test manually, we execute the test steps defined by us during test planning stage. We declare a step either pass or fail according to the fact whether the actual results of the application matched the expected output or not. # Running Tests Automatically: While running an automated test, the selected testing tool opens automatically, runs the test, and exports the test results to Quality Center. When we run a manual test, an e-mail is automatically sent to the specific tester, prompting to run the manual test. d) Analyzing Test Results: After a test run, the test results are analyzed to identify the failed steps and to determine whether a defect has been detected in our application, or if the expected results of our test need to be updated. In case a defect gets detected, we can create a new defect and link it to the test run, or link an already-existing defect with the test run. After the test execution gets finished the results can be analyzed through the Functional Testing Tool itself (like QuickTest Professional). The identified defects can be directly posted through the QuickTest Professional itself, alternatively the Defects Module of HP Quality Center can be used. 4) Defects Module: This module is like a Bug Tracking Tool and helps us in reporting the design flaws in our application. This provides all the facilities to manage the defects like adding of defects, changing the status of defects and analyzing the defects etc. a) Adding Defects: When a defect is found in the application, it is submitted to the Quality Center project. The project stores the defect information and it can be accessed by the authorized users only say like the members of the development, quality assurance, and support teams. This new defect can be associated with the cycle and release in which it was detected. The new defect can be associated with the test we ran, for future reference b) Reviewing New Defects: During this stage we decide as to which defects needs to be fixed. The project manager usually performs this task. Here we change the status of a new defect to “Open”, and assign it to the concerned member of the development team for fixing. c) Repairing Open Defects: This involves identifying the cause of the defects, modifying and rebuilding the application. Application developers perform such activities. When a defect is repaired, we assign it the status “Fixed”. d) Testing a New Application Build: Involves running of the tests on the new or 2nd build of the application. If the defect does not come up again, we assign it the status “Closed”. However If the defect is detected again, we assign it the status “Reopen”, and it is returned to the previous stage. The quality assurance manager or project manager usually performs this task. Doing testing on 2nd build on wards is called Re-Testing or Regression testing. Repeated testing from the Test Lab Module to Defects Module is carried out till all the defects get fixed. e) Analyzing Defect Data: View data from defect reports to see how many defects were resolved, and how many still remain open. Interconnectivity of Quality Center & QuickTest Professional (QTP): Applications can be tested using following two ways: 1) Through QuickTest Professional: By defining path for Quality Center while being in QuickTest Professional. 2) Through Quality Center: By launching QuickTest Professional while being in Quality Center.
Subscribe to:
Post Comments (Atom)
0 komentar:
Post a Comment