自动化部署与手动部署的区别_手动质量检查与自动化质量检查的分离

自动化部署与手动部署的区别

Over the years, the world has undergone many changes and thereby it has resulted in influencing the needs of people as well. Moreover, this has also pushed for evident changes in the software use and its development. Being an active member of Quality Assurance (QA) in Software engineering for the past 9 years I have been lucky enough to experience this transition that software industry has developed through its years of progression.

Ø版本这些年来，世界发生了许多变化，从而它已造成影响的人们的需求也是如此。 此外，这也促使软件使用及其开发发生明显变化。 在过去的9年中，作为软件工程质量保证(QA)的积极成员，我很幸运地经历了软件行业在其多年发展过程中所经历的这种过渡。

One of the essential parts of a tech team is the QA team that is the last barrier between the development team and your clients. As the manager of my development team used to say “Hodor” (ref: Game of Thrones) because it protects customers from bugs and defects. QA traditionally started as the testers used to sit for long working hours to enter the data manually and later it used to be tested one by one in order to complete the boundary analysis. But in the past few years, it has taken a 180-degree shift in its evolvement.

质量团队是技术团队的重要组成部分，是开发团队和客户之间的最后障碍。 正如我的开发团队的经理所说的“ Hodor” (参考：权力的游戏)一样，因为它可以保护客户免受错误和缺陷的影响。 传统上，质量检查开始于测试人员需要长时间工作才能手动输入数据，后来又逐个进行测试以完成边界分析的过程。 但是在过去的几年中，它的发展已经发生了180度的转变。

Photo by Tim Bennett on Unsplash

Tim Bennett在 Unsplash上 拍摄的照片

Now considering the change, test automation is fixing bugs automatically in the code with programs like Sapienz. What has pushed for such advancement? Answer to this question is the same as the answer to this one i.e. what has pushed humans to build airplanes or mobile phones that is It’s luxury, time-saving and ease of use.

现在考虑更改，测试自动化正在使用Sapienz之类的程序自动修复代码中的错误。 是什么推动了这种进步？ 这个问题的答案与这个问题的答案相同，即促使人们建造飞机或移动电话的原因是它的豪华，省时和易用性。

The key point for the evolution of QA was the fast delivery of the product at the minimal cost ever and better customer experience. Starting from simple web sign-up form-based applications for submitting some data into databases to the recent websites like Amazon or Ali Baba which have millions of users accessing them simultaneously with stock management to 3PL delivery systems. As the application’s architecture has become complex, the testing of those software have also become more complicated. The complexity of application further adds up when they become multilingual, multi-location and multi-category. Complexity of test scenarios increase two-folds when we encounter types of devices available to users with different operating systems and resolutions. Also, there are 1000s of test-case scenarios that needs to be covered in less time than before. This is because there is an endless competition and time to market of the product.

质量检查演变的关键点是以最低的成本快速交付产品，并提供更好的客户体验。 从简单的基于Web表单注册的应用程序开始，将一些数据提交到最近的网站(如Amazon或Ali Baba)中的数据库中，这些网站有数百万用户同时通过3PL交付系统的库存管理来访问它们。 随着应用程序体系结构变得复杂，这些软件的测试也变得更加复杂。 当它们变成多语言，多位置和多类别时，应用程序的复杂性进一步增加。 当我们遇到具有不同操作系统和分辨率的用户可以使用的设备类型时，测试场景的复杂性增加了两倍。 此外，与以前相比，有数千种测试用例场景需要用更少的时间来解决。 这是因为产品存在无尽的竞争和上市时间。

After the evolution of QA, one of the biggest mistakes which people continue to make is that they don’t recognize the difference between the one performing the manual QA i.e. writing test-cases, test-plans, testing first iteration of the developed Alpha or Beta builds and the automation engineers. According to my personal experience, as being a prominent part of this vast field, that you will never get time to work on Automation. Why is it so?

随着质量检查的发展，人们继续犯下的最大错误之一是，他们不认识到执行手动质量检查的人之间的区别，即编写测试用例，测试计划，测试开发的Alpha的第一次迭代或Beta版本和自动化工程师。 根据我的个人经验，作为这个广阔领域的重要组成部分，您将永远没有时间从事自动化工作。 为什么会这样呢？

• As automation initially is time consuming to develop, it will always be put on the back burner. So, business will always ask to meet the deadlines, which usually are very short.
  由于自动化最初的开发很耗时，因此它将始终放在后炉上。 因此，企业总是会要求在最后期限之前完成任务。
• The ratio between the developers and the testers or QA Engineers is always very low. Hence there will always be something on the table for testing and QA Engineers or testers will always be coping up with them.
  开发人员与测试人员或质量检查工程师之间的比例始终很低。 因此，测试中总是会出现一些东西，质量检查工程师或测试人员将始终与他们配合。
• Development of new features remain constant in agile teams since they come thick and fast. For the ease of use, the team lead will always ask to test it and release it to finish the software cycle. To sum it up, we can use this famous line as a reference i.e. “We will do it later” is coined often. Thus, it will end-up as huge tech debt which won’t get time in the development cycle going forward.
  由于敏捷功能强大且快速，因此新功能的开发一直保持不变。 为了易于使用，团队负责人将始终要求对其进行测试并发布以完成软件周期。 总结起来，我们可以使用这条著名的线作为参考，即“我们以后会做”经常被创造出来。 因此，它将最终成为巨大的技术债务，无法在未来的开发周期中花时间。

• As we have been used to hearing the term “Full-stack” used for developers; nowadays it is also being used for QAs as “Full-stack QA”. But what does it really imply? The answer is ambiguous since nobody has a clear definition for Developers or QAs. Although we hire Full-Stack developers in a company but they mostly work on one or two maximum stacks at a time. This happens because we recognize it is a specialized job and therefore it requires developers to focus on one stack to get optimum level of productivity.

  正如我们习惯于听到用于开发人员的“全栈”一词一样； 如今，它也被用作QA的“全栈QA”。 但是，这实际上意味着什么？ 答案是模棱两可的，因为没有人对开发人员或质量保证有明确的定义。 尽管我们在一家公司雇用全栈开发人员，但他们大多数时候一次只能处理一两个最大堆栈。 发生这种情况是因为我们认识到这是一项专门工作，因此需要开发人员将精力集中在一个堆栈上才能获得最佳的生产力。

  For QA, doing manual QA or writing test-plan etc. the same trend is followed since it is done with one mindset and writing test automation or managing test automation requires different a mindset. In simple words, you can’t expect a person to quickly switch on and off between these two and increase productivity.

  对于QA，执行手动QA或编写测试计划等，遵循相同的趋势，因为它是用一种思维方式完成的，而编写测试自动化或管理测试自动化则需要不同的思维方式。 简而言之，您不能指望一个人能够在这两者之间快速打开和关闭并提高生产率。

One of the reasons people don’t go for the separation of Manual QA and Automation QA is the increase of the headcount in the team and going away from lean team concept. In my preview, separating it actually decreases headcount and increases productivity of the team as a whole.

人们不赞成将手动QA和自动化QA分开的原因之一是团队中的员工人数增加，并且脱离了精益团队的概念。 在我的预览中，将其分开实际上减少了人员，并提高了整个团队的工作效率。

You may consider its possibility in the situation mentioned below;

您可以在以下情况下考虑其可能性；

I will make it vivid with this one example; when you add a QA in a team, your objective is to find bugs, issues with design, content or usability which customers or users will encounter if we release it without testing. The misconception people continue to hold that the amount of work for QA will remain same even if you deliver the same number of features with the similar complexity in each development cycle.

通过这个例子，我将使其生动。 当您在团队中添加质量检查时，您的目标是查找错误或与设计，内容或可用性有关的问题，如果我们未经测试就发布它，客户或用户将遇到这些错误，问题。 误解的人们继续认为，即使您在每个开发周期中提供相同数量的功能且具有相似的复杂性，QA的工作量也将保持不变。

Why does this happen? While testing, QA or tester needs to verify every new feature to see if anything developed before haven’t been broken. Adding all the complex scenarios and devices explained above you can imagine, the amount of regression it demands for running which continues to increase with time. So, will you keep adding QA, slow-down release or compromise on the quality? These are only 3 solutions if you stay on this path.

为什么会这样？ 在测试期间，质量检查人员或测试人员需要验证每个新功能，以查看以前开发的内容是否已被破解。 您可以想象添加上述所有复杂的场景和设备后，运行所需的回归量会随着时间的推移而不断增加。 那么，您会继续添加质量检查，放慢发布速度或在质量上有所妥协吗？ 如果您走这条路，这些只是3个解决方案。

Adding a test automation engineer initially might increase your initial headcount but will decrease your headcount down the line while pursuing its the primary objective; high quality product delivered to customers. Moreover, the faster the release, more productivity will be gained on the whole.

最初增加一名测试自动化工程师可能会增加您的初始员工人数，但在追求主要目标的同时会减少您的员工人数。 高品质的产品交付给客户。 此外，发布速度越快，总体上将获得更高的生产率。

I won’t challenge this without my personal experience, my ex-team experienced the same problems. We were always pondering over how much QAs are enough to test a system and develop automation with it. After going about it for a year and examining it in every retrospective, I came to a conclusion that we need to separate the QA team into two. To decide the ratio between them it relied on the need of the particular project or product of the company.

没有我的亲身经历，我不会挑战这一点，我的前团队也遇到过同样的问题。 我们一直在思考有多少QA足以测试系统并开发自动化系统。 经过一年的研究并在每次回顾中进行了审查，我得出的结论是，我们需要将质量检查小组分成两部分。 要确定它们之间的比例，它取决于公司特定项目或产品的需求。

We came up with the process of every new feature and its enhancement was tested by the Manual QA’s with a proper test-plan. Once it was released to production a test automation engineer wrote a feature test automation and added bug fixes released into the regression test suite, while manual QA’s were testing other new features. In this perspective test automation engineers were one development cycle or sprint behind the rest of the team. What resulted in its benefits?

我们提出了每项新功能的流程，并且其增强功能已通过手动质量检查人员按照适当的测试计划进行了测试。 一旦将其发布到生产环境中，测试自动化工程师便编写了功能测试自动化程序，并在回归测试套件中添加了已发布的错误修复程序，而手动质量检查人员正在测试其他新功能。 从这个角度来看，测试自动化工程师是团队其余成员的一个开发周期或冲刺。 是什么带来了好处？

• Faster release: We were releasing twice a month and once we had this process we were releasing twice or thrice a day to production.

  更快的发布：我们每月发布两次，一旦执行了此过程，我们一天就会发布两次或三次。

• High Confidence: Confidence in the release was higher to have lesser or no bugs. Even consuming more time before we ended-up having issues on production.

  高置信度：对发行版的置信度较高，具有较少的漏洞或没有漏洞。 甚至要花更多的时间才能最终解决生产问题。

• Less or No critical issues: Since we adopted this approach we had zero critical functional bugs or issues on production other than some common server issues.

  较少或没有严重问题：自从采用这种方法以来，除了一些常见的服务器问题之外，我们在生产中的关键功能错误或问题为零。

• Happier Team: The developers were quite elated because for every small issues they didn’t need to wait for manual QAs or testers to release.

  更快乐的团队：开发人员非常高兴，因为对于每个小问题，他们都不需要等待手动的质量检查或测试人员发布。

This is the solution which might not be 100 percent applicable in your team or company. But it is high time the software community should understand that needs have adapted so we can skillfully differentiate between different types of QA Engineers.

这可能不是100％适用于您的团队或公司的解决方案。 但是现在是软件社区应该了解需求已经适应的时候了，这样我们才能熟练地区分不同类型的QA工程师。

Discussion about what is exactly in the job description for different types of QA, that’s a different topic which I will cover in the next article. Stay tuned!

关于不同类型的质量检查的职位描述中确切包含什么的讨论，这是另一个主题，我将在下一篇文章中介绍。 敬请关注！

翻译自: https://medium.com/swlh/separation-of-manual-qa-from-automation-qa-7e98cfe9661

自动化部署与手动部署的区别