如何逐步提高软件开发测试的质量，在人力资源缺乏情况下？
刚到公司的IT部门当项目经理，部门不大，就10多个人，IT部门做的事情基本上就是在已经购买的软件做些小小的开发，扩展，满足业务部门的一些日常改动。
然后发现这个部门基本上还没有软件质量管理的概念，基本上就是开发人员开发完程序后，自己测试一下，再写个简单的测试用例， 基本就是叫业务部门的人员点击新的功能模块和输入看是否能正常运作，然后就完事了。这样的质量不行， 有时需要返工，即使业务部门确认了，但是用了一段时间发现问题了。
我虽说是项目经理， 但是手头上没有固定的兵，而且我们部门不可能专门去招一个搞测试和质量管理，针对这种情况，基本上现在走了三步:
1. 规定每个功能用户测试至少要走两次，而且我会具体看测试的结果。（先前的项目经理基本不看测试结果，全权信任开发人员和业务人员）
2。 正在逐步转移用户测试这块的工作量从开发人员那里 去其他人员（比如就是业务部门的人了） ，有时候就是我了。我就自己写测试用例了.但是自己还是觉得要做好测试用例， 挺难的。有经验的先指点以下
3。 打算接下来新年，我们部门的人都全体培训一下软件测试和质量管理这块 。
看能不能逐渐也把开发测试这块的工作量从忙的开发员逐步转移到 其他不那么忙的开发人员 。
但是这个心里没底，不知道行不行？而且从目前自己承担部分的测试用例的工作量和工作质量来看，自己也要提高。而且做这个测试有一定程度于自己的项目管理时间有冲突。
所以来版上问一下，在这种情况下，如何慢慢的调整，把软件质量和测试这块搞起来，部门人员在这方面的水平也提高。多谢了。
[解决办法]
应该从监督测试用例开始，而不是监督测试结果。
单元测试用例是否完整，覆盖度是否够。
功能测试用例考虑是否完整，特殊情况是否考虑到，这个应该重点检查。
测试用例设计完整了，只要写的非常清晰，测试人员一般很少回去糊弄，糊弄都是用例写的不清晰，测试人员都不知道怎么去测或者期待结果描述不清晰，就会差不多对就算对。
测试用例完整，描述清晰无疑义，测试容易进行，就不必过于关注测试结果了。。
所以，第一步还是从怎么设计测试用例和监督测试用例开始着手吧。
[解决办法]
设计测试用例其实没有固定的好办法，多靠经验，但对业务的理解是前提。必须对业务逻辑有非常清晰的理解，才能进行测试用例设计。
测试用例的设计方法很多，网上一搜一大把。但实际操作如果没有经验，还是不是很理想。
我的意见是针对某个功能要做测试，首先把这个功能的详细需求列出来，把这个功能的逻辑或者操作步骤一步一步详细列出来。然后对这个详细需求进行分析，看什么地方有可能出现错误。
首先要对正常工作流进行测试，就是详细需求中列出的正常顺序进行测试，并且测试每个分支（不同操作可能导致的不同结果）。
其次对异常工作流进行测试，不按照常理进行操作。输入框的输入一些需求中没有规定的数据，超大超小，错误类型等等的数据等。
异常流的测试可以让多个开发人员参与，一个人的想法肯定有限，考虑不全，多个人考虑能够全面一些。
也可以采用模拟操作的方法，多个人实地模拟一下操作，切身感受一下功能的使用，就能够发现问题。
范本倒是没有在网上见过，可以搜索一下，看有没有。
[解决办法]
如果要关注交付质量，如果把质量保障的工作量都算上的话，或者在项目管理中关注这些东西的话，测试的投入是必然的（一个误区，不是只有专职的测试人员做的测试才叫测试，开发过程中开发者的验证也是测试）。
建议可以从新增代码的单元测试开始（单元测试一定是要可以通过持续集成体系自动运行并获得结果的），逐步建立项目组的质量门槛，随着自动化用例的逐步积累，通过体系化的自动化用例来逐步确保交付产品的质量。
