在目前互联网产品迭代过程中,可能会出现上一个版本的需求被推倒重来,甚至整个已经实现的需求砍掉等情况,这些现象站在敏捷研发角度可能是正常且难以避免的,因为研发团队需要拥抱变化,快速响应迭代,但从研发过程成本来看,无疑是种重复消耗,这些消耗是需要有人买单的,开发需要再次进行方案设计、编码,测试需再次验证,过程反复有可能会增加团队的挫败感。然而这种看似合理,却又影响研发过程的“痛”,是不是真的只能逆来顺受,无从下手呢?
通过现象看本质,往往需求返工,大(多)数是因为需求本身出了问题,产品需求本身的价值最终可以体现在两方向:用户价值及商业价值,用户价值可以赢得好的品牌口碑及传播,商业价值则可以为业务团队带来长远的发展空间、资源。那么大家试想下,如果一件产品在最初设计的时候就是错误的,那么后续不管经过了多少轮开发,以及多久的测试验证,它始终是错误的,所以把控好整个研发过程的源头:“需求”就显的尤为重要,然而测试几乎位于整个研发过程的尾端,如何在需求阶段做更多的分析、挖掘及验证?如何实现测试“左移”这个动作呢?
其实,能够达到测试“左移”的方法有多种,大家可以从以下几个方面进行思考和扩展:
一、需求深度“理解”
二、需求分析:测试建模
三、需求价值验证
多数测试同学,拿到需求时,几乎都是默认了该需求的正确性,对于需求的来源、演变、背景等了解不够深入,试问这又怎么能够算是理解了需求呢?接到需求时,应该多问几个为什么:为什么要做这个需求,为什么是这个逻辑,还有没有其他的点没有关注到?
需求理解至少要包括这几个维度:
在深度理解需求的基础上,通过较为系统的方法对需求进行分析,一来可以让测试人中更好的认知需求本身,二来也可以在前期发现更多的问题,“测试建模”本身就是一种比较好的实践。
什么是模型?
“测试员在设计测试时,头脑中可能会有一个想像的图景,也可能有功能清单或某种图表。测试员会有谁是用户、用户关心什么的一些概念。所有这些都是模型。” -- 《软件测试经验与教训》。
通过对需求关键信息的理解分析,从而形成某个“结论”,这个“结论”可以是手绘流程图,又或是某个图表组合,这些都可以理解模型,而形成模型的过程就是建模。
我们为什么要建模?
i. 测试建模可以让测试人员更系统更全面的认知需求本身,更早期的发现问题;
ii. 模型便于简化复杂系统,多角色交流更高效,测试方案评审更有效;
iii. 通过模型有助于高效产生高质量的测试思路及用例,相对容易修改维护;
iv. 可视化模型可以产生更多创意,提升测试人员和洞察能力,更便于头脑风暴;
建模的方法都有哪些?
测试建模的方法有很多,如微软提出的HTSM模型,以及google的ACC模型,又或者批判式思维的NLP模型,这些都是比较成熟的模型,每个模型都有各自的优势,模型与模型间也可以组合、嵌套使用。
模型并不局限于表达的形式,建模过程比模型更为重要。
对于需求价值的验证,一般测试同学都不太会去关注这个点,如何在早期就验证需求的价值,从而尽可能的避免返工,同时又能将需求价值最大化呢?然而,一般业务团队对于需求价值的验证价值方式有以下几种:
这两种方式是最为有效的验证方式,然而,也有着一定的局限性,相对而言阶段比较置后,也比较被动,实际上在需求进入研发流程前也可以利用众测用户或是外团用户来进行调研及摸底,对于用户信息再进行二次加工分析,让用户“决定”需求的正确性。此外,测试人员本身的用户思维角度也需要多多积累。也许做为一名测试工程师,决定不了产品的战略方向或是布局,但是可以把控需求本身,包括需求对于用户的价值以及需求本身的质量,基于这两个维度,测试仍然可以在需求侧做很多“左移”的事情。
除此之外,在“测试执行”层面也有多个维度可以“左移”,将风险前置:
codereview
很多时候一提到CR,测试同学会默认为是开发同学的份内事情,其实不然,测试的CR可以是有别于开发的,代码review的实施可以从以下几点思考:
UT(UnitTest) & 框架开发
UT也是测试左移的方法之一,可以具体到某个核心类,也可以是接口类,类似在项目前期公共库函数建设时,UT的价值是很高的,往往可以发现很多隐藏性的风险,并且UT用例应该是集成在开发环境上,有代码变更时,开发能够直接在本地就验证,然而UT具体的实施角色建议是开发人员,那测试在UT阶段可以做些什么呢?
功能自动化左移
很多时候功能自动化一般都是在提测后才开始脚本开发,而且有部分功能自动化是基于UI逻辑的验证,针对这部分的自动化左移是否真的有必要吗?
答案是肯定是需要的,左移可以从以下几个方面实施: