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. 

Overview of The Concurrent Development Model

The concurrent development model, sometimes called concurrent engineering The concurrent process model can be represented schematically as a series of major technical activities, tasks, and their associated states.
It makes use of state charts to represents the concurrentrelationship among tasks associated within a framework of activities. It isrepresented schematically by a series of major technical tasks, and associated states. The user's need, management decisions and review results drive theover-all progression of the development.

The concurrent model is often more appropriate for system engineering projects where different engineering teams are involved. The concurrent process model defines a series of events that will trigger transitions from state to state for each of software engineering activities, actions or tasks. This generates the event analysis model correction which will trigger the analysis action from done state to awaiting changes state.

The concurrent process model is applicable to all types of software development and provides an accurate picture of the current state of a project. Rather than confining software engineering activities, actions and tasks to a sequence of events, it defines a network of activities. Each activity on the network exists simultaneously with other activities, actions or tasks. Events generated at one point in the process network trigger transitions among the states.