打破双亲委派么,怎么打破_质量保证被打破。 这就是我们如何使其像其他所有东西一样敏捷。...

打破双亲委派么,怎么打破

by Derwin

由Derwin

质量保证被打破。 这就是我们如何使其像其他所有东西一样敏捷。 (Quality Assurance is broken. Here’s how we can make it as agile as everything else.)

Process is the key to great software.

过程是出色软件的关键。

In general, the industry has made leaps and bounds in software development processes. But testing processes still remain archaic.

总的来说，该行业在软件开发过程中取得了跨越式的发展。 但是测试过程仍然过时。

Test engineers are forced to manually crunch through tests and bugs at the end of each development cycle.

在每个开发周期结束时，测试工程师被迫手动处理测试和错误。

The result? A ton of wasted time and energy throughout the entire process.

结果？ 在整个过程中浪费了大量的时间和精力。

Agile development is dramatically different from waterfall, which is an older, more rigid software development methodology.

敏捷开发与瀑布式截然不同，瀑布式瀑布式是一种较旧的，更严格的软件开发方法。

Our team practices agile. But as the leader of a team of test engineers, I’ve noticed that our QA process is much more similar to waterfall.

我们的团队练习敏捷。 但是，作为测试工程师团队的负责人，我注意到我们的质量检查流程与瀑布图非常相似。

QA瀑布 (The QA Waterfall)

We start testing at the end of the development process. This leaves test engineers cramped and short on time. You could say that QA testing in agile is a compressed version of waterfall.

我们在开发过程结束时开始测试。 这使测试工程师局促，时间紧迫。 您可以说敏捷中的QA测试是Waterfall的压缩版本。

While there’s less testing per session in agile than in waterfall, the process could be a lot more effective. For starters, when testing is lumped in at the end, it’s often very urgent and time sensitive. This forces test engineers to optimize for speed, which generally means testing products manually.

尽管敏捷中每个会话的测试要比瀑布中的测试少，但该过程可能会更加有效。 对于初学者来说，当最后进行测试时，这通常非常紧急且对时间敏感。 这迫使测试工程师优化速度，这通常意味着手动测试产品。

Obviously, manual testing works. But there are so many aspects of these tests that could be automated if test engineers had more time to write scripts that test software.

显然，手动测试有效。 但是，如果测试工程师有更多时间编写测试软件的脚本，则这些测试的许多方面可以自动化。

The time cost of manual testing adds up in subsequent weeks, as QA manually tests new builds of the same software. Instead, they could’ve built automated scripts to test more of the software, which would take it off test engineers’ plate and provide faster feedback for software engineers.

由于QA会手动测试同一软件的新版本，因此手动测试的时间成本在接下来的几周内会增加。 相反，他们可以构建自动化脚本来测试更多软件，这将使它脱离测试工程师的视野，并为软件工程师提供更快的反馈。

At Flipp, we’ve tried testing software the manual, old fashioned, way. But we ran into our own discomforts and challenges.

在Flipp，我们尝试以老式的方式尝试测试软件。 但是我们遇到了自己的不适和挑战。

For example, any delay in the system or releasing the feature would impact the QA team the week after. These types of delays would compound, to the point where the software engineering team would be extremely far ahead of QA, and QA would be desperately trying to catch up.

例如，系统中的任何延迟或发布功能都会在下周影响质量检查团队。 这些类型的延迟将变得更加复杂，以至于软件工程团队将远远超出质量保证，并且质量保证将拼命追赶。

One common solution to the problem of the development team getting too far ahead of the testing team is to throw a bug bash. This way, the development team can all test bugs to help the QA team catch up before the end of the sprint.

解决开发团队与测试团队相距太远的问题的一种常见解决方案是抛出bug。 这样，开发团队可以测试所有错误，以帮助质量保证团队在冲刺结束之前赶上来。

We implemented an even simpler solution: dev teams include test engineers from the beginning.

我们实施了一个更简单的解决方案： 开发团队从一开始就包括测试工程师。

This way test engineers can identify scenarios and write scripts to test with which to test the dev team’s new code. As developers build the actual software, test engineers can build the scripts to test this software with, which can be used over and over again each week. Most importantly, it collectively saves a ton of time, attention, and energy in subsequent testing.

通过这种方式，测试工程师可以识别方案并编写脚本来测试开发团队的新代码。 在开发人员构建实际软件时，测试工程师可以构建脚本以对其进行测试，并且可以每周多次使用该脚本。 最重要的是，它共同节省了后续测试所需的大量时间，精力和精力。

At Flipp, our QA team asks a lot of precision questions and design testability aspects early on, so that we don’t have to go through the cycle of QA to find out there’s bugs in the system. We question it right from the start. Some standard examples of our precision questions:

在Flipp，我们的质量保证团队会在早期就询问许多精度问题和设计可测试性方面，因此我们不必经历质量保证周期即可发现系统中的错误。 我们从一开始就质疑它。 我们的精度问题的一些标准示例：

• “How much load are we expecting?”
  “我们期望多少负载？”
• “What type of analytic beacons are we relying on so we can measure success for the project?”
  “我们依赖哪种类型的分析信标，以便我们可以衡量项目的成功？”
• “How are we going to make it testable so we can easily deploy?”
  “我们如何使其可测试，以便我们轻松部署？”

Here are the benefits we’d noticed as we implemented this solution, and why we think every company needs to rethink how they test for quality.

这是我们在实施此解决方案时注意到的好处，以及为什么我们认为每个公司都需要重新考虑他们如何测试质量。

反馈比敏捷更快 (Faster feedback than agile)

In general, sprint cycle duration varies from project to project. But for example, let’s say each sprint consists of five days.

通常，冲刺周期的持续时间因项目而异。 但是，例如，假设每个冲刺由五天组成。

In the first three days, software engineers will go through ticketing system — building features and completing tickets. Once they’re done, they then pass their build off to QA. QA’s test engineers have the final couple of days to examine these tickets.

在最初的三天内，软件工程师将通过票务系统-构建功能并完成票证。 一旦完成，他们便将其构建传递给质量检查。 QA的测试工程师将在最后几天检查这些票证。

This would be a typical sprint cycle in both agile and waterfall: Plan, develop, code, and test.

这将是敏捷和瀑布式开发中的典型冲刺周期：计划，开发，编码和测试。

I mentioned this earlier, but I really want to hammer the point home:

我在前面提到了这一点，但我真的很想指出这一点：

Instead of leaving testing at the end, we should implement testing right from the beginning (during the “plan” phase) and start asking questions. As test engineers, we would need to figure out how to test, and what systems we need to build, so we can test it right from the start.

我们应该从头开始(在“计划”阶段)实施测试，而不是在测试结束时离开测试，并开始提出问题。 作为测试工程师，我们需要弄清楚如何进行测试以及需要构建哪些系统，因此我们可以从一开始就对其进行测试。

Traditionally, software engineers would send a build to test engineers, who would then manually conduct a test, and send it back to the software engineers if there were any issues or bugs with the code. There would be a 1–2 day lag as QA might be working on previous tickets. Software engineers would have to wait until that ticket is complete. So, if QA testing is done manually:

传统上，软件工程师会将构建版本发送给测试工程师，然后由他们手动进行测试，如果代码有任何问题或错误，则将其发送回软件工程师。 由于QA可能在处理先前的票证，因此会有1-2天的延迟。 软件工程师必须等到该票证完成为止。 因此，如果手动进行质量检查测试：

1. Test engineers set up time to do tests
   测试工程师设置时间进行测试
2. Software engineers lose time and energy to context switching between different tickets
   软件工程师浪费时间和精力进行不同票证之间的上下文切换
3. Test engineers spend time to do tests
   测试工程师花时间做测试

Pretty clunky, right? Let’s look at how an automated test might work:

很笨，对吗？ 让我们看一下自动测试的工作方式：

A test engineer builds a script where each time someone makes a change and deploys it to the servers, the test ensures that there would be no 500 errors or JavaScript errors. If the test finds any of those errors, the build failed this test, and software engineers will be notified in minutes. Nobody has to wait 2–3 days, it happens automatically. This extremely fast feedback allows the software team to move a lot faster.

测试工程师构建一个脚本，每次有人进行更改并将其部署到服务器时，该测试将确保不会出现500个错误或JavaScript错误。 如果测试发现这些错误中的任何一个，则表明该构建版本无法通过该测试，并且几分钟之内就会通知软件工程师。 无需等待2-3天，它就会自动发生。 这种极其快速的反馈使软件团队可以更快地移动。

The fast feedback compounds into significant savings, particularly for simple and obvious errors. It also minimizes context switching, an overlooked cost.

快速反馈可以节省大量资金，尤其是对于简单明显的错误。 它还最大程度地减少了上下文切换，这是被忽略的成本。

Consider the software engineers’ mind when they have to return to the build a test engineer just sent back. “What was that feature again? What was that bug? How do I fix it?”

当软件工程师不得不返回构建时，请考虑一下软件工程师的想法。 “那个功能又是什么？ 那是什么错误？ 我如何解决它？”

Here, within five minutes, they would know that the phase of testing is complete, and whether it requires more work.

在这里，五分钟之内，他们就会知道测试阶段已经完成，以及是否需要更多工作。

Naturally, as the software becomes more complex, so do the tests.

自然，随着软件变得更加复杂，测试也将变得更加复杂。

最少的紧急情况 (Minimal emergencies)

Because QA considers situations from the beginning of the software development process — and doesn’t wait till the end to manually test scenarios and situations — they will have more time to predict emergencies or consider a wider range of circumstances.

由于QA从软件开发过程的开始就考虑情况-不会等到结束时才手动测试情况和情况-他们将有更多的时间来预测紧急情况或考虑更广泛的情况。

It’s as close to zero emergencies as a software and test engineers will get. Obviously, unanticipated errors still come up. But now, the team has a better idea of how to gather and understand the data, and a bug’s impact on users.

正如软件和测试工程师所能得到的那样，紧急事件几乎为零。 显然，仍然出现意外错误。 但是现在，团队对如何收集和理解数据以及错误对用户的影响有了更好的了解。

For example, let’s say users are reporting an error with the discount slider in the Flipp app. The test engineer will have considered the analytic beacons necessary to quickly check on the reach and significance of the bug. Because of these measures, they might look at the data and notify the team, “This is only impacting 1% of our users.” They can determine that what appeared to be an emergency isn’t really.

例如，假设用户使用Flipp应用程序中的折扣滑块报告错误。 测试工程师将考虑必要的分析信标，以快速检查错误的范围和重要性。 由于采取了这些措施，他们可能会查看数据并通知团队：“这只会影响我们1％的用户。” 他们可以确定似乎紧急的情况并非如此。

A standard QA team is inflexible and won’t allow any bugs to go through. Here there’s tolerance to allow smaller bugs to go through — in order for test engineers to focus on higher priority, wider reaching, bugs. They can more accurately assess the risk of bugs and what’s going through. If impact is minimal, then the test engineers can flag it and have software engineers fix it in the next sprint.

一个标准的质量检查团队是不灵活的，不会允许任何错误通过。 这是允许较小的错误通过的容忍度，以便测试工程师专注于更高优先级，范围更广的错误。 他们可以更准确地评估错误的风险以及正在发生的事情。 如果影响很小，则测试工程师可以对其进行标记，并让软件工程师在下一个冲刺中对其进行修复。

重塑软件团队的文化 (Reinventing your software team’s culture)

Ultimately, incorporating test engineers into the software development process is one symptom of a greater culture shift. Test engineers’ perspectives will now be considered earlier in the process.

归根结底，将测试工程师纳入软件开发过程是文化转变的一个征兆。 现在将在过程的早期考虑测试工程师的观点。

On the test engineering side, test engineers need to be more curious to see how they can make the system better and improve its quality.

在测试工程方面，测试工程师需要更加好奇，以了解如何更好地改善系统并提高其质量。

The shift would be in everyone — product owners, scrum masters, testing engineers, and software engineers — accepting these questions earlier on and considering them.

这种转变将出现在每个人(产品所有者，scrum管理员，测试工程师和软件工程师)中，他们早日接受并考虑了这些问题。

This will unify the team and create a better understanding of what feature success looks like.

这将统一团队，并更好地了解成功的功能。

Typically, engineering leads and product owners take x amount of days to bring something to completion. But their definition of “done” is different from QA’s. Their definition of “done” is sending software over to QA. In contrast, QA’s definition of “done” is when software is releasable to users.

通常，工程负责人和产品负责人需要花费x天的时间才能完成工作。 但是他们对“完成”的定义与质量检查的定义不同。 他们对“完成”的定义是将软件发送给质量检查人员。 相比之下，质量检查(QA)对“完成”的定义是用户可以发布软件的时间。

关于Flipp如何进行质量检查的一击 (A blow-by-blow of how we do QA at Flipp)

In closing, I’m going to give you a specific example of how this might look when your software team builds and tests a feature. Let’s walk through the various stages of a two week sprint, and what the test engineer’s role, aims, and priorities should be in each of them.

最后，我将为您提供一个具体示例，说明您的软件团队构建和测试功能时的外观。 让我们逐步进行为期两周的冲刺的各个阶段，以及每个阶段中测试工程师的角色，目标和优先级应该是什么。

Note that at Flipp, we call our test engineers, “software engineers in test.” For clarity, we referred to them as test engineers in this piece, but this shift in wording in our organization reflects how embedded QA truly is into the software engineering team.

请注意，在Flipp，我们将测试工程师称为“测试中的软件工程师”。 为了清楚起见，在本文中我们将他们称为测试工程师，但是我们组织中措辞的这种变化反映出嵌入式QA真正成为软件工程团队的方式。

阶段1：概念 (Stage 1: Concept)

This stage takes place on day one, when the feature is still little more than an idea. The team doesn’t have much clarity on the feature (around 10%). They know about it, but don’t know exactly how it’ll be built.

这个阶段发生在第一天，那时功能仅是一个想法。 团队对此功能的了解不多(大约10％)。 他们知道它，但不确切知道它将如何构建。

The test engineer’s most important job in this stage is to thoroughly understand, and potentially help define, what success means to the product owner. Some companies call these definitions the “acceptance criteria.”

在此阶段，测试工程师最重要的工作是彻底了解并可能帮助定义成功对产品所有者而言意味着什么。 一些公司将这些定义称为“接受标准”。

In any case, I prefer using the guiding question: “What is winning?”

无论如何，我更喜欢使用指导性问题：“什么是胜利？”

Figuring out the answer — and corresponding key metrics — will be the whole team’s main focus of the concept stage.

找出答案和相应的关键指标将是整个团队在概念阶段的主要重点。

阶段2：模拟和设计 (Stage 2: Mocks and designs)

This stage also happens early in the sprint (usually on day one), when the feature has been defined a bit more clearly (around 30%). The test engineer’s understanding of the feature will change how they test it, and understanding the desired user behavior will inform the testing flow.

此阶段也发生在冲刺的早期(通常在第一天)，此时对该功能的定义更加清晰(大约30％)。 测试工程师对功能的理解将改变他们对其进行测试的方式，而了解所需的用户行为将为测试流程提供依据。

The product owner might define winning as having the user take a certain action. If that’s the case, the test engineer must help determine how to take the user there. As the team starts preparing mockups, some flows or concepts might not make sense. It’s the test engineer’s and team’s job to call out mockups that does not follow user flow or doesn’t lead to winning.

产品负责人可能将获胜定义为让用户采取特定行动。 如果是这样，测试工程师必须帮助确定如何将用户带到那里。 随着团队开始准备模型，某些流程或概念可能没有意义。 召集不遵循用户流量或不会导致获胜的模型是测试工程师和团队的工作。

The test engineer doesn’t necessarily act in a quality assurance capacity here, but still contributes as a team member. They must help identify different user profiles and different ways the app will be used (i.e., personas). The most important thing for the test engineer in this phase is still one of understanding: to grasp the feature as a whole rather than individual ticket elements.

测试工程师不一定在这里发挥质量保证的作用，但仍可以作为团队成员做出贡献。 他们必须帮助识别不同的用户个人资料和应用程序的不同使用方式(即角色)。 对于测试工程师来说，在此阶段最重要的事情仍然是一种理解：从整体上而不是单个票证要素上掌握功能。

第三阶段：门票 (Stage 3: Tickets)

Software tickets make up the bulk of the sprint. It could potentially take place from day 1–10. The tickets make the feature much clearer (at around 60%).

软件票构成了冲刺的大部分。 它可能从第1天到第10天发生。 门票使功能更加清晰(约60％)。

As software engineers work on the feature and resolve tickets, test engineers build small tests to ensure the feature will be built properly. Tickets make the feature more concrete. As the feature becomes more certain, the testing methods become clearer. The test engineer should also build pipelines to enable faster feedback.

当软件工程师研究该功能并解决故障单时，测试工程师会进行一些小型测试，以确保正确构建该功能。 门票使该功能更加具体。 随着功能变得更加确定，测试方法变得更加清晰。 测试工程师还应该构建管道以实现更快的反馈。

That’s a lot of information, so I recommend that the test engineer start off by literally building one test that would be running after every commit or any change. I’d recommend building the happy path scenario first, then moving into the more detailed tests.

这是很多信息，所以我建议测试工程师首先从字面上构建一个将在每次提交或进行任何更改后运行的测试。 我建议先构建幸福的道路场景，然后再进行更详细的测试。

When the test engineer tackles these other more detailed tests, they should also identify other paths: What happens if the user rotates the screen? What happens if they cancel? What happens if they have a strange feature combination? What about the potential critical failures of the feature (e.g., making sure the page loads and avoiding the dreaded 500 error, or ensuring the action on the web page gets recorded accurately in the database).

当测试工程师处理这些其他更详细的测试时，他们还应该确定其他路径：如果用户旋转屏幕会发生什么？ 如果取消，会发生什么？ 如果他们具有奇怪的功能组合会怎样？ 该功能的潜在严重故障该怎么办(例如，确保页面加载并避免可怕的500错误，或者确保网页上的操作已准确记录在数据库中)。

Some of these other paths will be frequent, others will be less common. The test engineer should prioritize the ones they should be testing. I recommend evaluating based on these two criteria:

这些其他路径中的某些路径将很常见，而另一些则不太常见。 测试工程师应优先考虑要测试的对象。 我建议根据以下两个标准进行评估：

What is the impact on revenue or key business metrics? The test engineer should make it easy for people to get where they want to go. For example, in Flipp, we want to make it as easy as possible for the users to get to their desired flyer. Any obstacle takes away from quality.

对收入或关键业务指标有什么影响？ 测试工程师应该使人们易于到达他们想要去的地方。 例如，在Flipp中，我们希望使用户尽可能容易地获得所需的传单。 任何障碍都离不开质量。

Does it affect retention? The test engineer must ensure the app doesn’t crash, or users don’t exit for any unplanned reason. They should also consider ways of bringing users back in, or encouraging them to re-open the app.

它会影响保留率吗？ 测试工程师必须确保该应用不会崩溃，或者用户不会由于任何计划外的原因而退出。 他们还应该考虑使用户重新进入或鼓励他们重新打开应用程序的方法。

The most important thing for test engineers is for them to prioritize what is being found, based on their definition of winning. They must also identify risks throughout the feature based on the usage, impact, and probability of that scenario occurring. How many people will the ticket influence? How deep is the problem? If the app does fail, will it be difficult to recover?

对于测试工程师而言，最重要的事情是，根据他们对获胜的定义，他们优先考虑发现的内容。 他们还必须根据使用情况，影响和发生这种情况的可能性来确定整个功能的风险。 门票会影响多少人？ 问题有多深？ 如果应用程序确实失败了，将很难恢复吗？

阶段4：质量保证和测试 (Stage 4: Quality assurance and testing)

Quality assurance and testing takes place from days 5–10 (all the way up to release). The feature should be be 90–100% clear at this point.

质量保证和测试从第5天到第10天(一直到发布)进行。 此时，该特征应为90–100％清晰。

As tickets become resolved, test engineers should look at their strategy, which they developed in the previous stages, and start executing on their plan. They will work with software engineers to build more clarity or to resolve bugs.

随着故障单的解决，测试工程师应该查看他们在先前阶段中制定的策略，并开始执行他们的计划。 他们将与软件工程师合作，以提高清晰度或解决错误。

The most important thing here is for test engineers to ensure the features that are related to winning are clear. Nice-to-haves or should do’s aren’t going to be fixed unless there’s extra time.

对于测试工程师而言，最重要的是确保与获胜相关的功能清晰易懂。 除非有额外的时间，否则要固定好或应该做的事情不会固定。

阶段5：发布/部署 (Stage 5: Release/deployment)

Release takes place on the final day (hypothetical Day 10). The test engineer’s job must ensure the release is smooth. Prior to release, they should test the feature on a replica of production system. We have a specific post-release checklist we use to keep things consistent. I won’t bore you with the details.

发布在最后一天(假设的第10天)进行。 测试工程师的工作必须确保发布顺利。 在发布之前，他们应该在生产系统的副本上测试功能。 我们有一个特定的发布后检查清单，用于使内容保持一致。 我不会告诉你细节。

As the feature launches, test engineers should keep a close eye on the data to see if it’s in a healthy state, and look at crash logs. We’re humans, so we all miss things sometime even after testing. There might be events even the most careful testing engineers don’t anticipate.

该功能启动时，测试工程师应密切关注数据以查看其是否处于健康状态，并查看崩溃日志。 我们是人类，所以即使经过测试，我们都会在某个时候错过一切。 即使是最仔细的测试工程师也可能不会想到的事情。

Smarter quality assurance starts with considering testing at the beginning of the software development process. It means bringing test engineers in with software engineers at the beginning of the test cycle, and considering scenarios and possibilities from the get go. It’ll make the development process smarter and, most importantly, lead to better software.

更加智能的质量保证始于在软件开发过程的开始就考虑进行测试。 这意味着在测试周期开始时将测试工程师与软件工程师联系起来，并从一开始就考虑各种场景和可能性。 这将使开发过程更智能，最重要的是，可以带来更好的软件。

I’m Derwin, the director of test engineering at Flipp. I published a partial version of this at the Flipp blog. If you’re interested in reinventing the way people buy things, check out our current job postings.

我是Flipp测试工程总监Derwin 。 我在Flipp博客上发布了部分内容。 如果您有兴趣重塑人们的购买方式，请查看我们当前的职位发布 。

翻译自: https://www.freecodecamp.org/news/quality-assurance-is-broken-heres-how-we-can-make-it-as-agile-as-everything-else-64bd19d5e426/

打破双亲委派么,怎么打破