1、引入的测试需要过程。
公司中专业从事测试工作的人员和部门从无到有，这需要一个循序渐进的过程。
当前给我的感觉是一旦有了专职测试的人员存在，就希望所有的项目都能有测试人员的参与，而测试人手又无法满足。导致测试人员总是在非常被动的情况下，奔波在不同的项目组，做得没头没尾，仓促之下必然无法达到公司对测试部的期望。
任何一个新生事物，我们在接受它时，总会需要时间的，测试也不例外。
[建议]
在开始引入测试时，应当仅似一个项目做为引入专职测试人员的试点，可同时将其它与试点类似的项目做为参照，对比一下引入测试后，对于项目对于公司创造的价值在哪里，有多少。
找出开发与测试在配合中出现的问题及经验，根据测试人员的人手将项目测试推广到其它项目中去。
2、测试人员介入项目的时机
对于测试人员最重要的不是技术，而是业务。测试人员在项目中介入的时间越早，越有利于他们尽早地熟悉项目业务、发现并纠正其中不合理的地方。一般应在需求阶段就介入，并参与到对需求的讨论中。修复需求中的BUG，对于整个项目需要的成本来说是最低的。
如果测试介入的过晚，他们就来不及熟悉项目的所有业务就得投入测试，对于整个项目的质量而言，风险比较高。
3、测试环境
对于测试环境，应保证与用户最终的生产和使用环境一致（包括操作系统、数据库、浏览器、安装部署的方法、打补丁的流程），这样才有利于查找和发现问题，测试工作才会有真正的意义。
4、测试人员及开发人员的考核
当前对于测试和开发人员的考核是以BUG的数据为依据，这一形式有些过于理想化了。对于管理而言简单，但实行起来可能会带来更多的负面影响。
深圳的华为公司曾经也是采用这一机制来评价开发和测试人员的绩效，造成了开发和测试人员之间关系非常紧张，不利于团队之间的团结与协作。
[建议]
建议改为其它形式，如给团队中相关协作及管理人员发放问卷的形式，来收集对被考核人的评价，来综合评定考核绩效。问卷内容可包含技术、协作、沟通等。
5、测试人员的要求
作为测试人员，至少应考核的内容有：逻辑思维能力，勤于动手的能力，耐心和责任心。
良好的逻辑思维能力，可以更好更快地理解项目中复杂的业务；
测试不只应有开放的思维，也应有把思维转变为对项目有用的测试用例的动手能力；
测试用例作为测试的输出物，及测试人员之间交流、作为项目传承的文档，必须认真对待，需要测试人员的耐心和责任心。
6、项目进度的估算与控制
项目的进度在进行估算时不太合理。没有考虑到人员对项目及开发框架熟悉学习的时间，项目中人员的技能水平，项目中人员的可能变动情况，测试需要的资源准备及测试执行时间。
工期过紧，开发和测试人员压力过大，可能会导致两个严重的问题：
（1）把开发人员还没有经过自测的程序交给测试人员进行测试，造成BUG大量爆发，对于测试和开发人员的信心都会受到打击；
（2）开发人员对于测试找出的问题不予理睬或无暇修改，把所有问题都留给了最终用户，导致用户对公司项目的质量产生怀疑，公司对测试人员的工作质量产生怀疑。
7、资源备份（人力及项目概况）
测试与开发人员对于项目的意见出现分歧时，需要向需求人员或查找相关文档进行求证，如果对于需求文档或需求人员没有做好备份，此问题将会突显。
网友评论