小抱怨

我是测试和开发一并包了。。。。。。

开发也需要自动化的回归测试，这样才能避免“直接找到代码, 修掉. 而往往修了这个bug, 不小心动了其它代码, 新的bug又产生了... ”这种情况，
开发和qa的压力都会小很多。

那应该是D喽

美女發帖果然，一下子就良好了！

JE很民主的... Orz

c#

如果开发能保证代码质量, 就不会发生这些事情. 做code review, 做单元测试, 动代码时候也同样仔细思考其它相关联的功能和模块.

项目初期, 应该是有先在自己本地测试, 然后再上传到svn, 然后再在开发服务器上测试一次. 因为那时候我们的bug不会把请求等贴上去, 只写出了测试的步骤, 期望结果, 实际结果(普通的错误报告的写法), 这样需要开发人员找出原因, 去重现步骤, 后来QA为了提供给客户更多详细信息, 才加上了request, service, response这些内容, 慢慢转变为开发直接修代码. 而不会思考更多.

如果发现bug是开发测试各打50大板的话, 大家也都会更加小心, 而现在有问题只打测试100大板, 总之有QA兜底儿, 总之那句"早怎么不发现"就是对QA喊的, 总之奉行那句"有bug就是QA的不好"的话, 久了自然有安逸心理了.

其实这就像一个跷跷板, 一边压力大了, 另一边压力就小了.

mm总结的真好，赞一个。
球队丢了球就赖守门员，我猜教练一定是疯了。对于这种愚蠢的制度，mm试过向上提出建议，或者见过其他人反映吗？结果如何？

过讲

提过意见和建议, 但是冰冻三尺的事情, 想改变总是很难. 

当然, QA本身也有问题, 常期对于一个软件做大量频繁的回归测试, 会产生盲区. 
克服盲区, 可以找其他QA来测试, 但是这又涉及到对这个软件的熟悉程度. 

客户也有不尽意的地方, 不给文档, 不给业务逻辑, 发布前不沟通, 新版本不给更新列表.

哎, bug是永远无尽的, 只是努力做到更少.

bug, 重复提交...

过讲

提过意见和建议, 但是冰冻三尺的事情, 想改变总是很难. 

当然, QA本身也有问题, 常期对于一个软件做大量频繁的回归测试, 会产生盲区. 
克服盲区, 可以找其他QA来测试, 但是这又涉及到对这个软件的熟悉程度. 

客户也有不尽意的地方, 不给文档, 不给业务逻辑, 发布前不沟通, 新版本不给更新列表.

哎, bug是永远无尽的, 只是努力做到更少.