当我们在谈项目成功时我们在谈什么？Internal Sharing To Test Engineer.
工作上做了许多项目，最终都是成功的，但是过程曲折，有很多不顺与需要改进的地方，往往我们在做完一个项目后，就觉得万事大吉，顿时就松懈下来，不做总结，不反思下过往，急着投入到下一个项目中去，又开始了腥风血雨的征程。so，我们在谈论项目成功时，应该谈写什么？
一、总结
- 项目中最大的阻塞事情是什么？为什么会有？
- 项目中让自己觉得最困难的是什么？怎么产生于解决的？
- 流程上有什么问题？
- 交流/反馈上有什么问题？
- 自身问题？
- 其他
二、指出问题、改进问题
指出问题是为了更好解决问题，我们在项目过程中一定会遇到各种各样的问题？如果抱着不解决的或者拖延的态度，问题最终还是会在那里膈应着你，所以在项目中，可以从以下几点入手解决：
- 记录问题。
- 分析问题根源。凡事的产生都会有一个根因，试着去分析，深入的思考，看透现象的本质。
- 解决问题，先自己尝试解决，无果的话就及时反馈上级，切不可阻塞进展。
- 最后以日报形式记录总结，反馈给相关责任人
三、如何提高交付效率
做项目的目的是为了公司挣钱，自己挣钱，体现自我价值。而面对竞争日益激烈的市场，【快、稳】是保证公司能迅速占领一席之地的法宝。项目需要快速交付，版本需要快速迭代，需求随时又可能会改变，对于测试人员无疑有较大的压力，这时候，抱怨肯定解决不了任何问题，带着情绪工作也不会有好的结果，那么，如何面对这些压力并提高交付效率呢？
- 测试用例：黑盒测试，以测试用例为基础，需要不断的打磨自己的项目测试用例，如何设计高质量的用例，是优先要考虑的，否则面对复杂的系统，没有用例的支撑，就会面临许多的漏测。
- 测试策略：知道怎么测，哪些是重点，哪些是客户最关心的模块，往往能第一时间发现最要紧的问题，并及时反馈到开发去解决。问题发现的越早，成本就越低。所以测试策略很重要。
- 项目计划：项目计划里有开发的项目计划/测试的计划/客户验收确认的计划等。知道了计划，就需要提前对每个计划节点的目标做准备，做好相关资料/环境的构建。
- 开发版本质量差怎么办？：其实版本的质量保证，最终靠的还是开发人员，因为他们是bug的创造者，测试人员只是站在另一个角度去帮助开发发现自身代码逻辑的错误，而不是制造问题的人。所以有的领导说让测试保证质量，这是不可能实现的，因为测试只能发现到问题，而无法参与解决解决问题，更无法保证开发不引入新的问题。所以，开发的版本质量差，测试最直接有效的办法就是版本打回，不再投入（如果有明显的致命/严重bug），以此方式反推研发改进版本质量，重视自测流程等。当然，开发的内部结构优化，如何保证转测版本质量等，不在这里细谈。
- 需求来回变动怎么办？：2019年经常看到程序猿与项目经理干架的新闻，大概就是因为需求变动太频繁了吧。哈哈哈~，那么对于测试而言，需求变动要做的，就是针对需求做好分析并设计对应的测试用例，静候需求的下发与功能验证，保持平静的心态。因为需求一般是客户/市场/产品设计者产生，下发到项目经理审核后给到开发（审核的作用不大 - -），程序猿小声抱怨一番后，摸一摸光亮的前额，开始分析/敲代码，一顿操作后，又变更了一个需求，走上述流程后，程序猿开始大声抱怨了，但最终也还是得改，几次反复以后，就看到了我们上述的新闻。所以，需求真正下发到测试还是有一定的过程的，及时已经到转测阶段修改，应该也不会太多次，而测试也只能是抱怨或强烈抗议项目经理冻结需求~，保持平静的心态对待，还是有必要的，兵来将挡水来土掩，做好该做的。
- 客户确认周期长怎么办？：如果是和客户合同定制的产品，而客户有存在确认周期长的问题，如果做好前三条，其实也是静观其变。测试无法与前端直接沟通，只能去催市场销售人员等，但是一切的前提，只要保证自己的工作做好，客户1来不会反馈很多问题，2是催多了容易黄，也不会催。
四、分析Bug的产生周期及原因
- bug的产生阶段：需求期？设计期？代码期？
- bug的产生原因：需求不清楚？设计错误？代码失误？测试环境局限或数据不足？培训不到位测试人员没理解功能？
- 为什么没有在测试阶段发现：测试用例设计失误？研发流程不完善？测试资源不足？测试时间太紧张？测试工程师失误？
- 以后想项目中避免同类bug的方案？如何举一反三发现更多的bug，找出研发的设计漏洞？
对于bug产生的原因分析，有助于真实的解决实际问题。
五、如何构建质量系统
- 充分了解每次版本发布的设计变更/逻辑变更
- 设计有效的测试用例
- 固定有效的测试环境
- 制定有效的测试计划
- 与相关人员进行review并改进
- 随时掌握研发进度
- 对任何可能影响到测试的变动要警惕/敏感
- 及时作出反馈，汇报风险
- 根据需要及时更新测试用例及测试计划
- 了解项目负责人的编码/工作习惯，提前识别风险点