一、测试者也可以提出需求

　　在需求不明确的时候，测试人员也可以提出需求，但前提是你应对你提出的需求做好充分的调查取证，要有足够的理由去支撑，通常可以将你的理由陈述在Bug说明中。

　　一个做测试的朋友告诉我，她们公司开发过程不太规范，没有需求文档，通常通过开会确定需求后，直接进入开发阶段。导致测试人员在测试时，对某些功能的实现产生疑问而无依据可寻。只能与开发进行确认，而这种疑问的产生，通常由于开发没有得到如何现实的指示。个人理解根据问题涉及面或严重程度有两种解决途径：一种，如果问题比较严重，那么可能需要管理者，针对该问题（功能），给出解决方案或者对问题（功能）如何去实现进行详细的定义。另一种，如果问题不太严重，那么测试人员可以站在用户的角度提出建设性意见，然后由管理者决定是否执行。

　　作为需求的提出者，应当有足够的理由来支撑。因此作为测试者，不仅要对软件技术有所了解，更重要的是要对业务相当熟悉，包括本行业的其它公司的产品，当然，介于我们的职责范围，要以提高测试效率和产品质量为最终目的，因此建设性的需求，要以当前测试目标和产品目标为基础，提出适合产品的。当然，当你能提出建设性的需求时，那么估计你的能力也足够强了，因为产品需求的提出，通常是由产品经理和用户共同提出。哈哈…可以考虑加薪了…

　　说到这里，下段是我在网上看到对开发过程中部分角色定义，大部分书籍讲得过于专业，个人觉得通俗易懂的，实用性更强。

　　● 产品经理，定义需求，做什么

　　● 架构师，技术实现，怎么做

　　● 项目经理，产品开发控制，如何按时按质完成

　　当然，有的项目经理，还会兼职做开发，甚至包括架构师的角色，从技术角度指导开发人员如何实现。至少这种情况，正在我们公司发生…

　　二、项目总结

　　1、提高BUG提交的质量

　　目前，项目正在进行下一版本的开发，所以有机会喘口气，将上一阶段测试过程中的不足之处做一个总结：

　　● 放过多的时间纠结在Bug的重现上

　　个人不足啊，一个明知还犯的错。哈哈…

　　● Bug复现步骤过于详细，应尽量简练的语言描述

　　通常在不清楚Bug如何出现时，操作步骤尽量详细；当你已经明确知道Bug如何出现，应当一语中的，用最简洁的语言描述。现在，提交Bug前，我会以开发者的身份再审阅一边，以便提高提交Bug的质量。

　　2、增长行业知识

　　● 业务知识不足

　　其实，这次测试，有一段时间由产品部指导，目的是让我们熟悉业务流程。而从另一角度，产品部的关注点，与作为测试者的我们关注点还是有所不同的。但那段时间促进了我们业务方面知识的增长，对后阶段的测试，效果还是很明显的。

　　3、与各部门沟通方式有待提高

　　评测师考试的内容，有一章关于测试人员能力要求的部分，内容是这样的“一个理想的测试者必须能够同测试涉及到的所有人进行沟通，具有与技术（开发者）和非技术人员（客户，管理人员）的交流能力。既要可以与用户谈得来，又能同开发人员说得上话，不幸的是这两类人没有共同语言。和用户谈话的重点为必须放在系统可以正确地处理什么和不可以处理什么上。而和开发者谈相同的信息时，就必须将这些话重新组织以另一种方式表达出来。”其实，在此之前，对沟通能力的要求有所了解，但对这点的认识却是受了局限，一直认为作为测试者，即便与开发者沟通，也应该用非技术语言进行。记得之前针对“以哪种角色方式提交Bug”展开过一段讨论，是从开发角度还是从用户理解的角度出发！？个人理解，提交Bug也是另一种沟通，因此，建议根据对象，选择合适的沟通方式。只要目的明确，便于理解便可。