我已经与多家公司合作，其中质量检查团队被视为开发团队的一部分，并且质量检查团队参与了开发过程中的大多数活动。
但是现在我在一家公司工作，他们分开质量保证的工作，他们认为质量保证不是开发团队的一部分。从那时起，我与负责项目管理的项目协调员进行了一些辩论，他的想法是应单独评估质量保证。
详细信息是：开发团队（BE，FE，UI，PO）通常会开会讨论不邀请质量保证的过程和流程。质量检查仅被邀请参加每个冲刺的冲刺计划，而不被邀请参加项目的概述会议或过程。有时我会在会议上看到整个团队，然后我问PO为什么不邀请QA，PO说团队讨论了与QA无关的票证和流程！他们正在讨论该项目，因此质量检查无关紧要！我无语了。
让我抓狂的是，在规划会议上，只有BE和FE才被允许评估和跟踪JIRA中的工作。在计划之后，他们分别询问质量检查人员的工作并将此工作量估计写在票证中作为评论！如果质量检查还跟踪JIRA！中的估算和工作时间！我还收集了质量检查团队的反馈，并与CTO进行了讨论，CTO也同意项目管理存在问题，我们应该与项目协调员进行讨论。但是当我们开会时，这位项目协调员说服了首席技术官，她在做什么是对的！然后，什么都没有改变或改善。
因此，当质量检查团队的工作不受到赞赏时，我就会失去兴趣。某些专家能给我一些关于该主题的想法或建议吗，对与错？在此先感谢
#1 楼
我的前客户经历了非常相似的事情。当我开始时，没有邀请质量检查人员参加演练，项目会议，冲刺计划，日常站立等，而开发人员正在估计进行质量检查的时间！真的无法相信。我们最初的观点是，开发可能需要一天的时间才能生成修复程序，但测试可能需要四天的质量保证-质量保证专家是专家，不应浪费测试时间对其他人来说。
因此，我们达成了一项协议，我们能够以观察员的身份参加站姿，冲刺计划和回顾展……这只是意味着我们会坐在角落而不是参与进来。
公司意识到他们对项目工作或修复需要多长时间没有真正的了解。他们只知道开发需要多长时间。开发（和项目经理）需要学习和理解，但是慢慢地，他们开始向质量保证部门征求意见和建议，因为我们就在眼前。我们还着重指出了尽早发现缺陷的成本（PM往往会在节省成本时意识到这一点！），并就提高缺陷的重要性（甚至在静态测试中）进行了介绍。开发人员只需要知道对他们的工作进行票证并不是个人的。
几周后，参与质量检查就成了他们的第二天性。
无论如何...当我离开时，QA是开发团队的一员，并应邀参加了所有工作（即使我们认为还为时过早！），尽管我们把时间分配给了开发人员，肯定取得了进步，我们的吞吐量得到认可！我们是所有会议的积极参与者，开发团队认为我们的意见具有建设性。
TL; DR：请求观察您被排除在外的讨论。随着时间的流逝，您会参与其中。
（顺便说一句，对论文表示歉意），不跟踪您的时间可能对您有利，因为企业无法询问您的努力方向。这对他们来说很危险，但是如果您想放松一两天，对您来说并没有那么糟;）
评论
谢谢丹，我发现自己处在确切的境地。质量检查人员参加了每日Scrum和Retro，但正如您所说，质量检查人员更像观察员。问题是，我们所有的建议，更改/改进的建议都没有被听到，这很消极。如果不考虑我们的反馈意见，我不知道如何改进。
–拉格纳森
17 Mar 9 '17 at 12:43
路易斯，工作是提供最佳反馈。如何处理此反馈是项目/应用程序经理的问题。对于大多数公司而言，目标是赚钱，而不是生产最优质的软件:)
–乔治
17 Mar 9 '17 at 13:32
乔治，是的，我同意业务目标。但是从质量保证的角度来看，我们始终希望确保软件的质量能够满足任何利益相关者的需求；）。
–拉格纳森
17 Mar 9 '17 at 14:32
#2 楼
我去过那儿。这是我的经验：开始-查看您获得的所有文档。可能是一件好事，而一些关键的事情却被忽视了，因为项目经理倾向于只专注于他们的项目，而开发人员倾向于专注于他们正在开发的工作。测试人员通常具有广阔的视野。这里的关键是，每次遇到监督时，您都会及时跟踪纠正该监督的成本。它不一定要非常准确，只需几天就可以估算出来。重新考虑。在教育其余业务的这一阶段，如果重新考虑使程序员不得不重新编写代码以解决疏忽，这是一件好事。一旦发生一两次，您会发现他们接受这样的想法，即在开始编码之前发现这些差距会更好。有证据支持的时间：您可以指出费用和给公司带来的不便，无法尽快获得您的意见。您还应该得到开发人员的支持，因为我还没有遇到一个开发人员，该开发人员由于监督而不得不重做一半的项目。高层管理人员说和听到的语言就是金钱，而返工就是浪费金钱。
以上都保持礼貌和专业。高层管理人员的确注意到谁在以专业的方式行事，而谁没有。
评论
这是个好建议。总之，找到尽早交付价值的方法，PO /团队将开始重视质量保证。
– jruberto
17 Mar 9 '17 at 15:58
谢谢凯特的建议。我实际上已经尝试过上述建议，甚至与CTO进行了交谈，但是...我不知道，这里的情况很奇怪，这就是我能说的。就像高层管理人员一样，人们从未听说过来自团队（不仅是质量检查团队）的反馈。我们可以继续尝试通过某种方式使事情变得更好：）
–拉格纳森
17 Mar 10 '17 at 9:42
@LouisT-我花了一年多的时间来说服我的经理们，他们确实确实需要更早地参与我的工作-我不得不让多个大型项目进行重新设计，然后我的经理们才真正意识到我拥有的技能不仅仅是检查开箱即用的事情：很多经理都认为测试不是熟练的职业道路，并且通常是那些不知道为什么测试人员应该在项目生命周期的早期参与的人。
–凯特·保罗（Kate Paulk）
17 Mar 10 '17 at 17:48
#3 楼
当您的问题被标记为Scrum时，我将尝试在该上下文中回答。它以Scrum的Done定义开头：
或将增量描述为“完成”，
每个人都必须了解“完成”的含义。尽管每个Scrum团队的情况差异很大，但是成员必须对完成工作意味着什么有共识，以确保透明度。
是Scrum团队“完成”的定义，用于评估产品增量完成的时间。
我希望工作能够完成还要经过测试才能完整。因此，这意味着开发团队应该在完成之前完成测试。因此，质量检查是开发团队的一部分，或者是开发人员进行测试。选择一个。
Scrum不认可开发团队中的任何子团队，无论
诸如测试或业务分析等需要解决的特定领域如何；该规则没有例外；
结论认为测试应该是估计的一部分，因此，如果QA进行测试，则它们应该是计划的一部分。现在，我知道这可能会使您的速度统计信息产生偏差，但是如果您以相对复杂度（理论点）进行估算，则应该不会有太大差异。还想知道这些统计数据是否真的有价值，肯定是内部开发的结果。
适当地调整“完成”的定义。
希望在回顾展期间能得到您的咨询，因为质量检查人员最好建议我认为可以提高质量。 />
ScrumBut：
总的来说，听起来您的公司不是在做Scrum，而是在做ScrumBut。真正的Scrum公司没有独立的质量检查部门。作为Scrum Master的前项目经理是最糟糕的！ （如果您问我，应该在《 Scrum指南》中禁止这样做。）
下一步：
加入团队的每日Scrum。这应该是一个公开会议，只是在会议结束之前不要讲话。也许在《 Dialy》之后提出一些关键的测试问题。或者聘请一位了解完成定义的敏捷顾问，该顾问可以说服您的项目协调员看到新的曙光。有人会挑战现状，并希望能比现在更好地实施这一过程。如果您不能更改组织，请更改您的组织！”
最后请记住，这与产品质量有关。如果当前的程序可以运行并提供高质量的软件，则可能就足够了。要么接受局势，要么继续战斗。最好的斗争是保持安静地向每个人重复您的愿望，直到他们实现。文化变革可能需要长达三年的时间，请准备好喘口气。
评论
我从未见过或在真正敏捷的地方工作过-因此，我喜欢ScrumBut的想法（和声音）：)
–trashpanda
17 Mar 9 '17 at 11:24
我有。 :)我不明白为什么团队只实施Scrum的一半。在实践了大约一年并真正了解它之后，才开始更改框架。 ScrumBut更好地命名为ScrumAnd，但请阅读：kenschwaber.wordpress.com/2012/04/05/…
– Niels van Reijmersdal
17 Mar 9 '17 at 12:31
感谢尼尔斯的解释。我了解ScrumBut。谢谢 ：）。作为质量检查人员，我们也参加了每日Scrum和Retro会议。正如您说的那样，“质量检查人员最好建议我想改善质量”，但是碰巧在我公司，Retro的质量检查就像观察员一样，坐在角落里（丹的回答）。在一个Retro BE和FE中，他们说他们在ABC上有问题，我本人建议进行一些改进，团队同意并在Sprint下一次做，但是他们没有，因为项目协调员说这样做的方式已经足够好了。而下一个Sprint，他们也遇到了同样的问题！
–拉格纳森
17 Mar 9 '17 at 12:40
“我希望工作也能通过测试就可以完成。” -如果测试发现很多错误，工作是否“完成”了？如果第一个错误非常严重而实际上无法测试，该怎么办？
–乔·斯特拉泽（Joe Strazzere）
17 Mar 9 '17 at 13:28
@NielsvanReijmersdal我认为这取决于ScrumBut还是ScrumAnd更合适。大多数情况下，公司喜欢scrum的想法，但是有些事情他们不喜欢，所以将它们排除在外。对我来说就是ScrumBut。 ScrumAnd将实现所有Scrum组件，但将其中一些更改为“适合公司”。再说一次，我是一个绝望的学徒。
– Cronax
17 Mar 9 '17 at 15:42
#4 楼
最大的问题是人们的看法，那就是需要改变的地方。有一些障碍需要克服。有很多合乎逻辑的立场，但通常是个人价值和个人偏见之一。我曾在多个项目/公司的Scrum团队的所有部门工作。开发人员更像是艺术家，创作别人只希望自己创造的东西。只要维持这种观点，质量检查就会成为敌人。这也是反团队合作，通常一个人的自我价值参与工作。 PO无法执行开发人员的操作，因此他们主要依赖于PO进行所有输入，以确保产品正确完成，这也是防团队合作的目标。开发人员作为对等方。有了适当的设置，其余的工作就可以自己解决。我已经通过多种方式做到了这一点。每个缺陷对编写代码的开发人员都是不利的打击。 （这听起来是敌对的，但是当您自愿在过程中尽早介入以避免可能的缺陷时，开发人员现在将您视为朋友而不是敌人……如果他们拒绝在测试过程中重击他们，他们通常不会长期保持这种立场-要求管理层强制执行负面命中。）
由于暴露了管理层决定不修复的错误，直接降低了客户满意度。 （这将奏效，但也有最大的潜在后果会再次出现在个人头上……尽管由于财务上的回击最终管理层将不得不拥有它，并努力解决产品中的质量问题）通过每天多次访问开发人员的办公桌来询问即将到来的功能及其计划/设计的非常“具体”的问题，可以成为最烦人的参与者（半个小时的时间只是为了让您不再困扰别人，然后您就有机会展示您的价值-如果Scrum管理员介入并说停止，那么只需转到SM向您解释一切...最终有人会包括您-获得所有质量检查，而不是只是您）
更好：说服您努力工作的人...不幸的是，人们常常需要“体验”质量保证的价值才能理解它。为每个人设计一种体验性方法，以从您的角度来看待他们，并为您的工作带来价值。这是具有挑战性的，但是它将帮助您提高整体人际交往能力，并在团队合作过程中更好地表达自己的价值。您还将帮助一次重塑整个团队1个人。这不是关于操纵，而是影响。寻找一种方法，通过包括您在内来帮助某人看到自己的工作和工作所获得的收益。这可能需要您更多地了解他们的工作以及与他们成为朋友。如果您说开发人员的话，那么它往往会在被人们听到并被包含进来时变得更远。
评论
谢谢。我从字面上看喜欢您的答案，尤其是关于开发人员是艺术家，而PO依赖他们的部分，这是如此反团队精神。在我的情况下，您所说的都是如此。
–拉格纳森
17 Mar 10 '17 at 9:50
#5 楼
在我从事的项目中，开发团队有一个测试团队，该团队根据需求创建了单元测试，并与编码人员进行了交谈。但是，除此之外，质量检查小组还坐在大楼的另一部分，流程有所不同。区别是白盒测试和黑盒测试。想象一下您的测试人员参与了开发过程，他们知道开发人员正在改变鼠标在屏幕上画线的方式。他们提出了一项测试，以确保线条的颜色和长度正确。但是，他们专注于更改而忘记了连锁效应，例如：撤消堆栈如何？
这里应该进行黑匣子测试，并说“发生了变化，我应该寻找什么？”。质量保证不应被开发过程所困扰，而应在阅读需求时对其进行解释。这种双重检查可以提供质量。一般而言，如果质量检查人员发现问题，则会对开发团队造成严重影响，因为他们没有首先注意到它。只有高级经理才能出于业务需求的目的绕过质量检查。这种反馈循环使开发人员对他们的代码和估计非常谨慎。这是一个独立的质量检查小组的重点。 > https://stackoverflow.com/questions/402161/black-box-vs-white-box-testing
http://softwaretestingfundamentals.com/differences-between-black-box-testing-and-white-盒测试/
评论
老实说，测试人员与开发人员对比以及完成文档的测试听起来很可怕。
–乔治
17 Mar 9 '17 at 21:05
评论
您认为在所有这些会议中加入质量检查有什么好处？谁是质量检查的“老大”，他为什么不为测试流程而战？取决于公司对公司；请参阅在每次会议和讨论中，都不需要包括质量检查团队。但是，尽管Sprint计划至少要有一个QA（QA负责人），以便他/她根据已决定的计划来推动自己的团队。
是的，我认为问题应该是“我提出的改变实际上会改善什么？”。我认为它的公司，产品，团队特定。没有人愿意因为“仅仅因为”而改变事情，但是，如果可以看到明显的好处，那就大不一样了。
关于关闭黑手党的注意事项：这个问题并非微不足道，但显然与QA生活有关，这很有趣。已发表。
请原谅我，但这看起来更像是一个棘手的问题。背景对于最终的问题无疑是有用的，但就目前的情况来看，我看不到任何背景。