合作可能会失败
紧密的合作关系是对时间的投资。有时候投资免不了得不到回报：
你的程序员是如此的固执以致你尖叫起来 – 只可惜很可能你的尖叫声还没他尖叫着说你固执来得响亮。
程序员可能会看起来故意阻碍或令人误解。（他也许在尝试通过使用公正的手段或不正当的手段来指示你从而节省他的时间。但是有时候他就是不可避免地粗心大意，或尝试隐藏他的无能，或其他什么原因。）
你的期望值没有达到。程序员对你做的事情不高兴。
我个人倾向于向糟糕的投资倾注更多的精力，更多的时间。那是错误的。有时候你必须承认计划失败并转向另外一个能工作得更好的计划。在这种情况下，后备计划是“扔过墙的测试”：撤退，保持一定的距离来工作，更正式的工作，专注于公共源代码的重大版本的测试。
因为我容易陷入一个角色，我发现清晰地评估合作关系的状态很重要，尤其是在早期。所以我记录下我花在跟开发人员沟通上的时间。有时候我会问自己是否值得投入这么多时间。沟通的人的性格如何？
是花在回答特定的问题上还是花在解释某个观点？或者是关于普遍性的问题？（当我与开发人员纠缠在一起的时候，我发现我会写很长的关于软件测试的基本原则的Email来解释我的决定。）
我是否发现自己很小心地写Email来避免任何可能的误解，或者在我跟开发人员讨论之前要很仔细地准备自己的言辞？那些是应付低效率的谈话的前期准备，但是它们本身会花费很多的时间。
我在重复自己的论点吗?开发人员呢？
有些低效率是一开始不可避免的。但是后面有没有减少？是否减少得足够快？
我也会问自己从这些得到了什么。
我学到的关于代码的东西能帮助我的测试吗？我忘记了什么好的注意没有？
有什么bug是比我预期的要早发现的？
我是否花费更少的时间在写东西、讨论、重新看bug报告上？
我改进效率的机会是什么？
当我受到挫折的时候，我会在我暂时离开工作一周后问自己这些问题。然后我平衡一下成本和效益。如果我怀疑我能达到我需要的结果，我会短时间尝试一下新的沟通方式，然后重新评估。或者我会简单地撤退。如果让我陷入的只是一个测试任务，我仅会从那里退出而已。
我不会因此而责怪谁。如果需要受到责备，我会乐于自己接受，有两个原因。第一，已经有很长时间被浪费掉而没有发现bug了，为什么还要花费更多的时间？第二，我确信，我不是足够的好，我不能跟任何开发人员一起有效的工作。
虽然没有必要大事宣扬你的计划改变的原因，但是确保你清楚地跟开发人员沟通，你的管理者，还有开发人员的管理者。他们有权利知道，不告诉他们会把问题弄得更糟糕。
你是明星吗？
一个评论者这样写到：“从我的角度看来，你的建议是让我找机会使得跟我一起工作的开发人员看起来很优秀而我看起来是什么都没做…我碰到的每个测试经理都高唱着bug数量不是有效衡量测试员的效率的标准的口号。但是真正我为他工作的每个人，在某种程度上，都在使用bug数量来挑选、奖励、提拔测试员。”
这个对于我来说不成问题。不管是为了什么原因，我从来没有意识到经理在使用bug数量（除非在某种含糊的意义上-像印象之类的）来评价我。如果你的经理这样做了，那我的方法就是一个问题。为了满足开发人员让你牺牲你的工作会有点过分。取样的方式可能会生效：假设你与4个开发人员一起工作，一个是比较紧密的，而另外3个是用传统方式的。你的经理可能会认为你在这3个开发人员身上发现的bug数量是你全部工作的代表。（这样的话就取决于你再他们的代码上测试花费的时间，但是这样简单的衡量就像“玩数字游戏的赌博”一样。）用开发人员方面获得证明，尤其是以请求你的服务的方式，会产生奇妙的效果。
个性和经验
有些测试员喜欢协作完成工作；有些则是不合群的。我的这种方法会减少你与其他测试员的交流。你的经理会看不大清楚你在做的事情，如果你没有意识到这一点则会很糟糕。这种方法给没有经验的测试员增加了风险。
有些测试员喜欢制定计划然后执行它。有些则比较能容忍过程的中断。我的这种方法倾向于后者。除了要能容忍，你还必须是能自我组织良好地完成你的所有工作。
斯德哥尔摩综合症
“斯德哥尔摩综合症”指的是与俘虏联结在一起并且采纳他们的观点的倾向。例如，人质可能成为敌人去观察警察。（注： http://www.vswap.com/confuser/stockhol.htm上有一个很好的简短的描述，但是当你去看的时候也许已经不见了。）
把测试员看成是程序员的俘虏有点过于戏剧化。但是长期与开发人员在一起工作，你可能采纳他们的观点而放弃了顾客的观点，导致你遗漏了bug。尤其是你可能遗漏这样的bug：产品决定这样做的并且是这样做的，但是却是顾客不需要的。可用性问题是这类问题的一个例子。一个科学计算器提供以2为基数的对数计算（主要是对程序员来说有用），而不提供大部分用户期望的自然对数的计算，或者一个在线银行系统给用户默认设置与用户名相同的密码。（一个随机的密码会更好，因为很多用户从来不修改他们的密码。）
所以我们要权衡好紧密工作的风险和价值。在大部分项目中，大部分时间里，我相信价值大于风险。“大部分”不是指全部。在安全至上的项目中，如果妨碍测试员吸取程序员关于潜在错误模式的假设，那么带来的附加的成本需要这些独立的测试组来自己承担。
尝试把顾客或其他用户的模型明确下来会减少这种感染的风险。下面这些书教会我如何在跟开发人员讨论时心里想着顾客：一本关于市场的书，描述塑造目标顾客特性的过程；描述基于行为的计划；，一个主流的描述如何挖掘需求的软件工程的书；提倡用完美的将来时态描述用户行为。
测试组的一部分应该专注于整个产品的测试，而不是测试孤立的功能特性。这样的测试通常是基于工作流来组织的（用例、场景、任务），最好由领域专家（例如，会计师来测试会计模块的内容）来测试。这些独立的测试人员来寻找那些因为受开发人员感染的测试人员遗漏的bug（还有功能模块交叉区域的bug和可用性问题）。
你的程序员是如此的固执以致你尖叫起来 – 只可惜很可能你的尖叫声还没他尖叫着说你固执来得响亮。
程序员可能会看起来故意阻碍或令人误解。（他也许在尝试通过使用公正的手段或不正当的手段来指示你从而节省他的时间。但是有时候他就是不可避免地粗心大意，或尝试隐藏他的无能，或其他什么原因。）
你的期望值没有达到。程序员对你做的事情不高兴。
我个人倾向于向糟糕的投资倾注更多的精力，更多的时间。那是错误的。有时候你必须承认计划失败并转向另外一个能工作得更好的计划。在这种情况下，后备计划是“扔过墙的测试”：撤退，保持一定的距离来工作，更正式的工作，专注于公共源代码的重大版本的测试。
因为我容易陷入一个角色，我发现清晰地评估合作关系的状态很重要，尤其是在早期。所以我记录下我花在跟开发人员沟通上的时间。有时候我会问自己是否值得投入这么多时间。沟通的人的性格如何？
是花在回答特定的问题上还是花在解释某个观点？或者是关于普遍性的问题？（当我与开发人员纠缠在一起的时候，我发现我会写很长的关于软件测试的基本原则的Email来解释我的决定。）
我是否发现自己很小心地写Email来避免任何可能的误解，或者在我跟开发人员讨论之前要很仔细地准备自己的言辞？那些是应付低效率的谈话的前期准备，但是它们本身会花费很多的时间。
我在重复自己的论点吗?开发人员呢？
有些低效率是一开始不可避免的。但是后面有没有减少？是否减少得足够快？
我也会问自己从这些得到了什么。
我学到的关于代码的东西能帮助我的测试吗？我忘记了什么好的注意没有？
有什么bug是比我预期的要早发现的？
我是否花费更少的时间在写东西、讨论、重新看bug报告上？
我改进效率的机会是什么？
当我受到挫折的时候，我会在我暂时离开工作一周后问自己这些问题。然后我平衡一下成本和效益。如果我怀疑我能达到我需要的结果，我会短时间尝试一下新的沟通方式，然后重新评估。或者我会简单地撤退。如果让我陷入的只是一个测试任务，我仅会从那里退出而已。
我不会因此而责怪谁。如果需要受到责备，我会乐于自己接受，有两个原因。第一，已经有很长时间被浪费掉而没有发现bug了，为什么还要花费更多的时间？第二，我确信，我不是足够的好，我不能跟任何开发人员一起有效的工作。
虽然没有必要大事宣扬你的计划改变的原因，但是确保你清楚地跟开发人员沟通，你的管理者，还有开发人员的管理者。他们有权利知道，不告诉他们会把问题弄得更糟糕。
你是明星吗？
一个评论者这样写到：“从我的角度看来，你的建议是让我找机会使得跟我一起工作的开发人员看起来很优秀而我看起来是什么都没做…我碰到的每个测试经理都高唱着bug数量不是有效衡量测试员的效率的标准的口号。但是真正我为他工作的每个人，在某种程度上，都在使用bug数量来挑选、奖励、提拔测试员。”
这个对于我来说不成问题。不管是为了什么原因，我从来没有意识到经理在使用bug数量（除非在某种含糊的意义上-像印象之类的）来评价我。如果你的经理这样做了，那我的方法就是一个问题。为了满足开发人员让你牺牲你的工作会有点过分。取样的方式可能会生效：假设你与4个开发人员一起工作，一个是比较紧密的，而另外3个是用传统方式的。你的经理可能会认为你在这3个开发人员身上发现的bug数量是你全部工作的代表。（这样的话就取决于你再他们的代码上测试花费的时间，但是这样简单的衡量就像“玩数字游戏的赌博”一样。）用开发人员方面获得证明，尤其是以请求你的服务的方式，会产生奇妙的效果。
个性和经验
有些测试员喜欢协作完成工作；有些则是不合群的。我的这种方法会减少你与其他测试员的交流。你的经理会看不大清楚你在做的事情，如果你没有意识到这一点则会很糟糕。这种方法给没有经验的测试员增加了风险。
有些测试员喜欢制定计划然后执行它。有些则比较能容忍过程的中断。我的这种方法倾向于后者。除了要能容忍，你还必须是能自我组织良好地完成你的所有工作。
斯德哥尔摩综合症
“斯德哥尔摩综合症”指的是与俘虏联结在一起并且采纳他们的观点的倾向。例如，人质可能成为敌人去观察警察。（注： http://www.vswap.com/confuser/stockhol.htm上有一个很好的简短的描述，但是当你去看的时候也许已经不见了。）
把测试员看成是程序员的俘虏有点过于戏剧化。但是长期与开发人员在一起工作，你可能采纳他们的观点而放弃了顾客的观点，导致你遗漏了bug。尤其是你可能遗漏这样的bug：产品决定这样做的并且是这样做的，但是却是顾客不需要的。可用性问题是这类问题的一个例子。一个科学计算器提供以2为基数的对数计算（主要是对程序员来说有用），而不提供大部分用户期望的自然对数的计算，或者一个在线银行系统给用户默认设置与用户名相同的密码。（一个随机的密码会更好，因为很多用户从来不修改他们的密码。）
所以我们要权衡好紧密工作的风险和价值。在大部分项目中，大部分时间里，我相信价值大于风险。“大部分”不是指全部。在安全至上的项目中，如果妨碍测试员吸取程序员关于潜在错误模式的假设，那么带来的附加的成本需要这些独立的测试组来自己承担。
尝试把顾客或其他用户的模型明确下来会减少这种感染的风险。下面这些书教会我如何在跟开发人员讨论时心里想着顾客：一本关于市场的书，描述塑造目标顾客特性的过程；描述基于行为的计划；，一个主流的描述如何挖掘需求的软件工程的书；提倡用完美的将来时态描述用户行为。
测试组的一部分应该专注于整个产品的测试，而不是测试孤立的功能特性。这样的测试通常是基于工作流来组织的（用例、场景、任务），最好由领域专家（例如，会计师来测试会计模块的内容）来测试。这些独立的测试人员来寻找那些因为受开发人员感染的测试人员遗漏的bug（还有功能模块交叉区域的bug和可用性问题）。