测试经理的职责

用测试经理的岗位勉励自己，努力的方向

转载自：https://www.douban.com/note/338536581/

测试经理的职责

测试leader/测试经理的职责是有效的领导一个测试团队。为了更好的履行这个职责，测试leader/必须理解测试的基本原则，作为一个测试经理在履行一个传统的领导角色的同时还应懂得该如何有效地实现一个测试流程。这是什么意思呢？测试经理应该管理、贯彻和维护一个有效的测试流程。这包括搭建一个能够支持良好沟通和有效成本控制的测试环境,创建一个有效的测试团队。
 
测试leader/测试经理的主要职责是：
 
1、在测试组织内部制定和分配测试角色。
2、根据每一次交付的版本/产物的内容制定测试范围。
3、为迎合测试需要进行测试环境的配置和管理。
4、实现和开展适当的度量和规划:
      (1) 交付的产品是否可以测试。
      (2) 测试团队是否已经做好测试准备。
5、为每一个给定版本进行测试计划、开展测试以及管理测试结果。
6、为迎合测试要求管理和壮大必须的测试资产：
      (1) 测试成员。
      (2) 测试工具。
      (3) 测试流程。
7、保持自身熟练的测试技巧。
 
测试leader应该明白怎样测试才能符合测试团队要求，换句话说，就是制定清晰的组织角色，这些可以通过创建一个任务说明或者定义一份测试规格书来实现。例如：“根据给定的版本内容预防、发现、记录以及管理缺陷”。
 
现在测试leader的任务是去沟通和贯彻有效的管理以及测试技术支持、简单的要求、团队的期望，你的同事(开发的领导以及其他领导)和上级应该被给定适当的时间计划表，完备的开发团队和测试团队。这些期望通常在功能测试的范围区域内外被定义。例如:
 
属于功能范围以内的：
(1) 创建一个新的客户曲线图。
(2) 更新客户曲线图。
(3) … …
 
属于功能范围以外的：
(1) 安全。
(2) 备份与防御。
(3) ... …
 
这个被定义的范围将贯穿在测试的各个不同的时期，关键的是确保你的团队或者组织能够清晰的理解在当前的版本中什么能够测试什么不能够测试。测试leader或者经理应该使用合适的测试框架和测试技术去迎合测试组织的需要。当任何测试组织的测试框架要求都很困难的去定义以下问题的时候，测试leader/经理必须进行自我反思。这些问题以及其他问题的答案，将会定义出测试基本框架的长期和短期的目标。
 
软件产品成熟度和测试的关系是什么样子的？
（ 这个地方是一张图片）
 
     
Acceptance: - 可接受的测试，或者称为验收测试，是指产品准备发布前由客户或者最终用户进行的测试。
System: - 系统测试，从整体上对产品进行测试，包括对软硬件环境的交互。
Function: - 对交付的各个组件进行的功能测试。
Unit: - 单元测试，是指开发者对代码的测试。
Design Review: - 产品设计阶段。
%Construction: - 可以理解为产品未完成百分比。
%Product: - 产品完成百分比
 
测试组织如何对于当前的项目中帮助预防更多的缺陷？
 
   这里确实有两方面对于测试验证和确认。不幸的是这意味着这些周期已经被几个管理/调整的团队给予了不同的定义。为了使其更简洁，一些测试应该在产品建构/建置之前被执行并且在产品建构/建置之后还会有不同类型的测试被执行。
 
   在当前的项目中尽量避免缺陷包含了产品被建构/建置之前的测试。有些方法可以帮助实现这个目标。最强大的和花费成本最高的是回归测试。回归是任意的正式的/技术的回归或者同级别的回归。一般产品开发生命周期将会提供测试团队一些有用的用于回归的测试材料/可交付产品。什么时候可以适当地实施任一个有效的开发范例应该提供这些可交付产物，例如:
 
(1) 瀑布式模型
(1-1) 需求文档
(1-2) 功能规格说明书
 
(2) 敏捷/快速开发
(2-1) 更高水平的需求文档
(2-2) 流程图
 
测试应该包含回归的过程并且任何缺陷都应该被记录和管理。
 
怎样并且什么时候测试组织能够发现这些软件缺陷？
 
测试组织能够发现软件缺陷是在产品或者一些被交付的可操作的部分以后，需要执行什么样的测试基于那个时间段产品的成熟度。主流的测试阶段顺序是：
 
(1) 设计阶段
(2) 单元测试
(3) 功能测试
(4) 系统测试
(5) 用户可接受的测试/验收测试
 
   测试团队至少应该执行三个阶段的测试：设计阶段、功能测试和系统测试。
 
   功能测试包括依靠功能规格说明书 和/或 产品需求说明书设计、实现和执行测试用例。这是测试团队依靠产品目标度量发现与测试用例之间的差异作为测试缺陷。例如测试验证一个网页是否允许一个新论坛成员登录，在这个用例中我们就以测试验证网页功能作为切入口。
 
   系统测试包含了很多与功能测试相同的过程(设计、实现、执行和缺陷跟踪)，但是他们的意图和关注焦点是不同的。功能测试关注的焦点是不连续的功能要求，而系统测试关注的焦点是系统的整体相关性。例如测试确保应用程序能够允许登录、激活和恢复一个新的论坛会员。在这个用例中我们就测试确保系统支持此功能。下面是一些系统测试的类型，对给定版本的测试哪些需要执行，可以通过下面的范围决定：
(1) 安全测试
(2) 性能测试
(3) 综合测试
 
什么是最小的度量和量化？
 
   测试团队的最重要的提交物是缺陷。缺陷是唯一的可用来衡量测试团队在整个项目中的产出的一个指标。缺陷依赖于系统被记录和跟踪 -- 一个空白的最小的缺陷记录应该包括：
 
(1) 缺陷的名称/标题
(2) 缺陷描述。什么需求没有被合理的实现？
(3) 详细描述如何重现这个缺陷。
(4) 缺陷的严重等级。
(5) 缺陷存在的功能区域。
(6) 缺陷发现者。
(7) 缺陷状态(开启的、正在进行中、解决的、关闭的)
 
这些将为度量的最小尺度提供依据：
 
(1) 缺陷上升的数量
(2) 在一定阶段内的缺陷严重程度分布
(3) 在一定阶段内的产生缺陷的功能区域分布
 
    从基线来看，度量一个测试组织的维护在于它的成熟度以及使命描述。SEI(美国软件工程研究所)应用于测试的过程成熟度模型，同时也应用于其他任何一个软件工程学科。
 
(1)初始级: (无组织状态)不可预知的简单的控制。
(2)可重复级: (不被承认的民间传说)重复执行先前的任务。
(3)已定义级: (标准的) 流程个性化，清晰，明了
(4)已管理级: (度量)过程度量和控制
(5)优化级: (优化的) 过程焦点是改进
 
    测试组织流程和测试的度量标准取决于测试经理和测试leader对测试成本收益的分析结果。如何评价一段时间内预诉讼锁定义的目标和前期取得的绩效？
 
如何去壮大和维护一个测试组织？
 
      管理和领导一个测试团队是IT行业最极具挑战性的职位之一。这个团队通常是人手不足、缺少适当的工具、缺乏资金，最终期限不确定，测试阶段常常受制于产品的延迟。测试人员流动频繁，要保持一个强有力的团队才是最重要的。怎样才能完成这些看起来不太可能的任务呢？下面介绍一下我作为测试leader和测试成员的经验：
（1）如果时间安排有冲突应该在一定时期范围内适当的更改测试计划。
（2）在测试团队和项目经理之间进行明确清晰的交流沟通。
（3）在开发成员和项目经理之间保持明确清晰的交流沟通。
（4）无论什么时候去推销自己的测试团队，记得你的卖点是团队对于项目的重要性和贡献
（5）测试组织应该确保给每个测试成员制定一个明确的角色定义和职业规划。
（6）度量和沟通测试效益回收 – 是否测试出来的缺陷到达了成本花费领域。
（7）明确一定的测试支出是投资而不是浪费。
（8）最后一定要保持冷静 -- 好运