4、 状态为已经修改的缺陷没有修改怎么办？
　　首先对这类缺陷进行分析：
　　（1）有些问题在开发环境下没有重现，而开发人员迫于进度压力，往往会把它标记为已经修改。这种条件下测试人员应该和开发人员进行直接沟通；
　　（2）有些问题测试人员没有描述清楚，开发人员认为问题不存在也可能把问题标记为已经修改（正确的作法是标记问题为商讨或者不可再现状态）。测试人员应该清晰的描述问题，减少这类问题的发生，尤其要描述清楚运行的环境以及缺陷的重现步骤；
　　（3）第三类情况纯属个人行为：迫于进度压力，开发人员来不及修改问题，会故意把一些问题标记为修改，这样就可以在下次测试后进行修改。解决这种问题的方法就是统计缺陷的修改次数，分析出哪些反复修改的缺陷归属于哪些开发人员，然后告知项目经理；（由可能和绩效考核结合起来。）测试人员遇到这种情况，需要重新打开哪些未被修改而状态为修改标记的缺陷。
　　决这种问题的根本方法就是加强项目管理，提高项目执行能力，一旦资源较充裕时，测试人员和开发人员就会更加投入的一起解决缺陷，共同来提高软件质量。这就需要在制定项目计划时尽量要合理。

　　5、 产品测试完成后产品由谁来发布？
　　很多时候产品经过最后一次测试后由开发人员来发布，或由质量管理部来发布，这样做都是不合适的。
　　开发人员发布产品常常会导致缺陷解决不彻底。一种较常见的现象是最后一次回归测试后，开发人员修改完成最后几个缺陷直接从开发环境发布产品，这种条件下实际是缺陷一次测试，因为修改缺陷通常会引入新的缺陷，甚至是严重的缺陷。
　　测试人员发布产品也不符合流程的，测试人员的职责是报告软件质量情况。而且测试人员发布产品容易带来版本管理混乱。
　　正确的做法是产品经过最后一次测试后，把产品和缺陷修改情况存入产品基线库，形成一个可以发布的版本。这样发布产品的一个前提是每次产品提交测试前都要有一个预备发布版本，测试或者回归测试后如果有问题需要修改解决，开发人员对该预备版本进行修改。如此反复多次后，直到最后一次测试，所有缺陷都得到修改或者审核，同时开发人员此次测试后没有对产品经过任何修改，我们就可以把这个最后一个预备发布版本存入基线库。
　　进行了上面正确的版本控制后，我们可以通过配置管理库进行产品发布管理。对外部发布产品时，直接从配置管理库中提取就可以了。

　　6、 用户试用阶段产生的新需求或修改意见由谁来处理？
　　在试用阶段用户会提出一些新的需求或修改意见，这些意见的反馈渠道应该是怎么样的呢？是反馈给测试人员、质量保证人员、项目经理还是项目的负责人？实际情况证实，这些新的需求或修改意见，反馈给项目经理或项目的负责人是最好的渠道，这样项目经理或项目负责人能够直接得到项目的修改意见或新增需求，而不是其他人员的转述。还因为项目经理或项目负责人是项目的设计者、开发者，他们对软件系统最熟悉，对于用户提出来的新的需求或修改意见可以根据系统的实际情况，应允合理的需求和合理的修改意见。屏蔽一些不合理的需求或修改意见，或给用户一个合理的不能修改的解释。
　　如果先给测试人员或是质量保证人员，效果不会很好；首先测试人员得到新的需求或修改意见后，不能马上确认是否修改，不清楚修改这些功能的工作量和是否有技术上的难点等疑问。其次在测试人员得到需要后，仍需要转述给项目经理或项目负责人，这样在一定程度上浪费了一些时间。主要表现在，如果测试人员没有完全理解新的需求或修改意见，这样在转述的时候就会有偏差，还得需要项目经理或项目负责人在对需求或修改意见进行再次确认，这样就产生了不必要的工作量。