• 自动化测试需要写技术方案吗?
  • 发布于 1个月前
  • 80 热度
    0 评论
  • 且醉
  • 0 粉丝 31 篇博客
  •   

有同学问我:在中小型公司做测试工作,领导提出要做自动化测试,是找个框架直接落地开干呢,还是先做做调研写个技术方案?担心做调研写方案没人看,领导只关注效率和结果。


又是一个难得一见的好问题,这个问题的终极拷问是效率高低和结果优劣的对比,这种现象在很多中小型公司甚至大型公司都屡见不鲜。一方面要效率要快速产出结果,另一方面又要求结果不能太差甚至要符合领导预期,作为技术同学,该如何平衡这个效率和质量的难题?

以自动化测试为例,简单来说就是将人工执行的测试用例转变为机器执行,更快的产出测试结果,其背后潜在的价值是缩短信息反馈链条,达到更快验证更快修复的目的。
想法挺好,好的技术实践案例也不少,但为什么在很多公司自动化测试最后都不了了之呢?原因无外乎这几点:
1、对自动化测试的实现细节和落地难度不太了解,认为自动化测试就是找个工具把用例转化一下,然后跑起来出结果就行了,简单快速,还容易出结果,随之定了比较理想的目标,大干快上。
2、项目迭代速度快,人力和时间资源紧张,寄期望能快速通过自动化提高测试回归效率,分出了一部分资源来自研/二次开发自动化测试框架或者平台。结果两三个月过去了,效率没提升反而下降,交付压力更大,质量也没有明显提升。
3、前期没调研,落地没规划,推广难度大,来回折腾不断修改,最后KPI不好看。
上述三点之外,还有其他影响因素,但无论是自动化测试还是其他的技术项目落地,失败的原因主要可以概括为目标、成本、时间和人的因素。

首先是目标,无论要实践哪种技术工程,都需要制定一个合理的可实现的目标。其次需要投入的一定的资源支撑目标的达成,再次需要有相对足够的时间来落地实践,最后还要有合格的工程师参与,并且和相关协作方保持良好的沟通协调。


这几点概括一下,其实就可以回答本文开头的问题:要不要前期调研写个技术方案?答案是,一定要!其实,有过自动化测试落地实践经验的同学都明白,只是单纯的技术实现并没有什么难度,难的是是否有资源支撑,给的时间够不够,定的目标合不合理,以及参与这件事情的人是否配合。


有些同学高估了自己的技术能力,低估项目落地和目标达成的难度,领导发话了,直接开干。这样做确实短期内能拿出一些所谓的产出,但稍微扩大覆盖范围就捉襟见肘,出现各种问题。


原因在于对目标没有足够的理解,没有管理好自己和领导的预期目标,落地过程不够具体,任务拆分比较粗糙,甚至没有考虑到时间、资源等各种因素是否满足落地条件。


本文开头的同学存在的疑惑是要不要写技术方案,我的建议是一定要写。无论项目大小难易程度,都建议写一个技术方案或者落地规划,写技术方案的好处在于:
1、梳理思路:做事情要靠系统而不是靠直觉,写技术方案的过程,是不断搜集信息并重新加工的过程。比如选择自研框架还是开源工具,比如当前团队现状是否有足够的时间和资源支撑,比如目标是否合理,比如落地要面临哪些挑战。将这些可能遇到的问题和落地实现步骤都写出来,不断梳理,最终成为一份可行的技术方案。无论有没有人看或者是否有评审环节,技术方案更多的写给自己看的,是用来梳理思路管理自己的。
2、管理预期:有了可行的技术方案,就可以判断预期的目标是否合理。如果不合理,可以拉上领导一起评审,找到双方对目标理解的gap,然后针对性调整,毕竟领导也不希望项目失败或者拿不到好结果。
3、争取资源:合理可行的目标+可落地的技术方案之外,还需要通过技术方案说明落地的难度和需要的资源。很多同学在职场容易犯错的一点就是不懂得向上管理争取资源,这样很容易导致做什么事情都束手束脚,最终拿不到好结果。
4、便于调整:技术方案还有一点好处就是可以根据具体情况实时调整。比如落地过程中资源不足或者时间紧张,可以按照方案中所述的落地步骤和里程碑,适当调整交付时间,或者申请更多的资源支撑,这也是保护自己的一种手段。

以自动化测试来说,落地实践拿到结果是一个复杂的工程,其中涉及到的人(直接参与&配合的人)、事(要做的事情)、物(资源)都会影响最终的结果。而合理可行的技术方案(或者说落地规划)则是串联其中并指导最终达成目标的关键因素。
用户评论