What should be done after a bug is found?
The bug needs to be communicated and assigned to developers that can fix it. After the problem is resolved, fixes should be re-tested, and determinations made regarding requirements for regression testing to check that fixes didn't create problems elsewhere. If a problem-tracking system is in place, it should encapsulate these processes. A variety of commercial problem-tracking/management software tools are available (see the 'Tools' section for web resources with listings of such tools). The following are items to consider in the tracking process:
- Complete information such that developers can understand the bug, get an idea of it's severity, and reproduce it if necessary.
- Bug identifier (number, ID, etc.)
- Current bug status (e.g., 'Released for Retest', 'New', etc.)
- The application name or identifier and version
- The function, module, feature, object, screen, etc. where the bug occurred
- Environment specifics, system, platform, relevant hardware specifics
- Test case name/number/identifier
- One-line bug description
- Full bug description
- Description of steps needed to reproduce the bug if not covered by a test case or if the developer doesn't have easy access to the test case/test script/test tool
- Names and/or descriptions of file/data/messages/etc. used in test
- File excerpts/error messages/log file excerpts/screen shots/test tool logs that would be helpful in finding the cause of the problem
- Severity estimate (a 5-level range such as 1-5 or 'critical'-to-'low' is common)
- Was the bug reproducible?
- Tester name
- Test date
- Bug reporting date
- Name of developer/group/organization the problem is assigned to
- Description of problem cause
- Description of fix
- Code section/file/module/class/method that was fixed
- Date of fix
- Application version that contains the fix
- Tester responsible for retest
- Retest date
- Retest results
- Regression testing requirements
- Tester responsible for regression tests
- Regression testing results
- 应该通知和分配buf给能够修复它的开发人员。问题被修复后，需要重新进行测试，并依据需求规格判断修复bug没有引起其它问题。假如使用缺陷跟踪系统，会包含这些过程。有很多商业化的缺陷跟踪/软件配置管理工具可供使用。下面列出了缺陷跟踪过程的项目：
1、开发人员能够理解bug的所有信息，bug的严重程度以及如何重现bug；
2、bug标识（数字、ID等）；
3、bug的当前状态（例如：复测版本，新bug等）；
4、应用程序名称和标识、版本号；
5、测试环境描述、系统、平台以及相关的硬件信息；
6、测试用例名称/版本/标识;
7、简要的bug描述；
8、bug的详细信息；
9、如果bug不是被特定的测试用例发现的或者开发人员不容易访问测试用例/测试脚本/测试工具，则需要描述产生bug的步骤；
10、测试中使用的文件/数据/信息等的名称和/或描述；
11、文件引用/错误信息/日志文件/截屏/测试工具的日志等信息能够有助于找到产生问题的原因；
12、严重级别（例如使用5级，从1-5为，通常使用“严重的”到“低的”划分）；
13、bug是被再次发现的吗；
14、测试人员姓名；
15、测试日期；
16、bug报告日期；
17、bug涉及到开发人员姓名、组、部门；
18、描述如何产生bug的；
19、修复的代码段/文件/模块/类/方法；
20、修复的日期；
21、包含修复bug的应用程序版本；
22、测试人员负责复测；
23、复测日期；
24、复测结果；
25、需求规格回归测试；
26、测试人员负责回归测试；
27、回归测试结果。