|
Case Study Example |
  
|
|
Case Study Example |
|
Case Study Example:
Consider the scenario where a defect has been raised against a software product. On raising the defect, the tester should “Link” the defect back to the software module’s “Configuration Item” from within the defects editor.
| • | The CI status report will now show this defect and its current status as part of the report. |
Let’s say that the design authority makes an assessment and subsequently assigns it to the developer for fixing. The developer investigates the defect in detail and decides to raise a Technical Query (TQ) regarding the original requirements since he believes that two clauses conflict with each other.
From the defects register, he first selects the defect to raise the query against and simply clicks the “Create TQ” button from the main menu. A draft query will now be created and opened up in the query editor. The editor will automatically add the required “Links” back to both the Defect and the CI for which the defect belongs. The query itself should be assigned to the design authority for assessment and subsequent response or sending to the client for response.
| • | The CI Status Report will now show both the defect and the TQ and their respective status information as part of the Report. |
| • | The Defect Report will now automatically show the query and its status. |
The client response to the TQ was to amend on of the conflicting clauses, which will ultimately require the software module to be modified. To do this the Design Authority should raise a Change Request Note (CRN).
To do this simple select the appropriate TQ from the register and the click the “Create CRN” button from the main menu. A draft Change Request will now be created and opened up in the Change Request editor. The editor will automatically add the required “Links” back to the Defect for which the query was originally raised.
The Change Request itself should always be assigned to the design authority, who should create the all required tasks required to complete the change assigning each task to the appropriate user.
| • | The CI Status Report will now show the Change Request, the defect and the TQ and their respective status information as part of the Report. |
| • | The Defect Status Report will now show the Change Request, all the generated task associated with the change and their respective status information as part of the Report. |
| • | The CRN Status Report will now show all the generated tasks as well as the originating Technical Query. |
As you can see from the above test case, a seemingly simple defect fix can escalate over time and can end up having a “snow balling” effect on the works. Project Assistant’s powerful linking feature can capture this effect as and when it happens by automatically adding to the status reports as the events unfold.
This has many advantages not just during the project lifecycle but post mortem as well, since Project Assistant has kept time and date details of the all these events for review or to support any post project commercial activities.