测试团队全权负责质量
降低质量的最好方法之一是将重点从产品转移到内部政治上。只让一个组织对目标负责(无论目标是什么)是分裂团队的行为，该组织将花费大部分时间和资源证明自己的职责得到了履行，而不是促进产品目标。
测试不负责确定发布内容，这是营销团队的职责。他们也不应该参与设置发布日期，这是销售的职能。他们还不确定要解决哪些问题，这取决于产品团队。
开发团队在专注于交付功能，不参与阿任何代码提交或合并规则，例如，代码审查、静态分析、单元测试等。毕竟质量是测试的责任，而不是开发的责任。
现实中常见的此类抱怨有：
- 为什么测试未找到此客户问题？
- 我们承诺在该日期之前向客户发布产品，停止测试并立即进行构建。”
- 我无法运行测试，因为您给了我一个坏的版本。
花时间争论要由谁来做是降低产品或服务满意度的绝佳机制。
所有测试在发布之前都必须自动化
这将确保您的测试组织将大部分时间都花在软件开发而不是测试工程上。目标从验证产品属性转变为计算运行了多少个自动测试。导致脆弱的测试基础架构并增加维护成本。
由于没有时间考虑测试策略和抽象，因此他们被迫编写非常具体但脆弱的工作流。只要Development对功能进行了微小的更改，测试就会中断。
100％的代码覆盖率
确保将所有执行对话都引向覆盖率度量，并使团队对此负责。人们将专注于构建调用所有代码功能的测试，而不管其输出如何。衡量覆盖率往往会影响时间安排或性能。这使任何人都很难理解实际的客户体验，从而增加了降低满意度的目标。
测试组织与开发隔离
两个组织积极合作时，它们往往会互相帮助。您会发现开发人员为测试人员提供了有关新更改的提示。反之开发人员会在报告错误之前就知道该错误。
协作导致更少的过程：
- 在某些情况下，问题只是解决而不是报告。
- 内部文档和知识转移的时间和精力更少。
- 测试工程师对产品的了解会更多。
- 发布计划反映实际情况。
Test不能访问源代码，Dev无法查看测试用例的过程。
评估过程而不是产品
时常有人问：有多少客户正在使用该功能？对我们的安装群有什么潜在影响？用户必须经过几个步骤才能使用此功能？渗透率是多少？我们满足该需求的潜在客户群有多大？有多少用户要求此功能？
这样产生了关心质量的组织。
最好的办法是通过询问有关流程的问题来重定向精力。以下各项是有助于完成此操作的一些统计信息。
- 未解决问题的数量以及由谁打开
问题不多显得测试没有成绩。
- 问题等待测试响应所花费的时间
- 关闭问题百分比
会让开发人员不愿意提交问题，阻碍测试与开发的沟通。
- 测试计划执行百分比
时常会成为数字游戏，还让人觉得测试组织看起来有空闲时间。
- 通过率
它提醒他们设计套件时要始终通过足够的测试，以便您能够满足流程要求。
准确的时间表
讨论代码完成日期时，请确保询问他们完成的日期，而不是星期或月份。如果您不同意该日期，请在所有同行的公开论坛中提出，以便他们可以争论。
- 开发人员之间相互斗争，减少了沟通。
- 在时间表上没有发言权。
- 不太可能按时完成任务。
增加了虚假信息，强调了个人主义。问题讨论扣扣qun 630011153 144081101。
- 参考资料
快速修补而不是解决
如果有足够的时间，工程师几乎可以解决所有问题。但是，当您采取相反的操作时，会出现一个有趣的现象：他们没有解决根本问题，而是解决了症状，有时甚至完全忽略了问题。
- 开发因快速而广受赞誉。
- 基本问题没有解决，因此有很多机会可以编写将来的错误，从而使测试团队和流程看起来更好。
- 客户将继续遇到相同的问题，这会降低满意度。
- 各种补丁蜘蛛网，使将来的工作更加困难，更加脆弱，从而降低了质量。
- 要解决的问题越多，跟踪遗留问题所需的过程也就越多。双赢！
