测试负责人做什么 存在的现状：
测试项目负责人都是在执行测试
带来的问题：
● 有些成员的缺陷质量不合格；
● 开发人员修改不及时，系统某些功能发生严重问题导致部分功能无法测试等等。
正确的做法：
● 测试用例执行情况；
● 测试员提交的缺陷情况；
● 测试中发生的突发事件。
测试中的版本控制
存在的现状：
测试小组版本管理不规范，造成测试对象不可控制。
带来的问题：
● 需求频繁变化，难以应对；
● 维护测试用例工作量大；
● 测试质量低下。
正确的做法：（专人负责！）
● 测试需求的版本控制；
● 测试用例的版本控制；
● 测试对象的版本控制。
提交的缺陷质量差
存在的现状：
提交的缺陷引起测试人员与开发人员的争议。
带来的问题：
● 开发的成本高；
● 回归测试的成本高；
● 交流的成本高。
正确的做法：
● 一个缺陷至少描述清楚概要描述、详细描述、重现步骤三方面的内容；
● 采用交叉测试的方法，测试工程师之间互相验证彼此提交的缺陷。
需要怎样的测试人员 存在的现状：
● 忽视测试团队，当要实施测试时，临时找几个程序员充当测试人员
● 安排一些毫无开发经验的新手去做测试工作
带来的问题：
● 测试质量低下；
● 测试效率低下；
● 测试人员觉得测试工作索然无味。
正确的做法：
● 一名资深的测试领域专家；
● 多名具备一技之长的成员；
● 多名测试执行人员（包括新手）；
● 兼职测试团队（包括同行专家）。
测试中最难克服的现象
存在的现状：
在回归测试时，之前由于进行过认真的测试，往往会认为某些功能是可靠，只要验证一些以前发现的缺陷是否修改完成就可以了。
带来的问题：
开发人员在修改缺陷时往往会引入新的缺陷，测试人员的疏于防范就会把这些缺陷带到用户那里。
正确的做法：
● 最好在最后一次回归测试时执行一次全部的测试用例；
● 测试工程师在回归测试时互相交换任务，反复测试某一功能的机会大大减少，从而也就不会“主观的”认为某些功能没有缺陷。
用来测试时间总是不够
存在的现状：
一旦整体进度不能向后延迟，习惯的做法就是缩减测试时间。尤其在功能还没有开发完成的情况下，这种现象更为突出。
带来的问题：
● 测试质量不满足要求；
● 项目经理受到指责。
正确的做法：
● 按照测试任务的轻重缓急，尽最大努力完成测试任务；
● 在实际工作中和开发人员共同配合，达到最佳效果；
● 采用平时积累的自动化测试方法；
● 不要抱怨，积极面对问题。
公司不重视测试怎么办 存在的现状：
尽管很多公司在意识上已经开始重视测试，但是在具体工作中，往往由于追赶进度、节省资源等方面原因而忽略测试工作。
带来的问题：
测试负责人仍要对软件质量负主要责任！
正确的做法：
● 要主动去配合开发人员完成工作；
● 逐渐显出测试工作的重要性，然后再逐步健全测试体系；
● 只有测试工作的业绩逐步表现出来，人们才会真正的注意到测试的重要性
管理者需要是技术专家吗
存在的现状：
在实际工作中，由于测试人员的短缺，测试管理者常常做为测试员来执行具体的测试任务。尤其在规模较小的测试团队，测试管理者的日常工作通常以具体的测试执行工作为主。
带来的问题：
测试管理没做好！
正确的做法：
● 管理者主要任务是制定测试策略，落实管理测试计划，为测试项目的进行创造良好的执行环境以及调动员工的创造性；
● 技术方面的背景知识对测试管理者是十分有益的。例如：分配工作任务、做进度预算，以及一些具体的执行工作，都需要一定的背景知识。
评估测试人员的绩效
存在的现状：
仅从提交的问题单数量、测试执行用例数量来判断测试人员的好坏。
带来的问题：
这种做法明显缺乏全面性。问题单的数量只是评估测试质量的一个方面。
正确的做法：
我们更需要看中实际的测试质量。这就需要考察问题单的质量、测试的难度、问题单的级别。
存在的现状：
对测试人员发现的问题的价值没有进行评估。
现实情况是：
发现1个系统架构设计方面存在的缺陷和隐患，远比发现几个普通界面的显示问题要有价值的多。
存在的现状：
不重视测试文档的质量。
现实情况是：
只有对系统进行了充分的、深入测试的测试人员才能写出高质量测试报告，说明测试的全面性和测试过程的质量。
存在的现状：
不重视测试人员的综合能力。
现实情况是：
需要关心测试人员的工作积极性，积极工作的态度不仅能带来很高的测试质量，还能提高整个团队的积极向上的风气。