解体
真实的故事。
那是一次痛苦的分手。我以为一切都很顺利，但是"不是你的问题"她说"是我的问题" ....就这样，我们的关系结束了。
我真没想到会这样。我们在一起工作了很长时间了。
真的吗？真的，我说。你不再需要qa？
她继续解释说，随着她的团队在构建软件方面做得越来越好，整个团队对质量有了更多的所有权。他们现在的节奏相当一致，每两周就会发布经过测试的软件，这与过去QA测试周期所需的时间差不多。她说:“我们现在发展得太快了。”
起初我是不是令人难以置信的。每个人都需要质量保证！QA是一个重要作用！你不能只是抽出代码，并希望它足够好。客户将为我们表示责合。起初，我以为她在说什么是荒谬的，但她解释的越多，就越开始有意义。几年前，她的团队已经开始测试驾驶发展，现在他们对整个码比具有非常高的信心。“这是一个团队优质的事情”她说。
他们的质量指标与任何其他团队相提并论。它们一直生产90％的自动化测试代码覆盖范围，包括代码分支。代码审查确保所有内容都被覆盖，并且在减少该覆盖范围时，他们都有自动工作。最终，他们几乎没有进入生产的缺陷;有一些最好的代码。它们还具有自动验收测试，UI测试和负载和性能测试。它们非常自动化整个测试金字塔。
测试驱动开发(TDD)只是一个开始。在程序员进行测试驱动之后不久，QA人员就开始在Selenium中自动化UI测试。为了了解他们是如何做到这一点，他们一直与程序员配对，他们在团队中的关系是我的QA团队中最好的。在那之后，他们开始使用cucumber berjvm与业务分析师和产品负责人一起构建行为测试。亚博vip9通道这个团队的开发速度比其他团队都要快，我几乎让这个团队在自动驾驶仪上运行，因为他们似乎从来没有遇到过同样的问题
其他队都有。
“我们不再有一个QA认证循环”。“我们已将其重命名为”团队验证“，因为整个团队在我们演示之前进行测试”。她继续下去。“我们还取得了探索性测试的所有权。整个团队每周都做探索性测试，这确实是QA人们一直在大帮助的地方。“
“所以你确实需要我们”我说。“哦，是的”她说，“你的人民很棒，但让我解释一下。我们仍然需要我们可以得到的所有优质专家。只要他们致力于球队，致力于继续学习，并每天留在团队中“。
她看着我说:“我们不需要的是过去所有的管理监督。”
我开始明白了。我意识到她还是想要高质量的。事实上，她比公司里的其他任何团队都更注重质量，我们是一个庞大的公司。她倡导的是一种其他队伍只能希望复制的水平。
她继续说：“如果我们能够”，我们想保留你的一些团队成员。“你是什么意思？”我说。她继续......“你的大多数团队成员都接受了我们所介绍的变化。他们喜欢测试自动化，学习和我们现在如何生产质量的协作性质。那些人在我们的团队中有一个地方。“她继续前进，“QA伙计们真的采取了探索性测试的领导力。我们希望保留它们，因为他们看到了不同的事情。他们寻找异常和边缘案例，他们真的帮助团队排出我们需要的测试的所有方面。“
当然，这个团队真的很重视敏捷采纳和自组织。他们真的是团队合作的缩影。他们不像流水线一样，将工作从一个角色传递到另一个角色。通过有组织的交叉培训和结对，他们消除了团队空间中特定角色的许多限制。对于几乎任何任务，大多数人都可以与别人配对，如果他们自己不能完全完成任务的话。
“但我们现在快速移动，作为一支球队”她说。“And I guess what I’m saying, is that we want to keep your folks on the team and…well, there’s still a lot more that I can go into, but the short answer is…We just don’t need a QA Lead anymore.”
我是嵴。从她的角度来看，分手并不痛苦。痛苦都在我脑海中。我意识到，自组织团队不需要作为传统团队的管理。整个团队现在拥有质量，我想，从长远来看，这将是一件非常好的事情。
评论(10)
加里
伟大的帖子。我喜欢QA成员成为团队中组成部分的方式。在许多地方，我工作的地方，QA总是被视为外部影响力，当用它结束的DEVS时被递给了代码。在他们说的情况下围栏。根据您说，QA成员应该是建立软件的团队的一部分，他们找到了边缘案例和DEV团队有时会忽略的其他事情。
汤姆教堂
我很高兴你喜欢它。将QA人民融入团队的整合在一夜之间没有发生过夜，但对于整个团队来说都是必不可少的，也是为了自我持续增长。移动质量留下了......即在游戏中更快地获得QA的方式......是/真的是每个团队都需要工作的方式。QA人们有必要的技能，并且他们越早涉及和合作，更好。
鲁珀特Schmidtberg
伟大的文章汤姆。许多团队认为他们是敏捷的，因为他们有backlog，正在使用Scrum或看板。您的文章强调了自组织团队、强大的技术实践和支持基础设施对实现高性能的重要性。谢谢你的分享。
汤姆教堂
谢谢鲁珀特
我同意。敏捷更多的是一种技能，而不是任何仪式。不要误解我的意思，团队必须从某个地方开始，但是您是对的，标准需要围绕自组织、工作测试软件和支持团队工作的整体环境设置。
凯文
谢谢分享你的经验!
我同意：“我们只是不需要QA铅。”
如果他们拖慢了进度，增加了官僚主义，与其祈求上帝保佑敏捷性，不如移除他们。
我同意：“我们不再拥有QA验证循环。”
=>测试应该是左侧，测试仪。我看到在集成之前的测试比验证和验证更好（AKA。浪费时间）。
我不同意：“他们非常自动化整个测试金字塔”......“它们一直生产90％的自动化测试代码覆盖率”
=>测试金字塔是一个很好的模型，但它可能误导人们专注于数量（覆盖，失败/通过）并缺少真正的风险。编程检查仅适用于“已知区域”，但不是“未知”区域。完全测试覆盖率不等于质量，从来没有。
我不同意:“QA ==质量保证…”
至少对我来说，我正在做QA ==质量援助
感谢阅读和回复Kevin-
他们的测试最肯定是“左移”测试方向。谢谢你的放大。
此外，我看到了你对完全测试覆盖的看法没有等于质量保证。测试金字塔只是使用/用于确保质量且甚至防止检测质量问题的练习和工具星座的一小部分。我的意图不是为了尽量减少整个练习星座。
此外，QA ==质量保证。我喜欢你的优质援助姿势。单词重要和该术语反映了团队关系周围的更好方向。
感谢您的反馈意见。
:-)
TC.
伊姆兰
令人印象深刻的......最令人印象深刻！
汤姆教堂
他们是一支伟大的球队。我之所以说“是”，是因为我已经不再和他们一起工作了，但这些人仍然在那个团队中，这个团队仍然很出色。
担
哈哈! !在一篇文章....中有这么多关于软件测试的误解这一切是多么愚蠢，我的头快要爆炸了!
一些友好的建议:通过自动断言检查已知的期望只是测试的一部分。这并不是所有的测试。我建议您了解测试的更大部分，这是关于调查未知和发现关于软件/设计/软件思想等的信息。
我同意全团队股份有关质量的责任 - 该信息是真的，但有很多测试活动，有些人需要比其他技能彻底不同。如果您希望您的产品成功，您需要快速摆脱“自动化它”误解。
汤姆教堂
嗨dan-
感谢您的回复。
我很感激你的真诚。
我希望你能够实现一年又一年成功推出新产品，按时、不超出预算、无缺陷。他们真的很了不起，但你是对的....这是一款旅程游戏....我们都有更多的东西要学。
:-)