京东质量团队转型实践_以质量为团队的责任。 我们的质量检查经验
京东质量团队转型实践
Disclaimer: This is a translation of an article. All rights belongs to author of original article and Miro company.
免责声明：这是文章的翻译。 版权属于原创文章的作者和Miro公司。
I'm a QA Engineer in Miro. Let me tell about our experiment of transferring partially testing tasks to developers and of transforming Test Engineer role into QA (Quality assurance).
我是Miro的质量检查工程师。 让我说说我们将部分测试任务转移给开发人员并将测试工程师角色转换为QA(质量保证)的实验。
First briefly about our development process. We have daily releases for client side and 3 to 5 weekly releases of server side. Team have 60+ people spitted onto 10 Functional Scrum Teams.
首先简要介绍一下我们的开发过程。 我们有客户端的每日发行版和服务器端的3至5个每周发行版。 团队有60多个人，随随便便组成了10个功能Scrum团队。
I'm working in Integration team. Our tasks are:
我正在集成团队中工作。 我们的任务是：
- Integration of our service into external products 将我们的服务整合到外部产品中
-
Integration of external products into our service
将外部产品集成到我们的服务中
For example we have integrated
例如我们已经整合
Jira. Jira Cards — visual representation of tasks so it's useful to work with tasks not opening Jira at all.
吉拉 Jira Cards-任务的可视化表示，因此使用完全不打开Jira的任务很有用。
实验如何开始 (How the experiment starts)
All starts with trivial issue. When someone of Test Engineers had sick leave then team performance was degraded significantly. Team was continued working on tasks. However when code was reached testing phase task was hold on. As a result new functionality didn't reach production in time.
一切始于琐碎的问题。 当某位测试工程师请病假时，团队绩效将大大下降。 团队继续进行任务。 但是，当到达代码时，测试阶段的任务将继续。 结果，新功能无法及时投入生产。
Going onto vacation by Test Engineer is a more complex story. He/she needs to find another Test Engineer who ready to take extra tasks and conduct knowledge sharing. Going onto vacation by two Test Engineers at the sane time is not an applicable luxury.
测试工程师去度假是一个更复杂的故事。 他/她需要找到另一名测试工程师，他愿意承担额外的任务并进行知识共享。 在同一个时间由两名测试工程师去度假并不是一种奢望。
We have started to think how to solve this problem. We find out that root cause is that testing phase is a bottleneck. Let me share few examples of these.
我们已经开始考虑如何解决这个问题。 我们发现根本原因是测试阶段是瓶颈。 让我分享一些例子。
情况1：任务乒乓球 (Case 1: Task ping-pong)
There are Me and Developer. Each have own tasks. Developer have finished one task and send it for testing to me. As far as this new task has higher priority I'm switching on it. I found defects, raise them in Jira and return task back to Developer for fixes.
有我和开发人员。 每个人都有自己的任务。 开发人员已完成一项任务，并将其发送给我进行测试。 至于此新任务具有更高的优先级，我将其打开。 我发现了缺陷，在Jira中提出了缺陷，然后将任务返还给开发人员进行修复。
I switch back to previous tasks. Developer switch back from current tasks to returned task. After fixes developer returns task back to Me for retesting. I found defect again and return task back again. This could long continuous.
我切换回以前的任务。 开发人员从当前任务切换回返回的任务。 修复后，开发人员将任务退还给我进行重新测试。 我再次发现缺陷，然后再次返回任务。 这可能会持续很长时间。
As a result accumulated time spend on task is increasing in few time and therefore time to market which is critical for us as a product company. There are few reason of effort increasing:
结果，花费在任务上的时间越来越少，因此上市时间对于我们作为产品公司来说至关重要。 增加努力的原因很少：
- Task constantly moving between Test Engineer and developer 任务在测试工程师和开发人员之间不断移动
- Task spending time in waiting for Test Engineer or Developer 花费时间等待测试工程师或开发人员
- Developer and Test Engineer have to frequently switch context between task which causes additional loses of time and mental energy. 开发人员和测试工程师必须经常在任务之间切换上下文，这会导致时间和精神上的额外损失。
情况2：任务队列增加 (Case 2: tasks queue is raising)
There are a few developers in our Scrum Team. They send task to me for testing regularly. That forms a task queue which I proceed based on priorities.
我们的Scrum团队中有一些开发人员。 他们定期发送任务给我进行测试。 这就形成了一个任务队列，我根据优先级进行处理。
That's how we have worked for about a year. However during this time company is grown. Number of projects and developers was increased and therefore number of tasks for testing. At the same time I still was the only one Test Engineer in our Scrum Team and I weren't able to increase my performance in times. As a result the more and more tasks stuck in queue for testing and ping-pong process also increased waiting time.
这就是我们工作大约一年的方式。 但是在这段时间里公司成长了。 项目和开发人员的数量增加了，因此测试的任务数量也增加了。 同时，我仍然是我们Scrum团队中唯一的一名测试工程师，而且我无法及时提高性能。 结果，越来越多的任务排队等待测试和乒乓球处理，这也增加了等待时间。
Suddenly I got sick. New Features delivery from our Scrum Team to production was fully stopped. What team should do in this situation? It's possible to ask for a help of Test Engineer for another team. However another Test Engineer is not in context and didn't get knowledge transfer upfront which will negatively affect quality and schedule in both teams.
突然我生病了。 从我们的Scrum团队到生产的新功能交付已完全停止。 在这种情况下应该做什么团队？ 可能需要其他团队的测试工程师帮助。 但是，另一位测试工程师不在上下文中，也没有提前进行知识转移，这会对两个团队的质量和进度产生负面影响。
The outcome from both cases in the same — teams are too depending from test Engineers:
两种情况在同一情况下的结果-团队也取决于测试工程师：
- Velocity of the team are limited by velocity of Test Engineer. 团队的速度受到测试工程师速度的限制。
- Amoun of developers can't be increased without adding Test Engineers because it doesn't make sense to speedup development if all developed tasks are stuck in queue for testing. 如果不添加测试工程师，就无法增加开发人员的数量，因为如果所有已开发的任务都排在测试队列中，那么加快开发速度是没有意义的。
- While Test Engineer verifies task after Developer the Developer's felling of responsibility for a quality is decreasing. 在开发人员之后测试工程师验证任务的过程中，开发人员对质量责任的减少正在减少。
- If Test Engineer is unavailable then delivery process is suffering. 如果测试工程师不可用，则交付过程受到影响。
让我们添加测试工程师吗？ (Let's add Test Engineers?)
The obvious idea — let's increase amount of Test Engineers. That could work until certain moment: amount of tasks will increase but it's impossible to increase amount of Test Engineers continuously. It will be too costly and inefficient.
一个明显的想法-让我们增加测试工程师的数量。 这可能会持续到某个时刻：任务数量会增加，但不可能不断增加测试工程师的数量。 这将太昂贵且效率低下。
More efficient is to keep velocity and quality with current resources. That's why we have decided to launch an experiment which will help teams to create functionality with embedded quality assuming risks and corner cases. We called this experiment "Transform tester to QA" because it's about transformation of one role from monkey-testers seeking bugs to QA who consciously influence and provide quality across all SDLC phases.
更有效率的是保持当前资源的速度和质量。 因此，我们决定启动一个实验，该实验将帮助团队在承担风险和极端情况的情况下创建具有嵌入式质量的功能。 我们将此实验称为“将测试人员转换为质量检查人员”，因为它是将一个角色从寻求bug的猴子测试人员转变为有意识地影响并在所有SDLC阶段提供质量的质量检查人员。
让我们改善开发流程 (Let's improve development processes)
Experiment objectives:
实验目标：
- Remove team's dependency of Test Engineers not losing in quality and timing. 消除团队对测试工程师的依赖，而这不会损失质量和时间。
- Improve level of quality assurance provided by QAs and teams. 提高质量保证和团队提供的质量保证水平。
The first important step was to change team's mindset. All was expected that Test Engineers exclusively cares and responsible for quality.
第一步是改变团队的观念。 所有人都期望测试工程师完全关心质量并对此负责。
Our idea was that adding effort in task preparation and verification will help to reduce number of ping-pong iterations. Therefore it will allow to deliver new functionality on production keeping acceptable velocity and quality levels or even to improve these.
我们的想法是在任务准备和验证中增加工作量将有助于减少乒乓迭代的次数。 因此，它将允许在生产中交付新功能，同时保持可接受的速度和质量水平，甚至可以改善这些水平。
My Scrum Team together with Test Engineers from other Teams had created new process. We had been worked accordingly this new process for a half year and fix few issues appears during this time and now process looks like:
我的Scrum团队与其他团队的测试工程师一起创建了新流程。 我们为此进行了半年的新工作，因此在此期间修复了一些问题，现在该过程看起来像：
- Presentation on task statement. 陈述任务说明。
- Technical solution and test scenario. 技术解决方案和测试方案。
- Development and verification. 开发和验证。
- Release. 释放。
任务说明 (Task statement)
Product Owner present task statement for a Team. Team analyses task statement to discover corner cases from technical and product point of view. If there are questions appears for clarification or investigation then it's tracked as a separate task with dedicated time in a sprint.
产品负责人向团队提出任务说明。 团队分析任务说明，从技术和产品的角度发现极端情况。 如果出现需要澄清或调查的问题，则将其作为单独的任务进行跟踪，并在冲刺中花费专用时间。
技术方案 (Technical solution)
As an outcome of Analysis is a Technical Solution which is created by one or few developers. All relevant teammates along with QA must review and agreed on it. Technical Solution contains purpose of solution, product's functional blocks which will be affected and description of planned code changes.
作为分析的结果，是由一个或几个开发人员创建的技术解决方案。 所有相关的队友以及质量检查人员必须对此进行审查并达成一致。 技术解决方案包含解决方案的目的，将受影响的产品功能块以及计划中的代码更改的说明。
Such Technical Solution allows to discover more lightweight and more proper solution based on experience of relevant development process participants. Having detailed Technical Solution it's easier to discover and avoid blocking issues, easier to conduct code-review.
这种技术解决方案可以根据相关开发过程参与者的经验来发现更轻巧，更合适的解决方案。 有了详细的技术解决方案，就更容易发现和避免阻塞问题，更易于进行代码审查。
这是技术解决方案中一些块的示例： (Here is an example of some blocks in Technical Solution:)
Task description任务描述
Are new entities or approaches introducing into the system?
系统中是否引入了新的实体或方法？
If yes, these are described along with explanation why it's impossible to solve task with current approaches.
如果是的话，将对这些内容进行说明，并说明为什么用当前方法无法解决任务。
Are interactions of servers within a cluster changing? Are new cluster roles introducing?
集群中服务器的交互是否正在改变？ 是否引入了新的群集角色？ Is Data Model changing?数据模型在改变吗？
For server it's about objects and models.
对于服务器，它与对象和模型有关。
If data model is complex it could be represented ans UML diagram or text description.
如果数据模型很复杂，则可以将其表示为UML图或文本描述。 Is client-server interaction changing?客户端-服务器交互是否正在改变？
Changes description. If it's an API then could we publish it? Don't forget about exceptions handling i.e. log correct reasons.
更改描述。 如果是API，那么我们可以发布它吗？ 不要忘记异常处理，即记录正确的原因。
测试场景 (Test scenario)
In parallel Developers or QA are creating test scenarios assuming corner cases and potential problem points. If it's created by Developer then QA must review it on completeness. If Test Scenario is created by QA then Developer need to review and confirm that it's clear how to implement each points. Team also assess Test Scenarios on correctness.
并行地，开发人员或质量保证人员正在创建测试方案，并假设极端情况和潜在问题点。 如果是开发人员创建的，则质量检查人员必须对其完整性进行审查。 如果测试方案是由质量检查人员创建的，则开发人员需要检查并确认是否清楚实现每个要点。 团队还评估测试方案的正确性。
For creating and keeping test scenarios we are using HipTest.
为了创建和保持测试方案，我们使用了HipTest。
开发与验证 (Development and verification)
Developer creates an application code based on Technical Solution and assuming corner cases and test scenarios. passing code review and verify feature against test scenarios. Merges branch to master.
开发人员根据技术解决方案并假设一些特殊情况和测试场景来创建应用程序代码。 通过测试场景的代码审查和验证功能。 将分支合并到主。
On this stage QA supports Developer. For example help with reproducing complex test cases, test environment configuration, conducting loading testing, consulting about delivering big features on production.
在此阶段，质量检查支持开发人员。 例如，帮助重现复杂的测试用例，测试环境配置，进行负载测试，咨询在生产中交付重要功能的咨询。
释放已完成的功能 (Release of done functionality)
This is a final stage. Here Team may need to provide pre- and post-release actions. For example toggle on new functionality for beta-users.
这是最后阶段。 在这里，团队可能需要提供发布前和发布后的操作。 例如，为Beta用户启用新功能。
文档和工具 (Documentation and tools)
New development process had required from Developers more deep involving it testing process. Therefore it was important that I as a QA supply them with all necessary tools and study them of Functional Testing Fundamentals. Together with other Teams' QAs we have compiled a list of necessary documentation, have created missing testing instructions and have updated existing including non obvious for Developers things.
开发人员需要新的开发流程来更深入地测试它。 因此，作为质量检查人员，我必须为他们提供所有必要的工具并研究功能测试基础知识。 我们与其他团队的QA一起整理了必要文档的清单，创建了缺少的测试说明，并更新了现有内容，包括对开发人员而言不明显的内容。
Then we have granted to Developers access to all testing tools and test environments and have started to execute testing together. On the beginning Developers didn't want to take responsibility for testing results because no one verified after them. It was unusual. Each Developer had only Test Scenario, functionality created by Developer and Merge button. But they got adapted fast.
然后，我们授予开发人员访问所有测试工具和测试环境的权限，并开始一起执行测试。 刚开始时，开发人员不想对测试结果负责，因为没有人在之后进行验证。 这很不寻常。 每个开发人员只有测试场景，该功能由“开发人员”和“合并”按钮创建。 但是他们很快适应了。
实验结果 (Results of the Experiment)
It's a half year since the beginning of the Experiment. There is a graph of bugs amount per week. Amount of all discovered bugs is represented by red color. Amount of fixed bugs is represented by green. Yellow line is a beginning of the Experiment.
自实验开始以来已经半年了。 每周有一个错误数量图表。 红色表示所有发现的错误的数量。 固定的错误数量以绿色表示。 黄线是实验的开始。
It's visible that red line stay on the same level except pike at the beginning of the Experiment. Amount of bugs didn't increased and therefore we have kept current level of quality.
可以看到，除了实验开始时的派克，红线保持在相同的水平上。 错误的数量没有增加，因此我们保持了当前的质量水平。
Along with that average time spent on task decreased on 2%: 12 hours and 40 minutes before Experiment vs. 12 hours 25 minutes after. It means that we managed to keep velocity.
与此相伴的是，平均花费在任务上的时间减少了2％：实验前12小时40分钟，而实验后25分钟12小时。 这意味着我们设法保持了速度。
As a result there is no more hard dependency from QA in a Team. If I'll get sick or will go to vacation the Team will continue development without losses in velocity and quality.
结果，团队中不再存在来自QA的严格依赖。 如果我生病或要去度假，团队将继续发展而不会降低速度和质量。
Are we considering Experiment successful despite velocity and quality stays the same? Yes we do because at the same time we have freed QA capacity for conscious work on product and QA Strategy. For example for exploratory testing, increasing functional test coverage and describing of principles and rules of test documentation creation in all teams.
尽管速度和质量保持不变，我们是否认为实验成功？ 是的，我们这样做是因为我们同时释放了质量保证能力，可以有意识地从事产品和质量保证策略方面的工作。 例如，对于探索性测试，增加功能测试的覆盖范围以及描述所有团队中测试文档创建的原则和规则。
We have seed experiment mindset in another teams also. For example in one Team QA now doesn't test what described in pull request by Developer because Developer may verify it himself. in another Team QA reviewing pull request and tests only complex and non obvious corner cases.
我们在其他团队中也有种子实验的心态。 例如，在一个小组中，质量检查人员现在不测试开发人员在提取请求中描述的内容，因为开发人员可以自己进行验证。 在另一个小组质量检查小组中，审核拉动请求并仅测试复杂且不明显的极端情况。
启动实验前应注意的事项 (What should bear in mind before launch an experiment)
It's a complex and long way. It couldn't be implemented immediately. It requires preparation and patience. It doesn't promise quick wins.
这是一个复杂而漫长的过程。 无法立即实施。 这需要准备和耐心。 它不能保证快速获胜。
Be ready for Team's resistant. It not a way just to state that from now on Developers will verify functionality. It's important to prepare them to this, craft approaches, describe the pros of experiment for Team and product.
为团队的抵抗做好准备。 这并不是说从现在开始开发人员将验证功能的一种方法。 为他们准备这种精巧的方法，描述团队和产品的实验优势非常重要。
Velocity loss at the beginning is unavoidable. Time for Knowledge transfer for Developers, for creating missing documentation and for changes in a processes it an investment.
开始时不可避免的会出现速度损失。 开发人员进行知识转移，创建缺少的文档以及对流程进行更改所花费的时间。
There is no silver bullet Similar processes are implementing for example in Atlassian however it doesn't mean that it's possible to implement it in your company as is.It's important to adapt experiment for culture and specific of the company.
没有灵丹妙药例如，在Atlassian中正在实施类似的流程，但这并不意味着有可能在您的公司中实施它。根据公司的文化和具体情况调整实验很重要。
京东质量团队转型实践