被团队Snag
不同类型的团队如何完成从捕获到拉取请求的循环。
本节中的每一页
- 面向代理机构的 Snag 工作室要为一些网站负责，而这些网站的使用者并不是它的员工。发现 bug 的是客户的市场经理，或者客户的客户；描述它的是一封邮件；复现它的，是你这边当周截止日期最少的那个人。Snag 让遇到问题的那个人直接把会话交出来。
- 面向继承代码库的团队的 Snag 在你接手的代码上，一个 bug 最贵的部分不是那处改动，而是找到这处改动该落在哪里——在一个系统里，而它当初的种种理由，已经随着当初的那些人一起离开了。
- 面向内部工具团队的 Snag 内部工具的使用者离你足够近，近到可以顺口跟你说起一个毛病——而正是这份近，让它从来没有被正式提交过。等它被提起时，他们早已绕过了它，而这个绕法已经变成了流程本身。
- 面向 QA 团队的 Snag 测试人员在回归测试进行到一半时，撰写的报告比任何工具生成的都更详尽。但他们无法提供的是导致错误返回的请求、未显示在屏幕上的异常，以及页面出错时的状态。只需在开发、预发布或用户验收测试 (UAT) 版本中添加一个脚本标签，即可将所有这些信息添加到他们原本就打算提交的报告中。
- 面向独立创业者的 Snag 当你就是整个工程团队时，一份 bug 报告在成为缺陷之前，先是一次打断。真正花钱的部分几乎从来不是那处改动，而是弄清楚这个人到底做了什么、在什么页面上、用的哪个浏览器，以及你是不是已经见过它。
- 面向客服支持团队的 Snag 支持团队通常只有一次机会询问客户任何问题。客户会用自己的语言描述故障，等到有人问起他们使用的是哪个浏览器时，他们早已关闭了标签页，继续工作了。而使用Snag，他们提交的是会话本身，而不是对会话的描述。
- 面向已有编码代理的团队的 Snag 编码代理对你的代码库了如指掌，却完全看不到故障发生前的那二十秒。它需要的证据一直存在——在报告人的浏览器里——而这些证据进入上下文窗口的唯一通道，一直是你，一个字一个字重新打进去。