八年测试工程师—浅谈职场发展

最新推荐文章于 2024-07-26 16:41:46 发布

软件测试凡哥

最新推荐文章于 2024-07-26 16:41:46 发布

阅读量445

点赞数

分类专栏：经验分享软件测试心得

本文链接：https://blog.csdn.net/m0_70618214/article/details/127079219

版权

经验分享同时被 2 个专栏收录

225 篇文章 14 订阅

订阅专栏

软件测试心得

48 篇文章 2 订阅

订阅专栏

前言

从测试leader的角度如何保障质量交付？

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

结语

前言

今天几个测试圈子的朋友约了个局，席间彼此交流了很多关于职场工作上测试相关的话题。

听了他们的一些观点很有启发，我自己对于聊的话题也做了一些描述和实际的案例说明。

下面是聊的一些关键话题，我将交流的内容和个人观点整理了下，供大家参考。

从测试leader的角度如何保障质量交付？

聊的第一个话题就是测试leader如何保障团队的质量交付，这个话题最近在很多地方，听很多人聊过。我会尝试从以下几点来做阐述说明，观点仅代表个人看法。

流程管理

问：流程是什么？为什么要有流程？流程能解决什么问题？流程能带来什么保障？

流程是什么？

流程是保障团队目标达成的最佳实践，因人/团队/业务类型/迭代速度/资源紧张程度而异。

为什么要有流程？

没有流程会导致团队中的个体各自为战，目标不统一，进度不协调，资源配给失衡而导致交付质量下降。

流程能解决什么问题？

流程能保障团队或者群体在大方向上保持协调一致，尽可能降低由于团队人员能力、认知水平、资源不足、意外情况导致的项目延期或者质量下降。

流程能带来什么保障？

关于这个Topic，我想用比较通俗易懂简单直白的话来表述，想象一个场景：

如果没有流程，产品三天两头改需求，接还是不接？不接的话，产品投诉说需求很紧急，不做会影响运营指标、GMV、DAU......等等很多理由，技术不配合，怎么办？

虽然说职场是个讲规则讲道理的地方，但实际上从业务和产品团队的实际操作来看，当她需要和你讲道理时候，道理才成立。如果她不想讲道理，技术绝大多数时候就是故障定责时候背锅的。

这个时候，流程的作用是什么？流程可以保障你可以有底气的据理力争，虽然不一定能扭转局势，但在一定层面上，会哭的孩子有奶吃，偶尔学会受委屈给领导看，也是以退为进保障自己利益不受太多损失的技巧。

如何高大上的理解流程？

风险可识别+问题可追踪+结果可验证+数据可量化（记笔记，抄下来）！

需求评审

聊完流程管理，接着聊聊需求评审。这里不讲大道理，只谈实际操作的经验。

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

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

合作关系

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

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

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

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

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

你看，都是职场苦命人，对老板来说，大家都是被push的。

不同的KPI导致了一些新名词的出现，比如：线上业务稳定性和线上系统稳定性，这又是另一个话题了。

对技术团队来说，先保证需求交付，在保障交付质量，其次才是和业务及产品的关系。关系不一定有用，但某些时候可以降低你的利益损失。

如何提高测试在团队中的话语权/影响力？

前几天转发了某个大佬的一篇文章：《测试如何提高自己的话语权》，席间也聊到了这个话题。

知乎有个惯例是：先问是不是，再问为什么。

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

有，但大多数的测试是开发的附庸；

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

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

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

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

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

席间我们聊这个话题时候，还是蛮有意思的。

有个大佬说他们公司有个技术大佬，CICD、自动化、性能测试玩的一溜一溜的，结果年底了业务投诉较多，绩效只有B。

但另一个人技术并不是特别厉害，但能hold的住业务和产品，能保证按时交付，业务和产品也没有投诉，绩效相对更好。

问题出在哪里？

做技术的往往陷入技术陷阱，特别是一些技术大佬，因为他们觉得问题超级简单，为什么产品和业务就不能理解呢？

很容易陷入对技术的推崇而忘记了产品和业务本身就不是这个领域的，技术和业务之间的壁垒还是很严重的。如果能通俗易懂的让外行人也能听懂你在做的事情对他们带来的价值，才能更好的拿到结果。

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

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

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

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

养成时刻记录的习惯，笔记/便笺/快记都可；
定期复盘总结，将笔记转化为结构更完整的内容；
写博客写技术文章，这个过程是对自己思维能力和结构化表达的不断梳理；
多参加一些技术沙龙或者技术大会，多听更要多分享，经常约一些同行做深度的沟通交流；

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

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

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

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

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

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

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

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