查询建设工程规范的网站,天猫商城买卖平台,珠海做网站的公司有哪些,百度问一问官网读完需要26分钟速读仅需 9 分钟本文首发于个人网站「BY林子」#xff0c;转载请参考网站版权声明。#x1f440;00 引言测试人员缺乏体系化思维#xff1f;新建产品团队或者新启项目#xff0c;如何系统化地测试#xff1f;组织级如何构建统一的测试体系#xff1f;1. 三… 读完需要26分钟速读仅需 9 分钟本文首发于个人网站「BY林子」转载请参考网站版权声明。 00 引言测试人员缺乏体系化思维新建产品团队或者新启项目如何系统化地测试组织级如何构建统一的测试体系 1. 三个层次聊测试体系大家都接触过不计其数的测试、质量方面的文章或者培训课程内容不乏测试实践、技术相关但是却很难构建自己的测试体系。基于很多朋友类似的困惑结合本人多年的团队实践和咨询经验从基础篇、进阶篇和高级篇三个不同的层次来跟大家探讨测试体系化思维的构建。《构建测试的体系化思维基础篇》《构建测试的体系化思维进阶篇》《构建测试的体系化思维高级篇》 2. 基础篇和进阶篇内容回顾2022 年 1 月发布了《构建测试的体系化思维基础篇》后文简称《基础篇》从测试的五个基本职责出发围绕这五个基本职责介绍了相应的实践活动和方法集。理解和澄清业务需求制定策略并设计测试实现和执行测试缺陷管理与分析质量反馈与风险识别3 月发布了《构建测试的体系化思维进阶篇 》后文简称《进阶篇》跳出测试从软件质量的角度来看体系化思维的构建。从测试到质量跳出测试从质量维度来看测试的体系化建设。质量保障与质量内建质量是产品与生俱来的质量内建才是保障质量的根本。质量内建深入实践质量内建如何落地是大家最为关注的问题深入质量内建实践介绍供大家落地实践参考。 3. 高级篇内容概要本文为高级篇将从组织级别来看测试体系化思维的构建。从团队到整个组织跳出产品/项目团队从整个组织范围来看测试的体系化建设。组织级测试体系图谱基于“一个中心四个方向”图谱全面探讨组织级测试体系建设。组织级质量赋能根据测试体系图谱从组织级层面对整个组织进行质量赋能。 01 从团队到组织跳出产品/项目团队从整个组织范围来看测试的体系化建设。 1. 为什么要从团队到整个组织在《基础篇》中聊到的测试基本职责和《进阶篇》中聊到的质量内建主要还是在团队/项目范围之内。但是要真正做好测试体系建设或者说系统性地思考和开展质量保障工作团队的能力还是很有限比如下面这些场景有没有觉得似曾相识我所在的组织有很多绩效考核指标工作靠绩效驱动感觉有些工作并不能带来价值我在一个独立的测试部门跟开发团队的绩效是不一致/矛盾的业务部门离我很远所有开发和测试工作只能根据需求文档开展组织的各种评审流程很严格对文档要求很高很多时间花在了写文档、走评审流程上所开发的软件产品对上下游都有依赖测试数据的准备和测试环境的就绪需要很多等待我不清楚其他团队使用的工具、测试技术等具体细节……上面这些场景中的问题都是很难在某个团队内部解决的。因此从组织范围来看测试体系的建设才是我们构建测试体系化思维的终极目标。 2. 组织级测试体系需要关注什么质量保障相关的人、流程、技术等放到组织层面就是组织级测试体系需要关注的。通常有如下两个方面的内容跟质量和测试密切相关的包括质量目标、流程规范、测试策略、实践标准等看似跟质量和测试没有直接的关系但是对质量保障工作的开展有着非常关键的影响如组织结构、企业文化、各部门之间的合作方式等。 02 组织级测试体系图谱组织级测试体系必然比团队级要复杂得多为了更好地理解和讨论将组织级测试体系需要关注的方方面面组织成如下图所示图谱该图谱由“一个中心四个方向”构成要构建完备的组织级测试体系建议围绕“一个中心”、向四个方向发力一个中心核心价值观四个方向高效率协同、标准化指导、规范化实施、自动化支撑 1. 核心价值观核心价值观是一个组织的文化理念深刻地影响着组织内每个成员的行为测试体系的构建需要以核心价值观为指导。1.1 价值驱动 vs. 指标驱动绝大部分组织都会采用度量指标来对每个人的工作进行考核因为这是一种比较简单的衡量所做工作好与坏的方法但这种方法也是相当粗暴的因为“不是所有能测量的东西都重要也不是所有重要的东西都可测量”。过于看着指标就会形成指标驱动工作是为了满足某种指标。测量什么就一定能得到什么。一旦制定某个度量指标员工一定会在工作中想尽办法去满足指标而真正重要的工作内容是否完成就很难说了。这种指标驱动的工作方式一定会忽略工作背后真正的价值。这是非常可怕的在《指标陷阱(https://book.douban.com/subject/35115655/)》一书开篇就举了两个非常经典的例子警察破案率、妇产科医生的手术成功率。我们来看一个软件开发中以指标驱动的例子。在《速度Velocity不背这个锅》一文中提到的“速度驱动一切”的误区就是软件开发中错误地以指标开发速度来驱动开发的实例。如下所示- 周报里的速度保持稳定每周每对 pair 在 2 个点上下- 性能调优客户觉得目前看不到价值不给点所以团队就不做了- 技术改进同样的客户看不到价值不给点就不做了或者团队实在无法忍受想要改进那就从别的功能用户故事里多估算一些点来留时间给做技术改进- 目前组内开发速度不够用户故事都做不完了生产环境的 support 能给别的组就给别的组做吧那个太耽误开发进度了相信各位朋友要举出软件开发中指标驱动的例子一定是信手拈来此处不再多述。那么是不是就没必要度量了呢也不是适当的度量还是很有必要的。度量可以作为团队改进的牵引帮助团队提高。但是工作不可以以任何度量指标为目标不能由度量指标驱动而是要以价值驱动。软件开发是需要交付能够带来业务价值的、高质量的软件围绕这个价值目标所做的工作才是有意义的。因此软件的质量保障、软件测试也要以业务价值驱动。关于这部分内容请参考文章《业务价值驱动的测试》。从组织层面来讲需要构建价值驱动的文化引导员工更多地关注价值弱化度量指标带来的不良影响以防掉入指标陷阱。1.2 鼓励创新 vs. 追责文化绩效考核的一个直接后果就是追责追责文化是跟绩效指标紧密关联的。绩效指标没有达到甚至是出现意外是采取追责还是改进的措施将直接影响到员工的行为、态度和解决问题的方法。比如线上出现严重故障最终会调查追责到人并施以惩罚还是会分析故障原因找出后续如何避免的改进举措呢如果是前者一旦出现问题所有相关人员会提心吊胆很难客观地分析和解决问题反而会有某些隐瞒因素存在导致下次可能还会重复出现类似问题。关于后者之前在文章《缺陷分析如何帮助质量内建》中有关于故障/缺陷分析的详细实践这里想要强调一点的是缺陷分析分析到问题出现的客观原因即可无需追责到人。一个非常典型的不追责例子是敏捷回顾会议所遵循的最高指导原则(https://retrospectivewiki.org/index.php?titleThe_Prime_Directive)Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.“无论我们揭示了什么我们必须理解并真正相信考虑到当时的已知情况、每个人的技能和能力、可用资源和情境每个人都做到了最好。”-- Norm Kerth, Project Retrospectives: A Handbook for Team Review不追责的另一面是鼓励创新。成功来自于不停地试错要想把事情做好需要不断地尝试经历多次的不成功并且在一次次失败中总结经验教训从而获得进步。例如高科技公司谷歌和亚马逊都是非常鼓励创新的。组织要宣扬这种创新文化给予员工适当的创新空间鼓励大家积极地尝试新点子以不断改进软件开发流程提高软件交付质量。1.3 全员负责 vs. 独立割裂对于软件开发团队来说“团队对质量负责”几乎已经是家喻户晓了。但是从组织级来看团队该怎么定义道理都明白具体到实施层面又是怎么做的呢据我所知的现实情况部门与部门之间、团队不同角色之间还是比较割裂的还有许多人认为质量主要是测试部门/团队/人员的事情而业务负责业务需求、开发负责编码、运维负责线上就行了。之前写过几篇团队对质量负责的文章欢迎移步阅读《团队为质量负责“我”可以不负责》《敏捷测试的指导性原则——团队对质量负责》《说好的团队为质量负责呢》从组织角度来看需要明确质量目标并让全体成员知晓以质量目标驱动各个职能部门间的合作增强全员对质量负责的意识。 2. 高效率协同高效率协同强调的是组织结构形式以及组织内各部分的协同方式这是组织级测试体系构建非常关键的一部分。2.1 组织结构设计系统的结构受制于产生这些设计的组织的沟通结构。—— M. Conway马尔文·康威马尔文·康威 1967 年提出的康威定律康威法则, Conways Law即系统设计本质上反映了企业的组织结构。软件开发是一项复杂的社会活动需要业务、开发、测试和运维以及团队与团队之间等充分地沟通协作才能实现根据康威定律需要对组织结构进行相应的调整以适应软件研发的需要。而传统的企业通常都有着非常厚重的部门墙业务和科技之间开发和测试、以及运维之间都分别属于不同的部门并且这种部门墙非常难以打破。这无疑是非常大的矛盾之处。例如传统企业通常都有独立而庞大的测试部门/测试团队在独立的测试阶段来承接测试工作在新形势下要求持续测试不再有非常独立的测试阶段测试部门该如何调整以更好地与研发进行高效合作是备受关注的问题也是组织建立完善的测试体系需要解决的问题。该怎么解决比较常见的有两种方式保持原有独立测试部门测试人员归属于测试部门管理但是派驻到研发团队在研发团队内实施测试工作不再设有测试部门测试人员全部打散并入研发中心跟研发团队进行深度融合。上面哪种方式比较好很难说。从形式上看完成融合的第二种方式看起来是较好的能够实现开发和测试更深入的融合但是这对团队也是有很高要求的需要在测试左移、团队对质量负责等方面都做的足够好才能对于质量有让人放心的保障。因此对于质量要求非常高的行业比如金融领域比较容易接受的可能是第一种方式一是因为传统的部门墙打破实在太难还有很重要的一方面是还有独立的测试部门对质量“把关”似乎能让大家更放心。至于自己的组织适合哪一种形式还是需要组织自己去摸索。2.2 团队拓扑组织应该被视为一个复杂的具有适应性的有机体而非一个机械的线性系统。—— Naomi Stanford摘自《组织设计指南》Guide to Organization Design)《高效能团队模式(https://book.douban.com/subject/35528423/)》一书中指出组织结构的陷阱传统的组织结构图是相对静态的并不能帮助我们理解组织中真实的沟通模式在实际的软件开发过程中可能有很多不依赖于组织结构图中所体现的沟通存在这种适应软件开发的沟通结构是更为关键而有价值的。因此提出团队拓扑的概念。[《高效能团队模式》作者总结的团队拓扑Team Topologies](https://hennyportman.wordpress.com/2020/05/25/review-team-topologies/)团队拓扑方法围绕企业软件交付的有效团队结构带来了一种全新的思维方式。提供了四类基本的团队类型流动式团队、平台团队、赋能团队和复杂子系统团队以及三种团队核心交互模式协作模式、服务模式和促进模式。强调了在静态的组织结构团队结构之外更多地关注实际的沟通路径针对技术组织补充了传统组织设计中所缺少的动态和感知方面的能力。回顾前面提到的测试部门如何组织的问题基于团队拓扑思想我们可能会想到不一样的解决方案加强测试跟各个部门/角色的交互才是关键所在需要根据产品开发需求构建灵活适应的团队拓扑结构具体的组织形式或许不是最重要的。2.3 沟通协作团队拓扑强调了组织沟通结构的重要性在满足沟通模式的团队构建好之后是不是就一定能实现相应的沟通需求呢也不见得。例如下面的一些情况可能大家都或多或少经历或者听说过有些业务目标、质量目标可能只是“高层”领导人员清楚没有对全组织、全团队透明有的企业业务和研发团队坐在一起但是沟通方式跟原来没有区别还是通过需求文档来进行沟通有的团队测试和开发同属于一个团队但是测试不会参与开发的技术讨论开发有技术方面更新不会告知测试人员开发不会参与测试策略和测试计划的制定等同一个产品或者项目的不同小团队各自为伍没有知识和信息共享导致重复造轮子的事情时有发生……类似的情况可能还有很多。这些都是形式上貌似没有问题但实质上缺乏有效的沟通协作。关于沟通首先要重视沟通的内容尽量让信息在整个组织或者整个团队内透明尤其是关于愿景、目标和风险类的信息可以增强成员使命感和主观能动性。我在《敏捷测试的指导性原则》里介绍了高效合作的团队特点在《警惕团队“蘑菇种植”》中也通过一些事例分享了信息共享的重要性。另一方面对于沟通的形式也要注意不同的沟通形式所能起到的效果也是截然不同的。通常面对面的沟通是最为有效的方式。如下图所示协作建立在充分沟通的前提上一旦沟通到位了协作起来就会顺畅很多。 3. 标准化指导之前写过一篇文章《敏捷团队的质量保障赋能》文中通过对 Google、Amazon 和 Facebook 等大公司的软件开发交付流程的分析总结了团队质量保障赋能需要做到全流程的标准化。通过标准化工作方式的指导让团队能更好地做到每个环节的质量保障更好地实现团队为质量负责。标准化一定要注意不要只流落于书面形式参考《敏捷团队的质量保障赋能》中的“事实标准与书面标准”。3.1 研发流程的标准化测试和开发是密不可分的测试策略受到不同开发流程的影响。不管是传统瀑布式的开发流程还是迭代式的敏捷开发流程或者两者相结合的开发方式都需要将相应的流程策略标准化下来每个环节的活动有哪些不同人员的职责分别是什么都需要在组织级有清晰的定义。在标准化的研发流程指导下团队如果发现某个环节成为瓶颈一定要详细分析原因如果是流程已经不适应新的团队现状也是需要调整和改进的。3.2 测试策略的标准化针对不同的开发流程需要有对应的组织级标准化测试策略。组织级测试策略是个统一的指导方向不同的产品线和不同的项目团队也需要有自主调整的空间以更好地定制化适配的策略。除了需要给团队自主调整策略的空间还有一点要强调的是策略不是一成不变的需要根据不同时期的质量风险和团队状态进行适配和调整应该是演进式的。关于测试策略强烈推荐参考《一页纸测试策略》并根据所在组织自己的特点来定制化。3.3 质量目标和度量策略标准化清晰的质量目标能够更好地驱动组织级测试体系的构建。组织级的质量目标一方面是纯系统使用方面的质量要求更为关键的另一方面应该是跟业务目标紧密关联的是需要以业务价值来驱动的。关于业务价值与测试可以参考我的下列文章《业务价值驱动的测试》《敏捷测试如何优化业务价值》谈到质量目标势必需要相应的度量指标和度量策略组织级需要对质量目标定义相应的指标并且通过组织统一的度量策略来衡量。度量特别需要关注的是不可以只看单一指标而应该是综合多个指标衡量也不适合将指标作为产品线/团队横向比较的标准指标应该是指导产品线/团队自身持续改进的尺子非常同意 Thoughtworks 同事伍斌道长在他的文章《度量就是为了识别价值流最大瓶颈》中写的“在敏捷 IT 研发交付中度量的作用就好比是在识别价值流中最大的堵塞点以便在“价值准、流速快、质量好”这 3 个维度中识别端到端价值流最大瓶颈以及方向错误并将其作为下一步改进点进行改进以最大化改进成效。”作者吾真本链接https://www.jianshu.com/p/91eaf583ca3b来源简书著作权归作者所有。商业转载请联系作者获得授权非商业转载请注明出处。关于质量度量Thoughtworks 同事于晓南从定性和定量两个角度进行过非常详细的分享并且撰写过一系列相关文章欢迎参考她的《质量度量文集》。 4. 规范化实施在标准化策略的指导下如何保证每个实践活动都能做到位是个比较难的问题有的实践可能一开始就实施错了或者刚开始是正确的但是过了一段时间实践就变味儿了……规范化的实施方案是对标准化策略落地实施的保障。组织级需要从以下几个方面考虑各个实践活动的有效落地实施定义实践活动规范、沉淀新的优秀实践、定制化成熟度模型、定期治理与持续改进。4.1 定义实践活动规范对每个实践活动进行清晰的定义包括实践的目标、适用条件、参与角色、输入输出等最好用实例化的方式详细介绍整个实践活动的内容。可以采用画布的方式对前面几项列举介绍更加清晰直观。定义好的实践规范是团队实施落地的参考在团队实践过程中也鼓励团队根据实践经验去完善每个实践活动实现持续的优化。4.2 沉淀新的优秀实践团队在实践过程中也会摸索出一些新的实践活动建议将新的实践活动分享给更多的团队推荐大家试用一旦得到多个团队的认可可以将这个实践活动也规范化沉淀下来存入组织级实践库中。同时对于一些不再适用的实践活动也要进行淘汰和剔除。4.3 定制化成熟度模型基于实践标准的成熟度模型可以评估团队每个阶段的实践实施状况并制定相应的改进举措以帮助团队的不断成长。组织级需要制定指导性的成熟度模型供每个团队去定制化以牵引团队的改进。这块内容欢迎参考我的文章《测试成熟度评估》。特别要强调一点成熟度模型的目的不是用来评估主要是为了指导改进成熟度如果要跟团队绩效关联务必谨慎不然就会陷入指标陷阱。4.4 定期治理与持续改进光有成熟度模型没用要能指导改进定期治理很重要。组织级层面需要制定定义质量治理策略落到每个团队来讲就是可以根据成熟度模型定期对过去一段时间实践落地情况进行回顾对现状进行评估根据回顾和评估结果并结合当下的质量目标制定新的改进举措。比如可以鼓励团队根据迭代周期、发布周期等进行定期回顾和治理也可以根据改进举措的粒度大小对不同举措进行不同周期的治理和改进。总之组织级要有定期治理和持续改进的意识结合成熟度模型鼓励团队实现持续改进。 5. 自动化支撑强有力的基础设施能够对质量实践活动落地实施提供自动化支撑同步提升质量与效能。从测试体系构建的角度来讲组织级需要全盘考虑几个领域的自动化支撑流程管理全生命周期的软件交付流程通常需要有流水线的支撑测试框架各种自动化测试框架以及与持续集成流水线的关联数据分析可视化各种数据及其分析结果包括日志信息和度量指标数据等监控预警实时监控团队和产品状态对质量风险和严重缺陷进行智能预测和告警只要聊到效能大家脑海里就会冒出各种效能支持平台和工具这部分内容是非常熟悉的无需多述……不过鉴于大家对工具平台的热衷程度非常有必要提醒几点1. 强调工具平台的使用但人员缺乏相应的赋能不清楚工具平台背后的原理从而无法高效使用。平台厂商和采购平台的企业都有人跟我聊过这个现象说明不是个例。工具平台再好也只有用对了才能事半功倍不然就是个负担。2. 标准规范停留在书面上根本没有落地实施。这就是前面提到的《敏捷团队的质量保障赋能》中的“事实标准与书面标准”而工具平台是有助于将书面标准变成事实标准的。3. 不同的团队采用不同的工具框架组织没有统一工具平台的使用。这将不利于不同团队间的协作和集成不利于组织级数据的收集会增加多余的成本。不要重复造轮子能够共享的工具平台一定要在组织内共享一致的工具平台对数据的收集和可视化都会带来好处。同时也要考虑团队优先适配的问题比如某个团队的自动化测试最佳方案是用工具 A非强调要组织级统一强制使用工具 B那也是不合适的。万事皆需平衡。 03 组织级质量赋能根据前面介绍的测试体系图谱总体来说组织级质量赋能要着重关注以下几个方面 1. 树立适应新时代软件质量要求的价值观营造全员重视质量和价值交付的组织文化随着科技的持续发展软件生态日益复杂新时代软件质量有着更高的要求软件质量保障也面临更大的挑战传统的质量保障、软件测试的思路不能完全适合。而是需要改变传统的认知观念实现多角色深度融合、协同作战、全员为质量负责重视质量和价值交付。 2. 朝着全流程标准化的方向前行降低质量成本全流程标准化是大势所趋但一步到位也是比较难分步走的策略才是可行的首先定义组织级统一的流程策略形成书面标准同时制定实践活动规范以指导书面标准的落地实施通过部分团队实践验证逐步推广并标准化固定下来形成组织级标准利用工具支撑设置质量门禁等方式确保书面标准能够真正落地并持续改进和优化策略标准和实践规范。 3. 强化质量基础设施建设扩大自动化规模提升研发效能大规模自动化是实现全流程标准化的有利助手组织级测试体系需要从测试自动化和流程自动化两个方向加强基础设施建设两者缺一不可。 4. 人员能力是关键加强能力建设不容忽视一方面制定组织级人才培养机制针对不同角色建立相应的能力模型和提升路径形成人才梯度有计划地实现人员能力建设同时鼓励社区建设营造学习型文化氛围以促进人员自主学习和提升。关于测试人员能力提升可以参考下列文章部分内容《数字化转型背景下的测试转型》《软件测试人员该何去何从》 04 最后继《基础篇》针对测试人员的基本职责和《进阶篇》针对的全生命周期的质量内建之后本《高级篇》通过介绍“一个中心四个方向”的组织级测试体系图谱以帮助实现组织级质量赋能。至此构建测试的体系化思维系列的基础、进阶和高级三个层次的内容均已完成希望能够提供一个帮助大家思考的测试体系框架。
