1. Bugger 2016 介绍
Bugger 2016 is the version of Bugger adding support fot Team Foundation Server bug databases, GitHub bug databases, in addition to the existing Product Studio support. Bugger 2016 tracks Team Fundation Server, GitHub and product Studio bugs assigned to and opened by you, notifying you when new bugs are assigned to you or changed. The subtle overview window shows you the number of bugs assigned to you at all times, helping you keep track of up to 20 bug databases.
Flag bugs to track them even when they're not assigned to you, or to create virtual lists of bugs you want to follow-up on. Use Quick Query to quickly look up a specific bug or all the bugs assighed to someone from anywhere in Windows. Create bugs from anywhere in Windows with a single keypress.
The "My Team" feature helps you stay on top of bugs assigned to your coworkers and other team members. Rick bug viewa help you see which bugs need attention and react quickly to bugs as they are assigned back and forth.
使用 New Query 可以按条件查找已经开过的bug：
2. Bugger 2016 下载地址：
3. 使用Bugger 2016 创建bug的模板
当点击Create New Bug后，我们会看到有以下几种类型来选择，而我在工作中经常用到的就只有Test和Bug两种，其中Test即Test Issue是指自动化测试用例出错了需要去修复，而Bug即Code Defect是指产品缺陷，也就是我们常说的bug。
这里我们主要说明开bug时需要注意的事项， 一般情况下报bug是需要将以下19种情况都要考虑进去：
但使用Bugger有个好处就是它会将你必须要填写的选项标注出来，当你漏填这些必填项后它会提醒你这些是必填项。
这里需要说明一下的是，作为一个Tester,当你确定要报bug的时候，首先标题必须要具有高度的概括性用一句话将bug的情况描述出来，然后选择Area, Issue 选成Code Defect，优先级和严重性一般都有1,2,3,4种级别，越大优先级越低，严重程度越弱，后面的将黄色标注出来的必填项填上，还需说明的是Repro Steps要尽可能的详细，从测试的环境配置到还原出error的每一步都要详细描述，必要时可以同时粘贴上截图，这样做的目的是为了方面后面Dev修的时候能很方便的重现问题。写完步骤后，还要填写用例的期望结果和实际结果（同样必要的时候可以贴截图）。如果还有其他需要用到的文件什么的，可以加入到Attachments中作为参考。有时候，若遇到的bug是个regression bug,则还要去找到导致这个bug发生的regression bug,当所有这一切都填写结束后点击Save & Close，bug ID便会随机产生，这个bug就报成功了，随后要记得跟踪bug的状态以做后续处理。
4. The classification of bug Status
这里要分根据问题是Test Issue 还是 Code Defect来分bug所处的状态， 如果问题是Test Issue (Automation code出错了)，则它的状态有：Triage (刚创建还没修的bug状态)；In Development(Test Issue被调查中)；Code Review (修改后的code需要进行code review)；Check in (代码被SignedOff后就可以check in了); Resolved (Check in后这个 issue 就算修好了); 等到下一轮任务出来检查一下是否还会出现这个问题，要是没有的话状态就要修改成Closed，这时这个bug的使命才算完全结束了。但是要是开的是一个Code Defect，即产品代码的缺陷，状态有些不同，刚开始状态是Active，然后当Dev去调查时会将状态修改为Investigate，找出解决方案后会将bug的状态改为Fixing， 修复后提交code review，同时将bug的状态改为review，之后check-in， 这里就和Test Issue是一样的，check-in 成功后状态修改成 Resolved，随后还要去retest,所以状态自然要改成test，同时 Assign给开bug的tester去测试，若测试没通过则将状态重新修改为Investigate 重新assign给Dev去修，若测试通过则可以close bug，同时状态修改为Closed， 到此bug的生命周期就结束了。