本文主要面向软件测试的初入门者,但对有经验的软件测试工程师也应有益。
我起初准备自己写10条建议给刚入门的软件测试员们。但之后我看了lolcats/icanhascheezburger 上的名人Ben Huh的一段演讲。Ben指出,有了互联网,信息成了免费资源,但组织,编辑,以及表达却都需要技巧。受Ben和cheezburger网站的启发,我请求60名成功的软件测试工程师每人为刚入门的测试人员提出三条建议。其中的40多名答复了我,使我最终有了一个长达100条的建议列表。
出于保护他们的隐私,我不会原封不动的把这些建议罗列出来。但是有趣的是,我发现他们的建议中有很多共同的地方,而所有这些建议综合起来要比我原先自己想到的好得多了。
我把这些我搜集的建议总结成以下19项:
1. 想客户之所想
在测试的过程中时刻想着用户。培养自己对用户需求的共鸣。和用户沟通并且观察他们怎们样使用你的软件。
2. 多读Bug
如果你和一个团队的软件测试工程师一起工作,那么请阅读 他们每天发的Bug, 特别是那些针对你的测试部分
3. 多读代码
找到你测试的那部分功能的代码。虽然写代码并不是你的事,但是读那些代码常常会帮助你找到潜在的边际情况和软件缺陷。
4. 为你发现的Bug而骄傲
促成一个软件Bug的修复是从写好Bug标题和描述开始的。我每次发完一个Bug都会把这个Bug重读一遍以确保它是合理的并提供恰倒好处的细节。如果一些重要的Bug 没有被纠正,要追根究底,确保决定和利弊权衡是正确的。
在软代码编写之前,在仍有可能有大的设计变更的时候,积极参加软件的计划阶段,这会帮助你了解正被考虑的折衷和权衡。
6. 设计你的测试
无论是寻找边界值,运用组合技术,画图表,或创建测试模型,把你的想法放进你的测试设计中总是有用的。在试探性测试的时候,有意识地去交替你的测试计划和产品学习。
7. 了解你测试的功能
不管你测试的是那一块功能,你应该了解它的设计,它的局限性,别人发现的Bug,代码的变动,以及它和其它功能间的交互关系。
8. 和别人合作测试你负责的部分
和有不同专长的人一起测试你的功能模块,一起讨论测试的点子并且征询他们的反馈意见。
9. 学习你测试的软件
即使你只是测试一个软件中的很小一部分,成为其它新功能和整个软件的专家都会帮助你成为一个更好的测试工程师。
10. 培养和开发人员的良好关系
测试工作有时候是对抗性的,以致很容易使有些与你共事的人在做决定时忽略你的意见。与修复Bug的开发人员建立坚实的关系对了解最新进展和促成Bug的修复会有裨益。
11. 扩大你的领域和人际网络
成功的人都有一个的坚实可信的交际圈。他们可以从中得到他们需要的专业知识和建议。不断在你的公司内部和外部结交新朋友并发展专业领域的联系。
12. 寻找良师或榜样
我和许多出色的测试工程师一起工作过,并且从他们那里学到了很多东西。为了提高你的测试技能,你应该寻找“顾问”与他们见面或者榜样向他们效仿。
13. 保持自省
测试工程师善于发现软件的缺陷。如果把这种敏锐运用到自己身上,我们一定能更有效的发现自身的不足之处。
14. 管理你的时间
我们的时间很容易被大块的工作和不断的会议所占据,导致我们没有时间去学习,去深挖更多的Bug,甚至没有时间保持健康的生活状态。为了避免透支,你需要学习如何管理你的时间。
15. 明智地选择测试自动化
自动化测试可能缺乏熟练测试人员的那种“余光视力”。不正确的自动化有时会变成一推庞大而难以维护的代码,并且对衡量软件质量没有什么实际意思。但是精心设计的自动化测试有助于及早发现软件缺陷。
16. 提高你的编程能力
我遇到过一些很有天赋的测试人员,他们倾向于不去写代码。这有一定道理。就像电影评论家在变得挑剔而富有陈见后不会去考虑电影观众的喜恶一样,在我充当编程员的角色时,我想的就不再和用户一样了。但是编程还是一项有价值的技能,他能帮助你更好地阅读代码,理解产品的内在,同时帮助你写一些小工具使得平淡反复的工作变得简单。
17. 参加Bug的审阅 (Triage)
在产品发布前的最后一些日子里,Bug审阅组开会决定哪一些Bug应该修复,哪一些应该留到以后的版本去修复。如果你通常不在这个会议的邀请名单中,那么去主动要求参加。你会看到在测试员信誉,用户影响和已知风险等因素间做出折衷决定的过程。这将会是一种非常有趣的经历。
18. 不断学习
不管是“软技能”,比如公开演讲, 或者编程语言,亦或新的测试技术,成功的测试工程师总是会从繁忙中抽出时间来坚持学习。
19. 爱你所做的事,并把它做好
如果你不能承担放弃当前工作的代价,那么就学着去热爱它。测试人员有时会变得嫉世愤俗,尤其是在困难的发布周期中。享受工作并且不满足于仅仅完成计划内目标的人才会成为优秀的测试工程师。