一枚测试人员的苦恼：
在刚进入新的团队，我有幸第一次与团队成员参与了某个系统的测试，但是在产品提测的时候，我作为测试人员感觉有点头疼不已，因为过程质量不容乐观，整个过程中major的bug率占比较高，经常在提测阶段出现一轮所有用例没有测完就直接被Block的情况；其次，不断的回归以及代码的变动，让我们感觉有些力不从心，从时间上来说，哪怕进行了2*12天/人的测试回归，直至上线，仍然有很多无法把控的风险因素；
图1：该系统测试报告
一个契机：
从测试来说，我能看到的是项目已经表现出来的结果，1.项目时间上的延误 2.过程质量的不容乐观；
但是纵观整个整个产品开发过程，产生这些原因的根本可能是因为前期在协作以及方法上没有达成的一致：
1. 沟通的问题
1） 开站会的时候没有提出一些风险，站会草草了过，然后等项目提测时候延期提测，每次都不能按时间按要求给出一个较高的提测版本；
2） 等提测的时候，发现有些需求已经变更过，但是并没有通知到全体参与人员；
3） 多人开发的版本控制教乱，经常出现代码回滚合并不一致的问题；
4） 系统版本很多，多个版本开发以及测试人员的协调时间存在问题，曾出现过版本要上线了才发现延后了一个星期；
2. 需求变更频繁
1）需求把控一直是个比较头疼的问题，每次等提测的时候仍然有需求插入，没有进行需求把控；
2）针对变更需求没有详细记录，每次到测试阶段测得比较粗糙，到最后发现需求有些坑；
3. 历史遗留问题
1） 团队的快速扩大，由单作坊形式变成一个合作模式没有达成一套自己的管理模式；
2） 之前线上问题较多，每个版本在时间安排上都会被挤掉一些时间去处理线上bug；
3） 针对现有线上系统，团队整体的质量信心不高；
辣么多的问题，如果此时能够从源头去做一些多多少少的改变，或许对整个项目的质量有一些推进作用，对团队成员都是有个积极的正面效果。
有些事情需要项目管理去推进，然而当时我们项目组并没有项目管理；
But，我没有做过项目管理，又该怎么推进呢？
此时，我在每次测试报告中，都会提一些想法，然后跟我的leader反馈下处理方式，嗯，那就试试吧！
一些尝试：
我所理解的项目管理是需要对项目的成本，时间以及风险的把控，利用敏捷的思维，尽可能早的把问题发现使团队成员按照预定的时间和轨道到达目的地；
鉴于目前项目中存在的那些问题，我们断断续续做了如下的改进：
1. 重新理解站会的侧重点以及意义
之前站会存在2个问题：
1） 没有有效及时的抛出问题（比如延时提测，或者在开发过程中没有及时抛出需要协作的内容）；
2） 时间把控，有些时候会就一个问题在站会上浪费较长时间；
我觉得站会的意义是各自明确对自己计划的承诺，所以我们进行了一些改变和重申：
1） 明确自己所做任务的时间节点以及风险，有问题及时抛出；每一天针对前一天的问题先进行回顾查看前一天问题进度，再开始今天的站会；
2） 有效把控站会时间，明确站会框架，避免时间浪费（昨天做了什么，今天计划做什么，以及时间节点和风险）；
3） 针对需要协调的站会内容，当时没有用看板，而是用邮件记录的方式，将时间节点和每日碰到的问题和需要协调的事情记录；
图2：站会模式的探索
2. 需求的管理以及线上问题的处理模式探索-- Jira看板的推动
Jira看板主要是为了解决当时的几个问题：
1） 如何处理线上问题；
2） 针对需求变更，如何能够进行跟踪与需求描述；
3） 如何来管理一些零散需求，方便进行放入迭代管理；
4） 如何更有效直观的查看项目情况（包括任务，bug，进度等）；
于是组织开了个会，商议尝试着用jira创立需求池与线上bug的版本，进行跟踪，这样可以方便我们对线上问题的统计以及需求的管理，同时也方便进行项目过程质量的统计，当然前提可能需要改变大家以往的工作工具，例如excel等，进行工具的统一：
图3：看板的制定
3. 需求变更流程控制
需求变更控制是需要让全体成员了解在提测过后变更的一些风险，以及我们为啥要控制变更的原因，制定出一些公共策略全员一起讨论，达成共识。
1. 首选我们在流程上每次的测试报告都会提出变更的风险，所以在后续的迭代过程中大家针对需求类的问题达到了共识；
2. 其次我们尝试采用D-box的软件，需求变更的时候及时的通知；
图4：需求类问题的流程推进
4. 如何推动开发的版本控制
因为人员的不断扩张，在多人开发项目的过程中经常会出现代码回滚上传的时候一些代码遗漏，每次测着测着发现之前的bug又Reopen了，导致测试这边需要测很多轮，并且无法控制代码版本质量；
针对测试过程发现的问题，需要积极的和开发负责人沟通，有效的进行代码的管理，形成一致的代码管理方式，避免将版本控制的问题出到线上，同时也减轻了测试的回归量：
图5：制定多人合作的代码管理策略探索
5. 复盘会的框架选择
我们组内组织过几次复盘会，但是有些效果比较好，有些开的效果比较差，总结下来，我觉得复盘会需要注意以下几点:
1. 明确开会框架
会前发邮件明确开会内容和开会框架，最常用的框架是每个人能够用小纸条写出：
Good，NeedImproved以及Try进行阐述，让每个人有参与感；
其次在把控主框架的前提下控制开会时间，不要东跑西跑的绕开了主题，影响了大家的时间；
2. 抓住需要Try的重点
每次需要改善的东西很多，但是每次都不能什么都抓，所以需要主持会议的人根据每个成员所提的几个Top痛点进行筛选，制定改进措施，达成共识；
最后以邮件发出，定时回顾。
一点点总结：
第一次尝试一些项目管理的工作，在项目中作为一个双角色之间的转换，我深刻的体会到了全局意识和沟通的重要性；
作为测试人员，需要有全局意识，能够凭借职业嗅觉很快的从项目中发现项目过程的一些问题，并且能够最终的对发布版本的质量和存在的风险有着比较清晰的了解。
但是如果仅仅以一个测试人员强硬的角色去暴露出产品以及团队的问题，可能会和开发人员以及产品产生一些冲突，影响团队的和睦；
项目管理的角色恰好能够推动测试人员所发现问题的解决，但是在推动过程中需要有较强的沟通和协调能力，这些都是需要锻炼的。
过程质量的把控需要方方面面人员的协调与参与，共勉！