In the world of test, everybody talks about Quality Center (QC for his nickname) from HP Mercury. Everyone talks about the client to the service, from engineers who swear by this fabulous QC … What wonderful world that ours in which all players share the same project, share and use same benchmark test and ensure that business requirements are at the heart of everyone … But … The reality is less glamorous!
Indeed, among the thousands of engineers only a few really know QC and use it properly.
So I write this article in aim to present the basic tool and make some good practices to implement when using a testing repository (I will not write on the administration part of this tool).
Say Uncle, what is a testing repository ?
Or « How from minimum to maximum effort? « . For the answer see the article on the subject.
Say Uncle, there is what in QC?
Before explaining what is inside it clear that it is just a tool shared management of activities test, that his name was former Test Director (or TD).
The interface of QC is relatively « user friendly » (adapted from users) and practice.
In this tool there are 5 tabs (or parts). Each of these tabs is an important part for each test project. But see more detail each of them:
– Management of requirements
– Management of the test catalog or Test Plan
– Design campaigns to test or Test Lab
– Management of “anomalies” (French term) or Defects
– Management releases (not explained in this article because I want to preserve the suspense)
With tabs for each common features include:
– Reports & Graphics
– The ability to attach screenshots, documents, etc..
The logic of use is as follows, first on developing the test strategy and matrix of coverage (tabs requirements and Test Plan). Then we plan executions (Test Plan and Test Lab), when executions are created sheets anomalies through which we validate the corrections.
Finally, it updates the tests and repeats the cycle of tests.
Dives us in QC:
It is to identify the test requirements (based on business requirements and other specifications), to structure the test plan and specify future test sheets.
Small reminder: requirements may be the expression of needs or the list of features to be tested. Thus, all test requirements define the scope to cover. These requirements are also common among the records of specification and testing to be performed.
Take into account to ensure traceability between the design and execution. Finally, the requirements are support for impact studies of the evolution of specifications on the plans and test sheets.
This tab can also see all the details of requirements and see the status of the results sheets covering a test or its requirements.
Finally, it can be entered manually requirements is to use a macro to use on import documents to Word or Excel. Either in the form of addin or internal development or customer service company.
Managing the test catalog or the Test Plan:
It is designed to test sheets, define scenarios and prepare the reporting (in collaboration with the Lab Test). It is also to create the tree test sheets and sheets and create links between requirements and test sheets.
The Test Plan represents all the test sheets, being built or operational.
Design and execution of campaigns or Test Lab test:
It is the creation and planning campaigns to test. The performance takes place on this tab, whether automated or manual.
– A test campaign is a combination of scenarios (composed of sheets of test)
– A test may be part of several campaigns
– Following the implementation of the various shock, a form of test is considered PASSED status, if and only if all stages composing on the same status
– If at least one of these steps is in FAILED status or not completed sheet will test the same status
Management of anomalies or Defects:
After implementation scenarios / sheets test is to describe the anomalies and reporting information campaign.
Read the article following called « Best practices and test repository »