sap miro_Miro的质量检查流程

sap miro

What do we do? We need to do preliminary preparation for each block of the development process: task decomposition, evaluation and planning, development itself, investigative testing, and release. This preparation does not consist of simply throwing old parts out of the process but of their adequate replacement, which increases quality.
我们做什么？ 我们需要为开发过程的每个阶段做初步准备：任务分解，评估和计划，开发本身，调查性测试和发布。 这种准备工作不只是将旧零件扔掉，而是要进行适当的更换，以提高质量。
In this article, I will talk in detail about our testing process at each stage of creating a new feature and also about the introduced changes that have increased the quality and speed of development.
在本文中，我将详细讨论在创建新功能的每个阶段的测试过程，以及将提高开发质量和速度的引入的更改。

从瀑布到Scrum的过渡 (The transition from Waterfall to Scrum)

A few years ago, we realized that our development process, which was based on the classic waterfall model, needed to be adjusted to deliver value to users faster and more often. Scrum was great for this because it allowed us to end each sprint with an increment.
几年前，我们意识到基于经典瀑布模型的开发过程需要进行调整，以更快，更频繁地为用户提供价值。 Scrum对此非常有用，因为它允许我们以递增的方式结束每个sprint。
We introduced Scrum events and short iterations. Everything looked good in theory:
我们介绍了Scrum事件和短迭代。 理论上一切都看起来不错：

• to make a release at the end of the week, we need to have the implemented functionality on Wednesday;
  要在本周末发布，我们需要在星期三拥有已实现的功能；
• test it on Thursday;
  在星期四进行测试；
• fix the bugs;
  修复错误；
• roll it out to the production environment on Friday.
  在星期五将其发布到生产环境。

In reality, it turned out differently because we had not in fact changed the process but only put our waterfall inside a weekly sprint. As a result, the functionality was most often ready by Friday (not by Wednesday) because we could not correctly evaluate the tasks and because we were faced with new, higher priority tasks in the middle of a sprint. Testing was completely left out of the sprint process.
实际上，结果有所不同，因为我们实际上并未更改流程，而只是将瀑布放入每周的冲刺中。 结果，该功能通常在星期五(而不是星期三)准备就绪，因为我们无法正确评估任务，并且因为在冲刺过程中我们面临着更高优先级的新任务。 测试完全不在冲刺过程中。
Then we moved the preparation of acceptance scenarios to the beginning of a sprint. This immediately gave a result. Scenario preparation is approximately 60 percent of the testing time. Going through prepared scenarios is a quick process, and in addition, we learn about nonstandard cases before the start of development and can immediately take them into account in planning.
然后，我们将验收方案的准备工作移至冲刺的开始。 这立即产生了结果。 场景准备大约占测试时间的60％。 准备好场景是一个快速的过程，此外，我们在开发开始之前就了解了非标准案例，并可以在计划中立即将它们考虑在内。

质量检查流程的各个阶段 (Stages of the QA process)

开工会议，示例映射，验收方案 (Kick-off meeting, example mapping, acceptance scenarios)

Say a product manager gives the team a user story or a technical lead brings the technical story of a component’s development.
假设产品经理为团队提供了用户故事，或者技术主管带来了组件开发的技术故事。
The first thing you need to do is decompose the story. To do that
您需要做的第一件事就是分解故事。 要做到这一点

• The team forms an understanding of the story’s requirements that is common for all participants, using, among other things, an exhaustive list of questions for the product manager. This also helps to find requirements that were not taken into account initially. For meetings, we use an approach called “example mapping” (a map of test cases), which greatly improves their efficiency. It’s important not to apply this approach formally without an understanding of how it works, because in that case it will not work, and the team will end up with a negative attitude toward such changes. Learn more about example mapping.

  团队通过对产品经理的详尽问题列表，形成对所有参与者都通用的故事要求的理解。 这也有助于查找最初没有考虑的要求。 对于会议，我们使用一种称为“示例映射”(测试用例的映射)的方法，可以大大提高会议效率。 重要的是，不要在不了解其工作原理的情况下正式采用这种方法，因为在这种情况下，它将无法工作，并且团队最终会对这种变化持消极态度。 了解有关示例映射的更多信息 。

• UX designer anticipates user behavior and creates mockups.
  UX设计器预期用户行为并创建模型。
• Developer creates the technical side of the implementation.
  开发人员创建实施的技术方面。
• QA engineer writes acceptance criteria for each story and creates acceptance scenarios based on them (not a draft, but a complete list of tests that need to be performed to ensure that everything is checked).
  质量检查工程师为每个故事编写验收标准，并根据它们创建验收方案(不是草稿，而是需要执行的完整测试列表，以确保检查所有内容)。

An acceptance scenario (acceptance criteria are the part of the definition of done) is not just a simple list of test cases, but the result of an exhaustively detailed decomposition of the task. After that, you should be left in a state of “there is nothing more to discuss here.”

接受方案(接受标准是完成的定义的一部分)不仅是测试用例的简单列表，而且是详尽详尽地分解任务的结果。 之后，您应该处于“这里无话可说”的状态。

待办事项整理和冲刺计划 (Backlog grooming and sprint planning)

At this stage, we estimate, among other things, the coverage tasks and think through the investigative testing that may be needed: load testing, security testing, consumer testing, etc. Then, in sprint planning, we explicitly take test coverage tasks or write acceptance criteria for main tasks where tests are also explicitly taken into account.
在此阶段，我们估算覆盖范围任务，并考虑可能需要的调查性测试：负载测试，安全性测试，消费者测试等。然后，在sprint计划中，我们明确承担测试覆盖率任务或编写还明确考虑了测试的主要任务的接受标准。
Test coverage is an integral part of a task, and test writing is a regular job of a developer. But not everyone is used to that yet, so it is better to take test coverage tasks into a sprint explicitly, at least in the early stages. Now, fortunately, we are already encountering cases where the developers themselves remind us that we have not made a scenario for a specific task.
测试覆盖率是任务的组成部分，而测试编写是开发人员的日常工作。 但是，并不是所有人都已经习惯了，因此最好将测试覆盖任务明确地带入sprint，至少在早期是这样。 幸运的是，现在我们已经遇到了一些案例，开发人员自己提醒我们，我们还没有为特定任务制定方案。

Improving quality reduces the number of iterations and development time. In our experience, this has allowed us to reduce development time by more than half.
提高质量可以减少迭代次数和开发时间。 根据我们的经验，这使我们可以将开发时间减少一半以上。

开发和手动测试 (Development and manual testing)

The main difficulty here is a large number of development iterations. For example, one of the features in our product went through twenty-six iterations. Why? Because earlier, an engineer, instead of testing the code themselves, gave it to the QA team, which led to errors and many fixes and improvements.
这里的主要困难是大量的开发迭代。 例如，我们产品的功能之一经历了26次迭代。 为什么？ 因为更早之前，工程师将其交给质量检查团队，而不是亲自对其进行测试，因而导致错误以及许多修复和改进。
Here is what it looked like:
看起来是这样的：

1. The developer implements the task but does not thoroughly test it because they know that a QA engineer will check everything anyway.
   开发人员可以执行任务，但不会对其进行彻底的测试，因为他们知道质量检查工程师仍会检查所有内容。
2. QA engineer finds errors and returns the task for revision.
   质量检查工程师发现错误，然后将任务退回以进行修订。
3. The developer fixes the found errors but makes new ones.
   开发人员修复了发现的错误，但又做了新的错误。
4. The cycle is repeated many times.
   该循环重复多次。

As a result, no one can guarantee the quality of functionality. The developer does not remember what they were doing in the last iteration. The QA engineer does not know exactly what and at what point they checked something, so the problem is that they both have a blurred perception (it is difficult to look at the same thing again and again) while also being busy with several features at different stages of development at once.
结果，没人能保证功能的质量。 开发人员不记得他们在上一次迭代中在做什么。 QA工程师并不确切知道他们在什么地方以及什么时候检查了什么，因此问题在于他们既有模糊的感知(很难一遍又一遍地看同一件事)，又忙于不同地方的几个功能发展的各个阶段。
What do we do about it? We could have transferred manual testing from QA engineers to developers, but this could have led to a loss of quality. Changes in processes are needed only when they guarantee an increase in the quality of the result. Therefore, instead of simply removing manual testing, we replaced it with new tasks that improve quality:
我们对此怎么办？ 我们本可以将手动测试从质量检查工程师转移到开发人员，但这可能会导致质量下降。 只有在保证结果质量提高的情况下，才需要更改过程。 因此，我们不仅仅删除手动测试，还用提高质量的新任务代替了它：

• Preparation of acceptance scenarios, thanks to which a developer knows exactly what to check and has every opportunity to do that.
  准备验收方案，开发人员因此可以准确地知道要检查的内容，并有机会这样做。
• Test coverage at different levels. We release daily and have about thirty teams that make changes to the codebase. At the same time, our website, frontend, and backend are three monoliths divided into modules and components, but there are still interconnections between them that can break.
  测试不同级别的覆盖率。 我们每天发布，大约有30个团队对代码库进行更改。 同时，我们的网站，前端和后端是三个整体，分为模块和组件，但是它们之间仍然存在可能断开的互连。
• Test automation. We do test coverage during development; for this, all QA engineers in the company can write autotests. Test coverage is organized differently in different teams: in some teams, all types of tests are written by developers (unit, integration, component, module, E2E); in others, QA engineers write API tests or all autotests.
  测试自动化。 我们在开发过程中测试覆盖率； 为此，公司中的所有质量检查工程师都可以编写自动测试。 在不同的团队中，测试的覆盖范围是不同的：在某些团队中，所有类型的测试都是由开发人员编写的(单元，集成，组件，模块，E2E)； 在其他情况下，质量检查工程师编写API测试或所有自动测试。
• Validation of positive scenarios together with the product owner. This allows the team to understand the reasoning behind the task better and to walk through a user story one more time.
  与产品负责人一起验证积极方案。 这使团队可以更好地理解任务背后的原因，并再次浏览用户故事。
• Verification of the design and layout. This stage takes place before the merge request, and both the designer and the frontend developer participate in it.
  验证设计和布局。 此阶段发生在合并请求之前，并且设计者和前端开发人员都参与其中。

Our product works in different browsers as well as several desktop and mobile applications. Due to the large number of changes that affect many browsers and applications, we are unable to verify today what we implemented yesterday. It is impossible to test everything frequently manually, so automation becomes a necessity rather than a fashion choice.
我们的产品可在不同的浏览器以及多种桌面和移动应用程序中运行。 由于影响许多浏览器和应用程序的大量更改，我们今天无法验证昨天实施的内容。 不可能经常手动测试所有内容，因此自动化成为必要，而不是时尚选择。

With a large number of users, there will always be someone who will trigger a specific variation, and without low-level tests, it can be missed in testing. This is one of the main reasons for bugs in the production environment.
在大量用户的情况下，总会有人触发特定的变化，并且如果没有低级别的测试，可能会在测试中错过它。 这是生产环境中出现错误的主要原因之一。

Now the developer knows that no one will test the functionality for them and that everything they merge will be automatically deployed to the production environment. Therefore, developers do manual testing — not because there is no QA engineer in this workflow, but because it increases the level of responsibility and quality. In any workflow model, a developer must ensure that everything works as they planned: not putting blind trust in their experience, but checking everything according to it. Another thing to note is that the developer does not want to do manual testing, which stimulates them to cover their code with tests. Also, unit tests help them to avoid double-checking the same functionality multiple times, which means that we do not transfer the problem of blurred perception from QA engineer to developer.
现在，开发人员知道没有人会为其测试功能，并且他们合并的所有内容都将自动部署到生产环境中。 因此，开发人员进行手动测试-不是因为此工作流程中没有质量检查工程师，而是因为它增加了责任心和质量。 在任何工作流程模型中，开发人员都必须确保一切按计划进行：不要对自己的体验抱有盲目信任，而要根据经验进行检查。 要注意的另一件事是，开发人员不想执行手动测试，这会促使他们用测试覆盖他们的代码。 此外，单元测试有助于他们避免多次检查相同的功能，这意味着我们不会将质量不清的问题从QA工程师转移到开发人员。
There are cases where some details cannot be thought out at the previous stages; when this happens, a QA engineer gets involved in the development stage to change the scenarios or for manual testing. But these cases are isolated.
在某些情况下，前一阶段无法考虑某些细节； 当发生这种情况时，质量检查工程师会进入开发阶段以更改方案或进行手动测试。 但是这些情况是孤立的。
Thanks to these changes, we implement both simple and large, complex tasks (that take, for example, a month of work for five engineers) in a few iterations, often in just one. Internally, we’ve agreed that backend tasks should be implemented in one or two iterations, five tops if the frontend is complicated. If the number of iterations increases, this is a signal for us that there is a problem in our processes.
由于这些更改，我们可以在几次迭代中(通常只有一次)实现简单和大型，复杂的任务(例如，需要五个工程师工作一个月)。 在内部，我们已经同意后端任务应该在一到两次迭代中实现，如果前端很复杂，则应该在五个迭代中实现。 如果迭代次数增加，则这向我们发出信号，表明我们的过程中存在问题。

功能检查标记和调查性测试 (Feature checkmarks and investigative testing)

By removing routine current testing tasks from the QA engineers, we freed up 80 percent of their time. It is very easy for the team to fill that freed-up time, but this does not always lead to improvements in quality. We spend it on additional testing, which helps us to dig deeper and find nonstandard cases that previously slipped to the production environment unnoticed.
通过从质量检查工程师那里删除常规的当前测试任务，我们节省了80％的时间。 团队很容易填补这些腾出的时间，但这并不总是导致质量的提高。 我们将其花费在其他测试上，这有助于我们更深入地发现非标准案例，这些案例以前曾被忽视到生产环境中。
A big feature is usually implemented by several people, is a sequence of tasks, and is released in parts, and the functionality itself is initially hidden from users (we use a technique of feature checkmarks for this). When a feature is deployed on the production server and is still hidden from the user, a QA engineer performs all the investigative tests that were worked out during backlog refinement (grooming): load tests, security tests, consumer tests, etc. For example, they could allocate time to break the whole functionality purposefully. The QA engineers have everything they need for that: they understand how it works, since they analyzed it in detail at the meetings and during the writing of acceptance scenarios, and their perception is not blurred since they did not participate in the development process.
一个重要的功能通常由几个人实现，是一系列任务，并且会部分发布，并且功能本身最初对用户是隐藏的(为此，我们使用了功能检查标记的技术)。 当功能部署在生产服务器上并仍对用户隐藏时，质量检查工程师将执行积压细化(整理)期间制定的所有调查性测试：负载测试，安全性测试，使用者测试等。例如，他们可以分配时间有目的地破坏整个功能。 质量检查工程师拥有所需的一切：他们了解了它的工作原理，因为他们在会议上和编写验收方案的过程中对其进行了详细的分析，并且由于他们没有参与开发过程，因此他们的看法也不模糊。
At this stage, a product manager must ensure that the implemented functionality is the same as the planned functionality. They verify that the result matches the task description, check the main positive scenarios, and try to use the feature.
在此阶段，产品经理必须确保实现的功能与计划的功能相同。 他们验证结果是否与任务说明相匹配，检查主要的肯定方案，然后尝试使用该功能。
Investigative testing covers the entirety of new functionality testing and how it fits into the current product: how consistent it is, how it interacts with other functionalities, etc.
调查性测试涵盖了整个新功能测试以及它如何适合当前产品：它的一致性，与其他功能的交互方式等。

发布和监控 (Release and monitoring)

After all investigative tests are performed, we release the functionality to users (remove the feature checkmark), and the team begins to monitor the feature. The release process itself consists of several stages, but I will talk about that in another article.
在完成所有调查性测试之后，我们向用户发布了该功能(删除了功能复选标记)，然后团队开始监视该功能。 发布过程本身包含几个阶段，但是我将在另一篇文章中讨论。

我们对测试过程所做的所有更改的摘要 (Summary of all the changes we made to the testing process)

Testing no longer takes place at the end of a sprint but is distributed throughout it.
测试不再在冲刺结束时进行，而是分布在整个冲刺中。
The quality of the result is not the responsibility of a QA engineer, but the whole team. Previously, a QA engineer took responsibility for everything done by the team because they were the only ones who did the testing and gave the order to release.
结果的质量不是质量保证工程师的责任，而是整个团队的责任。 以前，质量检查工程师负责团队所做的所有工作，因为他们是唯一进行测试并下达订单的人。
Now, everyone has a role in maintaining quality:
现在，每个人都在维护质量方面发挥作用：

• Designer is responsible for the consistency of UX and the ease of use of the feature;
  设计人员负责UX的一致性和功能的易用性；
• Developer is responsible for test coverage, including E2E;
  开发人员负责测试范围，包括E2E；
• QA engineer is responsible for the tricky cases of interconnection with other parts of the system and various testing approaches that help test the feature in its entirety;
  QA工程师负责与系统其他部分进行互连的棘手情况以及各种有助于整体测试功能的测试方法；
• Product manager ensures that the team implements the features that the users need — or rather, the implemented feature meets all the originally defined criteria.
  产品经理确保团队实现用户所需的功能-或更确切地说，已实现的功能符合所有最初定义的条件。

The diagram of the whole QA process in an easy-to-view format.易于查看的整个质量检查流程图 。
p.s. This article was first published on
ps本文最初发表于Medium.Medium 。

翻译自: https://habr.com/en/company/miro/blog/509818/

sap miro