当项目处于早期阶段时，质量检查工程师可以做什么？

#1 楼

如果产品处于MVP阶段，而您的质量检查才刚刚开始，则存在问题。作为一名BA，我一次又一次地在dev vs QA上看到，开发团队只有在他们认为产品“准备交付给QA”时才让BA进行测试，这是所有开发人员都应消除的观念。 br />
大多数开发人员上了大学，并上了一些编程课。当他们提交作业时，将对他们满足某些标准的程度进行评分，其中大部分是他们是否通过教授考试。这是一种令人难以置信的破坏性做法，因为它教会开发人员不要公开测试失败。

相反，质量保证应该在这些功能“就绪”之前就进行测试。如果您有10个工作日的冲刺周期，那么您应该将在第1天处理的事情在第2天发送给质量检查。不要在第6天将其与其他所有内容一起发送给质量检查，让他们对6种不同的东西给出反馈功能，并在第7天和第8天花费所有时间进行修复，以便在第9天进行最终测试并在第10天发布。

因此，如果您处于MVP阶段，则质量检查人员应该已经非常熟悉该产品，因为自您可以登录该应用以来，他们应该每天都在对其进行测试。如果您还没有，现在是时候让他们全职学习。如果此人具有可以自动化的测试，请这样做。不要害怕测试某些东西，因为它以后可能会改变。实际上，那是一件好事。很多时候，如果测试的结构合理，即使更改后它仍会通过。如果没有，那就很好。由于某些更改，您不太可能废弃整个测试。而且，如果这样做，那么您就需要对应用程序的各个部分进行测试，以最大程度地进行更改，因为这是错误发生可能性最高的地方。

长话短说，这位工程师应该在全时基础上进行手动和自动测试的良好组合（尤其是如果您有3个或更多开发人员全职从事该产品。）他们应该专注于当前正在变化的事情，因为其中最有可能存在错误。他们应该在测试完成之前对其进行测试，以便可以及早发送反馈。

#2 楼

您是否知道“软件中的大多数错误是由于不完整或不正确的功能要求引起的？”


QA工程师在项目处于早期阶段时最好的时间是什么？阶段吗？

通过询问正确的问题来发现和挑战需求中的隐含假设，测试需求本身而不是产品...

，它将确保需求
完整
且始终如一并符合客户需求。这可能是现阶段最大的回报。

我也认为这正是a我是测试工程师的质量检查工程师。


我一次又一次地看到，在项目中，即使在后期阶段，基本假设也不是完全正确的，或者至少是不被理解/挑战的。团队。

许多迟到该项目的人，要么不打扰，要么有信心/勇气来分析和挑战工作中的基本假设系统地满足需求。

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

这种策略有助于确定可能的错误类型以及在某些情况下常见错误的发生方式部分代码。它还有助于根据累积的问题检查需求。确保在应用程序中涵盖所有这些方面：

结构（产品是什么）：是一个程序还是多个程序？它附带哪些物理部分？我可以逐个模块对其进行测试吗？

功能（产品的作用）：其功能是什么？它执行哪种错误处理？它具有什么样的用户界面？它会执行用户不可见的任何操作吗？它如何与操作系统接口？

数据（处理的内容）：处理什么类型的输入？它的输出是什么样的？它可以处于哪种模式或状态？它与预设数据打包在一起吗？它的任何输入对时序或排序敏感吗？

平台（取决于什么）：它在什么操作系统上运行？是否必须以任何特殊方式配置环境？它是否依赖于第三方组件？

操作（如何使用）：谁会使用它？他们在哪里以及如何使用它？他们将用它做什么？用户是否更有可能做某些事情？是否有用户数据可以使测试更切合实际？

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

良好的需求应清晰准确，不得有任何歧义；就具体价值而言应是可衡量的；应该是可测试的和完整的；并且不应包含任何矛盾。

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

#3 楼

尽管所有观察结果都是有效的，但是从项目的角度来看，我缺少动机和学习的观点。
现在，开始一些自动化也可以成为该工程师和团队学习的一部分。他会因为自己可以做自己想做的事情而受到激励。是的，产品将会改变。但是他也可以随着产品的发展而成长。在“未来”中启动自动化甚至可能为时已晚，无法赶上这一阶段。还是非常困难，因为没有人考虑测试的需求（“在那里，完成了”）。复杂性也随之增长，自动化挑战也将日益增长。所以从我的角度来看：尽早开始。一起开发产品。学习和适应。重构是给定的。适用于所有类型的编码器。

话虽如此：质量协助成员已经可以帮助审核单元测试。提供协助团队的工具的帮助。建立模拟。除了已经提到的内容。

并返回到个人视图：编码测试器与其他类型的编码器没有太大不同：如果将它们埋在文书工作中，它们就会运行...只是我的2cnt。

#4 楼

我同意对于许多自动化而言可能为时过早。但是质量保证仍然可以为项目带来很多帮助，以帮助它在现阶段取得成功。

如果是我在项目中，并且学习到有关需求的一切知识，我会查看客户的实际行为以及他们的工作流程是什么，竞争对手可能提供什么以及我们先前开发的任何可能在该项目中使用的（好或坏）的产品。

我会设法被邀请参加任何与设计和开发有关的会议，这样我不仅可以了解产品要求，还可以了解编码人员如何开发和编写产品。请注意哪里有激烈的讨论，混乱或令人关注的领域-这些是您稍后可能需要特别注意的领域。

好奇并问问题。询问您可能要运行的测试，字段标签或客户期望响应时间是什么-询问所有问题。这证实了每个人都以相同的方式看待事物（比现在更容易抓住它）。令我惊讶的是，“无害”确认问题演变为长达20分钟的完整对话，可以解决纸上的主要问题，而不是何时进行测试。

我在一家敏捷商店工作-因此，我将开始起草一些史诗，如果可能的话，还会写一些第一个故事。他们可能稍后需要冲洗掉，但要开始考虑。然后开始查看您的要求-您是否有测试计划所需的特定格式，需要在测试中填写的法规文件等。如果您不知道现在是什么，那么现在是收集这些内容的好时机信息。

如果您发现新内容，现在可能是时候进行一些速成课程了。 （我曾经根据我当时从事的项目进行过医学编码入门课程...不需要，但是当我们深入研究时非常有用。）尽管质量保证工作进展缓慢，但还是值得一试。 >
成为质量检查人员只是项目的一半时间，这一切都是不可能的，但是即使解决其中的一些问题也将对整个项目有益。

#5 楼

听起来您似乎已经走对了，但除了仔细研究需求并熟悉路线图之外，绝对值得让他对MVP进行探索性测试并尽早了解产品。

此外，对需求文档进行静态测试将是有益的，因为它可以提供早期反馈，并且您的人可以制定后端需求以使其自动化更容易实现-我在自动化领域工作过团队将命名页面元素，而不是开发人员或业务分析师。

如果失败，那么为最高优先级的旅程（通常是“快乐的道路”）创建一些测试，将会展示出自动化的能力……并可能给客户留下深刻印象！

#6 楼

注意：我假设您是QTO的CTO或类似角色，或者是“老板”。

为了阐明我在项目/产品开发过程中对QA的“想法”，我将工作流程记为例如：



需求：对其进行形式化，更新，根据用例或用户故事跟踪每个发行版。

定义测试：定义如何测试用户故事，并应考虑到一些小案例

工具：找到合适的工具/框架/系统来构建测试

测试：这里的核心质量检查工作，为每个发行版运行测试或创建新的测试以涵盖大多数用户案例。测试可能具有以下类型：



单元测试：必须始终在任何地方对边缘情况（空，最坏的情况）进行代码测试。 >集成测试：api集成测试，例如使用邮递员之类的工具

最终用户测试：不是自动化测试，应注意核心用例，并可以手工（或鼠标）完成



文档和回顾：跟踪发布，已完成/已接受/失败的测试，以了解团队可以做得更好的下一步操作

回答您的问题： “对我来说，QA工程师在项目处于早期阶段时会做什么？”对我来说是：


帮助需求阶段：理解需求，帮助追踪需求并确定需求每个需求都应该有一个验收测试，以纯文本形式编写。找到一种方法来指定它们，跟踪它们，组织它们并使它们在“ test wiki / document”中保持更新是一项巨大的工作。我发现有用的定义不仅是定义用户故事/用例，而且定义“用户旅程”，以有意义的方式将用例连接在一起。所有团队都可以从这项工作中受益，并且质量检查工程师可以更快，更好地了解系统的工作方式和原因，并组织以下阶段
负责定义测试和工具阶段：确定要测试的内容，导入时间和位置以及！ QA工程师也应在这里负责（当然要获得CTO批准！）。批评工具的选择，自由地尝试其他工具对于质量检查工程师在这里负责是很重要的。
测试工作：这里的核心质量检查工作。负责并负责每个用户故事都被一组测试（单元/集成/最终用户测试）覆盖，测试类型的比例为70％/ 20％/ 10％。每个软件版本的关键路径都应手动测试。
文档和回顾：不要忘记这一点！帮助项目/产品经理确定需要改进的地方，提出建议并提供有关问题的反馈，因此计划功能/主题应更加容易。例如：我们在这方面有很多问题，是否应该在重新设计/重新思考上投入更多？

背景：开发人员和质量检查人员10年，产品所有者1年

#7 楼

我认为现在是问有关如何定义应用程序质量的好时机（例如，它需要多快，需要多少可访问性，受支持的浏览器）。我还发现测试自动化可能需要花费大量时间。很少时间起床和运行。有很多要安装的驱动程序和/或docker /虚拟机类型的容器可以启动和运行，以及有关使用工具，安全功能，将其连接到构建服务器等的决定，以及教任何想要做出贡献的人。查看结果。

即使只是登录测试，已经准备好动摇了，这对于许多人正在努力实现的“使冲刺自动化”非常有用。

#8 楼

需要讨论的是，关注团队成员业务分析师，开发人员，测试成员有关项目范围的问题。将产生一个想法，如何进行测试。

还要准备自己的文件（如果您没有文件）。如果您已经看了就读。尝试问尽可能多的问题。记下它。并启动testign。

了解更多：https://softwaretestingboard.com/q2a/3308/