想知道如何影响管理者吗？

　　■ 提供给他们需要的信息，以便做出更明智的决定。

　　■ 始终保持清醒，管理者们做的是商业的决定，不仅仅是技术的决定。

　　■ 知道产品不一定非要切合你的质量标准。

　　■ 让你高兴不是开发经理的工作，也不是任何其他人的工作。帮助你工作更高效，可能是他们工作的一部分。你要让他们了解如何做到这一点。

　　尤其要注意的是：

　　■ 使测试变缓慢的问题是可怕而重要的，因为它们使得缺陷可以隐藏得更久更深。所以在报告中不仅要描述产品的缺陷，还要描述阻碍测试的问题。

　　■ 如果你想提供些信息用于改进开发的过程，那么报告一下你的测试时间是如何分配的。

　　■ 注意到，通常都是这样，为什么测试需要这么长时间呢—你只花了极少的时间用于实际测试产品，而花了大量的时间用在缺陷调查和报告、测试准备、会议、文案、和其他为了获得更高测试覆盖率而进行的中断事务上。

　　■ 专注于测试报告的准确性（5%或10%）而不是精确性上。因为软件开发中的大部分问题都可以基于这些一手的度量数据而发现和解决，无需那些基于反正是无效的模型而进行的六十进制分析的数据。

　　■ 向管理者展示你所发现的大部分问题都不是简简单单地通过重复执行用例就可以发现的，而是通过测试用例所没有覆盖到的步骤和观察发现的–也就是说，是通过你对产品进行的一次次睿智的调查而发现的。

　　■ 帮助开发人员和管理者之类的人认识到，测试自动化，远远不只是编个程序让机器自动去代你敲键盘。

　　■ 让每个人了解自动化对某些种类的测试是有益的，但同时也极大地限制了测试的其他方面。

　　■ 帮助人们认识到测试和检查的区别，认清二者各自的价值，认识到优秀的检查需要具备大量的测试技能。

　　■ 用你的实际工作去证明测试是对产品的一次技巧性探索，让管理者认识到恰恰是这点使得你发现了很多缺陷。

　　■ 帮助团队认识到软件开发并不是一个线性的过程，而是一个有机的过程。

　　■ 帮助管理者和程序员逐渐认清，通常所说的”测试阶段“实际上应该叫做”缺陷修复阶段“。

　　■ 当被要求签署产品时，礼貌地提供你的测试报告，把签署的权利留给那些意见真正起作用的人：产品负责人。

　　想赢得你所在团队的尊重？

　　■ 为项目提供测试服务，而不是成为一个障碍。你是信息的提供者，而不是过程的强加者。

　　■ 停止去尝试那种”质量是测试人员的“，”测试人员对质量负责“的思想。并默认项目中的其他人至少是和你一样关心质量。

　　■ 认识到你的角色是挑剔的思考，帮助开人员和管理者不被错误的假想所欺骗–这首先要起于你自己不被错误的理念所欺骗。

　　■ 让你的技能、团队和战术尽量多样化。就像Karl Weick所说：”如果你想理解一个复杂的事务，你首先得让自己变得复杂起来。“

　　■ 如James Bach所说，去发明适合你的测试。不要满足于其他人所说的（包括我说的），基于你的知识、经验和技能去实地考证。经常在你所处的圈子里看看别人都是怎么测试的。

　　■ 如果你发现有什么东西可以帮助你提升你的知识或感官，有助于提升你的测试能力，就去学习它。

　　■ 学习测试技能，尤其是挑剔地思考的技能，同时也包括系统思维，科学思维，社会生活的信息，人机交互，数据表示，编程，数学，测量… …

　　■ 实践你需要的和读过的技能。通过参加周末测试活动提升你的技能。

　　■ 找一个当地的导师帮助你。如果你找不到，可以到互联网上找。请求帮助！

　　■ 不要屈服于外界压力而成为别人交易中的商品。参加认证意味着你花了钱却成为和其他成千上万人无异的人。要有你自己的标志。

　　■ 要知道，过程模型只是模型和过程模型–特别是那些涉及人类活动如软件开发的过程–很多真正的实际项目中发生的细节并未包含其中。

　　■ 聚焦于提升你的个人技能和思维，这样你就可以适应任何过程模型。

　　■ 分享你自己的软件测试中的经验教训和完美软件以及与有关测试的幻想。

　　最后，如果你是一名测试人员，远离质量保证部门。成为你能成为的最好的测试人员：一个熟练的调查者，而不是一个程序员或者项目经理的崇拜者（作者注：和Michael交流后，最后一句表达的是，”。。。成为一名熟练的 调查者，而不是缺乏技能或相应权力的情况下却想成为一个程序员或者项目经理。”）。