测试工程师的明天在哪里

如果一个人很真的看待自己的工作,那么可能会常常想到展的问题,所人无远虑,必有近忧嘛。同样的,测试人员也会常常问发展的方向在哪里,这其中,刚入行,准备入行或者做了几年的恐怕都有。

 

最近,在订阅的blog上也看到类似的讨论文章,比如:

测试架构师Jack同学有两篇关于测试专家的讨论。

3型的测试专家之路选择》

http://www.51testing.com/?uid-293557-action-viewspace-itemid-232781

《关于什么是测试专家的讨论》

http://www.51testing.com/?uid-293557-action-viewspace-itemid-233822

 

另外最近在淘宝的QA blog上也看到一篇他测试总监,郭芙女士的文章,叫做《测试者之路》,探测试的两条展路线,她称之P线M线,大概相当于我时说tech trackmanagement track

http://qa.taobao.com/?p=12059

 

都是很好的探,看了觉得很受益,不过又觉得不过瘾,好像,遂决定撰文述一下。先声明一下,观念有时候受限于个人经验,所以难免狭隘,不过我不准备大而全,而只说说自己看到的,宁愿少也不要误导大家。

 

为讨论方便,我把我看到的发展道路分了两大类,测试相关领域和非测试直接相关的。

 

1.先说继续留在测试领域的。

1.1 分,第一是管理路线。学而优则士也是有传统的,所以并不奇怪。

一路线发现大概是QA lead à QA manager (QM) à QA director

 

各公司叫法不同,大概的意思如此。一般是先开始做测试团队lead,或者叫组长。严格意义上,这个还不算是管理的职位,但是也算是预备。不过实际中,做lead并不一定意味着要发展到manager,很多技术路线的也可能在一段时间担任lead。其中的一个原因就是做lead是非常锻炼人的,即便以后走技术路线很多的知识和技能还是必备的,也是相通的,比如协调的能力,沟通的能力,对全局的把握。

就我个人的察,不同的group可能格不同,或者取决于QM管的范,有些目,QM介入很多,有的很少,所以相lead职责和空也不同。

 

如果是管理路线,到后面就是QM了,当然也可能会有acting实习)的段。到QM后就是比较纯粹的管理路线了。当然,看个人的格,有些QM也是比technical的,也会常研究测试工具技和方法,并出去分享。但是就能上,很多一部分工作是team的建管理和人选择培养,按照我公司的划分,是属于people manager的范了。

 

再往高,就是QA Director,比如在blog上活Kerry,下面一些manager品的范也更大,有些可能不看具体的目了,而更多思考一些全局性的方法和策略,但是人的培养应该是主

 

看公司的大小,也可能会有更多的层级,不大致是一的。在这条路上,到某个时候,再往上,可能就越界了,意思是不再直接和测试相关了,比如升任研发总监或者VP,到这个层面,已经不分开发和测试,因为两边的report line汇总到一个人上面了。我们公司三大RD head中就有一个做了很多年测试,有次和他吃饭聊起这个话题,他说早期公司人少,全职的测试人员也少,所以有机会接触很多不同的产品,也得益于此。

 

1.2 线

这个想必大家也不陌生,国内很多的公司,特别是稍大的公司都在提。其中有一个很直接的原因,那就是上面的管理路线会很依赖于组织结构和组织的成长,通俗的说就是要有坑才行。另一个方面,产品的精深对于高层次的技术人员也有更多的需求,而且不是所有人都想或者都适合走管理路线。那么对应的技术路线也就很自然的出来了。其实关于这一部分,最近几年我们的讨论也很多,一度大家也很迷茫,一个简单的问题是,大家没有想明白一个和manager,甚至director拿一样薪水的QA engineer应该是什么样的,有什么样的能力和贡献?

现在我们有了一些思路。这里说的是我个人的一些看法,不是官方的定义。

 

1.2.1 Domain Expertise

第一测试领域的专家,这一类Jack在文章中也有讨论。比如说automationperformancesecuritycompatibility等等领域,都是需要长久的积累,也很有专业性,可以产生对应的领域的专家。这样的专家也是从产品和项目中锻炼出来的,但是慢慢的发现,他们的经验和技能越来越深,而且也变得更加通用,可以让其他产品和项目也收益,这种影响力甚至可以扩展到其他部门,有点横向的发展。

关于这条该怎么去走,这里就不展开了,姑且就先知道有这么条路,应该有很多值得讨论的。

 

1.2.2 Engineer Productivity Developer

测试中会用到很多的工具和系统,如果组织够大的话,通常为了效率和ROI,会把这一部分抽取出来给一个部门来做,我们称之为engineering tools and service。其实这也是一条发展的路线,因为很多人喜欢去开发工具,让更多人的从中收益。不过目前我个人的看法,这条路在一个不以测试工具为产品的组织里面会有瓶颈。毕竟国内纯粹开发测试工具的厂商还很少,没有像SpirentIXIA, Micro Focus, 还有以前的Mercury之类的公司。

 

说到developer,很多人会说,转到developer也是tester的一个track。我不这样以为,因为那样而言测试不是一个独立的工作,而只是developer的预科,在有些公司,特别是一些测试不正规的小公司,可能这种认识会比较普遍。但是这个不在我这里讨论的范围,因为前提是把测试做为一个独立的工作类别。

 

1.2.3 Solution Architect

要一,比如言,设计模式等等,另一方面要了解和熟悉品相关的域知。比如设计和开发银行的业务系统的人要了解银行的业务。对于测试人员而言,同样如此,甚至要了解更多。试想一样,如果你去测银行的利息计算的程序,你都搞不清楚利息计算的方式和银行业的各种规章,又如何能判断测试结果的对错,被测系统设计得是否正确或者合理?换到别的行业和领域,也是一样。长此以往,很多测试人员就慢慢成为了领域专家,对业务和产品都非常熟悉。这种熟悉和developer不一样,通常developer是对某个他做的模块细节实现有深入的了解,受限于时间和精力,无法了解产品功能的全貌,而QA的角色使得难以了解到代码级别的实现细节,但是对于产品的各个功能,用户的部署和使用场景等方面比较熟悉。于是乎就又了solution architect这样的概念出来了,就是要针对具体的市场或者客户过来的问题,能做评估和分析,给出相应的技术方案,并做技术的验证。

我们公司现在有QA engineer在这种方向上走到和director同等的级别。这方面需要对产品的知识有非常深广的积累。

 

1.2.4 Industry expert/leader

上面的三条路,你会发现其实是讲平时的工作从几个不同的角度去延伸,分别是深度,通用性和产品领域。其实还有一个延伸的角度,就是影响力的范围,如果可以超出公司的范畴,可以超出行业的范畴,就变成我这里说的industry expert或者leader。这一方面,目前国内还不多,大家听得多的还是国外的一些同行,比如James Bach, Alberto Savoia, James Whittaker, Scott Barber等等。

他们在很多公司工作过,不过大家记住和尊敬他们是因为他们做的演讲,写的书,提出的理论和方法,可以benefit到其他人,让别人从中学到有用的东西。

这其实也是一条路线,独立于公司和产品。但是这条路显然不容易,至少要有深厚的积累,而且要有很强的归纳总结能力,能写能讲。当然很多这样的人本身也在公司里面上班,也有一些是自己开办自己的咨询公司,比如James Bach

 

 

好吧,和测试相关的完了,下面我来看看的方面。

2. 转换到别的角色

2.1 项目经理,Project Manager,简称JM

测试人员,特别是QA Lead转项目经理的例子在我身边还不少。分析来看,有很多skill方面的东西是相通的,比如要做进度的管理,良好的协调和沟通能力,等产品的比较深的理解,对公司各种相关的部门和流程的熟悉。

 

2.2 产品经理,Product Manger, 简称PM

这种例子没有上面多,但是也有一些。在我们的体系里面,PM负责整个产品roadmap的制订,简单来说就是决定下一版要做什么feature,以及对产品的市场定位和规划,有一部分是偏向marketing的。相对于JM,可能更偏向于business,对产品所在的行业,客户,以及竞争对手有比较深入的了解。相对而言,跨度要更大一些,而且对个人性格特质的要求也不太一样,因为JM毕竟还是属于R&D的范畴,而PM不是。

 

2.3 售后和技术支持

这方面的例子也有,我前老板的老板就去做了supportdirector,不过这个好像还是偏管理的。engineer也是有的,不过这方面要看组织的结构是把support做为完全独立的机构还是开发的一部分。

 

写到这里,大部分都是我在工作中看到的例子,发现其实也不少。但是我深信这个列表一定是很局限的,一定有更多的。

其实真的又更多,再举一个例子,比如去卖车卖车?是的,大家不要笑,我的是real case。前段时间,某天中午和同事去一家4S店看车,遇到一个sales,看了半天,也问了半天。末了,快要走的时候,他问我是做什么的,估计我们看了半天又不买所以要看看能否买得起,我说软件大道上做软件的。哦, 他说他以前也是做软件的,搞数据库方面的,后来受不了加班改行了。嗯,所以你看嘛,这也是一条路啊。

 

好了,先写到这里,也欢迎大家的讨论。

 

 

<think> 我们有一个字符串输入,格式应该是类似"YYYYMMDD"或者有固定格式的字符串(例如"2023-10-29"),但原代码中索引5、6和8、9的位置,说明可能是格式如"2023-10-29"(即长度为10,索引从0开始:0~9)。所以,第5、6个字符是月份(例如"10"),第8、9个字符是日期(例如"29")。 目标:判断日期是否小于10月29日(注意:小于10月29日,包括10月29日之前的所有日期,以及10月28日等,但不包括10月29日及以后?) 但原代码逻辑是:如果月份大于10或者日期大于29,则输出"QAQ",否则输出"No, It's not too late."。这个逻辑实际上是在判断日期是否大于10月29日(即月份大于10,比如11月、12月,或者月份等于10但日期大于29)。反过来,如果月份小于10,或者月份等于10但日期小于等于29,则输出"No, It's not too late."。 然而,用户要求是判断输入日期是否小于10月29。注意:这里的小于是指在日历上早于10月29日,即10月29日之前(不包括10月29日当天?还是包括?) 根据原代码的输出字符串,如果日期是10月29日,原代码会输出"No, It's not too late.",因为月份等于10(不大于10),日期等于29(不大于29),所以条件不满足。 但是,用户现在要求判断是否小于10月29。我们需要明确: - 小于10月29:即日期在10月29日之前,不包括10月29日。 - 例如:10月28日是小于10月29的,10月30日则不是。另外,9月的任何一天都是小于10月29的。 因此,我们实际上要判断的是:给定日期date,是否满足 date < 10月29日。 我们可以这样考虑: 1. 如果月份小于10,那么一定小于10月29日(因为还在9月或更早)。 2. 如果月份等于10,那么需要日期小于29。 3. 如果月份大于10(比如11月),那么肯定大于等于10月29日(因为已经过了10月)。 所以,条件应该是:月份小于10,或者(月份等于10且日期小于29)。 注意:原代码的条件是“月份大于10 或者 日期大于29”,这个条件成立时输出"QAQ"(表示已经晚了),否则输出“不晚”。实际上,原代码判断的是大于10月29日(即晚于10月29日)的情况。 因此,如果我们要判断是否小于10月29日,那么条件应该是:月份小于10 或者 (月份等于10且日期小于29)。 但是,原代码的输出字符串有两句:"QAQ"和"No, It's not too late."。根据用户要求,我们修改代码,使其判断输入日期是否小于10月29日,如果是,则输出一条信息(比如原代码的“No, It's not too late.”?),否则输出另一条(比如原代码的"QAQ"?)。 实际上,原代码的输出含义: - 条件成立(即月份>10或日期>29)时输出"QAQ"(表示晚了) - 条件不成立时输出"No, It's not too late."(表示不晚) 现在,我们想要的是判断“小于10月29日”,那么条件成立(小于10月29日)时应该输出什么?我们可以保持输出字符串不变,即小于10月29日时输出“No, It's not too late.”,否则输出"QAQ"。 所以,我们需要将条件改为:月份小于10 或者 (月份等于10且日期小于29)。注意这个条件是判断“小于10月29日”成立的条件。 因此,修改后的条件表达式: ```cpp (month < 10 || (month == 10 && day < 29)) ``` 然后,我们在这个条件成立时输出“No, It's not too late.”,否则输出"QAQ"。 但是,原代码的条件是相反的(它是判断大于的情况),所以我们也可以反过来写条件:如果满足(月份大于10)或者(月份等于10且日期大于等于29)或者(月份等于10且日期大于等于29实际上就是大于等于10月29日)?注意,原代码的条件是“月份大于10 或者 日期大于29”,这个条件会把10月30日、31日以及11月、12月的日期都包括,但它没有正确处理10月29日(因为10月29日,日期等于29,不大于29,所以不会触发,所以原代码在10月29日输出“No”)。而我们要求小于10月29日,所以10月29日我们希望输出的是“QAQ”(因为不小于)? 所以,我们重新定义: - 当日期小于10月29日时(即月份<10,或者月份=10且日期<29),输出“No, It's not too late.”(表示还不晚)。 - 否则(即大于等于10月29日),输出"QAQ"(表示晚了)。 因此,代码逻辑如下: 1. 提取输入字符串中的月份和日期(转换为整数)。 2. 判断:if (月份 < 10 || (月份 == 10 && 日期 < 29)) cout << "No, It's not too late."; else cout << "QAQ"; 注意:原代码中,输入字符串的格式应该是类似于"2023-10-29"(有分隔符)?因为原代码使用了索引5,6和8,9。如果是没有分隔符的"YYYYMMDD",那么月份应该在索引4,5(从0开始),日期在索引6,7。但是原代码中索引的是5,6和8,9,所以可能是"2023-10-29"这种格式(长度为10,索引0~9:0:'2',1:'0',2:'2',3:'3',4:'-',5:'1',6:'0',7:'-',8:'2',9:'9')。 所以,我们假设输入格式是"YYYY-MM-DD",那么: - 月份子串:索引5和6,即a.substr(5,2) - 日期子串:索引8和9,即a.substr(8,2) 然后转换为整数。 同时,我们需要检查输入字符串长度至少为10。 修改后的代码: ```cpp #include <iostream> #include <string> using namespace std; void ac() { string a; cin >> a; // 检查输入字符串长度 if (a.length() < 10) { cout << "Invalid input" << endl; return; } // 提取月份和日期 string monthStr = a.substr(5, 2); string dayStr = a.substr(8, 2); // 转换为整数 int month = stoi(monthStr); int day = stoi(dayStr); // 判断是否小于10月29日(即月份小于10,或者月份等于10且日期小于29) if (month < 10 || (month == 10 && day < 29)) { cout <<
评论 35
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值