当一个项目处于早期阶段时，QA工程师能做什么？

Question

美好的一天，漂亮聪明的人！

我们已经对一个应用程序进行了原型化，它或多或少处于MVP阶段，客户看到了所需的最低功能，正在认真对待并需要进一步开发。

在这个时候，我们有一个在测试自动化方面有经验的兼职测试人员，他渴望将他的技能应用到实践中，并尝试一个他一直想尝试的测试自动化框架。

同时，这是投资于测试自动化的早期时间，因为应用程序在后端和前端的变化都非常频繁。

目前，我们要求QA工程师检查客户的业务需求，并根据它们验证现有的功能，并熟悉路线图。

我们还能让他做什么？在项目处于早期阶段时，QA工程师的时间有什么最佳利用？

Answer 1

如果产品处于MVP阶段，而QA才刚刚开始，就会有一个问题。作为一个BA，我一次又一次地在dev和QA中看到，开发团队只有在他们觉得产品“准备好交付给QA”时才让BA进行测试，这是所有开发人员都应该致力于消除的想法。

大多数开发人员上了大学，上了一些编程课程。当他们提交作业时，他们的评分取决于他们是否符合某些标准，其中大部分是他们是否通过了教授考试。这是一个非常有害的实践，因为它教导开发人员害怕公开失败测试。

相反，QA应该在这些特性“准备好”之前就进行测试。如果你有10个工作日的短跑周期，你在第1天工作的东西应该在第2天发送给QA。不要在第6天把它连同你所有的其他东西发送给QA，让他们对6个不同的特性提供反馈，让你花7和8天来修复它，在第9天进行最后的测试，在第10天发布一个版本。

因此，如果您正处于MVP阶段，您的QA人员应该已经非常熟悉该产品，因为他们应该每天对其进行测试，因为您可以登录该应用程序。如果你没有，现在是时候让他们开始全职工作了。如果这个人有可以自动化的测试，那么就这么做。不要害怕测试一些东西，因为它以后可能会改变。事实上，这是件好事。很多时候，如果测试结构良好，即使在更改之后，它仍然会通过。如果没有，那就没事了。您不太可能因为一些更改而放弃整个测试。如果你这样做了，那么你需要对你的应用程序的各个部分进行测试，因为这是最有可能出现bug的地方。

长话短说，这个工程师应该有一个健康的混合手动和自动化测试的全职(特别是如果你有3个或更多的开发人员全职工作的产品)。他们应该把注意力集中在现在正在改变的事情上，因为这很可能会有错误。他们应该在它完成之前对它进行测试，这样就可以提前发送反馈信息。

Answer 2

您是否知道“软件中70%到85%的错误是由于不完整或不准确的功能需求造成的？”

？

-John von说：“当你甚至不知道你在说什么的时候，精确是没有意义的。”在项目还处于早期阶段的时候，什么才是最好的利用QA工程师的时间呢？测试需求本身，而不是产品.

通过提出正确的问题来发现和挑战requirements.It中的隐含假设，将确保需求

是完整和一致的，根据客户的needs.This，这可能是目前阶段最大的回报。我还认为，QA工程师与测试工程师的确切区别在于，QA工程师首先要防止bug，而测试工程师只是在事后才发现bug。

我一次又一次地看到，在项目中，甚至在后期阶段，基本假设要么不完全正确，要么至少没有被理解/作为一个团队受到挑战。

许多迟加入项目的人，要么不费事，要么有信心/勇气系统地分析和挑战需求中的基本假设。

为了使测试需求更加有效，您可以使用称为启发式测试的方法，或者使用依赖于过去有关概率的数据的策略进行测试。这种有针对性的测试类型通常允许对任何错误或问题发生的地方进行更智能的调查，甚至在需求测试中也是如此。

此策略有助于确定哪些类型的错误可能发生，以及在代码的某些部分中发生的错误有多常见。它还有助于根据累积的问题基础检查需求。一定要覆盖应用程序中的所有这些区域：

结构(产品是什么)：是一个程序还是多个程序？它的物理部分是什么？我可以一个模块一个模块测试它吗？

功能(产品的功能)：它的功能是什么？它会做什么样的错误处理？它有什么样的用户界面？它会做任何用户看不到的事情吗？它如何与操作系统接口？

数据(它处理什么)：它处理什么类型的输入？它的输出是什么样子的？它能处于什么样的模式或状态呢？它是否附带预先设定的数据？它的任何输入是否对时间或顺序敏感？

平台(它所依赖的)：它在什么操作系统上运行？环境必须以任何特殊的方式配置吗？它依赖于第三方组件吗？

操作(如何使用)：谁将使用它？他们将在哪里和如何使用它？他们会用它做什么？用户是否更有可能做某些事情？是否有用户数据可以使测试更加真实？

您可以发明自己的启发式方法，并将它们应用于整个应用程序以及需求分析。

好的要求应该是明确和精确的，没有不确定性或模棱两可；在具体的价值上应该是可衡量的；应该是可测试的和完整的；并且不应该包含任何矛盾。

进一步阅读：https://www.softwaretestinghelp.com/how-to-test-software-requirements-specification-srs/

Answer 3

虽然所有的观察都是有效的，但从项目的角度来看，我忽略了动机和学习的观点。现在开始一些自动化也可以成为工程师和团队学习的一部分。他会被激励，因为他可以做他想做的事情。是的，产品会变的。但他也能随着产品的发展而成长。在“未来”开始自动化可能为时已晚，赶不上那个阶段。或者说非常困难，因为没有人考虑到测试的需求(“在那里，做了什么”)。复杂性在增长，自动化的挑战也将如此。所以从我的角度来看:早点开始。与产品开发并驾齐驱。学习和适应。重构是给定的。所有类型的编码器。

话虽如此:质量援助成员已经可以帮助检查单元测试。帮助使用帮助团队的工具。建造模拟模型。除了已经提到的。

回到person视图:编码测试器与其他类型的编码器没有太大的不同:如果你将它们埋在文件中，它们就会运行。只有我的2 2cnt。