尽量不要出现蓝屏。

来自51testing的一个讨论。

http://topic.csdn.net/u/20090723/11/a51ddd7c-d76d-4df7-986c-d75b1bdbbe66.html

“项目管理不适合做讲座，只适合做咨询，因为每个公司的情况是不一样的。”

o6z几年前好像就说CSDN软工版都是侃爷，光说不练只知道些理论没有实践经验。

我很惭愧。几年来也就是偶尔上去看看，处理一些违规帖。

确实，问一些很二，很无聊问题的人很多，同时，很二，很无聊的回答也很多。

有时挺让人看着生气。

譬如这个问题：何保证软件质量呢？一般都用什么方法或工具？

我的回答是：我也想知道有什么工具能保证牛奶的质量。

下面是一个我觉得很二的回答，而这个回答可能会得到这个帖子全部20分的一半以上，在那里往往是写字越多，得分越多：

好大的题目啊
质量问题现在越来越受关注
不同的人有不同的看法，不同的人有不同的作用
客户，系统设计人员，项目经理，开发工程师，QA人员，测试人员
PS：突然发现这几个角色我都扮演过，哈哈哈
总之把各个阶段的缺陷控制住就相当不容易了
个人觉得，需求理解和设计阶段是最重要的，此时引入的缺陷，在分析设计阶段被发现了还ok，真正到了后面就闹大了
慢慢总结，关于质量真的有很多话题可以说
说到工具和方法，缺陷跟踪工具，缺陷围堵方法，同级评审，技术评审，需求评审，总之评审是个很好的方法～～就是太花时间和精力
一家之言仅供参考
祝你成功

很多时候，人们并不打算为其口头的表述承担责任。因为“说得轻巧”，往往就脱口而出。

事后如果出了问题，可能确实记不确切自己曾经是如何说的，也可能不承认的效益更大。

而人们对于必须写下来的东西，会慎重很多。其程度是纸笔写下 > email/电子文档 > 口头表述。

所以在承担责任的扯皮中我建议无论接受上级的任务指派，还是和其他同事关于工作内容的交流，使用email。

重要事宜，打印，签字。

如果同事不愿意回复email，只是口头传达。告诉他口头之外，再发一封email，以免你遗忘。发给他的询问email同时cc给你的上级和他的上级。

组织结构：

Z是内容部员工，B是技术部员工，A是B的上司，同时也是总管。就是说，A也是Z的上司。

事例：

一个特殊任务，A口头告诉Z可以使用免费代码，具体代码问B。

Z口头问B，B口头告知是F代码。

Z使用了F代码。

次日，发现出错了。

A追究是Z做错了，先声称自己从来没说过可以这样做。

Z回答B告知使用F代码。

A说B称从未说过。B事后称其说的是FX代码。

怎么办：

1）与B当面澄清，是否有曾去询问一事。有则是如何回答的。

2）以后，对于上司口头交代的任务，听完后说：“好，我知道了，请你再发一封email给我。”如果不愿意发email，就把接受到底任务写一封email发给上司，问他是这样吗。发出后电话或口头告知。

3）对于在和其他部门同事合作中，任何需要对方确认的事，务必使用email。记录下合作过程中每个人对自己的工作内容所做的判断和选择。

有人问：“在做测试计划时，如何估计软件的缺陷数量？”
这实在是一个很二的问题。
做计划的时候干吗要去估计Bug有多少？
有人回帖说：“作测试计划的时候，是应该估计一下该软件的BUG数量，BUG集中点，以及修改该BUG的难度与时间，如果这些不估计，那编写测试用例的时候无法对某些重要模块作出着重测试”。
神了，做测试计划的时候都能估计出修改Bug的难度和时间了，也别计划了，赶紧解Bug去吧。