1. 大型通用软件的开发就是以质量第一的原则
软件在卖到几十套的时候，质量只要过的去就可以了，但一旦软件卖到上千套，质量就绝不能以对付了事，否则维护部门的电话就要被打爆。测试人员一般的能达到开发人员的1/3就比较合理了，如果是刚起步的公司，考虑到 成本因素，而且大多是以开发项目为主，所以在测试上可以相对的放松一些，但一旦 公司进入正轨，开发规模增大之后，一定要重视测试。测试人员、开发人员、设计人员 都围绕需求进行工作，需求文档也是所有人员的主要依据，测试人员实际上起到了监督 开发人员工作的作用，而且也为工作的绩效考核提供了量化的依据.

2. 测试不能“教条主义”
测试也开发一样，也是一个实践性的工作，一个测试人员长期在进行某产品的测试，自然 会积累大量的经验，这些经验很难归结到一些测试理论中。在一些开发不太正规的团队中 反倒有一些过分迷信理论的倾向，其实实际操作并没有那么复杂，一个ERP系统的测试主要 就是功能测试，说白了就是光标点来点去，如果整天捧着厚厚的软件工程书，反而把简单的 问题复杂化了，当然在有一定测试经验后，回头看看理论。理清自己的思路也是有好处的.

3. 所有文档中，需求文档最重要
一般的，大家都是一致的对待各种文档，需求文档、概要设计、详细设计、测试报告等等， 但如果要排一个重要性的顺序的话，需求文档无疑是最重要的，在确定需求上花再多的时间 也是值得的，其次，设计文档也很重要，至于一般的将设计文档分为概要和详细两种似乎必要性 不大，如果是企业信息化系统的话，设计文档应该重点把后台的业务逻辑描述清楚，有可能的话把SQL语句都事先写出来，如果系统达到一定规模，应该会有大量的UI端的公共控件，所以在设计文档里只要把界面的大致轮廓描述出来即可，另外要把输入数据的约束说明.
在时间分配上，一般的，需求占1/4，设计占1/4，编码和测试占1/2。而且在编码和测试的时间段 里，纯粹的编码时间占的更好，测试的进行过程中往往要对代码做反复修改.