大头
Table_bottom

标签云
Table_bottom

分类
Table_bottom

日历
十一月
272829303112
3456789
10111213141516
17181920212223
24252627282930
Table_bottom

评论
Table_bottom

留言
Table_bottom

微博
Table_bottom

热门文章
Table_bottom

随机文章
Table_bottom

豆瓣上谁关注这里
Table_bottom

链接
Table_bottom

搜索栏
Table_bottom

RSS
RSS Link
Table_bottom

功能
Table_bottom

页面
Table_bottom

计数器
482027
Table_bottom

访客统计
Table_bottom

存档
Table_bottom

蓝屏

尽量不要出现蓝屏。

阅读全文

关于自动测试工具

来自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去吧。