在需求/测试环节出现了问题，迫切需要大家帮忙解决一下

fionn1129

按照部门职责的规划，我这边负责向研发提需求，另外一方面，就是负责产品成型后的测试。

现在产品质量不好，怨声四起，我很困惑，归结起来我觉得有如下原因：
1）首当其冲的是没有足够的人才储备。今年并行了多个项目，但是研发人数并未相应增长，很大程度上导致需求完不成。同时，测试人员素质不高，导致测试效率低下；
2）测试人员介入太晚。这点是我猜的，因为我没有什么研发经验。一般都是等软件可以打包以后才进行测试，这样是不是存在很多隐患了？是不是可能好多缺陷已经很难解决了?
3）版本管理不规范。公司还没有到达产品引导用户的地步。进行了需求澄清，但是在研发期间又不断的添加新的需求，并且很多需求是由于招投标引起的，所以研发不得不进行这些需求的投入，一定程度上导致了原定的需求实现日期无法满足；

是不是应该我这边去把握研发是否按照需求在完成呢？是不是应该我这边去跟研发建立若干个check点呢？在这样的一个状况下我应该怎么做呢？请大家给我一点建议吧，我真的是太困惑了。

dionysus

人才的贮备不是一时半时就能跟上的，怎样培养人我们可以努力，但怎样留住人就不是我们能做主的了。
一般测试从系统阶段开始也不算晚，只要测试人员前期做好充分的准备，如仔细阅读需求文档，编写测试用例，这样测试起来就会效率很高。
需求的频繁变化是很让人头疼的，最好需求能制定一个基线并通过评审，不达到这个基线版本是不允许发布的

fionn1129

基线是比较好制定。

但是来自市场和销售的压力很大，一会儿加一个东西，一会儿加一个东西。并且确实软件没有一个明确的功能划分了，完全按照客户需求来。这样是不是不对的？

yiyi820106

需求经常变更的话测试人员应该做些主动变更
   1.及时了解需求变更的详细情况，尽早调整测试计划，不要闷头按原计划测试。
  2.将软件中稳定的部分与易变的部分区别对待，前者先测试，后者后测试
  3.设计一些比较灵活的测试用例，能适应某些变更

luoyear

国外通用的方法：Sign需求，对项目变更的范围额外收钱。
国内通用的方法：用无限期的拖延来弥补客户理想与项目现实的差距。