19、 你们的项目组使用缺陷管理系统了么？
应该用。ClearQuest太复杂，对于小型的项目也不够灵活，BugZilla或者JIRA，还有TRAC也行，特点是可以定义缺陷处理流程。
20、 你们的测试组还在用Word或者Excel写测试用例么？
不要用Word或者Excel写测试用例（Test Case）。应该用一个专门的系统，可以是Test Manager，也可以是自己开发一个PHP的小网站，或者现成的也有不少。
21、你们的项目组用了你能买到最好的工具么？
应该用尽量好的工具来工作。比如，应该用VS.NET而不是Notepad来写C#。用Notepad写程序多半只是一种炫耀。但也要考虑到经费，所以说是“你能买到最好的”。
22、值得再多花一些时间，从95%做到100%好值得，非常值得。
尤其当项目后期人困马乏的时候，要坚持。这会给产品带来质的区别。
23、 登记新缺陷时，是否写清了重现步骤？
要。这属于开发和测试之间的沟通手段。就算是可以面对面沟通，详细填写重现步骤也是很必要的。
24、 写新代码前会把已知缺陷解决么？
要。每个人的缺陷不能超过10个或15个，否则必须先解决老的bug才能继续写新代码。
25、 你们对缺陷的轻重缓急有事先的约定么？
必须有定义。严重程度要分几个等级约定好：蓝屏和数据丢失算等级1，功能错误算等级2，界面上的算等级3等等，但这种约定可以根据产品质量现状适当进行调整。要根据项目来确定等级的划分标准。
26. 所有的缺陷都是由登记的人最后关闭的么？
Bug应该由登记BUG的人来关闭。开发者不能私自关闭Bug。这可以通过缺陷管理系统的流程来控制。
27. 你们有没有专职的软件测试人员？
要有专职测试。如果人手不够，可以交叉测试，千万别自己测试自己的。自己的孩子舍不得打。
