rework

<rework>,中文名《重来》,一本最近比较火的书,周四拿到书,今天刚过了一遍,真是一本好书,尤其推荐在startup公司的朋友们读读。肯定会让你全身热血沸腾。下面是一些阅读体会:

  • Planning is guessing – 一个字:干!回头想想,以前曾经有过很多“计划”,最后都是一句“计划赶不上变化啊”就丢到一边了,别计划了,开干吧。就好像那个adserver regression UI那样,不需要计划,想到什么就做什么。
  • Scratch your own itch – 只有你自己才知道你需要什么样的工具来改善自己的工作,所以我建议AF QA的同事,别在原来adserver那个工具上改,做一个真能解决问题的regression
  • Start making something – 其实web.py看一天就可以开始动手做东西了,咱们又不是要应付考试
  • Ignore the detail early on – 之前就是犯过一个这样的错误,想做一个很酷的功能,折腾了1天,都没做出来,最后用一个朴实的方案,2个小时就OK了,而且据我观察,其实这个“功能”大家用的并不多
  • Launch now!
  • Meeting are toxic – 现在在公司还好,大家开会都很理性 : )
  • Good enough is fine – 这个东西是有点山寨,但是我们也不需要show给客户看嘛,呵呵
  • Go to sleep – 前段时间老加班,效率真的降低不少,工作时间的延长并不代表能完成更多的任务
  • Don’t copy – 我的成功可以复制,但是不能粘贴 – [段子]
  • Send people home at 5 – 赞成,但是不太现实

书中还有其他很多很好的观点,没能一一列出,如果不想买纸版书的朋友,可以找找哪里有PDF下,这本书是http://37signals.com/出品,大家可能不知道这个公司是干嘛的,没关系,Ruby on Rails听过吧?作者就在这个公司。

《Software Testing》第二十一章 – 软件质量保证

Quality Is Free – 质量是免费的。

质量为什么是免费的呢?因为其实一个公司可以不花费额外的开销就能生产出一个高质量的产品。回到前面书中已经提过了,越晚发现缺陷,付出就越大,而且这个不是呈现线性增长,而是指数增长。

把达到高质量产品的花费划分为两种不同类型,一种是conformance cost另一种是nonconformance cost。conformance的开销是指-计划测试并且运行一次测试证明软件是正常工作的,对于这些活动的总开销,就是conformance cost。如果软件存在缺陷,那么投入到隔离缺陷,提交缺陷报告,回归测试等相关活动的开销,就算是nonconformance cost的一部份。以上的错误都是在产品发布之前发生的,所以归类未内部错误(internal failures),而且总体的付出的不多的。
Continue reading “《Software Testing》第二十一章 – 软件质量保证”

《Software Testing》第二十章 – 度量你的工作

Using the Information in the Bug Tracking Database – 善于利用缺陷跟踪系统的数据。

我们把缺陷提交到数据库以后,其实我们得到不单只是一条记录那么简单,我们还能从里面得到更多。例如在1个月前项目的进展情况,在哪些模块上发现了多少的bug,上周的情况如何?我们还能根据这些数据来预测将来大概会是一个什么样子的情况。我们可以定义许多度量标准。有些公司可能用一个测试员发现多少bug来作为一个标准,其实这是不科学的,因为有可能刚好那个测试员所测的模块是由一个高手来写的,或者那个模块特别复杂然后做这个模块的人特别没经验,那么结果就相反了。

Metrics That You’ll Use in Your Daily Testing – 日常工作中常用的度量
除了提交bug,缺陷管理系统里面另外一个常用的功能莫过于查询出我们感兴趣的bug了。呵呵。我自己在公司就有几个查询,就是用来查找自己提交的bug的。随时跟踪情况。还有就是查询特定ID的bug,查询一下BUG的标题,看有没有重复提交的。
Continue reading “《Software Testing》第二十章 – 度量你的工作”

《Software Testing》(软件测试)读书笔记系列 – 第十九章

这个测试执行完了发现bug也不能随便跟人说说就算了,要记录下来

Getting Your Bugs Fixed – 让你发现的缺陷得到修复
不是我们找到什么bug,都会得到修复的,有些可能推迟,有些可能被忽略,有些可能作为下一版的feature。以下原因是为什么一个bug没有被修复

1.There’s not enough time – 时间永远都是紧张的。
2.It’s really not a bug – 业界有个名言“It’s not a bug, it’s a feature!”呵呵。
3.It’s too risky to fix – 对于一些遗留系统,他们就好像定时炸弹,没人敢碰他们。
4.It’s just not worth it – 不值得修复。这些决定都是商业决定或者基于风险的而得出的结论。
5.Ineffective bug reporting – 一份非高效的缺陷报告。测试员没有很好的对缺陷进行描述。

针对最后一条,也就是这章的重点,要记住以下一些报告缺陷的基本原则:
Continue reading “《Software Testing》(软件测试)读书笔记系列 – 第十九章”

《Software Testing》第十八章 – 编写和跟踪测试用例

The Goals of Test Case Planning – 测试用例计划的目的

测试用例计划的目的是什么呢?如果你想要别人按照一定的规矩办事,那么你自己也必须首先遵守这些规矩。所以作为一个测试员,如果一拿到测试计划就坐下来疯狂的写Case,那么跟一个不看产品说明书就开始编码的程序员是一样的。我们要仔细地而且系统地去计划测试用例,为什么要这样子呢?有4个原因:

  1. Organization – 一份好的计划可以被很好地组织起来,这样的话出来你以外的其他人就能有效地回顾你的成品
  2. epeatability – 如果没有一个正确的计划,那么是不可能知道我们的测试用例运行情况,而且几乎不能被重新使用,因为通常你都不知道它在哪里
  3. Tracking – 可追踪的。有了好的计划,才能追踪项目的进度,多少case已经被执行了多少pass多少fail。各自状态如何。
  4. Proof of testing (or not testing) – 证明已经测试过的。这个记得以前在reyrey的时候一个老外就说过,测试用例能够帮助公司避免法律的纷争。

Continue reading “《Software Testing》第十八章 – 编写和跟踪测试用例”

《Software Testing》第十七章 – 计划你的测试

制定测试计划的目的是增强测试团队内部和外部的沟通,统一期望,还有对将要被执行的测试的理解。测试计划(Test Plan)只是制定测试计划过程的一个副产品,并不是制定计划的目的。当然啦,这个测试计划的文档还是相当重要的。不过要提防一种现象 – Shelfware – 那些文档永远都是躺在硬盘里面,没有去人看它。

Test Planning Topics – 测试计划的主题。

1.High-Level Expectations – 概要期望。这个问题经常被忽略,因为这个问题实在太明显了,以至于大家都默认其他人都知道了。不过作为一个测试工程师,永远不要去假设。
a.你知道制定测试计划和软件测试计划的目的么?如果你知道的话恭喜你,不过你能保证程序员,经理还有其他相关人等都知道么?还有一个更加重要的问题,他们都同意么?
b.什么样的产品会被测试?这个问题真的很幼稚啊,不就是XXXX3.0嘛。我们公司的产品,但是这个产品在什么时候release?是个简单的升级还是改头换面的大变化?是在公司内部完成的还是外包出去了?等等……完全了解一个产品是成功完成任务的关键。
c.产品的对质量的要求是到哪个水平?不同的人会有不同的要求,但是很多要求都是不可度量的,例如速度快,所以要定义一个被大家所接受的Scope是非常重要的。一定要明确指出测试的目标,而且还要得到大家的同意。这里或许需要有很多人的妥协。
Continue reading “《Software Testing》第十七章 – 计划你的测试”

《Software Testing》(软件测试)读书笔记系列 – 第十六章

Bug Bashes and Beta Testing – bug盛会和beta测试

Having Other People Test Your Software – 让其他人来测试你的软件。这个跟中国古代的“三人行必有我师焉”是一个道理。同时,如果由几个不同的人来测试的话还能有很多好处:

1.可以防止“杀虫剂免疫”。一个人对某个软件不断进行测试,能找到的bug肯定是越来越少的。所以需要加入一些新鲜的血液:)
2.每个人都要自己的想法,不同的想法的一个并集就能很好地测试我们的软件啦!
3.男女搭配干活不累。那没有男男女女,几个人也行啊~反正一个人容易诱发自闭,呵呵。
4.观察其他人怎样工作的对自己的提高是相当有好处的!

Continue reading “《Software Testing》(软件测试)读书笔记系列 – 第十六章”

《Software Testing》第十五章 – 自动化测试和测试工具

我终于看到自动化测试了,呵呵,不过这章不是我想象中的那样子,可能这本书并不是主要介绍自动化测试的吧。

The Benefits of Automation and Tools – 自动化测试和使用工具的好处
自动化?那要人干啥!呵呵……人不就是用来实现自动化囖。自动化测试有什么好处,面试的时候经常有人问,答案其实没有十分标准的,不过通常都离不开那些老论调。

The principal attributes of tools and automation – 其实是工具的属性。与生俱来的能力

1.Speed – 速度。机子执行的速度是人的N倍,不顾这是要付出代价的,在你教会电脑做事之前,那就是一堆废铁。
2.Efficiency – 高效。当机子在一边跑case的时候你还能设计出新的case。事情真的是这样子的么?估计是在调试脚本吧。
3.Accuracy and Precision – 准确和精确。电脑可以全天工作不休息而且不会出错。人是铁饭是钢,一顿不吃饿得荒。

Continue reading “《Software Testing》第十五章 – 自动化测试和测试工具”

《Software Testing》第十四章 – 网站测试

这个Web系统测试可以出一本不厚不薄的书,而且现在就是有卖的,作者什么都忘记了,就是记得已经出到第二版了。呵呵……所以这里就是带我到门口而已。不过他的编排挺巧妙的,这章讲web系统的测试,中间引出一些困难,然后下面就是自动化测试了。

Web Page Fundamentals(网页基本原理) – 网页包含的元素还是网页的一些特征,相对于传统的光盘媒质,网页元素有其特别的元素和不同。我高中的时候就尝试做网页,然后也做过一些玩,因为那时候很多免费的空间。不过正如书上说的一句很精妙的话:不要以为给你一只画笔你就成艺术大师了。最后我的网页还是不了了之。很多网页都有但是不局限于以下的基本元素:

1.大小各异色彩缤纷N多不同字体的文字。
2.图像和相片
3.文字和图像超链接
4.广告
5.下来菜单
6.可以添文字的表单

Continue reading “《Software Testing》第十四章 – 网站测试”

《Software Testing》第十三章 – 安全性测试

黑客的动机!
1.Challenge/Prestige – (挑战性和威望)通常在一个社区里面有某些高手进入了某些号称安全性很高的系统里面,对于那个人的威望的树立是很有帮助的。而且这也是意见很有挑战性的事情。
2.Curiosity – (好奇)人就是这样子,你不让我看我非要看!
3.Use/Leverage – (使用和利用)利用电脑传播病毒,或者干其他坏事。
4.Vandalize – (破坏)随便删除别人的资料,或者利用肉鸡攻击其他系统。
5.Steal – (盗窃)偷取一些重要的资料,例如商业资料,客户资料~

Continue reading “《Software Testing》第十三章 – 安全性测试”