All About Bug
Download as DOCX, PDF2 likes656 views
An error is a mistake in code, a bug is an error found before production, and a defect is an error found after production. Defects can arise from product specifications or customer expectations. Defects should be named, have their severity and type classified, and priorities assigned. Examples of different types of defects include user interface bugs, calculation bugs, and improper alignments. Components of a bug report include the title, severity, priority, type, steps to reproduce, actual/expected outputs, attachments, comments, and test environment details. Guidelines for writing effective bug reports include being precise, clear, and providing all necessary reproduction details.
All About Bug
- 1. All about Bug, Error and Defects<br />Error: Mistake in code is error. Error is an undesirable deviation from requirement<br />Bug: if defect accepted by the development team it is called bug. Bug is an error found before the application goes into production<br />Defect: Defect is a variance from desired product attributes or normal flow. When defect reaches to end customer is termed as failure. Defect is an error found after the application goes into production.<br />Defects can be from product specs<br />Defects can be from customer or user expectation.<br />Attributes of Defect<br />Defect Naming – requirement defect, design defect, documentation defect
- 3. Critical (high) –show stopper
- 4. Major (high) incorrect output derived
- 5. Minor (Low) spelling mistake
- 7. Wrong- requirements implemented incorrectly
- 8. Missing – requirement given by end customer but it were not implemented at all
- 9. Extra – requirement implemented correctly but were not requested by end customerAbout Severity and Priority<br />Severity: Seriousness of defect with respect to functionality<br />Priority: importance of defects with respect to customer<br />High: without resolving defect we are unable to continue testing
- 10. Medium: compulsory to solve but able to continue
- 11. Low: may or may not be resolvedExamples:<br />User interface bug- low severity
- 12. Calculation bug- high severity and high priority bug
- 13. Improper alignment – low priority and low severity bug
- 14. Spell mistake – high priority and low severity bug
- 15. Final output wrong – low priority
- 16. Dependent output wrong – high priority
- 17. Annual report print functionality not working – High severity and low priority issueComponents of Bug <br />Title of bug
- 18. Severity of bug
- 19. Priority of bug
- 20. Bug type
- 21. Module name
- 22. Assigned to
- 23. Project manager
- 25. Actual output
- 26. Expected output
- 27. Attachment of log and screen shot
- 28. Comments
- 29. Test environment – browser, OS information etc
- 30. Build date and platformGuidelines to write bug<br />Be precise
- 31. Be clear – explain it so other can reproduce the bug
- 32. Mention exact steps to reproduce with details
- 33. Provide sufficient test environment details
- 34. Mention build date and number with details
- 35. When you close your bug mention on which build and date you verify it, so in future if require to reopen it we can have track on which build it works last