在发布前订购/处理数千个缺陷

Question

这个问题是在接受一位非常好的company.Below采访时向我提出的，我将以我们的互动(M: me &I:面试官).Though的形式提出这个问题，但我需要知道面试官真正想要什么样的想法/回答：

I:场景是您和另外两个由测试团队组成的团队。你，领导，是唯一能实现自动化的人，其他人只能做手工测试。您有近10,000个错误已经被提出，你有4-5周或更短的时间才能交付该产品。您将如何确保产品按时交付？

M:按优先顺序过滤bug，并重新测试它们。同时，记录哪些功能面临更多的回归，从而开始自动化它们。类似或相关的bug将提供给其他人进行进一步的测试。

I:假设没有一个bug被标记为任何优先级。你会怎么做？

M:我将使用dates.In过滤任何类型的SDLC，即使是敏捷的SDLC，核心组件也是首先开发的，如果有核心错误，首先需要修复。

I：(不赞成)如果在以后的sprint中添加了一个非常重要的功能怎么办？此外，你将如何利用你的队友和你的能力，自动化。

M:随着时间的推移，作为一名测试人员，我必须知道产品的核心&重要功能，直到date.So，记住这一点，我将找到每个sprint要处理的核心区域(关于团队匹配的回答和以前一样)。

I:假设，bug没有用每个sprint的时间线来标记。你会怎么做？

M:我会用关键词搜索bug列表，这些关键词代表了产品不能发布的重要功能。我会从那里挑出虫子。

I：(再次表示不赞成)用一个关键字，你会得到这么多的结果，你会一个一个地检查它们吗？

M：(慢慢地失去希望)我只会通过标题和决定。

I:一般来说，标题不那么有解释性，你会怎么处理呢？

M:我将开始亲自测试产品，并使用我所面临的类似bug进行搜索，而不是尝试通过bug，因为我需要对产品交付做出决定。

I:那么你会忽略那些虫子吗？利益相关者可能不同意。(在这之后，我完全失去了信心，不停地唠叨着，我不记得还有什么是asked.Also无处不在的，另外两名手动测试员的管理/工作被问到了)

这是一次高级SDET的采访。

Answer 1

除了其他答案，我要说的是面试官正在寻找你，作为一个团队的新成员，你将如何处理一个没有赢的情况。坦率地说，我怀疑--至少在过去--公司发现自己处于这种情况中。在最坏的情况下(我坦率地承认我是愤世嫉俗的)，无论谁得到这个职位，都会面临类似的情况。

作为一名面试官，我想从我面试的人那里得到这样的信息：

首先，我想知道这些bug是如何组织的，特别是优先级、严重性和风险。我假设我要进入这种情况，而不是从一开始我就被卷入其中，因为这种情况表明事情在某个地方出现了严重的错误。如果错误的组织方式不涉及优先级、严重性和风险，我想与其他测试人员、项目管理和开发人员交谈，以确定他们知道哪些问题对预计的部署日期造成最大的风险。如果有这样的组织，我希望与测试人员、项目管理和开发人员交谈，以确认风险最高的bug。理想情况下，我会寻找一种方法来构建一个必须在产品发布之前修复的bug列表。对于10,000个bug，该列表将需要一些时间来创建，并且假设没有测试人员无法找到的bug，因为报告的bug正在隐藏或阻止它们。一旦我知道情况有多糟糕，我就可以决定--在我看来--是否可以按计划发布应用程序。如果大多数bug是相对较低的风险，而且高风险bug似乎相当容易修复，我会将我的团队集中在高风险bug上，并与项目经理和任何其他团队一起工作，以获得最高风险(高严重性，最有可能发生在现场和/或应用程序块区域)错误的修复和测试。如果我找不到及时发布该产品的方法，我会开始与项目经理和我的老板交谈，看看是否有办法进行有限的、可靠功能的测试版或推迟发布。由于我是新来的职位，我不知道是否有任何合同要求或其他因素超出我的控制，可能迫使释放日期是固定的。我还会确保，在发布之后，我会与所有相关团队的负责人一起研究这种情况是如何发生的，以及我们可以采取什么措施来防止再次发生这种情况，以及我们如何共同努力，以减少bug积压。

请注意，所有这些都与SDET角色无关。从问题中可以清楚地看到，面试官希望SDET也能起到测试引导的作用--我不认为这是一件特别好的事情，坦率地说，我想知道这是否是公司对SDET的期望。

值得记住的是，即使面试是压力很大的情况，试着从侧面思考，看看你被问到的问题的含意，而不是潜入其中。这是很难做到的，因为你压力很大，并且尽力做到最好，但如果你能花点时间在心里问问自己，面试官的问题是什么，你通常可以给出一个更好的答案。

Answer 2

如果面试官提到错误而不是测试失败(如果它的测试失败，请参考@Lewis的答案

首先，在一个产品中有10000个活跃的bug是真正的危险信号。

你不应该发布这样的产品。但如果管理层的决定还有待公布，

面试官期望的答案是“严厉”。

如果没有优先级，团队应该首先修复高度严重的bug，如果不是紧急需求，并且不影响实际的业务逻辑，则应该保持低优先级。

首先集中精力自动进行烟雾测试，然后开始自动化所有回归套件。

对bug进行分组，查看bug集群发生的位置，并在修复完成后严格测试该模块。

在发布之前，手动测试所有烟雾测试场景(关键业务逻辑)

此外，有10000个bug可能会导致缺陷掩蔽，而这些bug掩盖了产品中的一些关键错误。

因此，一旦修复完成，就应该围绕模块进行更严格的测试，以挖掘更重要的bug。

所以如果我在面试中，我会回答如下：

1. 任何项目中的10000个bug将是一个巨大的危险标志，它表明没有适当的错误修复过程和评估到位。我肯定会担心缺陷聚类和缺陷掩蔽，这意味着大多数bug可能集中在单个模块上，而这些错误可能掩盖了任何其他关键的bug，这些错误只有在严格修复和重新测试模块之后才能识别出来。并将建议推迟发布日期，因为这一原因。

也就是说，当开发团队忙于修复bug时，我们将开始自动处理冒烟测试用例和错误用例。一旦修复到达，我们会将重新测试任务分配给手动测试人员，我们自己对模块进行严格的临时测试，以发现任何隐藏的关键错误。

1. 如果没有优先级，那么首先重新检查关键的或高度严重的bug是空闲的，还可以研究bug的生存期，并理解为什么bug在这么长时间内没有修复，以帮助改进未来的整个过程。

对于严重程度较低的but，我们需要对时间线和发布决定做出一个团队决定，是否使用这些but发布第一个版本，但仍然会记录相同的问题，并在需要时做出相应的解决办法。如果可能，还为可能的修复提供下一个发布日期。

因此，作为一名高级QA，当你看到危险信号时，你应该提出你的强烈意见来保持“不”。不要太灵活的

Answer 3

我想到的第一件事是--这些测试以前有用吗？如果是这样的话，不要惊慌。代码库或测试框架中发生了一些变化，这可能导致它们中的组失败。跟踪它，看看你能不能消除几千次失败一次。您仍然需要阅读那些再次手动通过，并再次检查他们，但也许这将只需要几天。

如果他们从来没有被检查之前，我还会做一些类似的事情-寻找任何共同之处，可以让你一次修复大组。

否则，有太多的噪音，可能会导致你错过一些关键的东西，正在失败。

在此之后，请接受这样一个事实:你可能无法做到所有事情，并专注于赚钱者的代码路径。必须要工作的东西或者商业折叠物。然后，在您清除了更多的这些，每隔一天或三天看看是否还有像前面提到的分组失败，并尝试清除更多的组。

注意:从SDET的角度回答这个问题--某个可以修复违规代码库本身的人。