您的QA团队有效吗？

Question

您的QA团队是否有效。我发现我遇到的许多QA人员都是更多的验证者和软件专家。

验证者的意思是，他们逐步完成所有提供的场景，基本上遍历应用程序并确保它完成应有的操作。

我的意思是断路器，他们会验证，但他们也在努力寻找破坏软件和发现缺陷的方案。

您的发现是否相似？

关于打破软件的历史记录80年代，IBM内部有一个名为Black Team的团队。当他们打破软件以鼓励识别缺陷时，他们有一种文化说他们已经“成功”了。当他们未能找到/识别软件中的任何故障时，他们认为他们的工作是“失败”。另一方面，他们“失败”的结果是非常可靠的软件......

这本书： James Whittaker撰写的“如何打破软件：实用的测试指南”

Answer 1

在许多情况下，如果质量保证这样做，我会很高兴。我的经验是，如果QA存在，它往往包括对业务最了解的低薪代理机构新员工。做好QA很难，就像编程很难，它很少被资源化或管理作为开发过程的关键部分。

另一方面，与我合作的最佳QA有20多个PC鬼图像，并且知道如何处理它们，他们是DB忍者，他们也可以与最终用户沟通。有一个具有广泛硬件的机器的测试平台。领导力很强，知道什么时候推，什么时候放手，她知道客户，她知道开发人员的想法。我们很快就了解到，我们的足够好的标准与客户不同。不幸的是，该产品仍然是一堆破旧的垃圾，这是生意，但它很少崩溃，客户喜欢它。

Answer 2

我实际上是一个测试团队，我们做的很多工作都是验证和软件破解，但这只是其中的一部分。我们还维护产品的自动化测试，以便在开发周期的早期捕获错误，并与开发合作运行大型可扩展性测试，以突破我们产品的极限并找到可以更新的区域，以便在以下方面实现进一步的可扩展性未来。

我认为我们在将最好的产品交付给用户的目标方面非常有效，简单的验证是该流程的重要组成部分。

另外......我认为QA在很多方面受到资源的限制，我们很幸运能够获得大量的开发工具，大规模虚拟环境（以及体面的）基于硬件的机器），我们有足够的自由来实际使用该产品。

一些测试必然是“运行这些测试用例”类型的交易，但这只是一部分。

Answer 3

我相信我们的QA团队是有效的。但是，我们不聘请测试人员，我们聘请QA分析师

• 使用为项目提供的业务要求和技术设计文档编写自己的测试用例。 QA尽可能早地参与开发周期。
• 熟悉业务。
• 了解单元测试，功能测试，系统集成测试，回归测试等之间的区别。换句话说，他们都在努力研究QA方法。
• 定期对系统执行回归测试。这可确保新项目未在工作代码中引入错误。
• 得到开发团队的尊重，以及与开发工资相当的工资。由于QA受到开发团队的尊重，因此开发人员可以快速向QA询问有关某些代码更改的意见，尤其是因为QA比特定开发人员具有更好的整体业务知识，而开发人员几乎总是专注于某个领域。

由一组使用开发人员提供的测试用例且无法掌握质量保证方法或业务领域的手动测试人员组成的质量保证团队可能效果不佳。

Answer 4

我认为这是一个广泛的概括（有些人在QA工作的人）。我会问你对QA的期望和期望是什么？

恕我直言，软件验证是你想要的QA团队，包括：

0）验证是否已实施所有要求 1）验证所有要求是否正确实施 2）报告与要求的任何偏差 3）提供文件以重现与要求的偏差 4）为产品提供可扩展性，压力和容量，故障容忍支持

这意味着要将该组称为“软件破坏者”和“验证者”。在我的工作中，人类健康的后果可能源于错误的软件。这不是关于我，我的团队或QA小组，而是关于帮助我们使用我编写的软件的人。这真的是关于态度。

关于“打破”事物的历史记录。在80年代IBM内部有一个名为Black Team的团队。当他们打破软件以鼓励识别缺陷时，他们有一种文化说他们已经“成功”了。当他们未能找到/识别软件中的任何故障时，他们认为他们的工作是“失败”。另一方面，他们“失败”的结果是非常可靠的软件......

Answer 5

我不想成为一名测试员。

QA与销售和技术支持有很多共同点，如果你知道自己真的很擅长工作，就不会再做那份工作了。

想一想：你曾经打过一条技术支持热线吗？这是一项不值得羡慕的工作（我很久以前就做过）。基本上你花了90％的时间为你无法控制的事情道歉（或者只是浪费你的时间试图在8岁的harwaare上工作，因为有人太便宜而不能为新PC安排几百美元，但是那是另一个故事）。

在我上一份工作中，我们的QA营业额很高。说实话，他们必须在那里待至少6个月才能学会他们的名字。在此之前，他们很可能继续前进，因此根本不值得花时间投资培训他们（以开发人员的身份发言）。

不要误会我的意思：有些是好的，但它们很少而且很远，只是因为如果它们很好，它们会继续成为BA或其他东西。

Answer 6

破解软件没有。我们的大多数QA人都不擅长这一点。有效的是，它们会捕获我们错过的错误，并就如何在对它们没有意义的情况下改进UI提出建议。

Answer 7

我们的质量保证团队做了一些突破和大量的验证，我认为这两者都是获得质量保证的基本要点。它们是您的代码与生产环境或RTM之间的最终严格测试点。

虽然他们没有积极尝试破解应用程序，但他们非常擅长做那些用户试图做的事情。在某些时候，这最终会破坏应用程序。

Answer 8

我在一个3人开发小组工作。我们每个人都必须测试并且通常留给我们自己的测试设备（我们主要做网络应用程序工作）。这不是我满意的解决方案。有时用户参与测试。我有几个非常敏锐和可靠的用户，但我从未打算从其他用户那里获得输入。

Answer 9

有效？你是如何衡量的？找到错误的数量？如果代码真的很扎实怎么办？如果他们只发现一个错误，但这是一个非常重要的错误呢？你是否因为裂缝中的漏洞而责怪他们？

Answer 10

我们的组织只有一个正式的qa团队大约一年半。现在我们正在尝试建立配置管理组（现在我们只有一个人）。对于一个人来说，所有开发经理都希望我们能够获得更多QA人员而不是配置管理，因为我们发现QA对我们来说非常有价值，而配置管理只会导致项目在我们等待某人放置新代码时更加落后在发布时间表而不是准备好的时候。开发人员在测试他们自己的代码时会有盲点（我们知道它毕竟应该如何发展）并且优秀的QA人总能找到开发人员错过的东西。

我认为获得优秀QA人员的最大问题是工资往往偏低。如果技术人员已经比QA人员制作的更多，那么他就没有理由进入这条职业道路。因此，他们最终会在校外或没有技术背景的人。这些正是那些不具备建立良好自动化测试知识的人或者了解用户需要软件如何工作的商业头脑。 （我已经与业务分析师见过这一点，他们对最终产品的质量也很关键。我刚看到其中一个工作开放，每年支付30K。我很抱歉，但是那个将要确定的人对于公司功能至关重要的软件要求需要比接待员获得更多的报酬。管理人员想知道为什么软件质量会如此之低。糟糕的要求=差的软件接近100％的时间。）< / p>

Answer 11

在我们这里，这些只是通过预先描述的风格来点击应用程序的学生。没有主动测试，没有兴趣，没有超出给定的内容。事实上，这是我（开发人员），我们的PM以及进行最终测试的可悲客户。

我发现我可能是唯一一个喜欢做非标准事情的人，只是为了看看会发生什么。我碰巧通过做一些没有人想过做了好几年的事情来发现软件中很常用的部分。我在公司呆了几个月。