合格的“测试开发”需要一颗“产品”的心

five3five3 34 于 2019-04-21 17:27:00 发布
  • 0 推荐
  • 0 收藏,235 浏览

前言

测试开发 - 一个很“神奇”的存在。职位属测试岗位,但干的是开发的活,钱拿的没有开发多,但事一点不比开发操心的少。但今天要讲的却是如何成为一个合格的“测试开发”攻城狮。

天然的熟悉业务系统,掌握必备的开发技能,这些都是测试开发攻城狮们所要具备的基础能力。

除此之外,想要成为一名合格或者优秀的测试开发,你可能还需要具备更多的软硬技能。其中硬技能包括:

  • 对业务架构技术栈的理解和分析能力
  • 对开发工具技术栈的运用和掌握深度
  • 对业界主流技术发展趋势的关注和洞察能力
  • 对开发、测试新技术的研究和学习能力

而软实力则主要体现在:

  • 对业务测试需求的辨识能力
  • 对开发项目的设计和规划能力
  • 对开发项目的风险评估和调整能力
  • 对开发项目的落地和推广能力
  • 对开发项目的反馈处理和响应能力

通过上面的分类我们可以发现,硬实力基本属于技术能力提升的范畴,把自己当作一个完全的开发去关注和学习新技术即可,重点关注的是项目的技术可行性。

而软实力则更偏向于项目能力的范畴,把自己当作一个完全的产品经理去思考项目的必要性和可行性,重点关注的是项目的业务可行性,保障测试开发项目的成功率。

相对于软实力而言,硬实力通常更为广大的测试开发所关注和实践。这种情况在新手测试开发身上体现的更为明显。

而经过了“洗礼”的测试开发老鸟们,则会吃一堑,长一智。除了关注硬实力,更多的还会去关注软实力的提升。

因为硬实力只能保证测试开发项目的实现,软实力才是保证测试开发项目最终能否成功落地和应用的重要砝码。所以想要成为一名合格乃至优秀的测试开发,你需要一颗“产品”的心。

业务测试需求辨识能力

测试开发这个岗位之所以存在,是因为在业务测试过程中,发现很多重复、繁琐、不便于人工操作的场景存在;而这些场景恰恰可以通过技术和工程化的手段来轻松解决。所以就有测试开发这样的一个细分工种,专门实现测试业务中的需求。

与纯开发人员相比不同的是,纯开发人员主要关注实现的可行性,开发需求则是由独立的产品人员来整理和提出;而测试开发人员则没有这样的待遇,不会有专门的产品经理来做需求整理的工作。

而对于非大厂的测试开发而言,他们的首要能力就是发现和提炼业务测试需求;因为整体上是没有规划的,你只能凭借对业务的熟悉程度和洞察能力,来发现业务测试过程中的痛点 - 业务测试需求。之后才能有发挥自己开发特长的能力,去做测试开发方面的工作。

对于大厂的测试开发而言,可能从架构上就有整体规划,自己需要开发的大目标就有了。

这样的情况之下,一方面需要在具体的实现上多关注、贴近业务需求,否则做出来的工具不易用就会很难推广;

另一方面你可能需要培养更广阔的洞察能力,从合作的业务部门、甚至整个公司去发现一些共性的需求,然后梳理出来进行评估和立项。

对于大厂的测试开发而言,测试开发的需求可能有很多,这时就需要培养对项目的选型能力。比如:第一优先的是那些团队和公司内部都存在的业务测试需求;
因为同样是做一个需求,你的所选的项目覆盖范围越广,最后能达到的效果就会越大。升职加薪自然就少不了你了!

发现了业务测试需求才仅仅是开始,你还需要对发现的业务测试需求进行评估,辨识这个需求的真伪。具体参考依据如下:

  • 当前问题的现状分析 - 分析人力成本、时间成本
  • 需求实现后的状况分析 - 分析人力成本、时间成本、额外优势
  • 需求实现的可行性 - 对技术实现和场景进行充分调研、demo、评估
  • 需求实现的成本 - 项目整体实现成本,分析投资回报率

当前问题现状分析

主要分析人力成本、时间成本。即当前操作该业务需要多少人、做多长时间;这里面要考虑多次操作时个体间的成本差异,每成功操作一次的出错率、和调试时间等;最后综合评估得出一个平均值。

需求实现后的状况分析

主要分析人力成本、时间成本。即通过测试工具/平台/脚本实现该操作时,需要额外补充的人力;以及需要等待工具完成该操作的时间。这里面要考虑测试工具运行的稳定性、成功率和并发执行的场景。

另外可以分析工具可能会带来的隐性优点。综合评估后得出的人力、时间成本,再跟当前现状的人力、时间成本相减,即可得到节约的人力、时间成本。

需求实现的可行性

主要对技术实现、技术难点进行分析和评估,对不熟悉的技术栈进行demo确认;梳理出整个业务场景的支点,并进行demo确认。

通过demo实现的反馈结果,综合评估出整体实现上的可行性,以及技术难点。

需求实现的成本

通过前面的demo实现,初步确定技术难点和主要耗时模块,结合架构设计综合评估出整体的实现成本;然后就是计算投资回报率:

总体实现成本 / 单次执行节约的成本 = 最少执行的总次数
最少执行的总次数 / 当前业务的使用频率 = 最少需要执行天数

最后,如果是阶段性业务项目则要考虑项目结束时间,如果

项目结束时间 - 当前时间 > 最少执行天数

则表示可以投入成本可以收回,否则表示收不回成本。

当然并不是所有情况下都能收回成本,有些时候仅仅只是单纯的为了提高效率而已。此时其作用等同于增加额外的人力来缩短测试周期。

测试开发项目设计能力

通过了各种需求提取、可行性分析之后,表示该业务测试需求可以做,并且值得一做。但是能不能把项目做好是另外一回事,可能给A做就能成,而换成B可能就成了烂尾。而这很大程度就体现在测试开发人员的项目设计和把控能力。

首先,作为测试开发人员在项目设计的时候,往往会进入的误区是:从技术实现的角度来设计项目,而非从用户使用场景的角度来设计项目。

换句话说就是:技术实现驱动用户界面,用户界面驱动用户使用场景。通过这种方式设计的项目,最后都会很难落地和应用并最终导致烂尾。

提升项目设计能力的重点就在于,要把测试开发的项目当做用户产品来对待,要从用户的角度想问题,设计界面及场景交互,用最少的额外成本来完成某个任务。举个简单的例子:

在不使用测试工具前,操作一个业务需要5分钟,而使用测试工具后需要进行3分钟的额外操作,才能通过工具来执行该操作。那么这就不是一个好的用户场景。

在用户场景设计好之后,才会去依照这个用户场景和实际的业务操作来设计程序的架构,当然好的架构还要考虑业务并发性、业务扩展性等等。

测试开发项目调整能力

按照理想的情况,到目前为止应该正在愉快的开发项目,甚至马上就结项了。但是事实上,即使我们严格按照了上述的步骤来提取、评估需求,到头来还是出出现各种差错。

比如:公司架构调整、业务需求调整等。当遇到这些实际开发与目标期望严重偏离的时候,就要具备项目调整能力来
把项目尽量带回“正轨”。

对于组织架构调整,但是业务需求没有调整的情况下,可能原有的需求还是存在的,那么原来的测试开发项目就可以继续保留。

而如果原来的业务需求也一并调整了,那么就需要根据新的业务线来分析,当前测试开发项目是否可以兼容、改造和复用。

还有一种情况就是上层架构都没有变动,但是之前的需求分析阶段出了差错,没有提取到业务测试“真正”的需求。此时就需要通过及时的复盘,来发现需求实现和实际场景的偏差。

总体而言,就是在测试开发项目的每一个评审阶段,都要对把目标用户拉进来。一方面希望他们能提供宝贵意见,另一方面更重要的是获得他们的及时反馈。

测试开发项目的落地能力

在经历千辛万苦的设计、开发、内侧之后,项目在工程方面终于完成了。但离结项还有最重要的一步 - 应用与落地。

测试开发除了是项目的实现者,更是项目的首席布道师。你要对自己开发的项目有信心、有激情,并且运用一切的资源去推广项目,让项目能够在适用的场景下成功落地。

首先,如果是组内的业务测试需求的项目,一般都会比较容易落地,毕竟是知根知底,只要做出来的产品足够的易用、稳定即可。

其次,如果是可以覆盖跨部门的业务测试需求的项目,通常会先在本部门内先落地和应用;在取得了一定的效果和数据积累之后,再开始向外部门推广。

推广的策略是优先选取好合作、愿意合作的部门。比如:友情部门、业务测试需求比较迫切的部门,这些都是我们的种子用户。当积累了一定的实际数据之后,就可以依次往其它部门推广;这其中又把重要的部门作为第一批推广目标,这样可以作为后面其它部门推广当示范。

测试开发项目的反馈关注

测试开发项目落地后,可以说已经完成了95%的工作,但最后还差一个有效的反馈机制。因为项目的落地并不代表项目的成功应用,只有当项目落地后并有很好的应用数据来支撑,才算是成功的项目。

但好的应用数据往往不是天然就有的,可能需要我们不断的通过分析数据、追查原因、改善功能来不断的修复,最终才能达到我们想要的应用数据。所以一个好的反馈机制是保障应用最终有效落地的手段。

一方面可以通过提供用户反馈通道来直接的获取反馈;另一方面可以通过应用数据分析来间接的获得反馈信息。大部分情况可能需要通过第二种方式来获取反馈,并通过主动积极的与用户进行沟通来获取根本原因。

总结

通过这一系列的测试开发软技能的分析,可以发现想成为一名出色的测试开发并非易事。除了懂业务、会开发之外,还需要更多的产品、项目管理、运营的能力。如果把这样一名测试开发放在创业公司,那他就是“整支”创业团队的角色。

以前听说老王开公司,董事长、CEO、会计、出纳、保洁、保安都是他一个人,我不信;但自从做了测试开发之后,我信了!

新书推荐

Python Web自动化测试设计与实现

获取更多关于Python和自动化测试的文章,请扫描如下二维码!
关注二维码

你可能感兴趣的文章

本文隶属于专栏

TestQA @ TestQA

TestQA's Blog