测试之质量债问题表现及处理方案心得
以下资料内容仅供参考,如有不当或者侵权,请联系本人改正或者删除
一、词语介绍
质量债：团队在软件开发周期甚至上线周期过程中，不注重整体质量保障及质量传承，导致与质量相关的潜在问题/已存在问题
二、表象
质量债，往往涉及质量传承问题，整体质量保障过程，是不断填质量债，又不断埋下新的质量债的过程
表象：质量无良好沉淀、新同学介入困难、质量传承手段差
举例：
1、想了解某个模块的业务、测试方案、自动化方案等情况，是否直接有文档/工具沉淀
2、来了位新同学，需要做哪些事可以对项目规范/流程、整体测试方案熟悉起来
3、模块A，测试同学A刚刚测试完上线；之后的项目B，测试同学B需要多久可以了解模块A及之前的测试方法
4、业务M，测试同学AB负责测试，同学AB是否能说90%熟悉业务M
5、原有的需求文档和测试文档可能不全，甚至没有
三、起因
与团队测试模式相关。目前团队常见的两种测试模式：纵向合作模式、交叉合作模式
纵向合作模式：非特殊情况下，测试同学各自负责各自业务，耦合程度较小。测试同学A仅负责业务A，测试同学B仅负责业务B，二者之间一般不会交换测试业务。
交叉合作模式：测试同学除负责各自业务外，还会交叉负责他人需求，如测试同学A、B共同负责模块A、B。此模式耦合程度较大。如测试同学A负责业务A一期需求，测试同学B负责业务A二期需求，再之后测试同学A负责业务A三期需求。
交叉合作模式一般是因为几点：人手不足、期望人员互为后援、业务本身迭代模式决定
纵向合作模式：
1、测试同学可以说100%熟悉自己负责的业务。
2、若测试同学靠谱，及时总结留存文档（业务内容、技术、测试方案、测试文档等），质量债会比较小。
3、非特殊情况，测试同学A留下的质量债由其接任者背负。
交叉合作模式：
1、测试同学由于对各自负责的项目不熟悉，导致对负责的业务不能说100%熟悉，只能说一知半解。
2、该情况下，测试难度加大，可能会有遗落点，质量债也会比较大。
3、该情况下，A同学的质量债，会被B同学背负，B同学的质量债，也会给A同学背负
相比纵向合作模式， 交叉合作模式下的团队，会受质量债的影响更大
交叉合作模式下的质量团队，或多或少都会存在不同程度的质量债，在质量债重的团队中，测试同学做项目往往是十分痛苦的，需要找若干同学去沟通，xxx业务目前在线上是什么样子的，之前怎么造场景的等等；更危险的是，一旦存在当前测试同学感知之外的场景，改动，往往就会引发不同程度的线上问题。
四、防治
让质量债可衡量，是其防治的关键。团队在具体操作的时候，可根据其导致的几个关键问题，来有针对性的量化。
比如，针对每个项目，沉淀各自的业务、技术、测试方案、测试文档等；针对业务，提取核心业务场景及其介绍；针对测试手段，形成整体性的工具等等。
1、质量债的预防
要想让团队尽可能少的欠质量债，除了靠自觉以外，可能需要团队里面形成质量传承的氛围。
①团队形成质量传承氛围，详细文档沉淀机制（历史总需求文档、UI稿、整体设计架构、主要功能、测试工具、主要的缺陷分布、接口文档、研发流程、测试流程、上线流程、缺陷管理流程、测试用例、测试总结、各环境账号密码、数据库和日志等平台账号密码等）
②组员自觉靠谱，将总结留存文档（需求文档、接口调整文档、产品方案、技术方案、测试方案、测试用例、测试总结、测试工具等）
③项目前，整体了解组员间整体业务、整体需求文档
④项目后，分享机制（问题总结分享、需求测试历程分享、处理方案分享、更改点分享等）
比如，A同学负责上线一个业务/模块A后，给团队其他同学把项目相关沉淀输出出来。那么次，B同学想回归业务/模块A的时候，不会完全不懂其修改，或不必靠口口相传的方式去问A同学，B同学的工作效率，甚至是效果会提升不少。
2、质量债的治理
让质量保障方案，在团队内流转起来，尽可能保证大家对业务、测试方案的理解一致，有两个方案
方案1：技术性方案
为了更好避免理解性偏差，效率提升，采用尽可能多的自动化工具，来避免质量债问题。比如，A同学跟进项目，测试上线了模块A， 那么A同学需要提供类似一键自动化测试的工具，之后B同学再回归测试模块A的时候，直接用自动化工具测试。
方案2：分享性方案
如果某块业务，不适合自动化测试，或者项目排期紧迫等等，可以采用组内分享机制，来尽可能避免质量债问题。比如，同样的，A同学跟进项目，测试上线了模块A，那么A同学及时组织一个分享会，把业务、技术、测试方案等等内容，同步给组内其他同学。
质量债，同技术债一样，是伴随业务的不断迭代，而日积月累起来的。预防需要持续性的时间和精力投入，治理也需要从上到下的共同合作。
或许，质量债不可能100%消除，但为了整体的质量，需要尽可能减少质量债。