开发水平很大程度决定着测试的任务量，碰到这种开发你们怎么做……
开发什么样的水平我想负责对应模块的测试员应该都了解，为什么说开发水平很大程度决定着测试员的任务量了，这个开发水平——技术只占部分，更多是对自己负责的模块上不上心，就拿我们公司的开发来说，我们技术一部包括经理5个人，2个开发、一个UI设计、一个测试，两个开发的水平有很大的差别，最差除了工作，私下都不想与之打交道的人，我在负责他所做模块测试的时候就能看出，他开发依赖性很大，做完一个功能模块最基本的测试都不做——也就是自己测试这功能有没有实现，但是他不做，全凭自己的，自认为牛B的技术觉着行就OK，后面有个测试，有问题测试提出了再改，觉着这是测试员该做的——所以测试的时候往往最多BUG就是功能跑不通没实现——这才是真真的碰到了猪一样的队友:后来跟他说了下——好了一点点，比如现在手头上的一个注册功能，测了我好几天不是这里有问题就是那里有问题前后找出50好几个的BUG，仅仅一个注册功能而已，虽然字段有点多，先在还没测完，可见其水平——做人方面——除了经理我们几个都是不主动搭理他的——不但如此还不识趣
一直在蛋疼中纠结以后测试该咋办啊…… 对事不要对人，这是基本的职业道德，你这样也无助于问题解决。。。
开发人员水平如何不该我们测试人员下结论。。。
至于他的为人，觉得很差不与其交往就是了，但尽量不要把情绪带到工作中，如果带上了感情色彩这往往就先是你的不对而不是他了。。。 老实说 一个注册功能就50个BUG
还真不能让人淡定
第一，但是你们没有BUG数量的预估吗？这样明显是要超的啊 虽然预估了也没什么用 但是经理总要看看吧
第二，我们之前是每天high以上的BUG会给项目经理 各个领导写邮件
功能跑不通没实现的必然是high以上了
第三，我们要求程序员手上未修改的BUG不超过5个 如果不自测 肯定会超 改也是他的工作嚒 提示一句，转测试，是要有入口准则的，让开发人员把这么差质量的东西交付你们测试，你们也有责任啊 测试正是介入条件是 冒烟测试通过显然你需要强行来规范这一点
另外你们的团队小，就多通融点人情吧。冒烟测试不通过，可以帮助研发进行联调，来推进项目，总比相互指责要好些
页:
[1]
