非技术QA团队SQA框架的工业标准

Question

我正在寻找一个软件/平台，我可以让我的团队在软件开发中使用QA。

因此，基本上现在我们有一个开发团队致力于我们的平台的新功能和维护(一个web应用程序，但很快也将是一个手机应用程序)。我们希望建立我们的QA流程，在这个过程中，阶段将是:开发- QA - UAT - Live。然后我们有一个QA团队，他们将是来自非技术背景的人员，他们将在QA阶段，在新的/更新的产品进入UAT阶段之前从事QA工作。因为他们不是真正的技术人员，我需要用户界面尽可能的友好和容易使用。

我们需要的特性是“测试什么”、“测试结果”、“人工制品”(基本上是屏幕截图等)的一列。我们可能面临的另一个问题是，对于每一个更新冲刺，更新将是不同的，例如。这个sprint --我们可能正在更新一个输入自由文本字段，下一个sprint --我们可能正在做一个"who's online“功能。)因此，我不太清楚如何处理这个问题。我还需要执行负载测试，并希望负载测试和所有其他可以自动化的过程将自动化。

如果可能的话，我想补充一下，我希望它是免费的。

是否有任何不需要脚本的自动化测试？(实际上，我一半的预期都不会有。)但不要解雇我的职位！我的文章更多地介绍了用于手动测试的SQA框架)

什么测试在其他测试之前进行？(例如在负载测试之前是回归测试吗？)开发团队使用什么来进行负载测试/回归测试/心智测试(最有可能是手工测试，对吗？)

任何有经验的人都可以建议我如何设置这个QA SOP，以及我可以使用哪些软件来进行自动化/错误报告等？

Answer 1

手册

如果您主要关注的是手动测试，那么我将更多地关注使用一个好的测试跟踪工具，如Jira、Trello、VSTS(MS)或Pivotal Tracker。其中大多数都有不同种类的免费试验。我喜欢吉拉。我会把重点放在这一点上，再加上一个开发良好的敏捷过程和人员来管理流程，并避免在没有管理的情况下总是发生的事情，比如“来自地狱的积压”等等。

为了解决‘变更A本周’和‘变更B周’，你需要开发过程来管理它，比如敏捷开发，并将它们绑定到你使用的工具中，这个工具通常会涉及一个GUI，其中有一个带有功能/更改/bug修复的板，可以处理‘sprint’。

顺便说一句--免提产品--当你打算把它们作为你生意的一部分时，应该避免。他们要么打破，而不是突然被修复，要么他们会因为他们与改变界面的东西而崩溃，或者他们会突然转变成付费产品，被停止等等--因为选择一个免费的产品而可能出错的事情列表很长。没有什么持久的价值是真正自由的，对吗？

据我所知，在这个领域没有真正的“工业”标准用于手工测试。当然有测试认证之类的，但他们在社会上很少尊重，因为这反映了增值的能力。其中的软件工程和质量还处于初级阶段。

自动化

非技术人员通常无法维护一个复杂的自动化套件*。

*运行速度快、易于维护和可扩展并增加最大值的套件

对于自动化来说，非技术人员通常不能使用GUI构建复杂的应用程序产品这一事实也是如此。

这两个领域中GUI工具的示例是Visual和Selenium。这两个UI工具示例显示了我们当前一代UI工具的局限性。

我经常把这个问题称为‘千千个测试问题’，这是一个简单的问题，我经常向我面前的供应商提出这个问题。我最近看到了另一个供应商UI自动化‘这将是令您的公司的产品演示令人惊叹。在半个小时的演示之后，我问了一个问题:这看起来是做1次测试的一个很好的产品。当有一千次测试时，该产品将如何解决可维护性、可扩展性和性能问题。供应商说他们的产品没有解决这个问题。演示完毕。谢谢。

问题不在于供应商或工具(在某些情况下，我实际上是UI工具的粉丝)，问题更深。随着时间的推移和产品的不断增长和维护，测试套件的规模越来越大，运行起来需要更长的时间。此外，由于使用不受您控制的异步程序的性质，您通常会遇到间歇性错误，特别是在基于浏览器的测试中。此外，更新和更改测试的努力也越来越大，而且往往涉及到一个或几个关键人员的大量部落知识。由于所有这些问题，测试的价值开始执行。最终它实际上变成了负值。由于您的测试套件运行速度太慢，它们会减慢产品开发速度，而您的竞争对手也会吃您的午餐。

解决方案是使用干燥的测试自动化，使用SRP和其他编程原则来维护它。

您将遇到的另一个问题是，大多数非技术人员将使用UI来测试每个数据组合和业务用例。这些测试可能从几秒钟到几分钟不等。然而，技术编程人员将(应该)将测试分解为后端用户测试、集成测试、UI测试和可用性/性能测试。后端测试每个运行不到1秒，所以当您达到1000次测试时，UI测试可能需要几个小时或几天，后端“单元”测试可能需要几分钟。

一种选择是http://www8.hp.com/us/en/software-solutions/quality-center-quality-management/index.html，因为它似乎涵盖了您想要的特性。正如侯所见，它是复杂的，不是自由的。

顺便说一句，我还认为以下发言表明需要更多的技术专门知识来处理这些问题：

• 来自非技术背景的人员将在QA阶段，在新的/更新的产品进入UAT阶段之前从事QA工作。不明智。
• “所以我不太清楚该如何处理”。好吧，你需要技术专长

另请参阅

• http://www.softwaretestingstandard.org/。
• https://www.softwaretestinghelp.com/what-is-actual-testing-process-in-practical-or-company-environment/

Answer 2

No

迈克尔已经尽最大可能回答了你的问题，但我会强烈建议你不要做你提议的事。您将无法进行自动化测试，因为没有人能够设置，更不用说维护自动化了。所以，你将无法以任何有意义的方式进行回归测试，除非你计划雇佣新的手动测试员，因为已经存在的那些人将忙于做所有的非回归测试。你也不能做负载/压力测试，除非，再次，你计划雇佣成千上万的人来创造负载。

在缺陷管理方面，您也会遇到严重的问题，因为非技术测试人员将打开大量的缺陷，其中大部分将不是缺陷，并且在解释他们如何产生缺陷方面做得很差。

所以，你可以选择:你可以雇佣几个技术熟练的人，他们可以做一些事情，比如构建测试套件，维护测试套件，构建自动化测试环境，必要时加强测试，等等，或者你可以管理一个不断增长的非技术人员团队，他们将无法完成与这对技术人员一样好的工作。

测试是一门熟练的学科。你会去问如何在没有开发人员的情况下创建一个应用程序吗？或者如何在没有任何工艺工程师的情况下制造一辆汽车？理论上说，如果你在这些问题上投入了足够多的非技术人员，他们最终可能会想出一些办法，但如果你雇佣有正确技能的人，那就不会那么痛苦，也更有可能成功。让您的开发人员成为测试人员要比尝试依靠非熟练的劳动力来进行测试要好得多。

Answer 3

正如其他人已经评论过的，您的方法可能会失败。手动测试不适合回归测试。手动测试有利于测试新特性是否有效，但旧特性仍然有效。除非您的手动测试人员在每个版本上运行为您的应用程序创建的所有特性，否则您将错过bug并进行许多热修复。

您确实需要手动测试和自动化测试的结合，以便为您的应用程序提供信心。

如果你想做你想做的事情，你可以把你的手工测试外包给像掌声这样的服务，雇佣1到2个自动测试人员，而不是一个手动测试团队。

或者，您可以让开发人员编写更多的单元和集成测试，而不是拥有QA部门。几家大型科技公司也像Facebook一样这样做。