现在什么问题变小了？

为什么我要这么麻烦呢？看起来我是想去巴结一些朋友。朋友是好的，但是公司不会为我的社交生活付钱。公司给我报酬是让我使用一部分权力来达到某些目的，一种减少问题的方法。什么问题？
一般而言，摩擦。
我遵照John Daly的原则，不断地问自己：“我做测试不是找bug是做什么？”摩擦会减缓进度。开发人员和测试人员的一些典型摩擦浪费的时间其实可以更好地用在找bug上。
我的这种方法还帮助解决其它的问题。
找Bug的成本高、找得太迟。
如果一个bug能尽早发现，总是会比等到开发人员已经忘记了这个问题相关的内容时再修改的成本要低、修改速度要更快些。同时也可以避免正式的bug跟踪数据库的管理成本。
开发人员不测试。
对开发人员普遍的抱怨是他们根本不会自己尝试一下就“把最新的build版本扔过墙来”。一测试就停掉了，因此是不可测的，它们又被扔回去。没有意义的工作：浪费时间。
一个类似的问题是开发人员声称一个bug已经被修正了，但是最简单的测试就能揭示bug仍然存在。我曾经见过一个程序员把一个6行代码的函数重复修改了4次，每次都会引入一个明显的问题。明显看到他根本没有对自己修改的程序进行任何的尝试。
看起来我把问题弄得更糟糕了，因为我让测试人员把这个程序员束缚住了，每次修改都及时进行测试。是否我没有给开发人员足够的时间测试？不是的，因为我改变了这里的经济学。在这之前，程序员如果节省了10分钟但是浪费了你两个小时，那不会对他造成任何损失。但是现在会了：那两个小时的浪费意味着更多的private的bug会变成public的bug。他会有更多的积极性去跑那些你为他构建的自动验证测试（“冒烟测试”），在把代码交给你之前他会尝试测试新加的功能和修改的bug。他会跟你讨论怎样的分工是有效的。
“请为我debug一下这个问题”
开发人员通常要求测试人员为他们做很多debug的工作。他们会要求具体的测试用例即使是只有几个有限的步骤。他们会要求要对不同输入的测试的扩展文档即使是他们可以自己有效地尝试进行。
同样地，这个问题也得到了减轻，因为浪费你的时间也会使程序员付出一些东西。更进一步地，因为反馈的循环很紧凑，你只需要给开发人员展示错误是什么，而不需要填写详细的bug报告，而这些报告可能要等上3周的时间开发人员才会看到你为开发人员debug的成本降低了。
不知道什么是最新的。
测试员通常会抱怨他们不知道什么是新的编译版本中的内容。所以他们不清楚应该测试什么东西。有时候我们没有考虑到这点：对于每个东西都及时更新并通知每个人实在是太麻烦了。有时候则是故意的：开发人员迫切希望增加这个新的特性，但是没能得到批准，然而他们听了Grace Murray Hopper的演讲和她的口号“得到宽恕比得到许可更容易”，所以增加了新特性。（注：海军少将Grace Murray Hopper，已故，在计算机的早期阶段。她被认为是第一个发现计算机bug的人，发现一个蛾虫躺在 Mark I 计算机里。（有些人对这个看法提出一些质疑。））
对于一个与你一起工作的人很难会欠缺考虑的，尤其是他是帮助你把问题阻止在新特性处于private的状态时。同样你也很难对这样一个人隐瞒你的恶作剧。
“停止要求那些愚蠢的文档。”
测试人员在判断产品有没有做它要做的事情之前，需要知道产品应该做的是什么。程序员不会很乐意提供那些文档。
当工作在一起的时候，更多的信息能被非正式地流转。那也许不是很理想，因为比你后来的测试员还是什么都不知道，但是比什么都没有要好。（注：顾客也会什么也不知道，但是现在一般人认为他们通过尝试系统的功能特性来学习和了解，而不是通过阅读测试人员需要的详细的文档。）作为测试员，我也通过自己编写文档来贡献自己的价值（把非正式的信息转成正式的信息）。（这与Coplien的唯利是图分析者模式类似）
“请做这些不是你的工作的事情。”
测试组看起来在收集令人讨厌的、困难的、往往阻止它们做真正的测试的工作。尤其是测试组被冠以QA的头衔时，一个很模糊的术语，任何不想维护配置管理系统或创建系统构建版本的人都会同意QA应该做这些事情。（注：确实，这里我为了效果而夸大了。我作为“构建独裁者”超过了一年的时间，我没有发疯，最少在一开始的时候没有。）测试人员帮助开发人员可能导致方向的迷失，例如，编写一些辅助的代码。
你从我的技术作者的经验可能已经猜想到我不反对测试人员帮助项目组。但是，一旦bug修改成为开发人员的例行仪式，John Daly的原则会更让人着迷。
不可测试的代码。
测试人员通常会碰到很多代码的问题是很难重现的，但是用户可能不小心就暴露了这个问题。或者他们不清楚自己做了什么操作。或者不清楚代码究竟做了什么事情。当开发人员重视你的bug的时候，他们更倾向于添加增强可测试性的辅助代码。通常一点点就能帮了大忙）。
开发人员缺乏对bug的反省。
当我与开发人员紧密地工作在一起的时候，他们学到了我检测bug的技巧。他们会更加有能力防止那些我发现的bug的再次出现。这种方式下，我可以“顺流而上”，帮助开发人员设计和计划而不是仅仅对于已成事实的软件进行测试。我不会把这些东西推给开发人员；我会等他们来问。
我可能会引发什么问题？
每个解决方案都可能会带来潜在的新问题。
你必须要早点开始
如果你等到代码都写好了并放到公共的地方了才开始你与开发人员的工作，则剩下的就只有bug的修改了，你不能得到很大的益处。
引发对测试人员和程序员的比例的关注
考虑我的这种方法与“扔过墙”的测试方法的区别。
更多的中断驱动。为了维持好的关系，当程序员需要你的帮助时你要快速地反应。在传统的测试中，你拥有更多的自由去安排你的测试任务。
更加依赖结构的知识。在两种类型的测试中，你都必须从用户的角度看一个功能特性。在传统测试中，对功能特性的结构或整个系统的架构的理解会对你的测试有所帮助；它加强了你的以用户为中心的测试，并且有时候允许你忽略某些不必要的测试。但是，当你与开发人员紧密地工作在一起的时候，这些东西的理解就会更加有用：它们是有效沟通的关键并且也同样重要地让开发人员感觉到有效的沟通。
这里我需要小心说明。我不认为你需要成为一名程序员才能了解关于结构的知识。我曾经看到过很多非程序员能把这些学得很好。我曾经看到一个很棒的程序员高度赞扬一名非程序员因为解释结构给他们听需要他阐明他的思想。
这些区别意味着什么呢？
假设测试人员与开发人员的比例是1比10，而你尝试跟每个开发人员都紧密地工作在一起。
一般请求帮助会以不可预知的间隔发生。你需要安排好帮助他们的顺序。但是那自然会降低你对某些人的价值，所以下次他们就不会那么愿意叫你帮忙了。
你不能跟上每个程序员的子系统的结构。你会需要程序员解释一些东西，而这些东西在他们看来你应该早就知道了。你可能需要他们再次解释某些东西，而这可能会激怒程序员。（在他看来，他刚刚给你解释完。从你这边看来，介于7个不同的任务之间，很容易把刚才解释过的东西忘记了。）或者，更糟糕的是，你可能记住的一些东西不再是有效的，导致错误的测试或误报的bug。
在这种情况下，测试会退化成“扔过墙的测试”，因为在这种局限下“扔过墙的测试”会工作得更好些。为了避免不好的感觉，你也许倒不如就按这种方式测试更好些。
假设比例是1比3左右。则容易处理些，但是仍然可能会让开发人员失望，因为不能像他想的那样测试（意味着太多private的bug被忽略了）。你需要谨慎地处理这些问题。注意确保不要过分承诺，导致不能兑现期望。我曾经那样做过。很不好，比不紧密工作在一起还要糟糕。要尤其注意识别出开发人员代码的风险区域，或者高风险类型的bug，明确说明那些是你将要重点关注的区域。
因为我知道开发人员很容易寄希望于测试人员，我更喜欢被指定与一名开发人员紧密工作在一起，而同时用传统的方式兼顾其他两名开发人员。
你不能从秘诀中学习
假设测试人员和开发人员干得很漂亮，很少bug出现在公共源代码。这样的话谁还能从这些少得可怜不值一提的公共bug报告中学到东西呢？Noel Nyman读了本文的初稿后写到：“当我到了一个新的测试组时，首要的信息源就是bug历史。它是洞悉产品的无价之宝，并且是制定回归测试内容的依据。没有谁告诉我关于产品的信息能超过我从旧bug中发现的信息的10%。”其他评论者也指出，开发人员可能学着避免他们自己独特类型的bug，但是他们不能从看其他开发人员制造的其他类型的bug中学到东西。过程改进组也会有类似的问题。
对于这个问题我没有很好的回答，除了作为一个我愿意付出的代价外别无它法。公共的bug还是会被发现并登记。在某种意义上，它们是最好的能学习的东西，因为它们逃脱了开发人员和测试人员的眼睛，但是了解私有的bug还是会更好些。成功实施过程改进的公司（我从未在这样的公司工作过）可能会更加无私一些，在那里开发人员会更加愿意把private的bug登记进去，为了公众着想。我在下一主要章节的论点会帮助我们朝那个方向前进。我没能有幸在一家公司是能很好地做评审的，但是这样的公司可能已经习惯于共享private的bug，至少在开发人员之间。
控制Build
我曾经把这样的方法应用到相对单片集成的和自我包含的产品中：我从开发人员手中获取可执行程序然后在我的机器上执行。如果产品被分解成很多块（共享库、配置文件等。）并且开发人员不负责构建和整体地提交，或者没有实用的方法可以单独测试开发人员的每个模块，知道它是真的孤立的，跟其它模块是隔离的（尤其是包含其他开发人员在同时开发的模块时） - 那么你就碰到了配置控制的难题了，它可能吞没紧密工作带来的好处。最好能定期获取完整的build版本。
设置了错误的期望值
开发人员可能会期望获得很好的益处但是不付出什么代价。应该小心设置他们的期望值。
你的工作是提供关于bug的早期信息。那就意味着所有的任务。项目经理认为有足够的质量的代码创建，要快速地进行。然而，如果开发人员修正bug时你在找bug，那么任务的第一部分，获得第一个可演示的代码版本并放到源代码控制中，可能会延迟。开发人员可能会认为那很恼人或不合适。
虽然你会小心的保证他的时间，但是你还是需要知道很多信息。你需要跟他讨论，或给他发送Email。这些都会占据他的时间，不可避免地使他觉得受到打扰。承诺尽量减少中断他的工作。例如，为了充分利用他的非工作时间，我曾经在开发人员吃中午饭、早餐、晚饭的时候访问他，或者在送他到机场的时候或取修理店取他的车时。但是有些时候打扰还是避免不了的。
确保你强调了你们的关系会不可避免地引发一些摩擦。你会烦人地在他认为他已经完成后发现一些严重的bug，让他感觉你为什么不能一开始就发现这些问题。他最好抱怨，即使是不恰当的抱怨，也好过“避而不理”（作为一种逃避不愉快的问题或人的方法而消失）。避而不理不是解决的办法，因为你会坚持。虽然是客气的坚持，但是还是坚持着。（我曾见这样说“我还是会坚持帮助你，即使你再也不能忍受。”）