测试工程师职业发展初谈

需求评审环节，测试和开发是统一战线，评审时需求能砍就砍，有问题就多质疑多喷，否则评审完了，含着泪跪着也要做完这些需求，按期交付；
想办法提前了解业务/产品团队未来一个月甚至一个季度要做哪些东西，提前评估工作量以及资源的问题，有风险提前想办法应对；
需求是做不完的，很多时候产品会通过版本迭代之外的独立项目或者多版本并行的方式让技术团队吃下需求，这个时候就要考虑团队的资源配给问题；
如果对交付质量没太高的信心，在质量报告中预估风险，表明可能出现哪些问题，只保证核心的流程功能不出大问题即可。这样即使出问题，也可以均摊风险，有锅一起背；
兜底方案：尽量拉着产品甚至业务一起参与到UAT（用户验收测试）验收环节，给他们提供case，这样万一有问题，也能在故障定责battle时候，有底气去据理力争。

玩笑话：需求评审是技术面对业务和产品时，最后一次的求生机会和保命措施。

1.3 合作关系

职场是很现实的世界，每个角色或者团队的KPI衡量维度是不同的。

运营看拉新效率、DAU及履约转化；

产品看出了多少需求，上了多少功能；

开发看的是完成了多少需求，线上稳定性；

测试看的是线上故障率以及故障的影响程度；

都是打工苦命人，都是被push的对象。不同的KPI导致了一些新名词的出现，比如：线上业务稳定性和线上系统稳定性。对于技术人员来说，优先保证需求交付，再保障交付质量，其次才是和业务及产品的关系。关系不一定有用，但某些时候可以降低你的利益损失。

2、如何提升测试角色在团队中的影响力和话语权？

2.1 测试在技术团队中有话语权吗？

有，但大多数的测试是开发的附庸，特别是一些相对低阶的测试人员。

2.2 为什么有一些测试会问这个问题？

在职场中没有安全感，生存的危机感逼迫；

2.3 怎样提高测试在团队中的话语权？

在自己擅长的领域做到让其他人挑不出刺，比如：我测试覆盖过的保证没问题，我风险报告里提到的还真的出问题了，多来几次，你就有话语权了；
在开发擅长的领域用开发擅长的东西打败开发(很难)，比如：性能优化时候，开发搞不定，你可以快速定位分析性能瓶颈并提出可行高效的优化方案；
在测试和开发共同面对的某些问题上做的比开发更好，比如：电商双十一大促，要搞全链路压测，测试可以主导整个流程，并且对整个环节的各个细节都了如指掌，没了你他们要踩很多坑(要做到这点需要机会，更需要你可以证明自己有这个能力并且真的拿到好的结果)；

3、除了技术还有什么可以支撑在职场走的更远？

有些技术大佬，CICD、自动化、性能测试玩的一溜一溜的，结果年底了业务投诉较多，绩效一般；但有的人技术并不是特别厉害，但能hold的住业务和产品，能保证按时交付，业务和产品也没有投诉，绩效相对更好。

什么原因？

做技术的往往陷入技术陷阱，特别是一些技术大佬，因为他们觉得问题超级简单，为什么产品和业务就不能理解呢？很容易陷入对技术的推崇而忘记了产品和业务本身就不是这个领域的，技术和业务之间的壁垒还是很严重的。如果能通俗易懂的让外行人也能听懂你在做的事情对他们带来的价值，才能更好的拿到结果。

这里实际上就是自己懂和让别人也懂的区别，说白了就是沟通和表达的问题。

在职场中，特别是上规模的企业，沟通和表达有时候比技术更重要。有些特别明显的例子：

年度绩效考核或者述职，领导要求你写个PPT；
要写一份清晰全面的系统规划或者技术设计文档；
做了一个项目拿到了好结果，要给老板做汇报(越高层的领导技术出身的概率越小)；

如何提高自己的沟通和表达能力？

养成时刻记录的习惯，笔记/便笺/快记都可；

定期复盘总结，将笔记转化为结构更完整的内容；

写博客写技术文章，这个过程是对自己思维能力和结构化表达的不断梳理；

参加技术沙龙或者技术大会，多听更要多分享，经常约一些同行做深度的沟通交流；

4、测试主导的跨团队项目如何拿到更好的结果？

有时候我们容易陷入思维误区，在职场中公事公办，按流程办事。逻辑上来说这样是没错，但职场我们打交道的是具体的人，而不是问题。人有自己的情绪和利益考量，很多时候是屁股决定脑袋。

示例1：DBA以及基础架构的同学沟通关于变更权限收口的内容。

我：大佬，我要搞环境稳定性治理，希望减少随意的表结构变更和让底层数据保持一致；

DBA老大：我一直想干这个事情，但推业务那边一直不搭理我，阻力很大；

我：你看我们合作怎么样，我和业务研发协调这个事情，你把底层的技术规范搞定？

DBA老大：没问题，权限收口/变更走工单，降低变更频次，规范SQL规范，我来搞定；

我：那你先准备技术方案规范，先挑环境试点，业务方我去沟通，好了我们就开始搞；

DBA老大：可以，需要帮忙的尽管说，做这个事情对我们DBA也是个好事情；

分享这个对话要表达的是：我们工作中面临痛点，也是其他人想解决的问题，寻求利益共同体，协作达成，比孤军奋战更轻松，达成的效果也会更好。

示例2：测试环境容器化

基础架构一直想推业务线接入容器，但一直很难推下去，理由也很正当：“业务迭代需求太多，没时间没资源接，而且稳定性也是要考虑的”。正好我在牵头做测试环境治理，希望能快速拉起环境和服务（ECS虚拟机部署服务太麻烦了，速度还慢），结果聊着聊着，一拍即合。我负责和业务方沟通，基础架构提供技术解决方案。

这里要补充说明下，不是我有多高的职位和权利，才能去和业务方沟通。而是测试环境的痛点已经影响到整个技术团队的需求迭代研发交付了，大家即使不太乐意，但这个问题不解决大家都很痛。

主要想表达的观点是：

跨团队的项目，沟通是最重要的。想办法找到其他团队的利益共同点，团结更多的力量，而不是孤军奋战；

有时候领导看的不仅仅是你个人拿结果的能力，还有一部分是你能否少给他找问题，没人想被更多的问题困扰；

先把蛋糕做大，再考虑分蛋糕的问题。很多人蛋糕还没做出来，就考虑自己要切多少蛋糕的问题，这个很不明智；

团结更多的力量和利益共同点之后，即使项目最终不了了之没有拿到好的结果，法不责众下，个人也不会承担太多失败的风险；

5、目前的面试求职市场上测试领域有哪些变化？

现在的求职市场，已经不仅仅只考察个人的项目经验和技术能力了，而是更关注你做的项目落地的经验。如何理解这句话？

很多同学简历会写自己的擅长技能以及项目经验，常规的面试流程基本都是聊技术细节，举个我面试其他候选人的例子：

我：简历里你写了比较擅长自动化测试，聊聊你是如何做自动化的？

候选人：我用的python+python+jenkins+allure框架，用了PO模式，数据用Excel维护；

我：为什么会选择这个框架，和其他框架相对比，这个框架有什么优势，能解决什么问题？

到这里70%的候选人基本就卡壳了。。。

当然，上面的描述只是一个例子，我一般还会问其他关于自动化的问题，比如：

自动化测试的结果如何度量？

如何提高自动化case的覆盖率？

一个人维护还行，假设现在有多个人要共同参与到自动化项目中，你有什么改进思路？

除了Excel你会考虑其他方案么？比如用数据库统一存储，维护专门的自动化测试数据；

多人参与的项目，大家提交的case和代码，如何做好版本管理？

我实际上并没有直接问纯技术的细节，而是在试图引导候选人，对自己做这个项目的一些想法，包括技术框架选型，扩展性如何考虑，如何对结果进行度量等，希望能听到更多实际的思考和遇到问题如何解决的。

6、测试同学成长的核心认知

职场生涯中，不同阶段确实关注点会不一样。像测试工程师这种技术岗位，在职场生涯初期，重点在技术提升和实现细节上，确实是首要的。但长久来说，如果希望自己的职业生涯走的更远更稳定，除了技术和方法，也需要对质量保障体系有更深入的了解和认识。

从更宏观的角度来说，了解质量保障这件事在整个软件工程中的定位，了解技术如何在产品中产生正面作用，创造业务价值，比技术本身更重要。太过关注技术和细节，反而容易忽略全局，容易陷入迷茫，或者职场发展天花板会变低。

6.1 技术不等于能力

软件测试工程师是一个技术岗位，要胜任这个岗位，技术是第一要素，很多同学也会把技术提升放在第一位置。但技术优秀就一定能做好质量保障工作吗？不一定！

很多时候我们在工作中面临的问题，反而不是技术问题。比如对需求的理解不一样带来的信息差，比如对任务优先级的定义不同带来的资源错配，比如不同岗位对同一个需求的实现难度评估差异带来的工时预估和排期冲突。这些问题需要我们了解业务，对需求有深入的理解和分析，对任务优先级达成共识，对技术方案和人效有较为客观的预算投入。

职场中我们评价一个人的能力，往往是他运用各种方法和技巧解决问题的能力，而不是技术本身，技术只是解决问题的手段，技术解决不了所有问题。

6.2 成长需要不设限的探索

这两年求职市场很冷，很多同学面临着裁员失业和找不到合适岗位的情况，偶尔有个看中的岗位出现，也会发现自己的能力和岗位要求相差甚远，原因是什么呢？

一方面，以互联网行业为代表的IT产业红利期，已经过去。每个行业都有自己的快速发展期和暂时的低谷，这是一种阶段性的波峰波谷。在行业发展初期，门槛较低，对技术和综合能力的要求没那么高，有基本的技术能力就大概率能找到满意的工作。但行业是不断发展和成熟的，技术也在不断迭代和演进，如果想着吃老本，或者自身技术以及综合能力的提升跟不上行业发展，那迟早会面临这种局面，这也是互联网行业“35岁失业危机”的原因。

另一方面，技术本身就是一种创新，会不断提高工作效率，降低成本。当技术发展到成熟期以后，除非有革命性的变化带来新的岗位，否则你可以认为这个行业发展到一定程度后会变成一个存量博弈。这个时候想要在这个行业持续耕耘发展，要么你需要想办法成为这个行业某个领域的前1%，成为定义事实上的标准那一小撮人；要么你就要不断扩展自己的职责和能力边界，去“卷”其他岗位。

为什么这几年所谓的敏捷、devops、测试左移右移越来越火热，从自私一点的角度出发，其实就是从单一职责逐渐向综合性岗位转变。单一职责能保证大家分工明确，都有肉吃，再不济有点汤喝。但存量博弈的时候，你多做一点，别人就少做一点。你的产出表面上会更高，被裁员的概率就越低。

我不否认敏捷、devops、测试左移右移对企业和团队甚至个人带来的正面价值，因为这个过程本身就是在优化质量，提升生产效率。但从测试工程师自身的发展角度出发，深入熟悉业务，了解产品运营，提升对研发和运维岗位的了解和技术能力，也能让你在职场的路更宽，可选择的余地更大。

参考文章：

测试同学职场成长的核心认知

rs勿忘初心

关注

2
点赞
踩
2

收藏

觉得还不错? 一键收藏
0
评论
测试工程师职业发展初谈

测试工程师的职业发展，从长远来看，可以往技术和管理两个方向发展，比如成为测试领域的行业专家或架构师，也可以从事测试团队的管理，带领团队高质高效完成测试任务。不管是技术还是管理，很多东西其实是类似的。下面这些内容是从网上学习到的，仅供参考。老生常谈的话题，各个团队或者公司应该大同小异。流程是什么？为什么要有流程？流程能解决什么问题？流程能带来什么保障？流程是保障团队目标达成的最佳实践，因人/团队/业务类型/迭代速度/资源紧张程度而异。没有流程会导致团队中的个体各自为战，目标不统一，进度不协调，资源配给失衡而导
复制链接

扫一扫