敏捷开发&质量管理
一、质量管理
1.1 什么是质量管理
百度词条的解释如下：
质量管理是指确定质量方针、目标和职责，并通过质量体系中的质量策划、控制、保证和改进来使其实现的全部活动。
为了能够在最经济的水平上并考虑到充分满足顾客要求的条件下进行市场研究、设计、制造和售后服务，把企业内各部门的研制质量、维持质量和提高质量的活动构成为一体的一种有效的体系。
质量管理是“在质量方面指挥和控制组织的协调的活动”。
1.2质量管理革命
质量管理的第一次革命是建立专门的QC部门。
第二次革命就是建立专门的QA部门。
第三次革命是将所有QA工作转交给所有职能部门（生产、采购、物流、营销等）。
第四次革命就是消灭专门的质量部门，或者说这就是质量管理的4.0。
1.3 质量管理4.0–消灭质量部门
传统的质量管理中QA有三大核心工作（审核、跟踪、总结）与四大角色（律师、警察、医生、老师），但是质量管理4.0则发生变化QA人员角色要从保姆变为教练， 从关注产品质量到关注流程质量。这就会产生一个良好的循环：
当QA人员不再直接参与解决产品质量问题时，开发部门一定会主动承担这样的角色，按照逻辑讲， 开发人员应该比质量人员更知道问题所在。
而当开发主管也开始关注优化流程时（QA的角色），质量部门的QA就可升级到QM的角色，即关注质量管理体系的框架设计是否合理，是否需要对各个体系进行整合。
而质量人员的使命就是消灭质量部门，这似乎是一个悖论，但实际结果就是这样。
当产品质量控制由生产人员承担，业务流程的优化是由各个职能部门负责，那质量部门就该寿终正寝，这需要质量人清醒认识到这一点。
二、敏捷开发&质量管理
对于敏捷开发不在此进行讨论，有在另外一篇中进行分享
首先需要理解不论是敏捷开发还是瀑布开发，质量都是一个研发团队需要关注的，质量管理也都是要进行的。任何一个不关注质量的团队，是没办法长期发展的。
2.1 敏捷开发与质量管理的关系
敏捷开发关注敏捷，快速响应变化，减少互联网发展带来的影响;
质量管理关注质量，确保产品质量，带来长期效益。
两者表面看起来是没有什么关联关系的，但是其实两者之间是一个互补的关系。质量管理为敏捷开发提供敏捷基础，敏捷开发为质量管理提供文化传播。怎么理解？
敏捷开发关注快速响应，但是长久的敏捷才是真正的敏捷！
如果为了实现敏捷闷头迭代向前冲刺，一段时间之后就会发现有很多瓶颈。例如：新类型的需求系统架构不支持，需要系统重构;为了快速响应、迭代上线，开发忽略了单元测试、测试忽略覆盖率，线上问题很多。质量管理就是为敏捷开发提供基石，让敏捷开发长期的快速前进。
2. 质量管理的重心思想是消灭质量部门，将质量变为所有人关注的问题。
敏捷开发是需要所有人参与的，通过敏捷开发将所有人召集，对于贯彻质量管理的思想无疑不是一个更好的途径
2.2 敏捷开发中如何做质量管理
上面提到质量管理4.0的时代已经开始，需要将敏捷开发与质量管理4.0结合
这里我想起之前整理’测试左移‘时的两点“质量上限、质量下限”
如果将敏捷开发看作“车”，质量管理看作“路”，那么团队要做得事情就是”把车开到目的地“
确定并遵守质量下限
明确质量下限就意味着，无论事情做得多糟糕只要满足质量下限，就可以认为产品是合格的。
跟敏捷开发结合起来就是，严格遵守质量下限的基础上快速响应，即提高了响应效率又保证合格的质量。就像只要“路”存在，“车”就可以跑起来。
不断挑战质量上限
挑战质量上线，就是通过更好的方式让产品的质量输出更好
跟敏捷开发结合起来就是，提高质量上限就像把“石路”变成“柏油路”再变成“高速路”，这样“车”就可以换成“跑车”，让敏捷变得更敏捷。
质量管理不要成为敏捷开发的累赘
为特定的“车”提供合适的“路”即可。团队的精力是有限的，既要“开车”又要“修路”，当”车“还是”奥拓“的时候没有必要为他修一条”高速公路“，如果把精力全部放在”修路“上反而没有精力去”开车“，毕竟”车到达目的地“才是重点
敏捷团队的所有人都要参与质量管理
”车“和”路“都有了，但是把“车”开到”目的地“还早，小心“路上有坑”！
敏捷开发提供了快速的工具，但是它毕竟只是工具，真正的完成目标还需要注意过程。
2.3 敏捷开发中质量人员的角色分配
传统质量管理角色（QC、QA和QM）
根据质量管理4.0的终极目标“消灭质量部门”，是不再需要质量人员的。
但是实现这个终极目标是需要进行很大的前期工作的，所以QM、QA、QC人员在这个阶段仍然是不可或缺甚至说很重要的，他们需要向着“消灭自己”持续奋斗
QM职在建立敏捷质量体系，需要真正理解质量管理、敏捷开发，定义质量体系结构。必要时QM可以扩充为一个组织（包括boss、总监、各级主管）
跟质量上限是一样的道理，QA人员通过质量文化传播、不断改进等方式为团队带来质量上线的不断提升。
同样QC人员通过功能测试、探索测试等方式为团队提供质量下限
其实敏捷开发中的质量人员角色，相较于上图的角色定位都向前迈出了半步。QC需要做一些QA的工作，QA需要掌握QM的基础，QM由部门走向全员组织。而最基础的QC检验即将被淘汰，所以说敏捷开发中
如果你将自己钉在 传统QC的位置上，基本上死定了。
如果你将自己盯在 QA，那么可以提升自己的系统思维方式，让你对质量有比较清晰的认识。
如果你将自己定在 QM上，你将是质量体系的组织者
三、敏捷开发&QA
3.1 敏捷开发&QA
敏捷开发需要团队对软件产品的质量负责，而不是某个带有QA头衔的特殊人员。敏捷中的QA可以是参与敏捷开发的所有团队人员，而并不一定是特定的专职的测试人员。但是当没有团队人员主动负责时，仍然需要有人带头进入这个角色，测试负责人是最合适的人选。
那么QA人员在敏捷开发中可以做什么？
协同确定质量下限
协同确定敏捷流程
敏捷开发并不代表着没有流程，只是将很多效益很小的环节变为面对面沟通，减少大量不必要的时间浪费。QA需要做的事情就是参与整个敏捷流程的制定，识别必要环节进行保留，保证过程质量
协同确定各环节输出标准
(1)敏捷开发可能会使产品人员去掉MRD文档，但是PRD文档是不可或缺的，对于PRD的输出还是要有一定标准，保证产品环节流入研发环节的质量
(2)敏捷开发提倡TDD、BDD等开发模式，目的就是因为开发人员更了解自己的代码，通过让开发人员自测的形式提高提测的质量，以达到适当减少集成测试时间的目的。通过对单元测试覆盖率、通过率等标准的制定，保证开发环节流入测试环节的质量
(3)测试人员作为产品的最终守护者，是面向用户前的最后一道质量防线，更要有严格的准出标准满足产品的合格。
(4)运维人员作为部署者，需要执行系统包的上架、数据库的割接等等事项，面向服务器的直接部署同样需要上线标准较少人员失误带来的部署问题
保证质量下限
对于制定的一些标准仍然需要监督遵守，毕竟人总是喜欢偷懒的，没有一段时间的监督是没办法让所有人自觉遵守的。所以QA要监督团队的质量下限遵守，让所有人慢慢养成习惯才可以
必要的时候QA需要充当Scrum Master的角色，参与敏捷流程各个环节引导团队成员正确前进，以达到提升质量的作用
发现风险，提出关键建议
QA参与整个开发流程，对系统整体的认识和把握可以说是团队里边最全面的。也更容易发现各个环节潜在存在的风险，提出并持续关注
参与整个开发流程，对于产品、开发、测试、运维环节的计划等，站在质量人员独有的视角提出一些关键的意见
传播质量文化，鼓励挑战质量上限
QA参与整个开发流程，不可必然的需要同每个环节的人员沟通交流，QA需要在这些交流中不断的传播质量文化
QA需要在传播质量文化的同时，也要鼓励团队人员挑战质量上线。
数据统计，持续改进
数据统计，这是QA必须掌握的一项技能。要主动寻找统计对象，通过不同的统计数据进行分析，发现敏捷开发、产品等等存在的问题
持续改进，将参与开发流程、数据统计发现的问题，组织进行持续的改进，让整体质量不断提升
3.2 敏捷QA，你需要具备哪些素质
不爱说话？别做敏捷QA了
如果你之前是安安静静专心找软件缺陷的工作模式，那么进入敏捷团队你可能会经历很长时间的不适应。因为敏捷QA不能被动地等待软件完成交到你手里再做测试，不能发现缺陷后不管不顾等着开发人员自发地去修复。你需要从软件的源头开始介入，在软件的整个生命周期中全程参与。
心态不好？趁早放弃
不知道你是否经历过这样的场景，在某些小餐厅等位严重的情况下，你需要站在某个快要结束用餐的客人边上等空位，而有些人却可以在用餐结束后无视旁边焦急等待的人群一直占着座位专注地聊天。虽然这种行为不是很好但也无可厚非，换个角度想，这种人的心理是非常强大的，因为很少有人能够不顾及别人而我行我素，而这种“能力”对敏捷QA是非常有用的。
如果处处顾虑别人的想法，会让你左顾右盼、思前想后直接影响你的判断和决定。
对PM、业务、代码、架构没兴趣？敏捷QA不适合你
敏捷QA需要对整个系统以及业务足够熟悉，这样才能从QA的视角帮助业务分析师和团队发现业务不合理或者缺失的部分。
另外如果可以具备一些编码能力，对于做敏捷QA也是非常有帮助的。当然，术业有专攻，并不要求每个QA都会写代码，但是要对代码有一定的兴趣，愿意听开发人员讲解他们的逻辑和实现，并通过提问题了解他们的思路。
不会管理工作的优先级？做敏捷QA很难
敏捷QA最大的挑战是，每时每刻都同时工作在很多事情上，敏捷QA需要全程参与开发流程跟很多人进行沟通，时刻关注风险等等。管理自己的工作任务、划分优先级是必备素质
四、敏捷开发&测试
敏捷开发与测试的关系，不得不提到敏捷测试，
敏捷测试的理解建议阅读你确定你懂什么是敏捷测试
4.1 敏捷测试&测试
敏捷测试中测试人员需要做什么？
分析用户需求，代理PO(产品负责人)
在敏捷开发中PO责任重大，但是PO也会有繁忙、遗漏的时候，敏捷测试人员必要的时候要充当PO代理，帮助产品负责人补充、细化需求、完善用户故事等。
测试人员面向的对象是产品，想要真正保证产品的质量，对于需求的理解是最重要的。
不仅是编写测试用例，测试需求(定义质量)
敏捷测试不仅需要编写测试用例，还需要测试能否完整理解产品需求，根据产品需求转化为测试需求，根据产品需求点转为为测试点。
对于测试进行需求化管理，站在研发的角度转换测试需求，更利于业务需求的澄清，让开发、其他测试人员对于需求有更深入的了解。
同时测试需求的转化，也是对于质量的定义。在测试需求转化过程中必定会加入测试要求，这不就是对于需求质量的定义嘛
保持质量视角，参与过程评审
敏捷开发流程中会有一些必要环节的评审，例如需求评审、设计评审等等。作为敏捷测试人员不仅仅是要参与这些环节，而是要保持质量的视角发展问题，例如需求是否不闭环、概要设计是否不完善、需求是否不清晰、设计是否不可测等等。
与客户和开发者紧密合作
根据工作性质，作为团队第二位对需求最了解的人，测试人员需要定期或经常与客户（业务）沟通合作;并且作为需求二次转化者，你同样需要跟开发者紧密合作。
发布演示(UAT验收)等环节，建立了一条让测试人员与客户（业务）沟通合作的通道，要好好把握沟通渠道，直接的沟通可以让你对需求更加了解
测试需求的评审、开发过程需求的问题，都需要测试人员与开发者进行紧密的合作，让需求讨论、问题定位变得快速简单
提供快速反馈
敏捷开发提倡快速沟通反馈，对于测试人员也是一样的。快速反馈系统存在的问题，以便于图啊对快速做出应对。
例如重视冒烟测试，快速验证系统是否可执行，避免测试工作无法进行浪费时间;根据更为详细的测试需求，快速检查验证是否有开发遗漏，尽快进行补充;测试遇到的问题，快速反馈进行解决;测试进度快速反馈，提醒运维人员提前准备介入等等
用测试策略规范测试
前面对于敏捷开发中质量人员角色的定位，测试人员要保证质量下限。那什么方式可以让测试人员保证质量下限，人员素质是一个重要因素，但是你并不能保证所有测试人员的素质都可以快速提升，这个时候规范的测试流程就是最根本的保障。
测试策略是一个很大的课题，推荐阅读刘琛梅老师的《测试架构师修炼之道》，对于测试策略有较深入的讲解，我对于这本书也有进行过一次阅读分享
测试者和分析者角色融合
敏捷测试中需要测试人员将测试者与分析者融合，站在测试角度分析需求合理性、站在测试角度分析系统可测性等。
分析者习惯将问题解剖，而测试者会带着“挑剔”的眼光审视问题，两者的融合不就是将问题解剖发现内在的“缺陷”嘛
掌握探索测试(合适的探索性测试)
首先需要理解探索性测试，探索性测试简单理解就是在功能测试完成后，根据系统逻辑不断探索边界，逻辑的边界、部署环境的边界、系统的边界等等，去发现更多的问题。
合适的探索性测试，探索性测试并不是没有规律的盲测，它一样需要规律条件刘琛梅老师的《测试架构师修炼之道》也有提到这一点。
不要陷入探索性测试，你的底层基本功能都还没有测试完成就去探索，那将没有任何意义
自动化回归测试
敏捷开发提高的是效率，而对于测试人员而言一样的需要提高效率，将大批量的旧版本旧需求的回归自动化，不久节约了大量的时间可以用来进行新功能、新需求的探索性测试了吗？但是请记住敏捷开发中的自动化测试同样讲究的是效率。
而对于UI自动化，建议跟前端配合将页面元素id规范化，共同制定一套id规范才有利于UI自动化的维护，PO模式确实也是是很好的选择
相对于UI而言，接口可能更适合先进行自动化，同样可以借鉴UI的PO模式管理，减少维护成本
BDD(题外话)
很多公司会引入TDD开发模式，先写单元测试在写代码;如果在TDD做好的情况下，可以继续进入BDD，针对于业务需求白盒可能比黑盒可能更能发现问题，毕竟直接调用内部函数比调用整个系统发现的问题的可能性更大。
————————————————
版权声明：本文为CSDN博主「小冯先生」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/baidu_36943075/article/details/100546829