本文仅代表本人观点，不代表 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 全栈测试工程师，这是病态的项目管理下才产生的职位。德智体全面发展，只能成为庸才。一面突出，才能突破（天才除外）。
其实我在推： 全程和全员测试。
看完了，涨姿势，很赞，打赏~~·
全栈测试工程师，相信我们这行业有很多这样的人，或者正在向这方面发展。
不过初学者，还是可以尝试多方向。n 小时=专家么。
全员测试，up！
恩.
项目的伪敏捷也到处都有，早期还好，靠牛逼的开发一起加加班，撑过了伪敏捷。
但是慢慢得团队壮大，开发的技术水平也参吃不齐，这时候的伪敏捷，就是漏洞百出 BUG 无限的下场了。
然后回过头来还说测试测太慢 delay...
这里的 “全栈测试工程师” 其实就是项目的保姆啊。。。啥都要干还必须是背锅侠。。。
不过开发还根据他的技术栈来安排工作，测试基本是哪里需要测试就去哪里，从服务器后台到接口，再到前端。有些时候全栈就是这样被逼出来的。。。
全栈，我也有点体会。。。
初期各个方向都尝试下也没啥，然后找两三个感兴趣的方向深挖就是了~
也没必要纠结在测试这个行当，测试工程师，无非就是专门从事测试这项行为活动的人。而测试这项行为活动 ，说白了，更像是验证性的工作，可以从开发阶段就介入进去，介入的深浅程度，取决于对业务对技术的掌握程度和反应速度（比如快速准确定位问题，协助 review 代码，帮 dev 理思路，上去改改空指针啥的，再牛掰点上去写点代码），比如纯银的一条长微博也说了，大意是他产品需求出了的时候他自己也会去写测试用例，期间变了需求那用例也随着改，这也意味着这项活动不一定非得测试工程师来做，可以组织带领引导指导好多人来做，走楼主说的全程、全民测试那个套路。
只要努力，不一定非局限在测试，转产品去给出更合适的引导、转开发去一线生产力、转项目经理揽大局也未（zhi）尝（yao）不（gei）可（gou）啊（qian）。。。
但是话说回来，技术栈真的越来越大了。。。这咋办呢。。。
伪敏捷那段深表赞同，在领导眼里我们测试都是背锅侠
全栈工程师要学的东西太多了，也学不过来了
现在公司就是全栈测试工程师 == 全责工程师，这太坑爹了
在俺们大平安以前分测试岗位的，现在统一名称了，so，在平安很早就全栈了
但是往往都是被逼出来。。。
我还是支持全栈的，变成全责就不知道了是因为啥了。
我看了标题才点进来，没想到去后面省略了几个字
我现在本职是测试，但是偶尔还要跟开发一起干活（人手不够。。
说实话，开发比测试轻松多了。。。。 FFSD ？
唉 ！现在的一些公司， 感觉只需要测试全责北国， 全栈不全栈对其来说不重要 。如果不能改变现环境还是考虑下其他环境的好~
其实我觉得有的时候领导不可理喻的，只要想想常识就觉得测试对质量全权负责是多么荒唐的事情。让一个组织里面相同级别工资最低的人，负责可能是产品最重要的事情 - 质量，天底下有这么便宜的事情吗？？？？如果要让测试负责质量，那么测试应该什么都可以管才对，让写单元测试写单元测试，让写文档写文档，让干什么干什么。。。。。。。。，这才叫负责质量，质量几乎包含了全部，你对质量负责，你就对全部负责，所以你就有全部的权利。。。。。。。。。。，不过要是真这样了，测试还叫测试吗？有谁能干这个事情，哈哈，一通胡说的话
小作坊 + 伪敏捷。。。。。转行 1 年多点。。。。项目跑个 MONKEY 开发就觉得就还行了。
不是纯互联网项目，项目完全没有那种高标准互联网测试需求，也就没有所谓的实践。
什么都做点皮毛，最近出去跟其他公司聊聊，都觉得什么都差点。年纪也不小了，实在是纠结。
顶一面突破，没有特点实在是很难出来！~
能做到 ownership 的自然就是全责了...项目当成自己的孩子一样, 负责到底那也是一种境界~
我也支持全栈，讲究一专（或几专）多能。这样才能活得更长久。
说真的，我们这这边的产品经理对产品非常了解，经常能帮我们发现不少问题
#23 楼 @zhangzhao_lenovo 一专和多专是自己的成长。我说过，团队中，一个人能做很多事和一个人做很多事是不一样的。
做测试工作也多年了，现在看到测试招聘的要求都心虚，要求精通 xx 语言，熟悉 xx 框架，熟练 XX 系统。什么前端，后端，性能，自动化，能想到的全上了。
我想说的，测试核心能力真的是要求的这些技能么？他们真的了解一个好的测试人员该具备哪些能力？
一切都要以产品为导向，从产品的角度去思考测试的真正价值！
背黑锅这个问题一直存在。但是，还是有部分人自身造就了这口锅。在摇旗呐喊的同时，请确定这口锅是别人给你的。
仅此！不针对个人。。。
觉得这篇文章的题目和内容偏失度蛮高的。“全栈测试工程师，这是病态的项目管理下才产生的职位。” 这个其实也算吐槽吧。
即使 twitter 也有文章说去全栈工程师，但是不要误解的第一点就是团队是什么样的。
“全栈测试工程师，这是病态的项目管理下才产生的职位。” 这句话应该这么说 “病态的项目管理下，说全栈也是病态的全栈工程师” 比较好。作为一个开放的平等的论坛这么说没有问题，但是如果影响测试发展这么说就不负责任了。
据我所知北京至少也有 3 个团队 run 全栈测试非常好，他们的困惑和我都是一样的，全栈测试为什么难招。回到这个话题我觉得你理解的全栈可能有很大的偏差。 就像国人理解敏捷的偏差一样。
背锅大侠，非常形象。目前还背着运维的锅，两口大锅，压力山大。
术业有专攻
想法是好的，但是到了国内就变成了 “中国特色” 类似的例子举不胜举。别说国外的月亮圆——老外也搞不懂，我靠你们不按套路出牌啊！
其实很多人是被全栈，因为小公司项目杂，人手不足，一个测试人员可能会接触不同项目，而项目会有不同的测试需求。初期我觉得也没什么不好的，至少可以打开眼界，多接触不同测试，但是的确，除非你是真的努力而且有天分，后期要全栈真的很费功夫，可能对大多数人来说专攻某方面测试对职业发展更好，而且实际某方面测试内容也已经很丰富了。
术业有专攻，很多都是产品狗不负责任。
全栈
#33 楼 @lihuazhang 不好意思，回复晚了啊，招人难因为上海的测试市场你也明白，除非自己培养出来的吧。其实就像敏捷一样，刻意去做敏捷的一定做出四不像来，全栈更多的也是自己去做，真实不排除中国特色的。正确的全栈测试更多的是自发形成的一种约束力，没有人说要做性能，又做自动化，又做线上监控，关键是如何能更好的保证质量。如果不做任何事质量能上去那么的确也会出现无测试化的状态。事业有专攻，测试的专供应该就是质量吧，无论线上还是线下。另外管理模式及团队一定也是影响的因素。
#1 楼 @lihuazhang 产品，开发和测试一起为质量负责才是大势所趋。但要做到，1 测试管理的影响力很重要，2 cto 或者 ceo 的理解&支持也很重要。
#20 楼 @simonpatrick 大多数产品和技术领导对测试理解不深，但更重要的是测试自己也是这样认可的。我觉得思路的改变任重道远。影响力很重要，对的事情就改大声说出来。
#20 楼 @simonpatrick 说的太对了。。。
感叹下吧……
我也感受过这些，个人认为这个和环境逃不开。测试本就是个 “万” 精油的类型，但是首先是” 万 “，至于” 精 “，没有环境但却有现实压力的情况下，是不可能精的。不过我现在又再次憧憬成为真正的全栈测试工程师，这路是比登天难，但梦想是需要的；或者有个好平台，成为专项测试工程师，还得能待一辈子的那种……说多了是泪，回到了三线，要么永生，要么离开这领域
多手准备，只因现实的无奈
全程和全员测试。这个我很有感触。
现在的团队就我一个测试，20+：1 的比例，所以测试不可能由我一个人来做。更多的时候，我去制定计划，全员测试。包括项目经理等等。大家都有这种意识，更容易推动流程，改进质量
那么问题来了，如何体现测试人员的专业性，而不至于沦为打酱油的呢？
的确如此，我最近一段时间，也是迷茫，学了好多的东西，很渣，很杂，最后发现，我会了这么多，然并卵，已经失去了学习新知识的动力了，现在我也不打算向什么所谓的 ‘全栈’，我还是老实先把测试接口这块整理，和服务器性能方面的知识重新的优化和梳理下，至于什么自动化测试平台，什么安全测试，我特么暂时不想碰了。。经常遇到一些测试助理，初级测试工程师，连最基本的手工测试都做不好，说我会 qtp,我会 lr，我会自动化。。
支持全员测试
全栈工程师在未来肯定会有的，现在只能尽量适应了。大部分团队，都是找个测试北国打杂
小作坊的测试确实会容易成为背锅侠，但 “全栈” 的定义不是技术树的叠加，而是在技术全面的基础上解锁更高层次的技能。就像某国产功能机其功能点上基本超越所有主流手机，但这改变不了山寨机的本质。技术本身就像手机功能一样，其本身没有本质的价值意义，看你怎么去发现问题、定义问题、解决问题，技术只是一种实现方式而已，真·全栈的核心竞争力就此。
年轻的时候也是北国大侠。。
刚开始的时候也觉得测试的方向应该面面俱全，什么都需要了解，但是不一定要深入理解 (那是研发的事儿)，做这样的"全栈测试"。
后来发现这样的知识结构在项目刚启动的时候很好用，但是一旦到了需要解决问题的阶段了，你的价值就小了。
然后开始尝试走深入技术的路线，结果还是一头雾水：性能啊，安全啊，移动啊，从单元到 E2E 各种层次的质量保证手段啊。太多太杂太混乱，我好迷茫我好方。
接着发现做了这么久的测试，测试经验也在不知不觉中积累了起来。有的时候新需求过来，研发一确定方案，你就知道哪些地方会踩坑需要重点测试了。甚至有的时候需求提过来大家还在看需求的时候，你已经发现需求里面的坑了。
回过头来分析一下，发现这些经验之所以能积累起来，是因为我的技术经验和领域经验都在慢慢积累中，当这些东西积累到了一定程度，就能 “未卜先知” 了。
所以多了解技术重不重要？当然重要，不懂技术你怎么总结针对 xx 类型需求的解决方案哪儿有坑哪些是 best practice？
业务重不重要，我觉得对测试来说业务更加重要。测试的核心竞争力我觉得应该是保障这个业务是有"价值"的，所以对于需求你也是需要测试的。有些需求莫名其妙反架构反人类甚至，这种需求直接打回去。算了还是好好跟产品经理沟通一下吧。。
但是如果换了个公司之前积累的业务知识不就白积累了么？并不是。首先前面说的业务只的是领域知识，换公司不一定换领域吧？
就算换了领域，在之前积累业务过程中你积累到的除了业务，一定还有如何积累业务知识的经验。这些经验能帮你在新的领域快速建立你的知识体系。
现在这个阶段，有幸在一个敏捷团队中工作，享受着公司从上到下都信奉"质量是全员的事情"氛围，研发十分重视质量，UT，集成，E2E 一个都不少，部分项目坚持 TDD。我自己也参与到 UT/IT/E2E 各种 T 的 review 中，所以拿到手上的东西很少会出现 BUG。自己也有更多的时间去思考，去做探索性测试，去实践新的知识。
所以比起全栈测试工程师，我更赞同全站测试工程师，站起来多走动，多发挥你协调沟通的又是，推动全程和全员测试。