JB的测试之旅-项目流程规范

事前药

本文阅读时长约10-30分钟，建议先浏览下总纲，很多细节不一定是通用的，主要还是想引导大家为什么这么做，而不是套模板，灵活比什么都重要，这个是初衷；

内容是全体测试同学及老大共同参与整 理，并得到了公司各职能的认可，目前已经在对某些团队宣讲及试点，并会不停优化整个流程，期望能形成一个好的团队合作模式；

从内容而言，算是一个大而全的输出，建议不同同学灵活运用，根据不同团队制定合适的流程和规范；

前言

随着互联网的飞速发展，企业为了争夺市场而快速迭代，随之而来的，就是敏捷、免测、自动化等一系列规范化的诞生，为的就是确保项目在高速迭代时依然能保持好的质量及团队配合；

而测试是处于整个迭代的最下游，一旦上游出现delay，项目在不延期的情况下，就会压缩测试时间，从而产生上午写bug，下午发布的情况，而这情况越来越普遍；

在这种环境下，测试人员压力很大，甚至喘不过气，而且bug发布后，一旦有线上问题，就归根到测试没有发现问题等，导致人员心里越来越疲惫，说句话说，员工感觉不到幸福感；

而这种情况，往往在小公司里会更明显，因为流程不清晰，各种不规范，产品乱插需求等等，很不巧，jb也遇到，正如上面说的，乱排优先级、delay家常便饭，老板一看，什么，又要delay？怎么搞的啊！ 不用测试啦，快速迭代，然后出问题又怪到 测试这，怎么那么多问题等；

正如弹簧一般，被压久了，就失去弹力，习惯了是个很可怕词语，一旦习惯了，就麻木了，人就渐渐失去激情了；

为了改变这种现状，测试团队及老大（技术负责人）也想改变这种情况，因此就有了下文的内容，主要是制定一系列的项目流程规范，跟各职能达成共识，严格循序；

做什么？

既然老大都支持做这个事，那就思考下要做什么吧？

常见的项目流程应该是这样的：

• 需求文档；
• 评审；
• 工作量评估；
• 制定项目计划，立项；
• 开发；
• 提测；
• 测试；
• 延期&需求变更；
• 验收；
• 上线；
• 结项；
• 线上问题跟进；

好像，大概，流程就是这样啦，没啥毛病；

但是，够了吗？可是要站在项目的角度想这个事情呢；

经过一轮脑暴，发现是还有很多细节，如：

• 职责；
• 开会效率；
• 邮件；
• 请假；
• 团队意识；
• 办公室命名；

还有吗？肯定还有的，只是没想到而已，但毕竟不是专业的项目经理，那先把想到的搞定先吧；

按照上面说的，会分几块：

项目迭代流程、职责分工（针对项目跟产品）、团队意识、开会、邮件、请假、 通讯工具（如某钉、某信）；

总纲

项目迭代流程

1.产品经理建立confluence版本目录;新项目就先建新空间;所有文档按照文档组织规范来存放；2.产品经理收集各方（运营、客服等）需求后撰写需求总表，包含需求概述（一到两句话）和优先级;3.需求文档：按照需求总表的顺序出，每个需求的细致程度和优先级一致;写需求期间设计师同步做设计初稿;4.负责人评审：由研发、测试的主管评审可行性和资源可用性（人力、服务器等）;简单的需求不一定需要开会;5.设计师初稿：有客户端或前端参与的需求，初稿要在全体评审前要做出来。期间设计师有机会先提出产品文档缺陷;6.全体评审：所有实际参与项目的同学参加。尽可能提前发现缺陷;7.工作量评估：各职能给出时间长度和依赖关系，汇总给项目经理排期;8.排期，立项：项目经理发出邮件，包含所有的信息;设计师标注切图;9.开发设计评审（一般小于10个工作日的需求不需要，具体由研发主管判断）;10.测试用例评审（一般小于10个工作日的需求不需要，具体由测试主管判断）;11.开发，提测;12.测试：先准备好冒烟测试案例给开发。每轮测试撰写测试报告;所有人都可以去报bug;13.延期和需求变更;14.加班;15.验收、上线：发布后运营和测试再做一轮冒烟测试或持续监控，达到放量的标准才叫完成上线;16.结项：数据分析、复盘，项目经理汇总后发邮件;17.线上故障;专项版本流程

专项版本的特点是独立版本项目，不跟随版本迭代的需求； 在项目空间的根目录建一个文件夹存放项目相关的内容； 确定搭车哪个版本上线后，可以把所有文档转移到那个版本的目录下；

具体流程规范尽量和版本迭代流程保持一致。

职责分工

产品经理对结果负责，项目经理对信息传递负责，各职能主管对流程负责。

项目经理的核心作用是信息枢纽，主要职责：

• 制定和优化项目流程规范；
• 收集工作量评估，排期，确认里程碑时间，如有必要可召开立项会议，最终发出立项邮件；
• 结项会议主持；
• 解决团队资源冲突，确定项目的优先级，协调人力资源；
• 发现团队合作中可以提升工作效率的地方，并推动解决。例如建设产品的axure预览空间；
• 发周报邮件；
• 对团队的问题做监督、总结、给解决方案；

产品经理：

• 确保需求通过评审，得到各方确认，并宣布立项；
• 收集来自运营、商务、客服的需求，做成需求文档安排到版本迭代中；
• 接收客服的反馈，bug就转交给测试跟进，产品建议则统一回复，如果需要处理及插入到各版本迭代计划里；
• 版本发布的最终决定人，即时有问题，只有产品同意，都可以发布；

团队意识

1.目标导向，不是为了任务而做任务；2.所有规则都不是死的，哪些要哪些不要，要具体地判断，按时高质量完成是最基本的目标；3.所有事务都有优先级顺序，如果不清楚的话就询问上司，直至boss；4.及时反馈，并通知到应该知悉的人；5.团队互助：别人做得60分，如果你抱怨着等别人完善，你也是60分；6.项目安排一旦定下来就是个承诺，能否兑现是职业素养的体现；开会

1.主持人要做好时间控制，尽量一小时内讨论完；2.开会要说明会议目标和议程；3.按需写纪要：讨论内容与结论，需要跟进的问题和责任人；4.按时参会，有事不能来或迟到应该告知主持人请假；5.在提前2小时有通知并说明了迟到要发红包的前提下，会议主持人可以要求迟到未请假者发红包，总额按参会人人均X元；邮件

1.什么时候要发：需要跟进和后续查阅的事项；2.推荐使用foxmail为客户端，也可直接使用钉钉；3.邮件标题，简明扼要，如果紧急，写上【紧急】、【项目周报】、【测试周报】，以此类推；4.称呼：写清楚是对谁说的，对全体就是“Dear All”；5.要有签名栏，至少有自己的名字；6.抄送：自己的上司、涉及人员的上司（至部门一级）；钉钉

1.每个项目组建一个群，拉上所有实际参与的人和各级主管；2.项目事情不允许建立小群来讨论，只要是说正事就不要怕打扰人。只有讨论非工作事宜的才能建，例如下午茶群。请假

务必保证上司知悉。如果自己身上有重要任务，必须让项目组也知悉。晨会

在项目迭代较快的时候，都要求进行晨会，目的是快速同步信息，了解进度，如果有遇到问题，也及时提出，让对应负责人推动，避免一切延期的风险；在晨会反馈时，需要技巧，不能这样：XX功能进度正常，按照原计划执行；

应该是需要反馈做了什么事情，这个事情的进度，大概什么时候完成，这个事情不是一个项目，而是拆分出最小的一个功能，比如：

昨天做升级功能，界面及接口联调已经完成，进度60%，今天会进行防劫持功能开发及自测,今天内开发完毕； 

小结

看到这里，是不是觉得很繁琐？这种鸡毛蒜皮的事都要管？没错，看上去越是鸡毛蒜皮的事，往往却是最重要的，互联网时代，什么都要高效、注重用户体验，这些事情都不例外；

那接下来，就针对项目迭代流程里的每个小点进行说明吧；

文档组织规范

总则

所有文档以Confluence（下文简称cf）为中心做管理，cf不方便存放的东西才放到svn。

项目组的钉钉公告栏只放置版本页的cf链接和当前版本的提测记录。

CF规范

每个项目由产品经理或项目经理建一个空间。

目录规范如下：

• 主页
• • 通用文档，包括第三方文档、全局术语表、全局信息（测试服务器地址、svn地址）等，跟具体版本无关联;
• • 专项文档，跨版本的需求统筹、跟版本无关联的运营活动需求;
• • x.x.x（版本号，按具体版本划分）
• • • 需求总表；
• • • 立项。可以不独立成文档，只存在于邮件或钉钉公告栏里即可，或在需求总表文档上回复；
• • • 各个需求文档，以需求名称命名文档名。如果用axure，在这里填写svn地址，还可以包括预览空间的url地址；
• • • 测试文档，以作用命名文档名，主要是用例，可放svn。测试报告只存在于邮件中，如果不嫌烦可以在需求总表的文档那里做回复；
• • • 结项。这个必须要，不能只在邮件里；
• • 垃圾桶（废弃的需求、不再使用的第三方文档等移动到这里）

SVN规范

目录规范如下：

• 根目录* * 小程序(按产品形态或者具体业务来分，任君选择)