可能和大多数的IT人一样,我的职业生涯也是从一名软件工程师起步的。虽说头衔是软件工程师,但其实是跟随项目需要什么都干,也许和当时的公司是做外包业务有些关系。不过回头想想这也是好事情,什么都了解一点,什么都做一点,才不会秉持着“我就只做开发”、“我就是做测试”的这种想法。又幸好我后来很快有机会专职做测试,才没有沦为啥也不精专的泛泛之辈。

我当时并不知道何为测试驱动开发(TDD)、可接受性测试驱动开发(ATDD)、持续集成或者敏捷测试这个概念,但我确实有做一些相似的事情。我们曾经做过一些SAP的开发,根据从日本客户那里拿到的详细设计书,开发一些ABAP程序。出于对自己的不自信,我完全不敢相信自己写出的代码,于是没写出一部分的代码,我都要实际地运行一把,看看运行的结果到底是怎样的。这里得称赞一把SAP的这个开发环境,真不错,帮助很容易查阅,也有一些示例程序,编译运行也很快,很容易就可以得到对自己编写程序的反馈。如果用今天的眼光来看待的话,其实也算是覆盖范围较小的持续集成了,只是我并非有意思的编写测试用例进行功能验证,只是执行程序看看外观和结果而已。由于每几段代码都能看得到实际的效果,再继续写后面的代码时我也有着更强的信心,一方面是对自己编写ABAP代码的信心,另一方面是对开发的方向以及ABAP语言的信心。

由于是第一次接触ABAP语言,所以我并不敢确信自己使用该语言的方式是否正确,所以基本上在进行开发的同时,我还打开这一个测试项目(Project,IDE工具例如Eclipse中的项目,并非项目管理中的“项目”一词),类似于一个沙盒。沙盒的作用在于,当我需要使用一些函数或者接口,又不肯定它该如何使用时,我可以在沙盒里写一个最简短又能使用到这个函数或接口的小程序,看看它的效果,输入输出参数该如何使用,而后再回到应用程序开发的项目中去使用它。如果我直接在开发中去使用或者尝试,那么带来的风险就太大了。

在其他一些项目中,我也做过许多类似于调整表格标示符位置,查看对话框位置之类的工作,后来我才了解到,在测试的社区里这些被称作是低等的手工测试工作。当时,我承担的任务被称作是“报表套打程序开发”,依然是被当做开发工作来进行的,虽然程序已经开发完毕,但是我们得细细盘查打印出来的实际效果是否正确,在电脑中看到以及排列整齐的表格,一旦打印出来却是错误百出。做这件事情,需要我们执行报表打印程序,打印到文件,然后观察打印出来的报表,看看表格或者一些字段是否显示在正确的位置。不仅如此,如果位置不对,那我们要立刻调整报表打印程序中的设置,再打印,再检查,再调整,重复此过程直到报表显示正确为止。

当时公司里除了我所待的开发部,还有一个业务部门,就是本地化(Localization)团队,其实也就是招来一大堆英语、日语等各种语言的专业人士,让她们(绝大部分是女同胞,只有一个男同胞)将界面、菜单、对话框等所有用户看得见的文字都要转化为中文。我也曾经被抓壮丁去帮她们做这些工作,其实是非常的繁琐,也就是要在软件系统中将相应字段定义的地方,把文字替换过来,还要检查在界面上的显示是否正确,是否和原文界面保持一致风格,等等。关于本地化测试的技术和各种方法,我就不多说了,相关的书籍、文章都不少。只是后来回想,我觉得这样的过程其实完全可以做得比较自动化一点,可惜当时的我还没有接触到系统的测试自动化知识,也没有足够的能力可以帮助到她们。当时这个团队还面临着另一个问题,她们的成员多数是语言专业毕业, 计算机方面的知识可谓匮乏,遇到翻译一些专业词汇之时,就容易出错,所以她们也会在项目周期中安排一个阶段,供我们开发部的同事介入进行后期检查。有点像是在做系统测试,但麻烦在于,开发部介入比较晚,而要检查的文字实在太多,仿佛大海捞针,通常也只有凭借经验挑选一些容易出错的地方做重点检查,现在想想,其实颇有一点基于风险测试(Risk-Based Testing)的意味。

查看更多“我的测试之旅”文章
1. 起点——作为软件开发人员
2. 转变——作为专职测试人员
3. 同期——加入测试自动化小组
4. 并行——自动化回归测试
5. 难点——功能改进的测试
6. 跳转——追逐新鲜事物的探险者
7. 启程——Scrum中的测试工作者
8. 困难——没有现成的测试工具
9. 行动——简化测试文档和流程
10. 贡献——开发项流程(Development Item Process)
11. 尝试——Scrum Master
12. 机遇——测试自动化培训师和教练
13. 转型——敏捷教练

敬请关注 《大测大悟——测试的敏捷之道》开放出版过程

联系方式:
- 新浪微博
- 谷歌邮箱 kaverjody @gmail.com
- LinkedIn