3

我曾在 QA 团队从项目开始到维护期间积极参与开发过程的环境中工作。我通常发现这是有效的，因为 QA 团队在流程的早期就从业务前景中了解了正在发生的事情。他们可以很早就开始编写测试脚本。

但是，我也曾在 QA 团队与开发团队非常脱节的环境中工作。他们对流程没有兴趣，只是在“开发”阶段结束时参与进来，争先恐后地提出测试，然后根据自己对业务需求的理解执行一组有限的测试。

你对此有何感想？您认为 QA 团队在流程中的参与程度如何？如何将习惯于“不参与”的团队转变为积极参与流程的团队？

4

8 回答 8

4

我赞扬您让 QA/Test 及早参与流程的目标。我大力提倡让一个强大的测试团队从流程开始一直参与到整个过程中。很高兴看到开发包含 QA。他们常常对测试参与有抵抗力。

如果你想让 QA 团队更多地参与进来，你必须让他们想要参与进来。这可能意味着确保他们的管理层看到其中的价值，并为他们的参与提供资金。一些 QA 团队有太多工作需要及早参与（或认为他们这样做了）。这包括质量保证管理。如果他们不接受，他们将无法奖励花时间与您互动的人。

您需要向 QA 证明他们可以在流程的早期做出贡献，并且他们会从中受益。环顾 QA 团队。找到知道如何编程或至少想知道如何编程的人。邀请他设计会议。鼓励他说话。基本上，开始让他参与对话。如果他不开始参与，请找其他人参与。有时考试有自卑心理，除非被问到，否则考试不会来。不过，一旦被问到，他们可能会抓住这个机会。

一旦你有一个 QA 人员出现，他们就会开始参与进来，他们的测试也会开始受益。一旦一个人看到好处，其他人就会效仿。

因此，简短的回答是与管理层交谈并获得他们的支持。然后接近团队并通过邀请和鼓励他让一个人参与进来。其余的应该遵循。

于 2009-11-21T07:46:56.777 回答
1

我认为 QA 团队应该与开发分开，但要与开发密切合作。

也就是说，我认为让他们更早地参与流程的一个好方法是编写好的规范并将它们包含在流程中。当您着手实施产品时，他们能够将测试重点放在核心部分（因为这些是在规范中定义的），并且能够在开发过程中进行协作。

作为一名 QA 人员，我直接体验了测试具有明确目标且可以理解的产品与需要涵盖的模糊框架之间的区别。

虽然可以在两者中找到错误，但在您知道产品应该做什么的环境中工作会更有趣，也更有价值。

于 2009-11-20T20:07:17.357 回答
1

我在根本没有 QA 团队的环境中工作。只有开发人员也是测试人员。我们编写规范、生产代码、测试、进行探索性测试。我坚信开发和测试是密不可分的。从开发过程的开始到结束测试应用程序会产生很好的结果。但我真的缺乏一个专门的 QA 人员或团队——与我的编码员想法不同的人。他们的角色扮演着我们距离很远的社区。

于 2009-11-20T21:13:07.343 回答
1

我认为这是一个让团队慢慢融入这个过程的问题。我目前工作的地方没有太多流程，QA 被认为是“测试人员”。在以前的公司工作过，QA 与 Dev 相当（薪水也是如此！），我发现这是不可接受的。我开始了执行开发提供的测试以外的测试的趋势，并通过这种方式发现了更多的错误。

但是，你必须小心，因为你可能会与根深蒂固的公司文化作斗争。你可以提倡改变，但最初感觉就像用凿子把冰川变成冰块。

四年后，我现在是 QA 团队负责人，我们的团队需要在所有需求文件上签字。我们会尽可能早地参与进来，大多数程序员和系统分析师都会就变更征求我们的建议。这是因为我们是业务中的通才，可以告诉程序员他们的更改可能会影响哪些其他模块。

我在这个团队中确实拥有的一个优势是，在 QA 工作期间，我还在另一家公司担任过编程职位，并在人们尝试和 BS 我们的团队时提醒他们这一点。但这一切都是非常外交的。

于 2009-11-20T21:56:46.967 回答
1

我对此有相当广泛的感受。我认为 QA 团队应该尽早参与，以便在需求收集阶段可以讨论一些测试的想法，然后在编写任何代码之前形成基线。这也使 QA 能够兼顾他们是否有足够的工作要做，或者他们是否希望看到更多功能来帮助构建各种测试。

如果您想尝试从戴尔·卡内基 (Dale Carnegie) 的著作《如何赢得朋友和影响他人》中进行过渡，有几个关键点：

让人们接受你的思维方式的十二种方法

  1. 避免争论。
  2. 尊重他人的意见。永远不要告诉别人他们错了。
  3. 如果你错了，请迅速而坚定地承认。
  4. 以友好的方式开始。
  5. 从其他人会回答是的问题开始。
  6. 让对方说话。
  7. 让对方觉得这个想法是他/她的。
  8. 诚实地尝试从他人的角度看待事情。
  9. 同情对方。
  10. 诉诸崇高的动机。
  11. 戏剧化你的想法。
  12. 抛出一个挑战。

成为领导者：如何在不冒犯或引起怨恨的情况下改变人

  1. 从赞美和诚实的欣赏开始。
  2. 间接引起对他人错误的关注。
  3. 先说说自己的错误。
  4. 提出问题而不是直接下达命令。
  5. 让对方挽回面子。
  6. 赞美每一个改进。
  7. 给他们一个不负众望的好名声。
  8. 通过让他们的错误看起来很容易纠正来鼓励他们。
  9. 让对方对按照你的建议去做感到高兴。

其中一些比其他更容易应用，但有一些话要解释为什么他们想要更早地参与，这对他们有什么帮助，他们为什么要关心进行更好的测试或帮助制造更好的产品或服务？

于 2009-12-21T22:48:10.643 回答
0

你听说过方法工程吗？使用这种方法，您的 QA 团队可以为您的公司（或开发团队）最终用于每个项目的特定方法（或方法）的设计做出贡献。

它的工作方式是，通过方法工程，方法（学）是从预定义的方法组件构建的，而不是现成的（例如 RUP 或 XP）。如果您的 QA 人员了解倾向于工作的实践、技术和工作产品，他们可以将这些作为方法组件贡献出来，从而参与方法的规范。

于 2009-11-20T20:07:10.503 回答
0

在我们的车间，QA 经理和开发经理是同行，这是建立在尊重和共同目标之上的关系。

您需要强大的、经验丰富的 QA 工程师、学习速度快、能够快速获得结果的人员；或者至少有一位强大的高级人员来领导 QA 团队：能够赢得高级开发人员尊重的人。然后让团队专注于真正的问题，采取基于风险的方法，展示他们的价值：一旦他们在产品发布之前就开始发现真正的问题，那些不应该超越聪明的开发人员的问题，然后动态开始改变。

让 QA 团队和开发团队都参与回顾/发布审查：让他们一起工作，想出改进软件构建和发布方式的方法。

于 2009-11-22T23:34:30.110 回答
0

软件 QA 的角色，该角色验证需求是否符合基本标准（模板），并且需求没有任何歧义。在完整性方面，软件 QA 还将审查未完成非功能部分的风险。软件 QA 还将审查可追溯性矩阵，以确保引用所有需求。

软件 QA 应该分析缺陷的来源并检查 SDLC 以确定缺陷的引入位置（需求\设计或编码），并与流程所有者一起审查这些以寻求可能的改进。

QA 还应该针对现有代码库运行这些测试。这验证了测试工具是否正常工作，并且新测试不会在不需要任何新代码的情况下错误地通过。显然，由于预期的原因，新测试也应该失败。这测试了测试本身，是否定的：它排除了新测试总是通过的可能性，因此一文不值。好的，这是第一天和第二天。

于 2011-01-04T16:54:55.183 回答