我们已经为您准备了质量管理工程师Dmitry Yarygin的文章翻译，他在OTUS的移动质量保证工程师课程的老师拥有8年以上的重大项目经验，该项目在全球主要项目中都有经验。 朝这个方向发展是否有趣？ 我们邀请您参加为期两天的免费密集课程“在Selenium和Appium上测试移动应用程序的自动化简介”。

质量检验。 谁对此负责？ 多年来，这个问题的唯一答案就在我脑海中。 当然是质量检查工程师！ 毕竟，我本人属于质量检查工程师。

我肯定知道测试计划向市场发布的软件产品的质量有多重要。 但是，我注意到测试过程中发生了一些模式。 他们让我考虑了整个测试过程以及如何改进它。

开发人员应该测试他们的代码吗？

感谢您的询问。 如果您是一名开发人员，那么您将知道代码中的所有细微之处和陷阱，或者至少比QA工程师更了解代码。 您已经广泛地了解您的代码，并且了解可能出现问题的地方。

如果您知道问题所在的位置，请告诉质量检查工程师。 是的，他本人会在某个特定时刻找到它，但是您仍然更好地了解应用程序体系结构。 如果您告诉测试人员在哪里遇到麻烦，测试人员将不胜感激。

我们是质量检查工程师，我们将专注于此并进行测试，以使您不必担心。 开发人员可能提供的任何其他信息显然是有益的。

单元测试绝对是开发人员应该做的事情，这是他们的职责范围。 单元测试将有助于避免不必要的错误和不必要的报告。 最好在代码到达测试人员团队之前避免错误，对吗？

关于测试您自己的代码的几句话。 我认为开发人员至少应该对其代码进行烟雾测试。 无需大量测试。 只需检查代码是否适用于某些输入数据集，然后将其交给测试人员团队，以便他们已经对它进行进一步的处理。

如果该代码在此阶段尚不可用，那么为什么要将其完全交给质量检查人员？ 尽管您已经知道存在问题，但是您仍然会收到许多错误消息-这只会减慢开发过程。

我们错过了错误。 测试人员要怪吗？

是的，没有。 每次检测到错误时，尤其是在生产中，您和您的团队都会进行讨论。 错误仅在此阶段出现的原因有几个：

1. 错误出现的地方从来都不是测试人员的优先事项。 很多时候，没人想到生产中出现的错误。 这是开发人员与测试人员之间缺乏沟通的结果。 在检查区域有多重要的问题上尚未达成共识。 这种疏忽的典型例子是性能和安全性问题。 如果您知道这些区域对您的应用至关重要，请告知团队。
2. 质量检查人员在测试区域没有必要的知识。 这也是一个普遍的问题。 开发人员编写了该函数，并自动假设QA理解了它的工作原理。 好吧，做出假设从来都不是分析严肃项目质量的好策略。 如果您看到某些重要方面，请确保质量检查主要工程师及其团队也能看到并理解他。 此步骤无法解决。
3. 开发人员并不在乎。 我们都是人类。 而且我们所有人都有工作以外的生活。 一些开发人员努力工作以创建高质量的产品，他们与测试人员交谈，告知他们可能存在的问题等。 还有一些开发人员不在乎。 他们不会每天使用此产品，也不了解其重要性。 对于他们来说，这只是一个需要完成并被遗忘的辅助任务。 简而言之，他们不在乎最终产品的质量是否会过低。
4. 质量检查工程师不在乎。 这是硬币的反面。 并非所有测试人员都关心该项目。 有些人只需要完成测试，做出漂亮的报告就可以了。 高质量的测试覆盖范围不会打扰他们，他们也不想与开发人员进行交流。 您可以讨论错误，但此类测试人员可能根本不认为它们很重要，甚至无法注册。
5. 测试人员资格不足。 另一个问题可能在于测试人员根本没有足够的资格来测试您的应用程序。 例如，您需要进行渗透测试，而您所拥有的只是一组只能进行手动测试的测试人员。 在这种情况下，他们根本不知道该如何接近他。 在这里，您需要依靠开发人员，或者选择更多
   合格的质量检查工程师，他们将确切地知道如何测试该特定区域。
6. 缺乏用户研究。 开发人员知道如何创建应用程序，而质量检查工程师则知道如何对其进行破坏。 用户呢？ 用户是真实的人，他们将在现实世界中使用您的应用程序。 他们不会破坏它。 只是它们都是不同的并且有不同的目标，但是他们都希望使用您的应用程序来实现它们。 质量检查工程师可以习惯于该错误并认识到该错误很少发生，因此，它并不重要。 用户不会容忍这一点。 如果您的应用程序崩溃，则下一步是将其删除，然后搜索替代方法。 那是现实。 研究用户受众和/或测试用户组是两项具有战略意义的重要工作。
7. 沟通过程的组织性差。 理想情况下，您需要一个简单的流程来对错误进行分类，从而使您能够评估质量检查中的错误（或至少对错误进行正确排名）并将其传递给开发人员，以使他们了解他们的工作量。 如有任何误解，测试人员和开发人员应始终能够在几分钟或几小时内相互接近并解决此问题。 如果这个过程没有建立，并且双方都不急于寻找造成误解的原因，那么就不会有任何好处。 双方都将模仿活动，但实际上，他们都将陷入僵局，等待三分之一的人来神奇地解决局势。 从根本上讲，这是错误的方法。
8. 测试人员不足。 应用程序可能很复杂，可能需要在多个平台和浏览器上进行测试。 仅几个QA工程师完成此任务可能还不够。 考虑雇用更多的人或重新分配您拥有的资源，以增加对测试的重视。
9. 开发人员超负荷。 您周围可能是理想且高素质的专家，但他们的工作压力不断，没有人可以帮助他们。 是的，他们承受着压力，而且他们没有时间与质量检查小组进行交流。 这是一个非常普遍的问题，这是软件质量较差的主要原因之一。
10. 质量不是人们关注的焦点。 也考虑这种情况。 在这里和那里有一些小错误。 它们都不是关键。 但是，用户不喜欢该应用程序。 评论不好。 用户体验低于平均水平。 又为什么呢？ 是的，因为没有人考虑过要生产优质的产品。 开发人员完成了工作，测试人员完成了自己的工作，但是没有人遵循质量控制流程本身。 应用程序开发应合并团队，使他们成为一个整体。 如果集体没有这样的心情，那么没人在乎质量。

结论

如今，应用程序越来越难。 如果您想找到应该为项目失败负责的人，这很容易。 可能是质量检查工程师，开发人员和主管人员的责任。 或全部在一起。 主要问题是，为什么我们要找那些人负责而不是对项目质量负责？ 没有意识到测试特定功能的重要性的任何人都可以代替有罪。

唯一的问题应该是： “我们生产的产品真的很好吗？” 。 如果对这个问题的回答是肯定的，那么毫无疑问，所有团队都在做一件大事。

没有人要责备，每个人都会感到高兴，因为质量保证是一项共同的任务！