How to generate reports for analyzing the testing process in test director?

Reports and graphs in the test director testing process help you assess up to what extent have your requirements, test runs, test plans, defect tracking etc have progressed.

Generating Reports in Test Director

- In test director you have the facility of generating reports as well as graphs at any point of time in the testing process and from each of the test director modules. 

- You have the choice of working with the default settings as well as the customized ones. 

- While you customize the reports or the graphs you have the right to apply sort conditions as well as filters. 

- Also the information can be displayed according to your specifications if you wish so. 

- The settings you make can be saved as the favorite views and they can be reloaded whenever required. 

- A report can be generated from any of the modules of the test director. 

- Each module of the test director provides you with a variety of report generation options. 

- Once you have generated the report, you can customize various properties of the report as per your wish. 

- The information can be displayed according to your specifications by altering or customizing various properties of that report. 

In this article we shall provide you with the steps for generating a standard requirements report, customizing it for a specific user name and adding it to the favorites list.

Steps for generating reports in Test Director

Follow the steps mentioned below:

1. First step is to open your project and login. If the project is not open, log on to it.
2. To view the requirements tree you need to turn on the requirements module. To do so clicking on the requirements tab will display the requirements module.
3. Next step is to choose a report. To do so go to the analysis option, then reports, and then finally click on the standard requirements report. A report will open up containing the default data.
4. Next if you need to customize the report as per your needs and specifications.  Clicking on the configure report and sub reports button will launch a report customization page with all the default options already selected.
5. Here you will get various options for displaying the number of items per display page. Set the option to ‘all items in one page’ if you want them to be displayed all in one page.
6. If you want to define a filter to view the requirements that were created by a specific user name clicking on the set filter/ sort button will certainly help. A filter dialog box will open up where you will see a filed titled ‘author’. For this click the filter condition box and click on the browse button. This will again open up the select filter condition dialog box. For the users field select the test director log-in user name and click OK. This will close the select the filter condition dialog box. Once again click OK to close the filter dialog box.
7. Under fields specify the fields and order in which you want them to be displayed. Select the custom field layout and next click on the select fields button to open the select fields dialog box. You will observe the following two fields:

a) Available fields: fields that are not currently displayed.

b) Visible fields: fields that are currently displayed.

You need to select the attachment option in the visible fields box and click the left arrow in order to move it to the available fields. Move the required fields to the available fields box.

8. Clear the history.
9. You can add the report as a favorite view by clicking on the add to favorites button.
10. Close the report. 

How is test management done by the test director?

If you are familiar with all the concepts of the test director you can apply them to your software systems or applications since you know how it works.

The test director implements the test management via four major phases as mentioned below:

1. Specification of the requirements
2. Planning the tests
3. Execution of the tests
4. Tracking the defects

Throughout each of the phases the date can be analyzed by the detailed reports and graphs generated earlier. Firstly, you need to analyze your software system or application and determine all of your testing requirements. 

Phase I - specification of Requirements

The first phase of the test director test management process involves the following steps:

1. Examination of the documentation of the software system or application for the determining the testing scope i.e., test goals, strategies, objectives etc.
2. Building of a requirements tree for defining overall testing requirements.
3. Creation of a list of detailed testing requirements for each topic mentioned in the requirements tree.
4. Writing a description for each requirement, assigning a priority level to it and adding attachments if required.
5. Generation of the reports and graphs for providing assistance in the analyzation of the testing requirements.
6. Carrying out a review of the requirements to check if they meet the specifications.

Phase II - Planning the Tests

The second phase involves the following tasks:

1. Examination of the application, testing resources and system requirement for determining the test goals.
2. Division of the application in to modules to be tested and building of a test plan tree to divide the application in to testing units hierarchically.
3. Determination of the type of tests that are required for each module and adding a basic definition of each test to the test plan tree.
4. Linking each test to the corresponding testing requirement.
5. Developing manual tests where each test step describes the test operations and expected outcome. Deciding which tests are to be automated.
6. Creation of the test scripts for the tests that are to be automated using a custom testing tool such as mercury interactive testing tools.
7. Generation of the graphs and reports for the analyzation of the test planning data.
8. Reviewing the tests for determining their suitability to the testing goals.

Phase III - Execution of tests

Third phase involves the following activities:

1. Defining the tests in to groups so as to meet various testing goals of the project. This may involve testing a new version of the application or a specific function in it.
2. Deciding which all tests are to be included in the test set.
3. Scheduling the execution of the tests and assigning tasks to different application testers.
4. Execution of the tests either manually or automatically.
5. Viewing the results of the test runs for determining if a detect was detected in the application under test and generation of the reports and graphs for analyzation of the results.

Phase IV - Tracking the Defects

The last phase of the test management i.e., defect tracking involves the following activities:

1. Submitting new defects detected in the software system or application. Defects can be added during any phase by QA testers, project managers and developers etc.
2. Carrying out a review of the new defects and determining which ones are to be fixed.
3. Correcting the defects that were decided to be fixed.
4. Testing the new build of the software system or application and repeating the whole process until all the defects are fixed.
5. Generation of the graphs and reports to provide assistance in the analyzation of the progress of the defect fixes and determining the date when the application is to be released. 

How do you modify and convert requirements in Test Director?

There is no doubt in the fact that one kicks off a testing process by inputting the specification of the requirements employing the requirements module of the test director. Requirements are a necessity in the testing process. Also, the foundation on which a testing team carries out the testing process is laid down by the requirements itself. The definition of the requirements is represented in the form of what is called a requirements tree. This is actually a graphical representation of the requirements as stated in the document view with the only difference being of hierarchical display. 

The requirements can be grouped as well as sorted out in a requirements tree. The following tasks can also be carried out:

1. Task allocation monitoring.
2. Monitoring the progress of the requirements.
3. Generation of the detailed graphs and reports.

Once the tests have been created in the test plan module they have to be linked to the corresponding requirements. 

Here in this article, we talk about the modification and conversion of the requirements in the test director. 

One can modify the requirements by following the below mentioned step sequence:

1. First, make sure that the requirements module is available on display. If in case it is not you need to open it using the requirements tab. Both the requirements tree as well as the document view will be displayed.
2. Your next step is to copy that particular requirement to which you want to make modifications from the requirements tree by clicking on the copy option. Next clicking on the paste option and you will get a warning saying that you are duplicating the requirement. Click OK and the requirement will be pasted in the same hierarchy level as that of the original requirement. Suffix _copy_ is added to the name of the requirement.
3. Next step, is to rename the requirement by following the usual procedure for renaming an object.
4. Next, move this requirement to a different location but in the same requirements tree. But the requirements should be pasted as child requirement. Click OK for confirmation and drag the requirement to any location you want in the requirements tree.
5. For deleting this requirement as well its child requirement use the delete option.

Once all the requirements have been created and defined, they can be used as a basis for providing definition of the test plan tree module. The conversion to test wizards can be used to get assistance for designing the test plan tree. Using this wizard you can convert the selected requirements from the requirement tree in to subjects or tests for the test plan tree.

Steps for conversion of Requirements

Now the below mentioned steps can be followed for the conversion of the requirements:

1. For the modification procedure make sure that the requirements is up for display and if it is not there do so by clicking on the requirements tab.
2. From the various requirements in the requirements tree select the one which you want to be converted.
3. Now launch the convert to tests wizard from the tool menu and from that click on ‘convert selected’ option.
4. You can go for the automatic conversion method by taking second option i.e., ‘convert lowest child requirements to tests’ for the conversion of the selected requirements in to tests.
5. Now clicking on the next button will start the conversion process and after the conversion the results will be displayed in the step 2 dialog box. 

What is the Test Director Testing Process? What are the phases involved in it?

Mercury provided the world with its first global test management solution popularly known as the test director. Test director has helped many of the organizations in the deployment of very high quality software systems and applications in a quick and efficient manner. 

There are 3 module requirements of the test director on which it operates namely:

1. Test plan
2. Test lab
3. Defects

The above mentioned three module requirements seem to be well integrated providing a way for smooth flow of the information between the various phases of testing.

Up on adding the script editor to all the modules any methodology and best practice can be enforced or followed by the test director based up on the customized requirements of the organization. 

There are several facilities and features that able the users to customize the test director as per the requirements of their projects for capturing the data as needed in the whole testing process such as:

1. Greater number of available user fields
2. Ability to add memo fields
3. Creating input masks

Following processes are incorporated in the test director testing process:

1. Requirements management
2. Scheduling
3. Planning
4. Executing tests
5. Issue management
6. Project status analyzation

What are phases in Test Director Testing Process?

1. Planning Tests: 

In this phase the application software to be tested is broken down in to various test subjects and a project is build. The testing goals as well as objectives are defined keeping all the requirements in view.The following three things are examined so that it can be determined that how and in what way the testing process will take place:

a)   Application software

b)   System environment and

c)   Testing resources

- Next step in this phase, is to provide a definition for each of the test subjects by further dividing them in to test director modules to be tested.  

- A test plan tree is drafted representing the hierarchy among the test subjects. 

- Tests are defined and broken in to steps where each step gives the description of a particular operation that is to be performed. 

- For each test, the output that is expected is determined. 

- Now the turn comes to automate the tests if you are following the automation testing. 

- Here, you will need help from Winrunner for creating the automated test scripts in test script language or TSL. 

- Once all is done, go through your test plan and analyze all the reports, graphs etc.

- Have a rough determination of whether your test plan will be able to meets the defined goals or not.

2. Execution of the Tests: 

- Tests are grouped into suites and running them. 

- Once you have the test schedule in your hand you can start assigning the tasks to the testers and start executing. 

- The graphs and the reports thus generated after the execution of the tests help in the determination of the progress level of the test execution. 

- While the execution of the test suites is in progress there is a need that you keep analyzing how the testing process is going on with the help of the graphs as well as reports.

3. Tracking of the Defects: 

- In this phase the defects that you discovered need to be reported to the management.

- When the defects are repaired, you need to analyze how the repair process is going on. 

- Information and details regarding all the discovered defects are to be stored in the data base meant for storing defect data. 

- After the repair process is complete, put the application once again through the tests and check if again some discrepancy is encountered. 

- After you are done with the analyzation process you can decide when the project is to be released. 

Exploratory Testing - Introduction and Overview

Exploratory testing is an interactive process of concurrent product exploration, test design and test execution. This testing is defined as simultaneous test design, test execution and bug reporting. In this approach, the tester explores the system without having any prior test cases or test scripts. It is also called as ad hoc testing, gorilla testing or intuitive testing. In operational terms, exploratory testing is an interactive process of concurrent product exploration, test design, and test execution. The outcome of an exploratory testing session is a set of notes about the product, failures found, and a concise record of how the product was tested. When practiced by trained testers, it yields consistently valuable and audit-able results. Every tester performs this type of testing at one point or the other. This testing totally depends on the skill and creativity of the tester. Different testers can explore the system in different ways depending on their skills. Thus, the tester has a very vital role to play in exploratory testing.

A systematic approach of exploratory testing can also be used where there is a plan to attack the system under test. This systematic approach of exploring the system is termed as formalized exploratory testing. It is a powerful approach but it has not got recognition and is often misunderstood and not gained the respect it needs. In many situations, it can be more productive than the scripted testing.
This testing believes in concurrent phases of product exploration, test design and test execution. It is categorized under black box testing. It is basically a free-style testing approach where you do not begin with the usual procedures of elaborate test plans and test steps. The test plan and strategy is very well in the tester's mind. The tester asks the right question and judges the outcome. During this phase, the tester is actually learning the product as he tests it. It is interactive and creative. A conscious plan by the tester gives good results.