从测试感悟到的项目管理

  一个项目从孕育到生产的这个完整的流程，需要各个部门密切顺滑的配合才能够像齿轮一样的环环扣紧不脱轨。在这中间，所有的技术人员都像一颗螺丝钉，如果自己的任务钉对了位置，方能愉快的做好自己的事情，如果中间的沟通协作等流程出现了问题，各个螺丝钉都会感觉不自在以致痛苦。人肉的项目管理流程毕竟不能够带来严谨的工作态度，测试作为生产线上的最后一个环节，如果前面的生产环节出了一点小问题，堆积到测试这里就会绕城一大坨大问题。

  经历多了坑的流程，我一直对流程化、自动化的东西很是在意，常常思考作为测试怎样在没有完善流程的项目中，贡献自己的力量。

  项目不仅应该根据定好的时间点，完整的分割每天的任务量，且有责任监督文档的完整性，可读性，可测性，了解从研发到UI到测试的工作流程与提高工作效率的方法，来调整文档的规范性。

  从研发内部的协作自动化，部门直接的协作也很有兴趣，核心就在于换位思考，了解各个职位的详细工作流程，以及在各个岗位最希望应用的工作模式。

利其器

  个人认为不管是多大的团队，都应该善于使用各种管理工具，有的认为团队小高效率就应该任何事情口头立马沟通交流，但是长久以往，所有的信息没有载体记录，流程会因为节点的不清晰而变得混乱，后期总结归纳起来也特别不方便。不管团队大小，总有适合当前场景的管理工具，重量级到轻量级的工具，找到适合自己的就好。

版本管理：SVN，Git

项目管理工具：

1. Excel
2. Microsoft Project
3. dotProject
4. redmine: bug 需求也可以管理
5. Jira
6. Teambition
7. Worktile
8. trello

不仅要用项目管理工具提升效率，还有很多其它常用工具能大大提高平时的工作效率，参见：it常用工具思维导图

风险评估

  测试需要评估bug的风险，对公司的受益影响，对用户的使用体验影响，对版本开发迭代的影响。项目同样也需要评估风险，对需求的改动，版本的更新，资源的调动使用都是需要对相互的影响作出评估。

沟通

  测试需要针对功能问题，流程，效率，和各个部门进行沟通，项目需要对资源等进行沟通调配。

需求

  需求的产生，并不是随意的有一个idea，或是抄抄别人家的产品画个图就可以了。从测试角度，版本每次测的兼容性，如果产品阶段考虑的好，向前的兼容性就能很好，功能性兼容，接口层面的兼容都应该考虑到，而不是每次强制用户升级造成用户体验极差。

  从用户角度实用性，易用性也同样需要兼顾，所以需求的考虑是一个复杂的过程，具有前瞻性，多往后考虑1到3个版本，不是就当前版本简单的列个功能性列表，开头没开好，整个团队会为了填需求的大坑疲倦不堪。而这些坑，往往从每一个环节堆积，到最后的测试环节就会凸显的特别明显，作为测试对这种坑真的太深恶痛绝。

  所以想要团队效率高，轻松过渡，需求环节太重要了。设计者的技术知识实在不可缺，但有的公司并不在意这个点，浪费了时间和金钱，导致资金链断裂，公司岌岌可危还以为是市场没有做好。

任务分割

  任务分割及其的重要，将任务分割到每小时，每天，这样任务的可控性也会大大提高。对于项目的管理，风险的预期都是很有益处的。测试对于细节要求会很高，希望控制到每个细节，这样会比较有安全感。对于项目管理来说，也有相同的效果，对细小的东西掌控的很好，在合起来的时候，才能做到心理有底。对后续开展工作能得心应手。

项目规划点

• error code：考虑到兼容性，从立项开始前端特定的error code按照规定的提示，没有规定的error code，按照服务端返回的error message提示。
• 版本记录：每个版本应该记录除了需求意外的变化，比如APP具体修改的功能细节，服务端接口的变化，如果有特殊的接口还应该详细记录，包括其兼容性的影响。

大而谈之，不如切分为每日任务，踏实做之.