后来我被直接派驻客户（诺基亚网络杭州3G研发中心，现诺基亚西门子网络杭州研发中心）现场，再后来被直接买下，成为了诺基亚的员工。也正是从派驻诺基亚那时起，我开始了自己作为专职测试人员的旅程。但编程这个活动一直都伴随着我，直到现在，这也是我从来都不认为开发、测试有着很清晰的界限的原因，欲知详情请继续往下看。

　　当时我们两家公司合作已经有一段时间，已经有数十位工程师在诺基亚干活，我们这一批人是专门为研发中心某个产品线的测试部门补充人力的。团队管理非常简单，我们自己公司的事务由自己的外包经理或者叫协作者经理（Collaboration Manager）管理，当然，在我们这批人和经理之间还有小组长（Team Leader）。而从做事情做项目的角度呢，我们则直接由诺基亚的项目经理来负责管理，也即由他们来分配任务、确定时间表等各种事务。

　　该产品线的结构应该属于比较常见的一种，分为几个开发部门和一个测试部门，支持型的部门还有质量管理部和产品管理部、项目集群（Program）管理部等等。使用的是自己独特的开发模式，类似于瀑布模型，也即分阶段、基于文档的开发模式。一个产品的开发会被分割为多个项目集群，而后项目集群再分作多个项目，每一个项目又分割为多个子项目。通常一个子项目也即是某个或某些模块的开发任务，或者测试任务，测试和开发是独立分开进行的子项目。测试项目要等待整体的开发完成之后才开始。

　　刚到诺基亚时，我颇为感慨，果然是大公司啊，真是有风范，的确很有人文关怀的感觉，我们所担心的事情都有人考虑到。当时，诺基亚的新员工都要先参加总长度两个月的入职培训，包括从诺基亚介绍、价值观等人事的部分，也包括对产品线产品的介绍，以及开发模式的介绍，以及开发、测试具体流程的介绍，总之，非常的全面，凡是未来会用到的全都有涉及到。只要保留好课堂的材料和自己的笔记，回头上手干活基本上没有任何问题。

　　机缘巧合，我还在参加培训被小组长抽调过去先参与到测试项目的工作中去了，也许是因为我看着比较顺眼吧……当时的我心中非常忐忑，不知道该如何干活，所幸有诺基亚的导师（Tutor）制度在，小组长给我安排了一位导师（在此要非常感谢她的辅导，帮助我顺利地融入诺基亚的氛围，真的非常感谢！），她教给我作为一个测试人员所要做的各种事情，给我很多的相关资料可以自我学习，也手把手地指导我执行以及分析和写测试报告等等很多很多。总之，和她配合，我受益颇多，测试项目开始不久，我差不多已经可以独立工作了。

　　我加入时导师已经在开始执行测试的阶段，于是我主要是要去理解测试计划、理解测试用例，熟悉测试工作和被测产品，掌握测试执行的各种操作命令。测试部门的知识传承做得相当不错，所有的文档都有模板和介绍，很容易上手，知道各个部分写的是什么东西，以及如何使用。而且在测试用例中，不止包含测试步骤，通常也包括要执行的命令，和每个步骤的预期结果，以及终的预期测试结果。测试报告也有模板，只要按照模板的要求，将测试时的环境，被测对象的各种版本信息，执行的命令和返回的输出等等各种信息都记录下来行。

　　当我渐渐地熟悉如何执行测试后，开始对周遭事物有着各种好奇，成天都缠着导师问各种问题。一开始主要是在测试失败，或者得到一些不完全符合预期的输出时，不知道该算是通过还是失败，要去找导师请教。慢慢地开始问很多关于，为什么要这么设计这个用例啊，到底要测试的是什么功能，之类的问题，而导师的回答总会附上一句，“多看看功能需求说明书吧”。于是我开始看功能需求说明书（Functional Requirement Specification），从中去理解我所测的对象所应该实现的功能。功能需求说明书也是有模板的，不过依然会出现不清楚或者难以理解的地方，这也是让测试人员很头疼的地方，因为无法确定测试的对策。好的解决办法是去问文档的作者，只不过这份文档的作者通常是其开发人员（或者开发人员所在领域的专家），而他们通常都比较忙，忙着进行后续版本的开发（针对同一版本，测试总在开发完成后开始，所以测试开始时，开发人员都已经在做新功能的开发了）。