我们在业务上经常会看到问题单管理工具，无论是DTS、Jira、redmind、禅道等工具，都可以管理问题单，甚至来说使用Excel也可以管理问题单，然后很多QA就会开始琢磨里边的使用方法、系统提单改单的环节；但你有没有想过这些工具里边的逻辑是怎么来的呢？如果让你使用Excel来管理问题单，问题单的流程规范你能不能制定呢？因此，掌握背后的逻辑才是做好问题单管理规范的根本，不然一项工具的推行往往会让业务怨声载道，抱怨使用的繁琐性，而你却束手无措无法解释和讲清楚为什么要有这些环节。

如果我们从零开始去做问题单管理？

首先是提单、改单、关单，这个基本流程规范需要定义。测试提单需要讲清楚问题单的重现环节，问题出在哪，是怎么测出来，这样开发在收到问题单的时候才能复现去定位问题出在哪，然后修改，修改完了之后告诉测试一声，测试再重新测试验证问题单修复了就可以关闭问题单了。好，这就是最基本的一个闭环，大家可以看到里边提到了where、what、how，如果要进一步完善这个，你觉得该怎么做呢？

可以试试套用5W2H，是不是还得强调when、why、who、how much？

首先是when，在问题单描述中得明确什么时机或触发条件下会出现这个问题，这个描述对那种非必现的问题或者说是一线用户传过来的问题很重要，可以方便开发加速定位问题发生的原因。

然后是why，什么原因让你或用户觉得这是个bug？这又是一个很重要的优化点，往往有些问题在开发看来可能就是刷新下网站、重新登录或者索性就是因为用户使用环境的问题才出现的bug，如果没有写清楚原因，开发是很难把bug修复到用户或测试所认为需要的程度的，这就是为何经常出现开发认为问题修复了，测试说没修复的原因。

紧跟着who？什么角色对象中觉得这块有问题？之前我们经常性遇到开发复现不了问题的情况，认真分析才发现权限角色用户不同，效果不同；特别是开发的环境或账号是完整权限的，使用的浏览器经常会清理后台，那就会在定位问题的时候没法重现用户的实际使用场景，所以测试描述问题要讲清楚是什么角色权限用户下发现了bug。

至于how much，这也是业务上修改问题常常遇到的困难，同类似的场景和问题单数量不可能反复提，所以需要测试在一个单子上把所有潜在的场景和问题点都罗列完整，这样方便开发一次把所有bug修复。

以上仅仅是基本环节正常流程中的问题单管理规范，5W2H在实际规范中也不仅仅就这么些描述性要求，where、what、how，也要结合实际来优化，本质来说问题单规范性管理的目的是强调高效发现问题修复bug。

讲完了正常环节下的问题单管理，异常环节下的问题单管理还需要注意啥呢？受限于篇幅，在此只做抛砖引玉，如：非必现问题单的处理、问题单的定级降级升级、修改引入新问题、回归验证不通过的问题、一些属于需求的疑似bug、长周期迟迟没修复的问题单、重复的问题单、大量问题单涌入等等；我们在质量管理工作中一定要始终强调实事求是，结合实际情况有序有条件的增减规范持续改进，而不是无视现状一股脑把所有规范都上了，因此，这些非正常环节的问题单管理，结合实际发生数量，再去进一步建流程规范，匹配组织发展的需要。

文章首发于微信公众号“流程与质量”