如何让QA团队更多地参与SDLC？

Question

我曾在QA团队积极参与从项目开始到维护的开发过程的环境中工作过。我一般认为这是有效的，因为质量保证团队在过程的早期就已经了解了商业前景的变化。他们可以很早就开始研究测试脚本。

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

你对此有何感想？您认为质量保证团队需要参与的过程如何？如何将习惯于“不参与”的团队转变为积极参与该过程的团队？

Answer 1

我赞扬你的目标是尽早让QA / Test参与这个过程。我是一个很大的倡导者，从整个过程开始就一直有一个强大的测试团队参与其中。很高兴看到开发期待包含QA。他们常常对测试的参与有抵抗力。

如果您希望QA团队更多参与，您必须让他们想参与其中。这可能意味着确保他们的管理层看到它的价值，并为他们参与提供资金。一些QA团队有太多的工作要提前参与（或者觉得他们这样做）。这包括质量保证管理。如果他们没有被买进，他们将无法奖励那些花时间与你交往的人。

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

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

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

Answer 2

我认为qa团队应该与开发分开，但与开发人员密切合作。

那就是说，我认为在这个过程的早期让他们更多参与的好方法是写出好的规范并将其包含在流程中。在您实施产品的过程中，他们能够将测试重点放在核心部分上（因为这些部分已在规范中定义），并且能够在开发过程中进行协作。

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

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

Answer 3

我在QA团队缺席的环境中工作。只有开发人员也是测试人员。我们编写规范，生产代码，测试，进行探索性测试。而且我真的相信开发和测试是不可分割的。从开发过程的开始到结束，测试应用程序可以产生很好的效果。但我真的缺乏一个专注的QA人员或团队 - 与我的编码人员不同的人。尽管如此，他们的角色扮演着我们的社区，但是距离很近。

Answer 4

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

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

四年后，我现在担任质量保证小组组长，我们小组必须签署所有要求文件。我们尽可能早地参与进来，大多数程序员和系统分析师都会询问我们对变化的建议。这是因为我们是业务的通才，可以告诉程序员他们的更改可能会影响其他模块。

我与这个团队合作的一个优势是，我在QA工作期间还在另一家公司担任编程职位，并在他们尝试和我们的团队BS时提醒人们。但这一切都是以外交方式完成的。

Answer 5

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

如果您想尝试进行来自Dale Carnegie's book, "How to Win Friends and Influence People:"

的过渡，有几点要点

赢得人们思维方式的十二种方式

1. 避免争论。
2. 尊重他人的意见。永远不要告诉别人他们错了。
3. 如果你错了，请尽快并坚决地承认。
4. 以友好的方式开始。
5. 从问题开始，其他人将回答是。
6. 让对方说话。
7. 让对方觉得这个想法是他/她的。
8. 诚实地从对方的角度来看问题。
9. 同情另一个人。
10. 呼吁崇高的动机。
11. 戏剧化你的想法。
12. 投下挑战。

成为领导者：如何在不给予进攻或激起怨恨的情况下改变人们

1. 从赞美和诚实的赞赏开始。
2. 间接注意别人的错误。
3. 首先谈谈你自己的错误。
4. 提出问题而不是直接下订单。
5. 让对方挽回面子。
6. 赞美每一项改进。
7. 给他们一个良好的声誉，以实现。
8. 通过使他们的错误看起来容易纠正来鼓励他们。
9. 让对方高兴做你的建议。

其中一些比其他更容易应用，但有一些东西可以解释为什么他们希望早些参与，它如何帮助他们，他们为什么要关心更好的测试或帮助制作一个更好的产品或服务？

Answer 6

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

它的工作方式是，通过方法工程，方法（ology）是从预定义的方法组件构建的，而不是现成的（例如RUP或XP） ）。如果您的QA人员了解往往有效的实践，技术和工作产品，他们可以将这些作为方法组件提供，从而参与方法的规范。

Answer 7

在我们的商店，质量保证经理和开发经理是同行，这是建立在尊重和共同目标之上的关系。

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

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

Answer 8

软件QA的角色，此角色验证要求是否符合基本标准（模板），且要求没有任何歧义。在完整性方面，软件质量保证还将审查未完成非功能部分的风险。软件质量保证人员还将审查可追踪性矩阵，以确保参考所有要求。

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

QA还应该针对现有代码库运行这些测试。这样可以验证测试工具是否正常工作，并且新测试不会错误地通过而无需任何新代码。显然，新的测试也应该因预期的原因而失败。这样做是对测试本身进行测试，结果是：它排除了新测试总是通过的可能性，因此毫无价值。好的，这是第一天和第二天。