软件工程客户满意度调查表_测试工程学的反模式：通过使用这9种简单的组织实践来破坏客户满意度并提高质量-CSDN博客

软件工程客户满意度调查表

A recent podcast episode reminded me that it's a good idea to examine things from different perspectives. Doing so can expose behaviors that appear purposeful as consequences of environmental factors. You won't succeed at fixing those behaviors unless you do something about the environment that encourages them.

最近的一则播客节目提醒我，从不同角度检查事物是个好主意。这样做可能会暴露看来是有目的的行为，这是环境因素的后果。除非您对鼓励这些行为的环境做些事情，否则您将无法成功解决这些行为。

Today the discussion is about Test engineering and organizational practices that tend to lower the quality of your deliverables.

今天的讨论是关于测试工程和组织实践的，这些实践往往会降低可交付成果的质量。

When reading through, please keep in mind that we're emphasizing goals that are contrary to what you expect - lower quality and customer satisfaction. The suggestions may seem cynical and counter-intuitive, but that's the point of the exercise. So let's get started.

通读时，请记住，我们强调的目标与您的期望相反-较低的质量和客户满意度。这些建议看似愤世嫉俗和违反直觉，但这就是练习的重点。因此，让我们开始吧。

1.使测试团队对质量全权负责 (1. Make the Test teams solely responsible for quality)

One of the best ways to lower quality is by shifting focus away from the product and towards internal politics.

降低质量的最好方法之一是将重点从产品转移到内部政治上。

You want to capitalize on default human behavioral responses that minimize reasoning and maximize conflict — what better way of doing so than encouraging tribalism.

您想利用默认的人类行为React来最大程度地减少推理并最大程度地增加冲突，这是比鼓励部族主义更好的方式。

Holding only one organization responsible for a goal (no matter what it is) will guarantee the divisive behavior you're trying to obtain.

只让一个组织对目标负责(无论目标是什么)，将确保您试图获得的分裂行为。

That group will spend most of its time and resources proving their responsibilities were met, instead of facilitating product goals.

该小组将花费大部分时间和资源证明自己的职责得到了履行，而不是促进产品目标。

To maximize the impact of this principle, make sure that Test teams only own the quality objective. They should not be responsible for determining release content, that's the Marketing team. Nor should they be involved in setting release dates, that's a Sales function. They also don't determine which problems to fix, that's up to the Product team.

为了最大程度地发挥这一原则的影响，请确保测试团队仅拥有质量目标。他们不应该负责确定发布内容，这是营销团队。他们也不应该参与设置发布日期，这是销售职能。他们还不确定要解决哪些问题，这取决于产品团队。

You want the Development team focused on delivering features by the time the Marketing and Sales orgs promised them. So avoid imposing any code commit or merge rules requested by Test, like requiring code reviews, passing linters, passing unit tests, and others. After all, quality is Test's responsibility, not Development's.

您希望开发团队在市场营销和销售组织向他们承诺时就专注于交付功能。因此，请避免强加Test要求的任何代码提交或合并规则，例如要求代码审查，通过linters，通过单元测试等。毕竟，质量是测试的责任，而不是开发的责任。

Breaking up objectives in this way, turns meeting agendas away from customer experience and towards the blame game. You know you're on the right track when you hear statements like:

以这种方式打破目标，使会议议程从客户体验转向责备游戏。当您听到类似以下的语句时，您知道自己处在正确的轨道上：

"Why didn't you find this bug sooner!"
“为什么不早点找到这个错误！”
"The current tests failed, but we really need to merge this new feature so you can start testing it."
“当前的测试失败了，但是我们确实需要合并这一新功能，以便您可以开始对其进行测试。”
"Why didn't Test find this customer issue?"
“为什么测试没有找到这个客户问题？”
"We promised the customer a release by this date, so let's defer all Test findings and give them a build today."
“我们承诺在该日期之前向客户发布产品，因此让我们推迟所有测试发现，并立即进行构建。”
"We found the issue that the customer reported, but you deferred it last month!"
“我们发现了客户报告的问题，但您上个月推迟了！”
"I can't run tests because you gave me a broken build."
“我无法运行测试，因为您给了我一个坏的版本。”

Spending time arguing about whose job it is to do the work is an excellent mechanism to reduce satisfaction with your product or service.

花时间争论要由谁来做是降低您对产品或服务满意度的绝佳机制。

2.要求所有测试在发布之前都必须自动化 (2. Require all tests to be automated before releasing)

Another device for distracting from quality is requiring test automation for every feature. It guarantees that your Test organization spends most of its time doing software development instead of test engineering.

另一个分散质量的设备要求对每个功能进行自动化测试。它可以确保您的测试组织将大部分时间都花在软件开发而不是测试工程上。

The goal should change from validating a product attribute, to counting how many automated tests ran to verify it.

目标应该从验证产品属性转变为计算运行了多少个自动测试来验证它。

Rather than thinking through the test breakdown that validates various code paths or fundamentals of a function, engineers will spend time and resources executing multiple iterations of the same test. It leads to higher counts.

工程师们不会花时间考虑验证各种代码路径或功能基础的测试故障，而要花费时间和资源来执行同一测试的多次迭代。它导致更高的数量。

It also promotes a fragile test infrastructure and increases maintenance costs.

它还会促进脆弱的测试基础架构并增加维护成本。

Since there's no time to consider test strategy and abstractions, they're forced to write very specific - yet brittle - workflows. Whenever Development makes slight changes to the feature, the tests break.

由于没有时间考虑测试策略和抽象，因此它们被迫编写非常具体但脆弱的工作流。只要Development对功能进行了微小的更改，测试就会中断。

The Test organization must focus on producing a large number of tests as fast as possible. Otherwise, they'll have time to push more value into the product with more meaningful tests.

测试组织必须专注于尽可能快地进行大量测试。否则，他们将有时间通过更有意义的测试将更多价值推向产品。

Make sure to reward this behavior by promoting engineers that produce the highest number of automated tests that run frequently. But don't forget about those that save time by writing scripts that execute other scripts while hard-coding all the arguments so the user won't have to type them.

确保通过提拔能够产生频繁运行的最多自动测试的工程师来奖励这种行为。但是不要忘了那些通过编写执行其他脚本同时对所有参数进行硬编码的脚本来节省时间的方法，这样用户就不必键入它们。

3.需要100％的代码覆盖率 (3. Require 100% code coverage)

Since product quality and customer experience are only correlated to code coverage, forcing your Test and Dev teams to chase 100% coverage is another tactic.

由于产品质量和客户体验仅与代码覆盖率相关，因此迫使您的测试和开发团队追求100％覆盖率是另一种策略。

Make sure you direct all execution conversations towards the coverage measurement and hold teams accountable for it. People will focus on building tests that call all code functions, regardless of their output.

确保将所有执行对话都引向覆盖率度量，并使团队对此负责。人们将专注于构建调用所有代码功能的测试，而不管其输出如何。

A nice bonus is that measuring coverage tends to affect timing or performance. It makes it hard for anyone to understand the actual customer experience, thereby adding to your goal of decreased satisfaction.

一个不错的好处是，衡量覆盖率往往会影响时间安排或性能。这使任何人都难以理解实际的客户体验，从而增加了降低满意度的目标。

Make sure that tool implementations are automated, and that every report includes the coverage numbers, so it's easy to bring up in conversations.

确保工具实现是自动化的，并且每个报告都包括覆盖范围编号，因此很容易进行对话。

Avoid focusing on code branching coverage. It's essential to prove that you tested every function, not every code path in the function. After all, there's no point in planning for customers to hit failure cases. They only happen a small percentage of the time.

避免专注于代码分支覆盖范围。必须证明您测试了每个功能，而不是功能中的每个代码路径。毕竟，没有必要为客户计划失败案例。他们只发生一小部分时间。

Just like the previous section, don't forget to reward the team for being as close as possible to the 100% coverage number. It goes a long way in showing your engineers the behavior that matters.

就像上一节一样，不要忘了奖励团队尽可能接近100％的覆盖率。向您的工程师展示重要的行为有很长的路要走。

4.将测试组织与开发隔离 (4. Isolate the Test organization from Development)

One of the worst things in software development is when the Dev team is so in-sync with Test that they finish each other's sentences. It's a red flag! It means that you're on a path for producing a quality product or service.

软件开发中最糟糕的事情之一是，开发团队与Test如此同步，以至于他们彼此之间都是一句话。这是一个红旗！这意味着您正走上生产优质产品或服务的道路。

Reduce all chances for collaboration, including physical proximity.

减少所有协作的机会，包括物理上的接近。

Make sure to separate the teams, so it takes physical effort for a Test engineer to walk over to a Developer and ask questions. Human nature will take hold and solve the rest of the problem for you.

确保将团队分开，这样测试工程师需要花费大量的精力才能走到开发人员并提出问题。人性将扎根并为您解决其余的问题。

When both of these organizations actively collaborate, they tend to help each other considerably. You'll find the Developer gives the Tester a heads-up about new changes. Alternatively, the opposite could happen, where a Developer will know about a bug before it's reported. Not only does this break tribalism, but it sidetracks well-defined responsibilities.

当这两个组织积极合作时，它们往往会互相帮助。您会发现开发人员为测试人员提供了有关新更改的提示。另外，情况可能相反，开发人员会在报告错误之前就知道该错误。这不仅破坏了部落主义，而且也使明确定义的责任背道而驰。

Collaboration leads to less process:

协作导致更少的过程：

In some cases, issues are just fixed instead of reported.
在某些情况下，问题只是解决而不是报告。
Internal documentation and knowledge transfers receive less time and attention.
内部文档和知识转移的时间和精力更少。
Test engineers become more knowledgeable about the product.
测试工程师对产品的了解会更多。
Release schedules start to reflect reality during planning.
发布计划开始反映计划中的实际情况。

All of these lead to higher quality and better customer satisfaction! The direct opposite of your goals.

所有这些导致更高的质量和更好的客户满意度！您目标的直接对立面。

Enforcing more process is a great way of discouraging this behavior. It helps highlight the requirements that an engineer doesn't meet when directly engaging with other teams. It can come in the form of extra checkpoints and meetings, but preferably, more documentation.

强制执行更多过程是阻止这种行为的好方法。它有助于突出工程师与其他团队直接接触时工程师无法满足的要求。它可以以额外的检查站和会议的形式出现，但最好是更多文档。

Another excellent tool for increasing isolation is access controls. Make sure that Test does not have access to source code and that Dev cannot see the procedures of a test case.

另一个提高隔离度的出色工具是访问控制。确保Test无法访问源代码，并且Dev无法查看测试用例的过程。

I find that separating tests from code is a must! If you have both in the same repository, then Developers will know ahead of time when they break a test. A process shortcut that leads to the very efficiencies we don't want.

我发现必须将测试与代码分开！如果两者都在同一个存储库中，那么开发人员在打破测试时会提前知道。导致我们不想要的效率很高的过程捷径。

5.评估过程的成功，而不是产品 (5. Measure the success of the process, not the product)

I can't tell you how many conversations I've had with coworkers that keep asking impertinent questions about customer adoption.

我无法告诉您我与同事进行了多少次对话，这些对话一直在询问有关客户采用的无关紧要的问题。

Things like: How many customers are using that feature? What's the potential impact to our install base? How many steps must the user go through to use this feature? What's the attach rate? How big is our potential customer pool for that requirement? How many users asked for this function?

像这样的事情：有多少客户正在使用该功能？对我们的安装基础有什么潜在影响？用户必须经过几个步骤才能使用此功能？附着率是多少？我们满足该需求的潜在客户群有多大？有多少用户要求此功能？

These folks don't get it. It's imperative to discourage this behavior as it happens. It tends to spread to other team members, and pretty soon, you'll have an organization that only cares about quality.

这些人不明白。必须阻止这种行为的发生。它倾向于传播到其他团队成员，很快，您将拥有一个只关心质量的组织。

The best thing to do is redirect that energy by asking questions about the process instead. The items below are some stats that help accomplish this.

最好的办法是通过询问有关流程的问题来重定向精力。以下各项是有助于完成此操作的一些统计信息。

未解决问题的数量以及由谁打开 (Number of open issues and who opened them)

It helps prove how well the Test team is doing and how much work they're putting in.

它有助于证明测试团队的工作状况以及他们投入了多少工作。

Don't forget to encourage the employees that opened the highest number of issues. Bring it up in meetings often, so the rest of the folks are not surprised during performance reviews.

不要忘记鼓励那些打开最多问题的员工。经常在会议上提出来，因此其他人在绩效考核中不会感到惊讶。

Some will try to argue that too many open issues lead to significant overhead in managing them. Again, that's the whole point.

有些人会试图辩称，太多的未解决问题导致管理这些问题的大量开销。再次，这就是重点。

Refocus team effort away from quality and towards process. Plus, if there are too few issues, then the Test org looks like their not working.

将团队工作重心从质量转移到过程。另外，如果问题太少，则测试组织似乎无法正常工作。

问题等待测试响应所花费的时间 (Amount of time an issue spent waiting for Test response)

It's trickier to measure, but when you can pull it off, it's a great way to show how well the Test org is doing when compared to Development. It encourages behaviors that help maximize the active issue count.

衡量起来比较棘手，但是当您可以实现这一点时，它是展示测试组织与开发组织相比做得如何的好方法。它鼓励有助于最大程度地增加活动事件数量的行为。

To help the situation, try to tie issue status changes to process requirements that enforce particular field values for specific situations.

为了帮助解决这种情况，请尝试将发布状态更改与对特定情况实施特定字段值的流程要求联系起来。

It reduces the time an issue spends on the Test side whenever parameters don't match because the engineer will have to ask for the correction.

只要参数不匹配，它就可以减少问题在测试侧花费的时间，因为工程师将不得不要求更正。

Development is usually too busy to care about this stuff. So it also leads to lots of political discussions in project management meetings and encourages more tribalism.

开发人员通常太忙而不关心这些东西。因此，这也导致在项目管理会议中进行大量的政治讨论，并鼓励更多的部落主义。

封闭状态下的问题百分比 (Percentage of issues in a closed state)

Before a release, you want to encourage the team to close all issues. It's best to base the performance review of Development engineers on how many issues were open against their code at release time.

在发布之前，您要鼓励团队关闭所有问题。最好根据发布时针对他们的代码公开的问题来对开发工程师进行性能评估。

It guarantees fewer defects opened by the Development team - further boosting your Test performance. It also discourages communication with the Test organization and increases friction.

它保证了开发团队发现的缺陷更少-进一步提高了测试性能。它还会阻碍与测试组织的沟通并增加摩擦。

与执行计划相比执行的测试百分比 (Percentage of tests executed compared to an execution plan)

Don't forget to make an execution curve telling the team how to spend their time throughout the test cycle. Be careful not to base it on history, or you may find that the org meets the numbers and improves quality.

不要忘记绘制一条执行曲线，告诉团队如何在整个测试周期中花费时间。注意不要以历史为依据，否则您会发现组织符合要求并提高了质量。

Check the graph in every status meeting and ask for progress regardless of the state of the product. It forces the inclusion of tests meant to always complete just to pad the numbers and meet expectations.

不论产品的状态如何，在每次状态会议中检查图表并询问进度。它迫使必须始终完成测试，只是为了填补数字并达到期望。

Discourage anyone that beats projections. Doing so makes it look like the Test org has free time.

不鼓励任何超出预期的人。这样做使测试组织看起来有空闲时间。

测量合格率 (Measure the pass rate)

You'll want to track the percent of test execution that's passing vs. failing for all the tests put together.

您将希望跟踪所有测试组合中通过测试与未通过测试的百分比。

Make sure you explain to the team the required pass rate to reach a release stage. It reminds them to design suites with enough tests that always pass so that you can meet process requirements.

确保您向团队说明达到发布阶段所需的合格率。它提醒他们设计套件时要始终通过足够的测试，以便您能够满足流程要求。

6.需要工程师的详尽预测 (6. Require granular projections from engineers)

Getting a schedule from Dev is hard. Many times they try to throw reality at the problem as if complexity mattered. The truth is you'll release by the date designated by the Sales organization regardless, but Dev never seems to understand that.

从Dev获取时间表很困难。很多时候，他们试图将现实抛在问题上，好像复杂性很重要。事实是，无论如何，您都将在销售组织指定的日期前下达工作，但是Dev似乎从来都不了解。

Whenever discussing code completion dates, make sure to ask for the day, not the week or the month when they'll complete. If you disagree with that date, bring it up in a public forum of all their peers so they can argue it.

每当讨论代码完成日期时，请务必询问要完成的日期，而不是星期或月份。如果您不同意该日期，请在所有同行的公开论坛中提出，以便他们可以争论。

Doing so accomplishes several essential points in lowering quality:

这样做可以达到降低质量的几个要点：

Developers fight among themselves, reducing communication.
开发人员之间相互斗争，减少了沟通。
They stop thinking they have a say in how to spend their days or do their jobs, which increases turnover.
他们不再认为自己在如何度过工作或做事上有发言权，从而增加了营业额。
It makes it unlikely that they meet their deadlines, which lowers their performance review and also increases turnover.
这使得他们不太可能按时完成任务，从而降低了绩效考核并增加了营业额。

Achieving high turnover is like the holy grail of lowering quality. It helps reduce the bottom line with fewer raises and promotions. It increases disinformation, emphasizing individualism. Finally, it removes any ownership that might build up in the team over time.

实现高周转率就像降低质量的圣杯。它有助于减少底线，减少加薪和晋升。它增加了虚假信息，强调了个人主义。最后，它消除了随着时间的推移可能在团队中建立的所有所有权。

7.奖励快速修补而不是解决 (7. Reward quick patching instead of solving)

Given enough time, engineers can solve almost every problem. But when you do the opposite, an interesting phenomenon occurs: instead of resolving the root issue, they fix the symptoms, sometimes ignoring the problem completely.

如果有足够的时间，工程师几乎可以解决所有问题。但是，当您采取相反的操作时，会出现一个有趣的现象：他们没有解决根本问题，而是解决了症状，有时甚至完全忽略了问题。

Here are some of the benefits you'll see when using this technique:

使用此技术时，您会看到一些好处：

Development gets praise for being quick.
开发因快速而受到赞誉。
The base problem isn't solved, so there's a bunch of opportunities for writing future bugs, making the Test team and the process look better.
基本问题没有解决，因此有很多机会编写将来的错误，使测试团队和过程看起来更好。
The customer will keep running into the same issues, which translates to lower satisfaction.
客户将继续遇到相同的问题，这会降低满意度。
The patches for each symptom develop a spiderweb of dependencies, making future work harder and more brittle, which translates to lower quality.
每种症状的补丁都形成了依赖关系的蜘蛛网，使将来的工作更加困难，更加脆弱，从而降低了质量。
You'll gain issues for everyone you fix at a viral pace. The more problems to fix, the more process you need to track the ones left behind. Win-win!
您将以病毒般的步伐为每个修复的人遇到问题。要解决的问题越多，跟踪遗留问题所需的过程也就越多。双赢！

Rewards are fundamental here as well. Make sure to incentivize this type of work with awards, and broadcast them to the team so everyone is aware of the behavior you want.

奖励在这里也很重要。确保通过奖励激励此类工作，并将其广播给团队，以便每个人都知道您想要的行为。

8.计划今天而不是明天 (8. Plan for today instead of tomorrow)

There's always someone trying to foresee what tomorrow brings. These days some engineers will do statistical analysis or machine learning. Formulating an algorithm that explains how well execution is going, which issues are important, how much time is actually needed, the number of resources required to test, etc.

总是有人试图预见明天会带来什么。如今，一些工程师将进行统计分析或机器学习。制定算法来说明执行的进展情况，哪些问题很重要，实际需要多少时间，测试所需的资源数量等。

Then there are the folks that have been around long enough and keep bringing up past mistakes or wasted efforts you should avoid.

然后有些人已经存在了很长时间，并且不断提出过去的错误或浪费的精力，您应该避免。

Ignore that advice and always plan for the best case today. It doesn't matter if technical debt is high, if the 3rd party vendor has low quality, or if everyone planned a vacation on the same day during the next release.

忽略该建议，并始终计划最好的情况。技术债务高，第三方供应商质量低劣或每个人都计划在下一个发行版的同一天放假都没关系。

Deal with problems when they occur, not before. Otherwise, efficiency will increase.

当问题发生时就处理，而不是之前处理。否则，效率会提高。

9.结论 (9. Conclusions)

While there are many more points to cover, it seems our fictional Sales team decided to ship before completing the article!

尽管还有很多要讲的要点，但似乎我们虚构的销售团队决定在完成本文之前先发货！

On a more serious note, test engineering and product validation gets exponentially harder with complex systems and large organizations. It's important to incentivize the right type of behaviors in order to succeed. However, those aren't always obvious and in some cases, they're even counter-intuitive.

更严重的是，对于复杂的系统和大型组织而言，测试工程和产品验证变得越来越困难。为了成功，激励正确的行为类型很重要。但是，这些并不总是很明显，在某些情况下，它们甚至违反直觉。

I do hope the article helped you observe the test world from a different perspective. One that provides some helpful insight. I find this practice of aiming for bad outcomes quite illuminating sometimes. At the very least, it's loads of fun to think through.

我确实希望本文可以帮助您从不同的角度观察测试世界。一种提供有用的见解的工具。我发现针对不良结果的这种做法有时很有启发性。至少，要进行思考很有趣。

If you liked the article and want to read more about development best practices from Cristian Medina and others, please visit tryexceptpass.org. Stay informed with their latest content by subscribing to the mailing list.

如果您喜欢这篇文章，并且想阅读有关Cristian Medina和其他人的开发最佳实践的更多信息，请访问tryexceptpass.org 。订阅邮件列表，随时了解其最新内容。