Best practices and test repository

22 10 2008

Say Uncle, you can give me some best practices pleaaaaaaaaaaase?
The first good practices are:
– Good sense
– Organization,
– Reflections.

Nothing but magic, properly implemented, will guarantee the proper use of a benchmark test. I will expose them as a question to ask the good moments:
Management requirements or requirements:
– Uniqueness?
o This is the only item on this test?

– Clarity?
o Reflect on the tree to establish,
o The need is expressed clearly enough and is there no gray area or ambiguities on the understanding?
o What are the requirements implicit and not listed in the expression of needs (for example), but we must still consider?
– Accuracy?
o The requirement is it enough to be measurable and quantifiable targets via specific test?
– Validity?
o The document led to the requirement is updated and validated by the customer?
– Testability?
o Is it possible to create one or more relevant cases to effectively test all aspects of this requirement?

Managing the card catalog test or the Test Plan:
– Each sheet test should be linked to one or more requirements or you can say goodbye to the test coverage
– Once the test sheet drafted a trick is to check if all the cards are connected at least once a requirement, otherwise you have holes in your racket!
– Depending on the strategy, the Test Plan should be prioritized according to the functional, organizational or business customer
– The tree test plan must:
o Be easy to understand by functional
o In order of business process / application client (use numerical codes to manage the directory eg
o be determined at the outset between all actors
o 4 to 5 levels MAXIMUM directories otherwise you watch the madness
– Provide care tabs « Details » and « Design steps:
o Enter a clear description of the common people for the purpose of the test card
– Provide care to the tab Design steps:
o Be sufficiently precise and detailed to avoid any ambiguity and interpretation at runtime
o Display data to be used and their origins
o Inform the expected outcome (RA) so precise and clear because the result will be compared to the result (RO) during execution

Good questions:
– Uniqueness?
o A target = sheet test
– Clarity?
o The stages of the procedure are clearly identified, no-til no gray area or ambiguities on the way forward?
– Data?
o All representative data needed for testing are they identified?
o Have data that are:
– Coverage?
o The modus operandi of the sheet test is relevant and complete the objective identified?
– Generic?
o No test sheet valued unless a value is hard in the test

Design and execution of test campaigns or Test Lab
– Cash?
o Environment to conduct any tests available?
o The application to test it is installed with the correct version (versioning policy of the client)?
o The access (login / passwords) to applications and other servers valid?
– Preparation?
o The test cards are up to date or she date a year ago?
o Automated test scripts are identified and in the right directories?
– Clarity?
o The names of campaigns and test sheets are quite explicit for your next tier include?
– Data?
o At’on all the data needed to run the cards?
– Coverage?
o The entire campaign covers happens objective identified?

Good practices during the execution of the test sheets:
– Have environments, platforms and networks available
– Availability of the coffee machine effective
– During the execution of steps:
o Follow the procedure in the « description » on LETTER!
o The tests outside the marked paths are BANNED!
o Compare the result (RO) with the field Expected Result (or expected outcome (RA)).

Management of anomalies or Defects:
– Have a workflow defined anomalies that is known, validated, shared and clear. This is for all players
– If yes, do all the players are aware of their roles and responsibilities?
– If the execution proceeds failure:
o Verify that the specified outcome is correct
o Enter the result as clearly as possible
o Check that the anomaly is reproducible integrator or ridicule you and not take into account the anomaly
o Open an anomaly
o Describe the anomaly as clear as possible otherwise your work will not help and you will lose a lot of time in explanation
o ALWAYS associated with a sheet test

– Reproducibility?
o The anomaly is it reproducible under the same conditions?
– Compliance?
o The abnormality has been detected by following the procedure laid down in the sheet test?
o expected results included in the file are updated?
– Uniqueness?
o The anomaly detected is not already open?
To do this, ask your colleagues and your manager is a good start
Use filters and search fields
o Is not there already opened a ticket on a subject almost identical?
– Gravity?
o What is the level of severity of the anomaly?

A final practice for the road? Make a copy and paste the above practices in an Excel file, the file named « Checklist guaranteeing the quality of the test repository ». You do not have:
– Go to request and ask a bonus to your manager ;-)
– And submit your client to be finally a real example of industrialization of testing tools

And for the record, know that putting into practice every day these recommendations will make the implementation of this tool CMMI level 3 (see article on CMMI3 and QC).


Survival Manual on Quality Center for testers!

22 10 2008

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
– Review
– The ability to attach screenshots, documents, etc..
– Printing
– Administration

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:
Management requirements:
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.
Remember that:
– 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 »