去全栈测试工程师——进全程全员测试
本文仅代表本人观点，不代表 Testerhome 观点。理解上有问题的，请各位前辈指正。You read it right
一开始我是支持 全栈测试工程师 的，但是当越来越多软件测试人员往这个方向走时，我意识到这是个危险的信号。这让我想起了我家这边的社区医院， 有个全科，看看感冒还行，大病肯定看老天。
什么是全栈工程师？Full Stack Engineer，简称FSD，貌似是出自 Facebook 的招聘细节，白话文就是全技术栈工程师，再白一点就是全才。国外有一篇文章 What is a Full Stack developer? 定义了 FSD。看下作者描述的全栈的技术层：
[*]Server, Network, and Hosting Environment.
[*]Data Modeling
[*]Business Logic
[*]API layer / Action Layer / MVC
[*]User Interface
[*]User Experience
[*]Understanding what the customer and the business need.
很明显，以一个正常人的精力和学习速度来说，想在每一个层面都达到精通显然是不可能的，天才除外。基本公司招到这样一个员工，那么可以省下至少4个人的钱。作为雇主和企业，大力推行全栈真是益处颇多啊。
那什么是全栈测试工程师？2014年的时候，我在回复 移动测试必要技能都有哪些呢帖子的时候，提出了全栈测试工程师的看法。后来在2015年6月6日的 TesterHome ebay 移动测试会上，来自 GLOW 的 Jason Woo 也提出了 Full Stack Testing 的概念。为什么，会有这样的看法？这和移动互联网的爆发有关。阿里巴巴的一句 All in，吹响了移动互联网攻城略地的号角。软件测试一下子从传统PC端跳到手机端，基本没给过度时间。而移动互联网测试不像之前的传统测试，有长久的沉淀和积累。绘制基线，定制标准，摸索方法，人还是以前那批人，测试内容和技术都已经天翻地覆，也许基础的理论万年不变，但是毫无疑问的是，越来越难。测试方法和手段，也越来越灰盒，越来越白盒。对于测试技术层面而言，不会比开发少：
[*]服务端测试
[*]客户端测试
[*]业务测试
[*]专项测试
[*]用户体验
[*]测试管理
[*]风险控制
技术栈这一块可以看 @seveniruby 的测试架构师系列之测试体系。
我们小时候考试或者测试，都是老师给我们批改的卷子。所以如果你不比开发更懂开发，怎么能测试他的代码？如果你不比产品更懂产品，怎么测试业务？如果你不懂UX，你怎么测试交互？当然我们都可以用一句话来回答，测试最爱说的无敌金句：
我从用户角度出发……
个人认为这是非常不负责的，而全栈测试工程师应该定位到问题，提出解决方案，给出解决时间，预测方案风险。这是不是感觉测试工程师抢了很多人的饭碗？于是引出了下一个话题，谁才是最好的测试？
重塑，谁才是最好的测试？抛出这个问题的时候，我并不是说测试团队不是最好的测试，而是想探究下测试行为过程中，每个角色的重要性。
我想单从测试参与人员的角度出发。回顾下自己的工作经历：
[*]我参加工作的第一家公司，没有测试。公司很小，我们有三个初级工程师，两个高级工程师和一个主管。主管每天的任务除了控制项目进度外就是测试。没有人比他了解业务，也没有人比他了解架构。
[*]第二家公司是外包在谷歌做项目。除了正式的测试团队外，参与测试最多的是产品经理，技术经理，然后是模块开发owner 。绝对是全民测试的节奏。产品就像每个人的孩子，各种疼爱。
[*]第三家公司是一家英语教育软件公司。参与测试的除了我的测试团队外，同样还有产品经理，开发经理，甚至到技术总裁。
[*]第四家公司是yeahmobi ，由于大数据方向，特别是算法验证非常困难。一致要求开发参与测试。
很明显，业务驱动型和技术驱动型决定了项目过程中，哪些角色应该放精力进来测试?
[*]对于业务驱动型，有谁会比直接对接业务的产品经理懂行？
[*]对于技术驱动型，有谁比开发人员更懂他的实现？
测试行为是贯穿整个研发过程的。 无论谁都不能逃出持续集成！ 产品狗要时不时看看是不是他要的东西，开发猿需要一直警惕自己代码是否有问题，而测试团队要验证阶段性的新功能和回归老功能。但是不负责任的产品和开发把这些都抛给了测试人员。别拿忙来做借口，你们拿那份薪水。于是这又引出了下一个话题，哪里需要全栈测试工程师？
哪里会需要全栈测试工程师？
[*]伪敏捷
敏捷开发模式已经变成了加班模式。人人都敏捷，把差劲的项目规划转化为997，把有条理的文档转化为繁重的沟通。无论项目是否合适，统统上敏捷。而这个时候，测试人员，成了产品经理，成了项目经理，能力强点的成了开发，运维。成功一条龙服务。测试工程师成为了多职能全栈测试工程师，需求跟进，项目进度把控，精通业务，把控风险，定位问题，要打通前后端，做做 code review，写写自动化。看上去很美，也感觉地位很崇高，但是其实很明显：职能不清。测试人员把过多的精力放在了不需要他们做决策或者压根做不了决策的地方，反而忽略了测试的本职工作。了解是需要的，深入就本末倒置了。
[*]小作坊小团队
小团队就像是冲锋队，每个人都是一把快刀，为了拿结果，都是齐心协力，勇往直前。这个时候，全栈测试工程师的意义就非常大，对于团队的帮助也非常大。由于团队小，必然会一司多职。全栈测试工程师就会像是粘合剂一样，把整个项目过程给串起来。小而美的团队应该都会这样做，这我想也是全栈测试工程师最最理想的工作方式。
然而，无论是伪敏捷，还是小作坊，都不是可持续的状态。尤其在大公司里做着伪敏捷的小团队，容易得一种病：测试依赖症。把质量的问题都压到了测试团队，要知道 开发才生产 bug！ 而这样高压下的测试工程师，往往疲于奔命，最后终会出现纰漏，成了北国大侠！
全栈测试工程师 == 全责工程师很多时候，全栈测试工程师不仅要全能，还要全责。需求不明确，是测试没搞懂；项目有风险，测试早没预警；功能出问题，测试没覆盖；反正质量问题，都是测试的责任。在很多人的眼里，软件测试就是全责保姆，出一丁点问题，就唯测试是问。这个痛，相信很多人都遇到过。不多说，说多了都是泪。
所以去全栈测试工程师So f**k off 全栈测试工程师，这是病态的项目管理下才产生的职位。德智体全面发展，只能成为庸才。一面突出，才能突破（天才除外）。
项目的伪敏捷也到处都有，早期还好，靠牛逼的开发一起加加班，撑过了伪敏捷。
但是慢慢得团队壮大，开发的技术水平也参吃不齐，这时候的伪敏捷，就是漏洞百出BUG无限的下场了。
然后回过头来还说测试测太慢delay...
页:
[1]
