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

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

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

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

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