前言

　　今天几个测试圈子的大佬约了饭局，席间彼此交流了很多关于职场工作上测试相关的话题，听了他们的一些观点很有启发，我自己对于聊的话题也做了一些描述和实际的案例说明。下面是聊的一些关键话题，我将交流的内容和个人观点整理了下，供大家参考。

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

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

　　流程管理

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

　　流程是什么？

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

　　为什么要有流程？

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

　　流程能解决什么问题？

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

　　流程能带来什么保障？

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

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

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

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

　　如何高大上的理解流程？

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

　　需求评审

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

　　需求评审环节，测试和开发是统一战线，评审时需求能砍就砍，有问题就多质疑多喷，否则评审完了，含着泪跪着也要做完这些需求，按期交付；

　　想办法提前了解业务/产品团队未来一个月甚至一个季度要做哪些东西，好提前评估工作量以及资源的问题，有风险提前想办法应对；

　　需求是做不完的，很多时候产品会通过版本迭代之外的独立项目或者多版本并行的方式让技术团队吃下需求，这个时候就要考虑团队的资源配给问题；

　　如果对交付质量没太高的信心，在质量报告中预估风险，表明可能出现哪些问题，只保证核心的流程功能不出大问题即可。这样即使出问题，也可以均摊风险，有锅一起背；

　　兜底方案：尽量拉着产品甚至业务一起参与到UAT验收环节，给他们提供case，这样万一有问题，也能在故障定责battle时候，有底气去据理力争；

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

　　合作关系

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　1、在自己擅长的领域做到让其他人挑不出刺，比如：我测试覆盖过的保证没问题，我风险报告里提到的还真的出问题了，多来几次，你就有话语权了；

　　2、在开发擅长的领域用开发擅长的东西打败开发(很难)，比如：性能优化时候，开发搞不定，你可以快速定位分析性能瓶颈并提出可行高效的优化方案；

　　3、在测试和开发共同面对的某些问题上做的比开发更好，比如：电商双十一大促，要搞全链路压测，测试可以主导整个流程，并且对整个环节的各个细节都了如指掌，没了你他们要踩很多坑(要做到这点需要机会，更需要你可以证明自己有这个能力并且真的拿到好的结果)；

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

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

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

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

　　问题出在哪里？

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

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

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

　　·年度绩效考核或者述职，领导要求你写个PPT；

　　· 要写一份清晰全面的系统规划或者技术设计文档；

　　· 做了一个项目拿到了好结果，要给老板做汇报(越高层的领导技术出身的概率越小)；

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

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

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

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

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

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

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

　　这里大家可以看我之前的文章：《被忽视的问题：测试环境稳定性治理》。里面讲到了我在牵头做这个项目时，和DBA以及基础架构的同学是如何沟通的。下面是部分内容节选：

　　变更权限收口

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

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

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

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

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

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

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

　　测试环境容器化

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

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

　　举上面的例子，我要表达的观点是：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　上面谈了一些很有意思的点，我尽量用通俗易懂的话表达出来。这些也是我自己工作中曾经遇到的一些问题，希望看到这篇文章的同学，能对你当下面临的问题有所帮助。

作者：老_张    

来源：http://www.51testing.com/html/51/n-7794451.html