1. 缺少“产品”的概念
开发人员或者产品相关人员，缺少从“产品”的角度考虑问题。常常表现为以下几种情况：
一、产品版本功能规划不合理
举例：首个测试版本，仅有登录，没有退出。这种情况登录后要想退出重新登录，只能卸载软件，重新安装才可以，试想，谁会去重复安装n次来测试登录呢？暂且假设有人这么做了，每次都是卸载后重新安装进行的登录，测试结果可靠不？可想而知，显然，第二个版本的时候问题暴露出来了，虽然有退出功能了，只能登录一次，退出后就不能再登录了。
从产品的角度来看，产品应该是这样的，登录-功能模块操作-退出。确保这一整个流程都是通的。如果时间来不及，中间的功能模块可以减少。这就是所说的“做产品做一半”。
二、产品基础功能不能用
开发不进行简单的流程性测试就抛过来给测试，结果经常是主要功能都不可用。结果只能打回去，重新打包。
三、程序数据写死，为开发自测用数据
程序中的数据不是根据具体用户动态获取的，而是开发写程序时写死的测试用数据。
举例：登录，登录帐号是写死的，不管用哪个帐号登录，都是写死的帐号，这样与用户相关的信息无法真实体现，比如学识获取，课程学习情况，这个使得本应该在前期版本中就应该发现的问题到后期版本中才暴露。
2. 开发对需求理解不够透彻
明明有需求原型，但是就不按照需求原型来，或者是部分按需求原型来，部分不按照需求原型来，结果就是开发出来的产品常常是不符需求。要知道，毕竟工作性质不同，人家产品也不是吃素的。
3. 代码管理混乱
缺少对代码进行管理，常常表现在以下几个方面:
一、原来已经修复的问题再后面版本中又重现出来
二、每次提交测试的版本都不稳定，每个功能模块都出问题
简而言之就是：代码的修改没有很好的控制，过程比较随意，常常是大动手脚，结果到最后没有一个版本是相对稳定，可用的版本
4. 开发和测试缺乏互动
开发提交版本测试的时候，没有提交changlog或者提交的changlog不 明确。这样，如果系统比较复杂，测试人员除缺陷管理系统上提交的缺陷是否被处理外，不懂其它模块是否有做修改，哪些地方没做修改，测试人力不足的情况下， 时间短的情况下测试也就比较没有针对性，自然也就比较容易产生漏测。所以建议要加强这种文档反馈机制，当然口头交流能做到也行。
5. 时间太赶
测试在赶，开发在赶，反正就是很赶，一赶就出问题，常常看到bug被标记已解决，但是新版本测试中发现bug原封不动的存在，，，，，，所以，项目负责人应该学会谈判和计划，尽量为项目争取时间。
6. 不够重视
对提出的问题不够重视，结果就早期提出的问题在往后延几个版本才被处理
7. 考核机制不合理
考核这东西有利有弊，好处在有考核有压力、有责任感、有处罚，坏处就是为了通过考核，逃避处罚，可以不择手段，应付了事等