您的 QA 团队是否有效。我发现我遇到的许多 QA 人员更多是验证者和软件破解专家。
我所说的验证者的意思是，他们逐步完成所提供的所有场景，基本上是遍历应用程序并确保它完成预期的工作。
我所说的破坏者的意思是，他们验证但他们也努力寻找破坏软件并发现缺陷的场景。
你的发现相似吗？
关于破解软件的历史记录 在 80 年代 IBM 内部有一个名为 Black Team 的团队。他们有一种文化，当他们破坏软件以鼓励识别缺陷时，他们会说他们已经“成功”了。当他们未能发现/识别软件中的任何故障时，他们认为他们的工作是“失败的”。另一方面，他们“失败”的结果是非常可靠的软件......
还有一本书：James Whittaker 的《如何破解软件：测试实用指南》
在许多情况下，如果 QA 这样做，我会很高兴。我的经验是，如果质量保证存在，它通常由对业务最了解的低薪代理招聘组成。做好 QA 很难，就像编程很难一样，它很少作为开发过程的关键部分来获得资源或管理。
另一方面，我合作过的最好的 QA 有 20 多张 PC 幽灵图像，并且知道如何处理它们，他们是 DB 忍者，他们也可以与最终用户交流。有一个具有广泛硬件的机器测试平台。领导力很强，知道什么时候该推，什么时候该放手，她了解客户，她知道开发人员的想法。我们很快了解到，我们的足够好标准与客户不同。不幸的是，该产品仍然是一堆破旧的垃圾，这是生意，但它很少崩溃并且客户喜欢它。
我实际上在一个测试团队中，我们所做的很多事情都是验证和软件破解，但这只是其中的一部分。我们还维护产品的自动化测试，以便在开发周期的早期发现错误，并与开发合作运行大型可扩展性测试，以突破我们产品的极限并找到可以更新的区域以允许进一步的可扩展性未来。
我认为我们在将最好的产品尽可能交到用户手中的目标方面非常有效，简单的验证是该过程的重要组成部分。
另外......我认为质量保证在很多方面都受到他们提供的资源的限制，我们很幸运能够大量使用开发工具、大型虚拟环境（以及体面的基于硬件的机器） )，我们有足够的自由来实际试验产品。
一些测试必然是“运行这些测试用例”类型的交易，但这只是其中的一部分。
我相信我们的 QA 团队是有效的。但是，我们不雇佣测试人员，我们雇佣 QA 分析师
由一组使用开发人员提供的测试用例并且不掌握 QA 方法或业务领域的手动测试人员组成的 QA 团队可能不会那么有效。
我认为这是一个广泛的概括（并且有点反作用于在 QA 工作的人）。我会问你对 QA 有什么期望和要求？
恕我直言，软件验证是您想要从 QA 团队获得的，包括：
0) 验证所有需求均已实现 1) 验证所有需求均已正确实现 2) 报告与需求的任何偏差 3) 提供文档以重现与需求的偏差 4) 为产品提供可扩展性、压力和容量、容错支持
Sf 这意味着称该组为“软件破坏者”和“验证者”，就这样吧。在我的工作中，运行不良的软件可能会导致人类健康后果。这与我、我的团队或 QA 团队无关，它与使用我编写的软件的人有关。这真的是关于态度。
关于“打破”事情的历史记录。80 年代 IBM 内部有一个团队，叫做 Black Team。他们有一种文化，当他们破坏软件以鼓励识别缺陷时，他们会说他们已经“成功”了。当他们未能发现/识别软件中的任何故障时，他们认为他们的工作是“失败的”。另一方面，他们“失败”的结果是非常可靠的软件......
我不想成为一名测试员。
QA 与销售和技术支持有很多共同点，因为如果你知道的足够多，能够真正擅长你的工作，你就不会再做那份工作了。
想一想：您曾经拨打过技术支持热线吗？这是一份不值得羡慕的工作（我很久以前做过一次）。基本上你花 90% 的时间为你无法控制的事情道歉（或者只是浪费你的时间试图让一些东西在 8 岁的硬件上工作，因为有人太便宜了，不能花几百美元买一台新电脑，但是那是另一个故事）。
在我上一份工作中，我们的 QA 人员流动率很高。老实说，他们至少要在那里待上 6 个月，我才可能费心得知他们的名字。在此之前，他们很可能会继续前进，根本不值得投入时间来培训他们（作为开发人员而言）。
不要误会我的意思：有些很好，但它们之间的差距很小，因为如果它们很好，他们就会继续成为 BA 或其他人。
在破解软件没有。我们的大多数质量检查人员都不擅长这一点。是的，在有效时，他们会发现我们错过的错误，并就我们如何能够在对他们没有意义的情况下改进 UI 提出建议。
我们的 QA 团队做了一些破坏和大量验证，我认为这两者都是 QA 的基本点。它们是您的代码和生产环境或 RTM 之间的最终严格测试点。
虽然他们不会主动尝试破坏应用程序，但他们非常擅长做用户会尝试做的事情。在某些时候，这确实会破坏应用程序。
我在一个 3 人开发小组工作。我们每个人都必须进行测试，并且通常留给我们自己的测试设备（我们主要做网络应用工作）。这不是我满意的解决方案。有时用户会参与测试。我有几个非常敏锐和可靠的用户，但我从不打算从其他人那里获得意见。
有效的？你怎么衡量呢？# 发现了多少个错误？如果代码真的很可靠怎么办？如果他们只发现一个错误，但这是一个非常重要的错误怎么办？您是否将它们归咎于确实从裂缝中溜走的虫子？
在我们这里，这些只是通过预先描述的场景点击应用程序的学生。没有主动测试，没有兴趣，除了给定的东西之外什么都没有。事实上，做最终测试的是我（开发人员）、我们的产品经理和可悲的客户。
我发现我可能是唯一一个愿意做一些非标准的事情只是为了看看会发生什么的人。我碰巧通过做一些几年来没有人想过要做的事情，在相当使用的软件部分中发现错误。我在公司里只待了几个月。
我们组织只有大约一年半的正式质量保证团队。现在我们正在尝试建立一个配置管理组（我们现在只有一个人）。对于一个人来说，所有的开发经理都希望我们能有更多的 QA 人员而不是配置管理人员，因为我们发现 QA 对我们来说非常有价值，而配置管理只会导致项目在我们等待有人发布新代码时落后在发布时间表上而不是在它准备好时。开发人员在测试自己的代码时存在盲点（我们知道它应该如何工作），优秀的 QA 人员总能找到开发人员遗漏的东西。
我认为获得优秀 QA 人员的最大问题是薪水往往偏低。如果技术人员的收入已经超过了 QA 人员的收入，那么他或她就没有理由转向该职业道路。因此，他们最终选择的是刚毕业或没有技术背景的人。这些人正是没有知识来建立良好的自动化测试或商业头脑来理解用户需要软件如何工作的人。（我也看到业务分析师对最终产品的质量也很重要。我刚刚看到其中一个年薪 30K 的职位空缺。很抱歉，但要确定的人对公司功能至关重要的软件的要求需要比接待员获得更多报酬。经理们想知道为什么软件质量会这么低。糟糕的需求 = 几乎 100% 的时候都是糟糕的软件。）