测试人员中分成两种职位，Software Development Engineer in Test（测试组的软件开发工程师）实际上还是属于开发人员，他们具备编写代码的能力和开发工具软件的经验，侧重于开发自动化测试工具和测试脚本，实现测试的自动化。Software Test Engineer（软件测试工程师）具体负责测试软件产品，主要完成一些手工测试以及安装配置测试。
2. 测试计划
测试计划是测试人员管理测试项目，在软件中寻找Bug的一种有效的工具。测试计划主要有两个作用，一是评判团队的测试覆盖率以及效率，让测试工作很有条理的逐步展开。二是有利于与项目经理、开发人员进行沟通。有了测试计划之后，他们就能够知道你是如何开展测试工作的，他们也会从中提出很多有益的意见，确保测试工作顺利进行。总之，有了测试计划可以更好的完成测试工作，确保用户的满意度。
测试人员在编写测试计划之前，应获得以下文档：
1）程序经理编写的产品功能说明书或产品开发计划；
2）程序经理或开发人员提供的开发进度表。
根据产品的特性及开发进度安排，测试人员制定具体的测试计划。测试计划通常包括以下内容：
1）测试目标和发布条件：
a. 给出清晰的测试目标描述；
b. 定义产品的发布条件，即在达到何种测试目标的前提下才可以发布产品的某个特定版本。
2）待测产品范围：
a. 软件主要特性/功能说明，即待测软件主要特性的列表；
b. 特性/功能测试一览，应涵盖所有特性、对话框、菜单和错误信息等待测内容，并列举每个测试范围内要重点考虑的关键功能。
3）测试方法描述：
a. 定义测试软件产品时使用的测试方法；
b. 描述每一种特定的测试方法可以覆盖哪些测试范围。
4）测试进度表：
a. 定义测试里程碑；
b. 定义当前里程碑的详细测试进度。
5）测试资源和相关的程序经理/开发工程师：
a. 定义参与测试的人员；
b. 描述每位测试人员的职责范围；
c. 给出与测试有关的程序经理/开发工程师的相关信息。
6）配置范围和测试工具：
a. 给出测试时使用的所有计算机平台列表；
b. 描述测试覆盖了哪些硬件设备；
c. 测试时使用的主要测试工具。
此外，还应列出测试中可能会面临的风险及测试的依赖性，即测试是否依赖于某个产品或某个团队。比如此项测试依赖性WindowsCE这个操作系统，而这个系统要明年2月份才能做好，那么此项测试就可能只有在明年5月份才能完成，这样就存在着依赖关系。如果那个团队的开发计划往后推，则此项测试也会被推迟。
3. 测试用例开发
一个好的测试用例就是有一个合理的概率来找到Bug，不要冗余，要有针对性，一个测试只针对一件事情。特别是功能测试的时候，如果一个测试是测了两项功能，那么如果测试结果失败的话，就不知道到底是哪项功能出了问题。
测试用例开发中主要使用的技术有等价类划分，边界值的分析，Error Guessing Testing。
等价类划分是根据输入输出条件，以及自身的一些特性分成两个或更多个子集，来减少所需要测试的用例个数，并且能用很少的测试用例来覆盖很多的情况，减少测试用例的冗余度。在等价类划分中，最基本的划分是一个为合法的类，一个为不合法的类。
边界值的分析是利用了一个规律，即程序最容易发生错误的地方就是在边界值的附近，它取决于变量的类型，以及变量的取值范围。一般对于有n个变量时，会有6n+1个测试用例，取值分别是min-1, min, min+1, normal, max-1, max,max+1的组合。边界值的分析的缺点，是对逻辑变量和布尔型变量不起作用，还有可能会忽略掉某些输入的组合。
Error Guessing Testing完全靠的是经验，所设计的测试用例就是常说的猜测。感觉到软件在某个地方可能出错，就去设计相应的测试用例，这主要是靠实际工作中所积累的经验和知识。其优点是速度快，只要想得到，就能很快设计出测试用例。缺点就是没有系统性，无法知道覆盖率会有多少，很可能会遗漏一些测试领域。
实际上在微软是采用一些专门的软件或工具负责测试用例的管理，有一些测试信息可以被记录下来，比如测试用例的简单描述，在哪些平台执行，是手工测试还是自动测试，运行的频率是每天运行一次，还是每周运行一次。此外还有清晰的测试通过或失败的标准，以及详细记录测试的每个步骤。
4. Bug跟踪过程
在软件开发项目中，测试人员的一项最重要使命就是对所有已知Bug进行有效的跟踪和管理，保证产品中出现的所有问题都可以得到有效的解决。一般地，项目组发现、定位、处理和最终解决一个Bug的过程包括Bug报告、Bug评估和分配、Bug处理、Bug关闭等四个阶段：
1）测试工程师在测试过程中发现新的Bug后，应向项目组报告该Bug的位置、表现、当前状态等信息。项目组在Bug数据库中添加该Bug的记录。
2）开发经理对已发现的Bug进行集中讨论，根据Bug对软件产品的影响来评估Bug的优先级，制定Bug的修正策略。按照Bug的优先级顺序和开发人员的工作安排，开发经理将所有需要立即处理的Bug分配给相应的开发工程师。
3）开发工程师根据安排对特定的Bug进行处理，找出代码中的错误原因，修改代码，重新生成产品版本。
4）开发工程师处理了Bug之后，测试人员需要对处理后的结果进行验证，经过验证确认已正确处理的Bug被标记为关闭（Close）状态。测试工程师既需要验证Bug是否已经被修正，也需要确定开发人员有没有在修改代码的同时引入新的Bug。
5. Bug的不同处理方式
在某些情况下，Bug已处理并不意味着Bug已经被修正。开发工程师可以推迟Bug的修正时间，也可以在分析之后告知测试工程师这实际上不是一个真正的Bug。也就是说，某特定的Bug经开发工程师处理之后，该Bug可能包括以下几种状态。
已修正：开发工程师已经修正了相应的程序代码，该Bug不会出现了。
可推迟：该Bug的重要程度较低，不会影响当前应提交版本的主要功能，可安排在下一版本中再行处理。
设计问题：该Bug与程序实现无关，其所表现出来的行为完全符合设计要求，对此应提交给程序经理处理。
