1 需求评审
我觉得不管是自研产品还是其他产品，测试人员都要参加需求评审的会议，一方面，便于了解需求进而更好地开展之后的测试工作，另一方面测试人员往往是从用户考虑居多，更加能够从客户的角度提出符合实际的建议
2 制定测试计划
待需求最终确定下来，则可以开始制定评测方案，
确认测试目标，测试范围，测试方法，测试策略，资源安排，风险评估等
3 测试用例设计
待测试计划拟定以后，可开始进行用例设计，一般先使用思维导图整理大概框架，在使用测试用例管理工具，按照功能模块，使用场景进行设计
4 测试用例评审
因为一个人的思想是有局限性的，待用例设计好之后，最好项目组的所有人员都参与用例评审，以便查漏补缺，尽可能使用例覆盖更全面
5 冒烟测试：
待研发人员提交版本后，测试人员便可以进行冒烟测试，当然，冒烟测试的用例要提前选好
6 一轮测试
待冒烟测试通过。则可以开始执行度一轮的测试，发现的bug使用缺陷管理工具（如jira、resmine、禅道等）记录下来
7 N轮测试：
如果有必要，可以进行第二轮，第三轮，第N轮的测试
8 回归测试：
待研发人员吧本次序修复的bug都修复完成后，即可进行回归测试，主要验证缺陷是否真的修复，知否会影响现有系统的使用
9 之后就可以开始撰写测试报告、用户手册等相关文档，测试报告会反应本次测试的目标，范围，对象，执行过程即结论和风险分析
总结了一下，大概流程就是这样的：
需求评审（有开发人员，产品经理，测试人员，项目经理）－>需求确定(出一份确定的需求文档)－>开发设计文档（开发人员在开始写代码前就能输出设计文档）－>制定测试计划，写出测试用例－>发给开发人员和测试经理看看（非正式的评审用例）－>接到测试版本（可能测试的代码 通过冒烟测试的代码）－>执行测试用例（中间可能会补充用例）－>提交bug（有些bug需要开发人员的确定（严重级别的，或突然发现的在测试用例范围之外的，难以重现的），有些可以直接写到TD（Test Director 相当于禅道））－>开发人员修改（可以在测试过程中快速的修改）－>回归测试（可能又会发现新问题，再按流程开始跑）。