质量检查人员应该在功能完全实施之前就功能上的错误进行报告吗？

#1 楼

尽早开始测试始终是一个很好的实践。

如果您还没有开发，那么如果还没有完全实现，那么我想那不是一个好主意。是的，您可以使用增量构建版本进行测试，这可能会有所帮助。

您是否维护用于跟踪错误的中央存储库？

某种错误跟踪系统？如果是，那么您的测试人员是否在记录错误列表之前检查是否已经记录了错误？

他们不互相协调吗？

似乎存在严重的沟通和理解问题。

#2 楼

我认为问题出在您使用VCS的方式上：

您想提交代码，因为您已经完成了一个子任务并希望备份它，例如

您的测试人员会看到仓库中的更改，或者得到他们要测试的自动化版本。
除非有要求，否则任何测试人员都不得对此代码进行测试。 >
可以测试该提交，并且可以记录该分支中所有生成的错误。

#3 楼

对我来说，这是一个完美的示例，说明了基于错误的KPI评估测试人员的有效性时会发生的情况，在这种情况下，报告了许多错误。最后，它将损害测试人员，开发人员，测试人员与开发人员之间的关系并因此损害产品质量。

对我来说，这是错误的KPI，这里至少有两次讨论是这样的： br />

什么是软件质量保证的良好KPI？
对测试员来说最有用的KPI是什么？工作，但在正式报告之前，我先问一下。我问这是因为工作不完整还是仅仅是需求错了，我们需要讨论需求或计划在下一个冲刺中对其进行修复。这是很好的方法。但是，您说您正在进行UI更改两个星期，但尚未完成。对我来说，这表明您的故事可能太长了，您应该尝试团队协作来定义更小，更精细的故事。这也可能是测试人员和开发人员之间的折衷方案：他们可以使事情进行更频繁的测试，并且您可以专注于工作直到完成。最后，合并较短的分支可能不会那么痛苦。

#4 楼

在过去的十年中，我工作的大多数公司都使用敏捷方法。在这种方法中，需要注意几个因素，例如：


鼓励在正式流程中进行直接沟通
鼓励团队方法
坐在一起
我发现在这样的环境中，您想寻求诸如以下的实践：


在开发甚至开始之前就对测试计划进行配对
谈论如何测试某些东西在开发开始之前
在开发的多个阶段对功能进行配对
用于质量保证工作的开发人员配对，开发人员工作期间的测试人员配对，两组眼睛

该功能已完成足以进行测试，您将承担更多工作/不想更改已编写代码的风险，以及捍卫刚创建的代码的风险。

这确实需要更多的沟通，以便人们了解部分实现，需要忽略的问题等。

#5 楼

如果开发尚未完成，则浪费时间测试功能（报告错误并对其进行分类）是没有意义的。代码完成后，必须重新做所有这些工作。如果您的测试人员有太多的时间来为自己创建额外的工作，而这对项目没有任何好处，那么您的过程中就会有些奇怪。还是开发人员将代码直接从DEV部署到PROD？因此，QA被迫在DEV中进行测试，试图在bug进入PROD之前就发现它们？单独的测试环境可以避免这种情况。

更深层次的问题的综合症是所有SQA都会输入相同的错误。质量保证人员应负责对错误进行分类并查看是否存在重复项。尤其是如果所有错误报告都与正在测试的同一新开发功能有关。

如果您的过程包含QA环境，则几乎不会发生这种情况，因为只有在开发完成后才将代码部署到QA。

编辑：如果您工作敏捷并且有足够的资源，则可以开始探索/编写应用程序中不会发生快速更改（“已解决”）的部分的测试。但是这样的测试只是初步的，在开发完成时必须重复进行。质量检查人员和开发人员。敏捷开发在很大程度上取决于沟通。

#6 楼

不，测试您认为不完整且尚未准备好进行测试的代码没有任何意义。软件开发过程。听起来开发人员和质量检查人员之间的通信失败，并且期望值不匹配。例如，听起来您要将不完整的代码提交到共享代码存储库。相反，更好的做法是使用分支。您应该在功能分支上进行开发。例如，这是一个示例工作流程：


您有一个master分支，其中包含最新版本的代码。仅在准备就绪时，才将代码合并到该分支中。代码完成后，您可以将其合并到master分支。

这使将测试和SQA集成到工作流中变得更加容易。例如，一旦您认为功能分支已经准备就绪，就可以将其合并到master分支中。 QA团队只专注于测试和评估master分支，因此他们永远不会浪费时间测试正在进行中的代码（您知道这些代码尚未准备好进行测试）。

，一旦您相信了功能分支已准备就绪，您可以将其发送给质量检查小组以供他们进行测试。通过质量检查后，可以将其合并到母版中。有许多替代方案和变体，但关键是私有分支可以实现更好的通信：它有助于就应该评估哪些代码以及什么测试毫无意义的代码建立共识。

最终，这就是它的全部内容是：沟通并满足每个人的期望。

有关这种工作流的更多信息，请参见


分支还是不分支？
我的同事在没有测试的情况下进行提交和推送
开发vs阶段环境vs产品环境

#7 楼

多个测试人员甚至在不互相交谈的情况下测试同一件事的事实非常清楚地表明该过程已中断。您不应该让2个开发人员独立开发相同的功能，也不应该让2个测试人员独立测试相同的功能。听起来很明显，但是如果两个人在同一件事上工作，他们就需要了解彼此的工作并一起工作。 。

让我们将其与我之前使用的有效设置进行对比：

测试仪是日常会议的一部分，每个人都花一分钟（而不是一秒钟）让其他人知道他们正在做什么，以及自上次会议以来已完成的工作。测试人员是会议的一部分，并让团队知道他们是否有时间测试一些未完成的事情，因为测试完成的功能是优先事项。同样，该团队可以让测试人员尽早知道重构是否可能再次触及某些已完成的功能，因此需要重新测试。已经进行了部分测试，并且测试人员有时间进行测试，他们俩都在会议中提到了该问题，然后在会议结束后坐在一起以找出细节。双重：首先，开发人员仍然掌握着所有东西，因此可以解决问题，所花费的时间少于以后提出缺陷时所花费的时间。其次，通过更快地检测和修复错误，您的产品将尽快完成，即build-test-fix-retest-release管道变得更短。缺点是测试人员需要更频繁地进行测试。您会牺牲测试人员的时间来加快产品上市时间。

#8 楼

您希望检入代码以保存它。测试人员会测试他们可以看到的所有内容，这可能是因为不清楚尚未完成的内容，或者可能是出于其他原因。您可以采取一些措施来解决此问题。


您可以使用功能分支


您只需将代码合并到“ main ”完成后
其他开发人员可以根据自己的意愿查看您正在处理的内容
，但是完成后必须合并代码，这可能需要很长时间
，其他开发人员在进行合并之前，不能使用与您相同的代码。或编译时启用了新功能
如果未设置切换，则新功能不会显示在任何菜单等中。
如果是运行时切换，则测试人员和管理人员可以打开该功能
但是由于默认情况下该功能处于禁用状态，因此测试人员不太可能针对该功能提出错误。对于该货件已关闭
不难为每个客户授权使用该功能如果需要，可以使用
，但是必须基于功能平面等来启用菜单。
一旦开发完成并经过测试，您可以决定是否将切换保留在源代码中或删除它。



请参阅问题“功能切换与功能分支”和Martin Fowler在FeatureToggle上的博客文章。

#9 楼

我想说问题出在完整过程中。使用此文档，SQA不会测试尚未开发的任何内容。

如果绝对必须（由于管理限制）进行预先测试，则可以将功能切成小块，然后仅“交付”功能的某些部分，可以在完整功能同时进行测试尚未完成。

将功能切成原子块的事实确实帮助我们测试了正确的事情，而不会浪费时间在未完成的零件上。 “三遍相同的错误日志”问题，这是测试经理的职责，测试经理应组织其团队，以便他们不会同时测试相同的功能。对于开发人员和测试团队而言，这是浪费大量时间的最佳方法。

#10 楼

正常吗是的，没有。我首先要说的是，如果您处于AGILE环境中，产品所有者或其他人应在提交重复的缺陷报告之前先清理它们。功能正在运行，通常不像以前那样。但是，这只会浪费宝贵的QA时间，并使积压的订单变得混乱。

最后，除非您需要这样做，否则我会避免检入不完整的代码，因为其他人需要进行更改。即使那样，多个人也很难编写相同的代码。如果其他工程师不需要更改您正在使用的相同代码，请在完成之前不要对其进行检入。

#11 楼

实际上，在某种程度上，如果使用测试驱动的开发（TDD），这是很正常的事情-您可以预期在开发开始时将有近100％的测试失败，并且随着开发的进行会有所改善。

可能您需要处理公司的工作流程，以便将失败的测试记录为失败的测试，直到您尝试将功能标记为完整为止-当您这样做时，测试就会变成bug。功能分支是执行此操作的好方法。

如果测试人员正在复制错误，则存在一个严重的问题，即它们不检查已知问题，并且需要质量检查经理进行处理。

#12 楼

作为一名测试人员，我喜欢探索部分开发的代码，并向开发人员提供早期反馈。

正如其他人所提到的，关键是开发人员和测试人员之间的密切沟通。我需要知道哪些区域仍可能是不完整的，所以我不会浪费时间试图找出问题。开发人员需要准备概述完成的工作，并可能讨论解决未完成区域的方法的一些技巧（例如，如果尚未通过UI创建订单，我可能希望将数据直接插入数据库中，因此我仍然可以在其他领域看待。）

最大的好处是，我对我们正在构建的内容的理解与开发人员的理解一起增长，并且我可以提出有关潜在边缘情况的问题他们正在建立，从而节省了他们宝贵的时间并加深了我们的理解。

其他一些答案似乎都基于一种基于测试用例的方法，您一次又一次地运行相同的测试用例。坦白说，如果功能完成后我正在运行完全相同的测试，我会认为自己从以前的工作中学不到任何东西，因此会感到担心。在早期的测试阶段，我将开发自己的思维模型并考虑测试设计。

这似乎有点长-但是我想描述如何很好地完成它。您的情况显然没有得到很好的处理：


通过错误跟踪器进行通信
KPI驱动的测试人员试图提高错误的最大数量测试人员之间
试图澄清完全被忽略的范围

仅举几例。我建议与生产线管理人员讨论，以了解要求QA尽早介入的目的，并说明通过Bug跟踪程序运行所有程序的额外开销。如果可能的话，如果您尊重某个特定的测试人员，则可以建议在此早期阶段分配一位测试人员更为实际，这将使您共同努力制定一个更好的流程。

#13 楼

首先，不要因为提交代码而推迟，您应该继续及早并经常这样做。所有的自动化测试都应该在此时通过。

质量检查的目标应该是尽快测试您的工作，并且不要在冲刺结束之前就保留所有内容，但与此同时，不要测试尚未准备好的东西。这不仅浪费他们的时间，而且可能会在开发人员和测试人员之间造成分歧。

我会尝试提出这样的建议。


您已经准备好进行质量检查的功能，通知他们并安排对该功能的简短演示。这应该是开发人员使用测试仪停放5分钟并演示新功能的地方。这不仅可以改善质量检查人员与开发人员之间的关系，而且通常还可以在演示过程中找出开发人员可以在解决问题之前立即解决的问题。
您的质量检查团队会持续监控主分支并报告任何问题立即发现缺陷。这样一来，他们就不会都在同一时间报告同一问题，也许每个人一次都可以做到这一点。这也将鼓励开发人员将尚未准备就绪的功能保留在自己的功能分支中。

#14 楼

好吧，实际上就像开发箱测试一样。开发箱测试有助于确保进行更多级别的验证。在将其提交到QA环境之前，它可以确保用户故事的质量。就是说，不应该有JIRA票证或开发箱测试的票证。相反，必须在工作表中或通过电子邮件报告错误。如果您不愿意使用JIRA，那么可以使用一张DEV Box Testing票证，其中简要地提到了所有错误。 ！错误的数量并不总是能够反映出测试的质量。

#15 楼

如果功能是通过具有明确定义的DoD的连续故事提供的，则质量检查应在它们到达“准备测试”状态后立即对其进行测试。正如@PeterJackson提到的那样：“尽早开始测试始终是一个很好的做法。”因此QA会跟踪功能开发，并测试开发人员处理给测试人员的故事。关键在于所有团队成员（例如，分析师，开发人员，测试人员等）了解功能，上下文（如当前的SDLC阶段），DoD和项目前进的方向。然后尽早测试和报告问题会增加按时交付和满足需求的机会。