Defect Isolation
Break into small modules and then execute it.
Top down Approach - Bisection Technique
2. Open: After a tester has posted a bug, the lead of the tester approves that the bug is genuine and he changes the state as “OPEN”.
3. Assign: Once the lead changes the state as “OPEN”, he assigns the bug to corresponding developer or developer team. The state of the bug now is changed to “ASSIGN”.
4. Test: Once the developer fixes the bug, he has to assign the bug to the testing team for next round of testing. Before he releases the software with bug fixed, he changes the state of bug to “TEST”. It specifies that the bug has been fixed and is released to testing team.
5. Deferred: The bug, changed to deferred state means the bug is expected to be fixed in next releases. The reasons for changing the bug to this state have many factors. Some of them are priority of the bug may be low, lack of time for the release or the bug may not have major effect on the software.
6. Rejected: If the developer feels that the bug is not genuine, he rejects the bug. Then the state of the bug is changed to “REJECTED”.
7. Duplicate: If the bug is repeated twice or the two bugs mention the same concept of the bug, then one bug status is changed to “DUPLICATE”.
8. Verified: Once the bug is fixed and the status is changed to “TEST”, the tester tests the bug. If the bug is not present in the software, he approves that the bug is fixed and changes the status to “VERIFIED”.
9. Reopened: If the bug still exists even after the bug is fixed by the developer, the tester changes the status to “REOPENED”. The bug traverses the life cycle once again.
10. Closed: Once the bug is fixed, it is tested by the tester. If the tester feels that the bug no longer exists in the software, he changes the status of the bug to “CLOSED”. This state means that the bug is fixed, tested and approved.
Defect severity determines the defect criticality whereas defect priority determines the defect immediacy or urgency of repair
1. High Severity & Low Priority : Suppose there is an application which generates some banking related reports weekly, monthly, quarterly & yearly by doing some calculations. In this application, there is a fault while calculating yearly report. This is a high severity fault but low priority because this fault can be fixed in the next release as a change request.
2. Low Severity & High Priority : Suppose there is a spelling mistake or content issue on the homepage of BT.com website which has daily laks of hits all over UK. In this case, though this fault is not affecting the website or other functionalities but considering the status and popularity of the website in the competitive market it is a high priority fault.
3. High Severity & High Priority : Suppose there is an application which gives some banking related reports weekly, monthly, quarterly & yearly by doing some calculations. In this application, there is a fault while calculating weekly report. This is a high severity and high priority fault because this fault will hamper the functionality of the application immediately within a week. It should be fixed urgently.
4. Low Severity & Low Priority : Suppose there is a spelling mistake on the pages which has very less hits throughout the month on any website. This fault can be considered as low severity and low priority.
Ex: A 1000 page word document to be tested. TC format
Defect reports are probably primary work product for most of the software testers. The objective is not to write the perfect defect report, but to write an effective defect report that conveys the proper message, gets the job done, and simplifies the process for everyone. Good defect report, which is informative and understandable, earns you a good reputation. Weak report generates extra work for everyone. Most of the time, a weak defect report is returned with comments saying not clear, need more information etc. That makes you work again on the same defect and thus reduces efficiency of testers and developers both. Defect reports are not only used by programmers, but also by managers, executives, and documentation team and support executives for various reasons.
Break into small modules and then execute it.
Top down Approach - Bisection Technique
Description of Various Stages:
1. New: When the bug is posted for the first time, its state will be “NEW”. This means that the bug is not yet approved.2. Open: After a tester has posted a bug, the lead of the tester approves that the bug is genuine and he changes the state as “OPEN”.
3. Assign: Once the lead changes the state as “OPEN”, he assigns the bug to corresponding developer or developer team. The state of the bug now is changed to “ASSIGN”.
4. Test: Once the developer fixes the bug, he has to assign the bug to the testing team for next round of testing. Before he releases the software with bug fixed, he changes the state of bug to “TEST”. It specifies that the bug has been fixed and is released to testing team.
5. Deferred: The bug, changed to deferred state means the bug is expected to be fixed in next releases. The reasons for changing the bug to this state have many factors. Some of them are priority of the bug may be low, lack of time for the release or the bug may not have major effect on the software.
6. Rejected: If the developer feels that the bug is not genuine, he rejects the bug. Then the state of the bug is changed to “REJECTED”.
7. Duplicate: If the bug is repeated twice or the two bugs mention the same concept of the bug, then one bug status is changed to “DUPLICATE”.
8. Verified: Once the bug is fixed and the status is changed to “TEST”, the tester tests the bug. If the bug is not present in the software, he approves that the bug is fixed and changes the status to “VERIFIED”.
9. Reopened: If the bug still exists even after the bug is fixed by the developer, the tester changes the status to “REOPENED”. The bug traverses the life cycle once again.
10. Closed: Once the bug is fixed, it is tested by the tester. If the tester feels that the bug no longer exists in the software, he changes the status of the bug to “CLOSED”. This state means that the bug is fixed, tested and approved.
Defect severity determines the defect criticality whereas defect priority determines the defect immediacy or urgency of repair
1. High Severity & Low Priority : Suppose there is an application which generates some banking related reports weekly, monthly, quarterly & yearly by doing some calculations. In this application, there is a fault while calculating yearly report. This is a high severity fault but low priority because this fault can be fixed in the next release as a change request.
2. Low Severity & High Priority : Suppose there is a spelling mistake or content issue on the homepage of BT.com website which has daily laks of hits all over UK. In this case, though this fault is not affecting the website or other functionalities but considering the status and popularity of the website in the competitive market it is a high priority fault.
3. High Severity & High Priority : Suppose there is an application which gives some banking related reports weekly, monthly, quarterly & yearly by doing some calculations. In this application, there is a fault while calculating weekly report. This is a high severity and high priority fault because this fault will hamper the functionality of the application immediately within a week. It should be fixed urgently.
4. Low Severity & Low Priority : Suppose there is a spelling mistake on the pages which has very less hits throughout the month on any website. This fault can be considered as low severity and low priority.
Ex: A 1000 page word document to be tested. TC format
Defect reports are probably primary work product for most of the software testers. The objective is not to write the perfect defect report, but to write an effective defect report that conveys the proper message, gets the job done, and simplifies the process for everyone. Good defect report, which is informative and understandable, earns you a good reputation. Weak report generates extra work for everyone. Most of the time, a weak defect report is returned with comments saying not clear, need more information etc. That makes you work again on the same defect and thus reduces efficiency of testers and developers both. Defect reports are not only used by programmers, but also by managers, executives, and documentation team and support executives for various reasons.
No comments:
Post a Comment