What is trace-ability alert? How to trigger a trace-ability alert in Test Director?

The process of sending e–mails in order to notify the ones that are responsible whenever some change is made to the project. This can be done by instructing the test director to create an alert whenever a change occurs and send e – mails appropriately. One’s own follow up alerts can also be added. 

There are certain rules called the trace-ability notification rules (based up on the associations that were made in the test director among the tests, requirements and defects) which are activated by the test director administrator for generating the automatic trace-ability alerts.

On what occasions a trace-ability alert issued?

Only for the following issues test director can generate the trace-ability alerts:

1. Whenever a requirement (except change of a status) changes, the designer of the associated tests is notified by the test director.
2. Whenever a requirement having an associated test changes, all the project users are notified by the test director.
3. Whenever the defect status changes to ‘fixed’, the responsible tester of the associated test is notified by the test director.
4. Whenever a test run is successful, the user assigned to the associated test is notified by the test director.

Steps to trigger trace-ability alert

1. Log on to the project  as a different user.
2. Click on the test plan tab to turn on the test plan module which will display the test plan tree. Expand the concerned subject folders and select the required test. A designer box displaying the user name in the details tab in the right pane is seen. One thing to be noted is that whenever an associated requirement changes, the trace-ability notification is only viewed by the designer.
3. Click on the requirements tab to turn on the requirements tree and also make sure that it is in the document view.
4. Among the requirements choose the one that you want to change.
5. For changing the priority of the requirement click on the priority down arrow and select the required priority. This will cause the test director to generate an alert for the test associated with the requirement selected above. Also, an e – mail will be sent to the designer who designed this test.
6. When you are done log out of the project by clicking on the log out button present on the right side of the window.

How to view a trace-ability alert?

This trace-ability change can be viewed for a single entity or all the entities in the project. Here by entity we mean a test, a defect or a test instance. To view the trace-ability alert follow the below mentioned steps:

1. Log on to the project as the designer of the test.
2. Click on the test plan tab to view the test plan tree. Expand the subject folders to display that test. You will see that the test has a trace changes flag which is an indication of the fact that a change was made to the requirement associated with it.
3. Clicking on the trace changes flag for the test will enable you to view the trace-ability alert. Also, the trace changes dialog box will open up. Clicking on the requirement link will make the test director to highlight that particular requirement in the requirements module.
4. For viewing all of the trace-ability alerts click on the trace all changes button in the common test director tool bar. A dialog box listing all the trace-ability changes will open up.
5. Once done close the dialog box. 

How do you define and view requirements in Test Director?

Test director is currently available as a plug in or add – on as a support for HP quality center and works like a test management tool. The earlier versions of the test director i.e., version 6 and below worked as stand-alone desk top applications.

However, the next version i.e., the test director 7 was a standalone web application and was known to work on any of the browsers that happened to be supporting active technology. For all the testers world wide it has been easy to integrate with the other mercury interactive tools via test director.

Three facts regarding test director:

1. This tool is not going to work out for the collection of the requirements of a software system or application.
2. It is not an automated testing tool.
3. It cannot be integrated with the products save mercury interactive products.

Test director comes with four specific modules namely:

1. Requirements module
2. Test plan module
3. Test lab module and
4. Defects module

How can we define and view requirements in the test director?

- This is done using the requirements module. 

- In every test management process, specification of the requirements is the first important step. 

- It involves analyzation of the software system or application under test and determination of the requirements of testing that application.

- Requirements analysis somewhat helps in carrying out the coverage analysis. - The following tasks are involved:

1. Addition of new requirements or editing of the previously added ones.
2. Addition and editing of the child requirements.
3. Linking of the requirements to the associated defects.
4. Analyzation of the coverage.

- The requirements analyzation phase follows through the below mentioned steps:

1. Defining the scope: The scope of the requirements includes test goals and objectives and can be determined using the requirements documentation.
2. Creation of the requirements: A requirements tree needs to be built so that all of the testing requirements can be defined.
3. Providing details for the requirements: Detailing involves adding attachments, assigning priority levels to all the requirements if required for testing.
4. Analyzation of the requirements: This phase involves generation of the reports consisting of the graphs to provide an assistance in the analyzation of the testing requirements.

Steps for Defining Requirements

Follow the below mentioned steps for defining the requirements:

1. Launch the test director demo project. You will require to log on to the project if in case the project is not open.
2. Now clicking on the requirements tab will display the requirements module or the requirements tree.
3. One thing that you need to be sure of is that the document view of the requirements is also displayed.
4. Click on the new requirement option which will open the new requirement dialog box. Fill in the details and hit OK.
5. Click new child requirement button for adding a requirement as a lower level of hierarchy.

Steps for Viewing Requirements

For viewing the requirements follow the below mentioned steps:

1. First step is making sure that the requirements module is displayed and if not click on the requirements and turn on the document view of the requirements tree.
2. You can zoom in as well as zoom out of the requirements tree using the zoom in and zoom out buttons.
3. In some cases you may require to view the numeration of requirements. 
4. To view numerations go to view menu and click on the numeration option. If you make any changes in the requirements the same is updated by the test director and numerations are renumbered. 

What is the difference between check point and output value in QTP?

Check point value and output value are two very familiar terms in the field of quick test professional. In this article we will be discussing about output value and check point value and also about the differences between them. But before we discuss the differences let us know about what the check points and output values really mean. 

What is a Check Point?

- Whether a web site or web application that is currently under test is working as expected or not, is known with the help of a check point.

- This is done so by making comparison between the expected values of the properties and current values for the same properties.  

- Whenever a check point is added by the user, a similar check point is added by the quick test professional to the current row displayed in the key word view.

- In the expert view, an equivalent check checkpoint statement is added. 

- All this is default process and the name of the test object on which the check point is added is supplied as a name to that particular check point also by default. 

- The name of the check point can be changed as per the needs. 

- Below mentioned are the types of check points:

1. Image check point
2. Standard check point
3. Table check point
4. Bit map check point
5. Text check point
6. Accessibility check point
7. Data base check point
8. Page check point
9. Xml check point

- Return value of a check point in quick test professional is always of Boolean type i.e., it is either true or false. 

- If the return value of the check point is found to be zero then the statement following it, is executed otherwise the further execution is cancelled. 

- The check points of the quick test professional have a very limited scope therefore the best option is to use self created check points wherever possible. 

- Check point is one of the key functional testing features among others provided by the quick test professional. 

- “Check” method is used by quick test professional for working up on the check points.

- If the return value of a check point has to be retrieved than it is compulsory that you add parenthesis around the name of the check point present in the check point.

What is a Output Value?

- Output value step captures a value of a property of an object which is then termed as an output value. 

- This value is captured at a specific point and can be stored at any desired location. 

- These output values then can be used to serve as inputs at several different points of the test script.

- As required the user can select and output multiple properties of an object. 

- There are 4 typical types of output values:

1. Text output value: Text content present in the bitmap can be retrieved.
2. Text area output value: It is used for outputting text strings with a defined area of the screen.
3. Standard output value: Number of properties pertaining to an object can be retrieved.
4. Xml output value: It is obtained from resources and applications containing xml content stored in some specific column although the run session.
5. Data base out put value: This output value facilitates the checking of the content present in the data table and has been stored in a particular column during the run session.

- The output values are stored only till the duration of the run session ends and are obtained from AUT.

- Output values are suppose to have a dynamic nature.

Model-View-Controller (MVC) Design Pattern

Model View Controller design pattern is used to support multiple types of users with multiple types of interfaces. The Model-View-Controller (MVC) pattern separates the modeling of the domain, the presentation, and the actions based on user input into three separate classes:

- Model: The model locates all data information for the application. It does not care about how you interpret it or how process it. It divides functionality among objects involved in maintaining and presenting data to minimize the degree of coupling between the objects.

- View: The view manages the display of information. It is responsible for maintaining the consistency in its presentation when the underlying model changes.

- Controller: The controller interprets the mouse and keyboard inputs from the user, informing the model and/or the view to change as appropriate. The actions performed on the model can be activating device, business process or changing the state of a model.

The MVC pattern allows any number of controllers to modify the same model. The strategies by which MVC can be implemented are as follows:
- For Web-based clients such as browsers, use Java Server Pages (JSP) to render the view, Servlet as the controller, and Enterprise JavaBeans (EJB) components as the model.
- For Centralized controller, a main servlet is used to make control more manageable.