Suppose you have an application which is having a UI bug that doesn’t really affect the apps usability. In this case the severity is very low, but it is of high priority because it’s looks ugly. As priority indicates business value, this defect should get fixed at high urgency.
Inconsistency defect is nothing but the defect which is not stable, a bug which is not reproducible while retesting i.e. the defect is valid but it’s not reproducible always. For example, observing an issue whole day and at the end of the day when you reported that defect, you find it’s no more reproducible.
Here are the steps to reproduce defect
- Include exact data used during testing for easy reference
- The steps have to be in the exact order
- Mention pre-requisites when applicable
- Always recheck your steps to reproduce on a new system, clearing all cookies and cache memory
The Defect changed to deferred state means the defect is expected to be fixed in next releases.
The reasons for changing the defect to deferred state are
- priority of the bug may be low
- lack of time
Priority indicates how soon the bug should be fixed. Severity indicates the seriousness of the defect on the product functionality. More severe the defect is, higher the priority is given to ensure the defects are fixed as soon as possible to maintain the quality of the application.
Example: A bug that would damage data is more severe than something that is just annoying like say some functionality taking too long to load. Both should be fixed but those with higher negative impact should be fixed first.
Bug Report should contain the following fields
- Defect Description
- Date Raised
- Detected By
- Fixed By
- Date Closed
Defect management process is very useful to identify the defect of the software for the following reasons:
- Provide developers and other parties with feedback about the problem to enable identification, isolation and correction
- Provide test leaders means of tracking the quality of the system under test and the progress of the testing
- Provide ideas for test process improvement
- Find defects easily and at a very early stage of process because as soon as the defect is detected the cost of fixing it will be low
- RTM is mapping between test cases and customer requirements.
- It is used to track the requirements and to check the current project requirements are met.
- RTM is prepared before test case designing. Requirements should be traceable from review activities.
Conclusion: The main purpose of Requirement Traceability Matrix is to see that all test cases are covered so that no functionality should miss while doing Software testing.