项目管理之敏捷测试人员

◆◆◆

项目背景简介

项目名称：***项目

项目成员：测试：1，  后端：2，前端：1，产品：1，项目经理：1

项目周期：2个月(截止日期：元旦前）

工时评估：以天为单位，模糊评估

测试猿的窘境 

1.需求文档不明确

2.提测时间不明确 

3.项目进度不明确

4.我是谁？我该干嘛？ 

想必每个测试猿都会遇到以上的窘境，版本到项目快截止时才提测，最后项目延误了，又要默默的背锅？ 

项目进行了半个月，依然没有我什么事儿，我真的不想元旦加班啊，去年就已经安排了今年元旦行程，怎么可能延误，必须要改变现状了···

主动沟通，抛出问题

主动找研发经理沟通，抛出问题，提出解决方案；迈出这一步我也是三思而后行。

1.找到沟通有效的人

a.找项目负责人？项目负责人只是其中一个研发，解决不了根本的问题。

b.找项目经理？项目经理经常出差，很难得到准确的回复。 

c.最后，只能冒昧约研发经理谈话了，程序猿的直属领导，应该是最有话语权了。

2.抛出问题，提出解决方案 存在问题：

a.需求不明确，没有相关文档输出

b.任务没有划分优先级

c.任务工期评估模糊

b.按目前的进度，元旦前不可能完成该项目

3.解决方案：

a.工时精准评估，以小时为单位

b.提供产品待办列表，输出任务优先级、研发进度、提测日期等信息

c.进行迭代开发，三期迭代，每个迭代为期两周(离项目截止日期正好6周) 

该图片为引用图片

4.沟通结果：

a.第一点被否定，可以尝试进行迭代开发

b.测试（me）主动提供迭代需求清单模板

c.测试提前介入，先行接口测试，后续功能测试

5.迭代开发，积极推进

1.我主动提供迭代开发需求管理模板 （见如下截图）

2.总共三期迭代，每期迭代历时两周

3.周一：项目负责人邮件发出一期迭代需求清单，抄送项目干系人

4.周五：测试负责人，总结项目进度，邮件发送项目干系人

5.每期迭代结束，总结本期迭代的完成率以及优缺点，要生成可交付的产品；

该图片为引用图片

插曲：敏捷法则

   1.最小可交付

因为计划不是一成不变的，有时候客户自己都不知道自己需要的是什么样子的。老板自己可能也在变化。

交付1.0版本，给对方选择了挑选，可以先像客户，需求人先交付第一个版本。

2.持续迭代

根据客户需求不断地更新，不断升级自己的方案。

任务就像你背上的一只猴子，你要再接下一个项目的时候吧背上的这个猴子给扔出去，要始终保持背上只有一只猴子。

在做一个重要项目的时候，重要的事情多迭代，紧急的事情先迭代原则

6.迭代结束，项目完结

经过为期6周的迭代开发，团队小伙伴的不懈努力、研发经理的不断施压；项目最终按时完结，回归测试也提前完成，终于可以过元旦

7.项目过程测试经验总结

1.如何实现测试左移

a.需求阶段介入，明确需求甚至可以给出自己的对产品的设计意见

b.先行接口测试，尽早发现接口层面的问题，可避免后期测试浪费时间

c.重视数据库测试，新的项目所有的表都是新建的，可以从表结构、字段、索引等各个方面把关，遇到问题前期修改成本较低

2.多版本并行，如何高效执行测试任务 由于我一个测试猿要对接五个程序猿，某天出现了同时提测四个版本的情况，在片刻的慌乱后我采取了以下方式：

a.提测任务按优先级排序，进行一轮主功能测试，使每个程序猿手头都有缺陷要处理；

b.对优先级较高的任务进行第二轮全功能覆盖测试

c.回归缺陷，之后再进行三轮冒烟测试，发现新的缺陷，绝对不能让研发空闲

d.就像玩游戏一样，轮番先各个研发扔bug，直到所有bug关闭才game over

3.迭代开发、敏捷测试 由于我大学毕业后就加入了敏捷开发团队，敏捷（scrum模式）对我的影响很深，一直想在现在项目中推行敏捷，但是大家都不愿意拥抱变化，敏捷最大的一个特点就是“拥抱变化”。因此本次项目就采取了迭代开发的模式，用敏捷的思维进行测试

a.当面沟通，减少信息误差

b.持续改进，及时反馈问题

c.响应变化，停止推脱抱怨

4.有效管理缺陷，缩短项目进度 敏捷中注重处理bug 的效率，发现问题快，修复起来也较快；我在实际的测试中采用了传统与敏捷结合的方式处理缺陷，减低了bug修复的成本，有效缩短了项目周期；具体总结如下：

a.页面缺陷，集中反馈，提供截图说明 ；

b.需求缺陷，双方沟通，达成共识后记录缺陷，可降低时间成本；

c.面对面沟通，主动重现解释bug；

d.重视缺陷的成本，高时间成本，低价值的缺陷建议口头通知解决，低时间成本，高价值的缺陷需要记录追踪；

e.bug及时跟进：及时验证、及时反馈、及时关闭；归纳：主动沟通、当面沟通、耐心沟通、持续沟通·····

 " 最后在正式普及下 敏捷测试人员十大法则 "

1. 提供持续反馈（Provide Continuous Feedback）

既然是测试驱动敏捷项目，那么很显然反馈在敏捷团队中占据重要的地位。测试人员的传统角色就是“信息提供者”，这使得她天生就对敏捷团队很有价值。敏捷测试人员的最大贡献之一是帮助产品负责人或者客户采用实例和测试的形式描述清楚每一个用户故事的需求。然后，测试人员与团队同事将这些需求转化为可执行的测试。测试人员、开发人员和其他团队成员尽快运行这些测试，并不断接收有意义的反馈。

2. 为用户创造价值（Deliver Value to the Customer）

敏捷开发就是在较小的版本发布中提供客户目前最迫切需要的功能。这通常意味着限定范围。我们经常在客户团队中遇到较酷功能的需求。任何人都可以质疑这些内容，但是测试人员会判断其对故事的影响，因为他们需要考虑测试后果。

敏捷测试人员需要总览全局。我们可以在当前迭代中发布最重要的功能，稍后再完善。如果让新功能偷偷混进来，就面临一无所获的风险。如果过于关注边边角角，而忽略了核心功能，就无法提供业务所需的价值。

3. 促进面对面的沟通（Enable Face-to-Face Communication）

敏捷测试人员从客户的角度思考每一个故事，但是也理解实现功能相关的技术和局限性。他们可以帮助客户和开发人员达成共识。业务人员和软件人员经常使用不同的语言。他们不得不找到一些共同点来协作。测试人员可以帮助他们达成一种共通语言。

面对面的沟通是不可替代的。敏捷开发依赖于持续的合作。就像其他敏捷团队成员一样，从事测试工作的人会不断寻找客户和技术团队成员来讨论和合作。当敏捷测试人员对某个隐藏的假设或者误解的需求产生怀疑时，她会与客户和开发人员讨论。如果处于不同地点的人需要交谈，他们会试图寻找创造性的方式替代面对面、实时的交流。

4. 勇气（Have Courage）

当最初加入敏捷团队或者当前的团队开始过渡到敏捷开发模式时，通常会产生恐惧感，并且存在大量的问题需要答案。我们到底如何才能在如此短的时间内完成每一个用户故事的测试任务？测试如何跟上开发的节奏？如何确定多少测试就够了？又或者你是功能测试经理或者质量过程经理，不清楚在敏捷团队中如何定位自己的角色，没人知道答案。敏捷测试人员需要勇气找到这些问题的答案，但是除此之外还有其他原因。我们需要勇气允许自己失败，至少我们会短暂失败，并从中学习教训。在由于构建版本不稳定导致一次迭代失败之后，我们开始寻找方法以确保这种事情不再发生。

5. 简单化（Keep It Simple）

简单并不意味着容易。对于测试人员来说，这意味着采用能够找到的最轻量级的工具和技术恰到好处地测试。工具可以简单到只是一张电子表格或者清单。需要自动化回归测试，但是应该把它们分解到最底层以获取快速反馈。甚至简单的冒烟测试也可能满足面向业务的测试自动化。

6. 持续改进（Practice Continuous Improvement）

想办法把工作做得更出色是敏捷测试人员思想的一部分。当然，整个团队都应该具有这样的想法，因为敏捷的核心价值就是团队总是尝试更出色地工作。测试人员参加团队总结会，评估做得好的方面和需要增加和改变的方面。测试人员把测试问题摆到整个团队中解决。团队通过采取过程改进实践最大程度地改善测试和所有其他领域。对于更大的问题，团队一次只关注一到两个问题，以确保彻底解决了实际问题，而不是表面文章。

7. 响应变化（Respond to Change）

响应变化是敏捷实践的重要价值，但是我们发现这对测试人员来说却是最困难的概念之一。测试人员渴望的是稳定，所以他们会说：“我已经测试过了，任务完成了”。持续的需求变化是测试人员的噩梦。但是，作为一名敏捷测试人员，我们不得不拥抱变化。周三，我们可能期望启动故事A和B，下周五做C。但是到了周五，客户重新设定了优先级，现在需要故事A、X和Y。只要我们持续与客户交流，就能处理这些变化，因为我们与团队的其他成员保持同步。

8. 自我组织（Self-Organize）

敏捷测试人员是自组织敏捷团队的组成部分。团队文化贯彻于敏捷测试理念。当开发人员、系统管理员、分析员、数据库专家和客户团队持续关注测试和测试自动化，测试人员就会获得全新的视角。自动化测试很困难，但是当整个团队都在为此努力时就会简单得多。当大家具有多重技能和多层次视角时，任何测试问题都更容易解决。

9. 关注人（Focus on People）

坚持敏捷理念的敏捷团队对所有团队成员一视同仁。敏捷测试人员对团队做出了特有的贡献，开发团队认识到要想更加成功，团队需要拥有测试技能和背景的人。举例来说，一位熟练的探索性测试人员可能会发现自动化功能测试无法察觉的问题。一些测试经验丰富的工程师会提出其他人想不到的重要问题。测试知识是任何一个成功团队的组成部分。

10. 享受乐趣（Enjoy）

在我们看来，测试人员的理想团队是：所有成员协作，从项目的开始一直到结束，利益相关者与开发团队共同工作，整个团队负责质量和测试。相信很多人都认为每个人都应该在工作中找到乐趣。敏捷开发珍视敏捷测试人员对工作的激情。