QA,从 1.0 到 4.0

迄今为止,敏捷开发方法在各个公司都有了长足的发展,曾经的测试人员慢慢的在向QA职能过渡,但依然很多人不了解QA和测试的区别是什么。

敏捷实践不断地演化过程,使项目中各个角色不断弱化,同时,对每个成员的要求也越来越高。“全功能团队”的提出,不单单是对开发的要求,对QA来说,想要在快速变革中具备竞争力,就现在所具备的技能来说,还是远远不够的。

简单聊聊我所经历的“QA发展史”

1-qa4-0

(图片来自ThoughtWorks UX设计师 高媛媛)

QA 1.0 —— 机械化流水线作业

在我实习的那年,软件领域还很少提及QA,伴随着瀑布模型的兴起、软件工程规模的不断扩大以及市场对软件质量要求的提高,催生出了“测试工程师”这样一个角色。那时他们的职能很单一,每天的工作就是在各种测试环境中按照详细设计的文档,编写测试用例,并逐条测试,检查功能完整性,发现软件中可能出现的功能缺陷,并进行追踪。

这个时期是软件测试的原始时期,对测试人员的技能要求不高,只要对文档理解透彻,做事细心,是很容易胜任的。此时的产出和交付物可度量,虽然如此,测试工程师只是执行者,能力和价值都无法最大化,却被每天重复的工作所累。

QA 2.0 —— 过程化带来不同的工作内容和价值体现

我毕业的时候,开始接触敏捷方法,团队规模从百人变成了仅有十人左右,信息平等取代了逐级传递,分散的信息源( 客户的每一封邮件和每一句对话都可能是我们将要做的功能 )取代了几十甚至百页的文档,测试不再仅是提出软件缺陷和编写、执行测试用例,而是成为了团队的数据库和字典。

2-dictionary

当用户提出一个功能的时候,测试人员可以快速的进行需求分析,回顾并确定是否与此前的功能有冲突。当开发人员对某一块业务不了解的时候,测试人员也可以组织会议进行阐明。由于对业务和客户的深入了解,测试人员可以为客户提出建设性意见和功能,有时也会是做出决策的人。

高效、频繁的沟通,大大提升了QA的软技能。此时的测试人员已经过程化,对软件质量的理解,从“发现缺陷”提升到“对软件开发过程的质量控制和风险预估”,我们定义这样的测试工程师为QA。

QA 3.0 —— 自动化技能提高生产力

随着工程实践的日益成熟,QA的角色和工作日益复杂,这使得他们在大量重复、繁杂的工作与更有意义的角色之间频繁切换,这对软件质量也产生了一定影响。

3-transform

QA从开始的手工测试、探索性测试等手段,逐渐发展成为可以利用工具和程序对测试进行快速的回归,对软件性能进行有效监控,无论是前端还是后端、web应用还是移动平台。这使得自己从繁杂的重复性工作中解脱出来,去做更有意义的事情。他们通过项目的积累以及团队成员的帮助,对测试技术有了一定的认识。

QA 4.0 —— 角色向多技能、服务化转型

记得几年前,前公司领导对我说,“不管开发换了什么技术栈,你做的自动化框架都可以继续使用,对你来说没有任何影响。”当时我也赞同,认为框架已经足够好,可以适用于任何场景和业务。

从某个角度来说确实是这样, 测试相对于开发技术的指数级发展,平稳的太多。不论是在互联网还是移动互联网时代,缓慢的发展速度给了我们一种太平盛世的错觉,似乎我们掌握的技术足够坐吃几年。

来到ThoughtWorks之后,我发现了类似的事情,不论是在交付还是咨询的过程中,会有意无意中推一些我们认为的最佳实践,当遭到客户质疑和challenge的时候,我们似乎很沮丧。

在北京出差的日子,有幸做了一次咨询,虽然只有几天,让我学到一件事,我们认为的最佳实践和方法,并不完全适应于所有场合,尤其是在我们这样的咨询公司,对客户实施怎样的方案,取决于客户的领域、产品/项目特性、用户群、技术水平、政治文化、技术栈以及目标和期望等等。

4-balance

如果对于“最佳实践”过于坚持,也会影响客户关系和咨询效果。之后咨询同事讲的几个故事也似乎让我认识到,虽然我们对现在的工作和技能足够的熟练,但依然不够。

我们似乎还需要具备以下的能力:

1.尝试用不同的方法写“茴”

经验丰富的QA对于测试技术中的关键点都烂熟于心, 除了我们正在使用的方案和技术,尝试用不同的语言、框架去实现关键点和难点。这样的好处在于,我们可以通过深入的学习和使用,对流行方法、过程和框架进行比较,了解各自的优势和劣势,不但可以增强自身的技能,当面对不同客户的时候,也可以给出客观的分析,为客户提供精准服务,同时如果可以对客户现有的技术和方案、流程和方法提供有价值的意见,也可以提高在客户现场的生存率,轻松俘获客户。

2.If you cannot test it, dev it.

软件过程中,QA可以在需求分析和定义阶段介入,为项目提供不可估量的价值,但另一方面,QA技能实践(此处指Tech)是一个相对受限的领域,我们很难绕过未实现的代码和工程去做更多的事情。

你可能会说,“没有做过mobile的项目,如何去学习移动端的测试技能?”如果恰好你对行业的发展具有前瞻性和敏感度,例如你可能认为IoT和VR是一个趋势,你却没有机会去这样的项目中做QA。

那么我们是不是可以像开发一样,提升自己的学习能力和适应力,保持对技术的敏感度和热忱,了解不同技术领域,对该领域的开发、测试、构建和集成部署都有一定的了解?所以,如果你想比其他人走的快那么一点,go dev!

5-golf

3.真正的全功能

QA的领域虽然相对受限,但幸运的是角色相对不受限。在日常的开发过程和项目积累过程中,不但能对业务有深刻的理解、对用户行为有独到的见解,而且对技术也有一定的认识。

在需求分析过程中,QA总是可以从技术和业务结合的角度扮演好一个BA的角色,成为一个优秀的PM,甚至我们可以在客户提出一些需求的时候尝试着从一个UX的角度去设计原型,如果具备前端的能力,也可以自己去Dev、UI,不断拓展自己的技能领域,使自己成为真正的全功能。

总结

真正的全功能,并不是单纯意义上让QA去做Dev,而是最大程度弱化角色的概念,逐步强调和培养技能多元化。如何把对需求的理解能力强化为业务分析能力,把质量控制能力强化为项目管理能力。强化自身的优势,跳出自己的舒适区,使自己能够轻松胜任。这样我们才不会在看到去QA和QA消亡之类的观点后,无所适从。

1 2 收藏 2 评论

关于作者:ThoughtWorks

ThoughtWorks是一家全球IT咨询公司,追求卓越软件质量,为客户提供注重实效的咨询服务(IT组织优化、技术咨询、测试策略、客户体验)。同时我们也擅长构建定制化系统和产品,帮助客户快速将概念转化为价值。 我们满怀信心和激情,不断推动敏捷在中国IT业的推广和应用,提升中国软件开发的生产力。 个人主页 · 我的文章 · 24 ·   

相关文章

可能感兴趣的话题



直接登录
最新评论
跳到底部
返回顶部