摘要：互联网江湖中，技术同学想必对技术债都不陌生，几乎每个研发团队，都会经历一次，甚至几次的技术重构，来减少技术债。同样，对于质量团队而言，或者对于测试同学而言，质量债也是不得不面对的一个挑战了，不仅仅是影响测试效率，甚至会直接导致测试场景的遗漏，进而引发不同程度的线上问题。 下面就自己一些经验和感悟，聊聊自己的一些体会。
一、前言
深处互联网圈的同学，特别是技术方向的同学，想必对技术债一词耳熟能详了。“技术债”是 Ward Cunningham 在1992年提出的，它主要用来描述理想中的解决方案和当前解决方案中间的差距所隐含的潜在成本。类似金融债务：为了解决短期的资金压力，获得短期收益，个人或企业向银行或他人借款，从而产生债务，这种债务需要付出的额外代价是利息。
技术债的几个成因：
xxx必须按时上线；
当前先赶进度，稍后做一版重构；
团队内缺少必要的code review；
做技术设计时可扩展性差
那么与技术债类似的，实际的项目中，往往还伴随有质量债。质量债，顾名思义，与质量相关的潜在问题/已存在问题。技术债，造成的是研发新需求时的痛苦连连，比如，不断跳坑、在原基础代码上做扩展困难、需要时不时重构等。而质量债，往往涉及质量传承问题，整体质量保障过程，是不断填质量债，又不断埋下新的质量债的过程。下面就自己的一点经验，来说说自己对项目中的质量债的一些体会，不足之处，欢迎大家交流指正。
二、质量债的几大表现
如果要判断一个质量团队是不是存在质量债，不妨回答一下下面的几个问题：
想了解某个模块的业务、测试方案、自动化方案等等情况，是否直接有文档/工具沉淀；
来了位新同学，需要做哪些事可以对项目规范/流程、整体测试方案熟悉起来；
模块A，测试同学A刚刚测试完上线；之后的项目B，测试同学B需要多久可以了解模块A及之前的测试方法;
总结起来，质量债的表现为：
质量无良好沉淀
新同学介入困难
质量传承手段差
三、团队合作模式对质量债的影响
当前各个公司的质量团队中，团队模式大致可以分为几种：
1、纵向合作模式
在这种模式下，测试同学之间耦合的工作比较少，除非特殊情况，突发状况，一般情况下，测试同学A只会负责业务/模块A的测试，测试同学B只会负责业务/模块B的测试，二人不会互换测试，如下图所示。
由于测试同学A，测试同学B”独测“一块内容，假设A,B同学都有不同程度的质量债，但A同学的质量债，不会让B同学背，反之亦然。当然了，在一些特殊的情况下，比如A同学去负责其他业务了，那么A同学留下的质量债就会由其接任者背负了。
版权声明：本文出自《51测试天地》第五十七期。51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
