Bug 像是一个被过分宠爱的小孩子，得到了特别多的关注。它们在开发者的 IDE 里悄然无声的诞生，但在现身之刻却引来一片喧闹。
对于测试工程师发现的 Bug，它们的生命是这样的：测试工程师发现Bug，花些时间细细品味。
这一点很重要，不仅仅是因为我们有权利享受自己劳动的果实，而且，这对于理解此Bug 微妙的细小差别及其出现的条件也是很重要的。
它是否在用户必经之路上？这些路径被走到的可能性有多大？
除了发现 Bug 的这条路径，是否还有更多的路径也会导致相同的问题？
是否存在可能影响数据或者其他应用(这将增加其严重性)的副作用？
是否存在隐私、安全、性能，或者可访问性方面的影响？
当父母听到小孩子的一声轻轻的咳嗽时，常会想象最坏的衰竭性疾病，他们一定非常理解软件工程师对于软件 Bug 的感受。
就像父母会打电话给朋友或亲戚，讨论小孩子咳嗽一样，测试工程师也应该找同伴来分享他的发现。
邀请一个同事来观看演示，问问她的想法，讨论你的理解，Bug的严重程度优先级和副作用等。
这些讨论使问题更为清晰。父母经常可以免去到急诊室的行程，而测试工程师经常发现他曾认为是 P0 的问题实际上也无关紧要，从而避免出现“狼来了”这样的闹剧。
现在是提交 Bug 报告的时候了。
就像父母需要温度计一样，测试工程师也需要一些工具。
父母希望孩子的病情更容易得到诊断，妈妈希望说服医生孩子的病非常的严重，而测试工程师也希望增加严重程度，但更加重要的是，测试工程师希望Bug 更容易能被修复。
截屏、按键记录、录制视频，抓包，查看打印日志等都是记录Bug的方法。
开发得到的信息越多，修复起来心里越有底，Bug 被修复的可能性也就越大。
Bug报告会触发一封邮件，发送到所有相关人员的邮箱里。
修复会产生一个变更列表(CL)，CL 排队去接受评审，一旦得到批准，就进入构建目标队列中。
这相当于治疗Bug的药物，就像父母观察孩子对抗生素的反应一样，测试工程师也会收到新的测试构建已经就绪的邮件提醒。
他接下来就会安装这个构建版本，然后重新执行发现 Bug 的测试用例。
现在，这个测试用例会成为该应用的回归测试集的一部分。
尽可能把它自动化，以防止 Bug 重复出现。
至少应该编写手工测试用例，并提交到测试用例管理系统中去。
这样，系统就对未来的感染具有了免疫力，就像小孩子建立了对曾导致他生病的细菌的免疫力一样。
