2012-05-09 12:26:11 janne09 阅读数 2142

上次参加培训时,在课堂上有人提出来现在公司测试需求变更太快,测试人员一直疲于应付各种变更,开发人员提交测试的质量太差,正常的流程很难一次跑过,边边角角的问题更多。想做进一步深入测试,但是时间总是不够,自动化测试也只是想想。

吴穹老师说,这些问题的主要原因是测试滞后导致的,所谓测试滞后就是说,本来不应该由测试人员来做的事,现在都由测试人员来做了,测试人员在还其他人的债,所以自己本身的事反而没时间做,越没时间做,欠下的债越多,还起来越慢,最后形成恶性循环。最好的办法是测试前移。

什么是测试前移?吴穹老师接着提到“质量不是测出来的,是开发出来的(本人觉得有点偏激,和很多因素都有关系,呵呵)。测试是开发人员与测试人员共同的责任”。也就是说,单元测试,开发完成后的自测并且保证自测成功,这些是开发人员的责任,而不是说因为有测试人员所以就可以在实现完成后直接丢给测试人员。有人认为,我的任务就是按照设计实现出来,后面不是有测试人员吗,我们都测试完了,那还要测试人员做什么。借个好听点的借口,没有测试人员把关,我们不敢发布。这种想法的开发人员水平再高也只能是一个码农。对自己的作品都不愿意审视,还有什么责任心可言,把事情丢出去,出了问题有别人顶雷,不敢担当责任,一个这样的人还有什么可谈。

开发与测试之间经常像冤家一样相互指责埋怨,动辄就拿团队合作说事。在别人的博客里看到一段话,直接引用了。“其实各种工作并不会平白无故的消失,当咱们不去做的时候,一定是被另一个人承担了,他是谁? 咱们是不是应该对他有所感激,有所报答? 当咱们说不能做某件事儿的时候,一定有另一个人承担了这样的苦差事,咱们能不能相互分担?怀有一颗同理心,当有一件事儿自己不愿意做的时候,想想是不是别人都特别乐意做,当别人做了,咱们该如何帮助他们团队合作就是这么简单,怀有同理心,不施命于人。

2019-03-27 20:13:56 sylan15 阅读数 409

目前的现状。

bug 太多,懒得写 bug 单,很多需求合理性的验证都放到测试阶段,比如文案的测试,逻辑实现的健壮性也是留在了测试阶段,稍微一点异常就容易挂掉,然后就是各种改,提测次数频繁。

从我目前面试的经验看,不管是社招还是校招,有不少人选择测试的原因都是测试门槛低,不会的能很快学会,稍微好点的是因为够不上开发的标准,所以才选择做测试。

在这样的大环境下,导致很多测试人,自己都觉得测试的技术含量不高,开发更是觉得自己理解的测试没技术含量是正确的了,然后大家就进入了这个恶性循环的怪圈。

而且从测试这个 title 来看,也容易让人误解为所有需要验证的东西都是测试人员的职责,

为什么要前移?

如果不前移,测试人员就算忙死,对整个团队的质量保证的贡献也是有限的。

因为很多的测试验证工作都是一次性的,不可复用的,做自动化吧,不值当,不做自动化吧,很繁琐。

同时因为质量保证时间点后移,导致测试人员的时间开销特别大,能分配到做一下随机测试和深入逻辑验证上的时间非常少。

这样导致的问题就是,每次填坑的同时也在不停的埋坑,很多当前不会发生的问题,以及很长一段时间没人触发的问题,在之后的某个时间点,突然爆发,然后就需要重新花时间填坑,同时又会埋一个新坑,最后谁也不知道到底有多少坑,到底什么时候会把什么坑给暴露出来,这也是一个恶性循环。

如果测试前移了,很多基本的质量问题都可以在前期得到保障,就算提测时间晚,但是提测质量高,测试可以花更多的精力做更深入的测试,发现的 bug 肯定也都是质量比较高的了,同时这样的项目发布,埋坑的可能性就小,我们只需要关注本次修改内容及其影响范围即可,这才是良性循环。

如何前移?

我的答案是,测试即服务。

作为质量保证部门,我们的职责是保证产品的质量,但并不是说一定要我们去做具体保证质量的事情,所以换个角度,我们可以把我们保证质量的能力输出给真正能影响产品质量的人。

比如我们给产品人员提供服务。加强需求评审阶段的投入,把我们对于用户角度的思考,把我们对于需求合理性的思考,把我们对于产品质量预防的经验,在需求评审阶段就进行输出,把我们已知的问题在需求评审阶段都消灭掉。

比如我们给开发人员提供服务。给开发提供完备的编译环境支持,环境中可以包含必要的白盒检查、自测环境、冒烟测试用例,甚至是提测前的代码 review,把我们对于代码质量的基本要求和规范,都在代码编写阶段进行解决,从而把我们已知的编码中可能出现的问题尽可能的消灭在提测前。

产品和开发是和我们质量保证联系最紧密的两个角色,如果能把这两个角色的服务做好,基本可以保证提测质量了,也就能满足我们最低的测试前移的要求了。

当然,如果要达到这样的效果,更多的是对我们测试人员能力的更高要求,所以,为了可预见的美好未来,一起加油吧。

以上,如果认同我的观点请转发让更多人看到,或者点「好看」让我知道你的态度,如果有更多想法,欢迎留言和我讨论,期待。

本文首发于公众号「sylan215」,十年测试老司机的原创干货,关注我,一起涨姿势!

sylan215

2014-08-14 20:08:00 wolfseek 阅读数 948

 

1.1. 敏捷开发的目的

质量风险前移

适应需求变化

及时总结、思考和促进团队成长。

 

 

2.      User story和需求列表的不同

需求栈通常如下:

序号

功能

详细描述

1

功能1

…………………………………………

2

功能2

………………………………………….

 

 

 

 

 

 

 

为完成以上功能,我们通常会将任务按重要性,和依赖性对其的优先级排序,排在前的优先做。这是在开发过程中惯用的手法。

可是每个功能开发该估计多少工作量呢?这个数据确实千差万别,同时按功能实现还有一个缺点,有些功能只有接口,没有界面。如后台功能。这导致测试没办法正常介入。只有当后继的支持功能和界面完成以后,测试才能介入。同时后继开发也面临着问题,包括上次迭代不完整引起的重构问题,上次迭代遗留的BUG可能很多。

 

出现这些问题的实质原因在区分清楚user story和需求列表的区别,特别是在敏捷开发中的区别。

敏捷开发,崇拜的价值交付,每一个迭代的交付都是有价值的。传统开发模式下任务是横向切的。


横向切的意思就是先做数据存储,再做数据访问,再做业务,再做界面。你可以看见当界面没有成型时测试是没有办法有效介入的。

而敏捷是竖直切的。


没一个迭代都有完成的数据存储,数据访问,业务和界面的实现。通过每一步迭代完成一套功能。

l  概括起来,敏捷的userstory有如下的特点:

l  已工作场景为单位描述

l  每个user story相对独立

l  可讨论的,能够支持开发,需求,客户三者,基于场景沟通。(一个功能是无法承担这样任务的)。

l  有独立的价值。客户可以付钱来卖的。

l  可估计,可预算的。包括了技术上是能实现的,方案和业务逻辑是可实施的,时间上是可估计的。

l  小到一个迭代内可完成的。

l  可测试的。

 

在实际的开发过程中,也会对userstory排序,排序是更具user story对用户的价值为准则,价值高的先开发。

2019-09-12 08:15:00 sylan15 阅读数 63
640?wx_fmt=gif

后台回复「MTSC」,领取大会 PPT

一、从一个 Bug 说起

最近在使用一个 IM 时,突然发现一个有趣的秘密。

话说这个 IM 有一个发起问卷的功能,这个功能支持匿名答卷,效果图如下:

640?wx_fmt=jpeg

有一次在使用时,我好奇的点了点几个入口,突然发现匿名的内容和实名确认名单,可以通过时间线进行关联,我简直惊呆了。

到底怎么关联的呢?别着急,听我慢慢说。

上图中应该能看到发起问卷的时间是3/14 21:38,记好这个时间,我们再打开确认人列表如下图:

640?wx_fmt=jpeg

从图中可以看到每个人确认后面(前面被打码掉的是实名的确认人信息),会有一个确认时间的记录,这个记录中左边是用户实名,右边是时间线。

接着我们返回到第一个图的问卷主页,点击问卷中某个问题的回答,会打开新的问卷结果查看页面,如下图:

640?wx_fmt=jpeg

看到没?每个匿名回答后面也有个时间,这个时间减去问卷发起的时间,恰好等于实名确认记录页面那个时间线(并且,它已经给做好了排序,实名确认记录的顺序和回答的顺序刚好相反,然后就完全一一对应了)。

我的天,原来这个匿名只是把实名和回答放到两个页面显示而已,吓得我一身汗。

二、我想说什么

今天不讨论这个 bug 的发现和定位,我想继续说说需求的合理性验证。

需求相关的话题,我之前有写过三篇文章了,可以点击如下链接回顾: 

其中在第二篇文章中,我有提到测试人员在需求评审过程中,应该考虑需求的合理性。

按理说这种事情应该是产品来考虑的,但经常会发现产品对产品使用的路径考虑的没有测试周全。

比如上面这个例子,如果从每个功能单独来看,什么毛病都没有,说不定当时还测试出时间线显示不准确的问题呢。

但是把三个时间点一结合,就出现问题了,而这个问题又不是功能性问题,只是没有达到需求预期的「匿名问卷」的效果,所以这个效果应该也是我们一个重要的测试点。

如果是在需求评审阶段,评审合理性的时候就需要考虑设计是否满足了需求,如果是在测试阶段,就需要优先验证是否满足了需求的最终效果,而不是只是验证功能实现了正确的结果。

三、我们怎么做

其实谁也不希望出问题,但是真出现了问题也还是很无奈,比如上面这个例子,现在这个现状就是,之前做的那么多铺垫全白费了,满足了表面上的需求,却没有实现真正需要的需求,而且使用者可能都以为是真正的匿名呢,反而会造成一些使用上的隐患。

如果要规避这种问题,产品经理考虑问题的角度当然是需要更周全,特别是提供的设计方案稿,不能仅仅是满足了表面需求,但是说起来容易,做起来难呀。

如果是从测试角度看的话,我们需要固化测试人员对需求的关注度,同时要时刻记住需求合理性需求全面性这两个关注点,时刻从这两个角度进行需求确认,只有这两个角度都经过验证通过后,才开始真正的功能测试。

又或者说把这两点当作方法论一样去应用和实践,借助方法论从而更有目的的指导实践。

今天重新聊这个话题,是因为发现这样的 bug 真的很无语,就算功能测试做的再怎么天衣无缝,结果反而事与愿违,甚至悲哀。

以上,记录了一个发现的奇葩 bug,基于此,建议大家在项目过程中都要关注需求的合理性,从而尽可能早地避免问题,不知道你是否同意我的观点,欢迎留言说说你的意见。

当然,如果你觉得自己有所收获,欢迎分享文章到朋友圈 + 点个「在看」让更多人看到,谢谢。

为了感谢大家的支持,我准备了一个抽奖,在 9 月 17 号上午 8 点 15 分自动开奖。

感谢你的阅读、在看和转发,点我抽奖,祝你好运!

640?wx_fmt=jpeg

推荐阅读:

2019-09-09 15:57:33 tianwen2010 阅读数 20

 

测试分层设计

一、案例背景

为了实现在新研项目中开发人员在功能交付给测试之前,本地可以自测快速验证新研功能质量情况,实现测试前移目标,我们开始了新研项目测试分层设计实践,基于测试建模和接口测试技术(C++端)

二、解决的问题

1) 测试前移:聚焦核心功能价值,实现开发交付测试前,本地自测代码,快速反馈代码修改质量,实现测试前移目标,支撑质量保障,不泄露bug。

2) 接口测试分层: 降低UI自动化比例,使用接口测试代替UI大部分自动化实现测试分层,提高自动化质量反馈效率

3) 实现测试建模&数据设计和接口测试无缝对接

4) 促进产品代码解耦和代码架构最大程度优化,从而支持接口的可测试性和产品接口服务化

三、成果价值

1、开发交付测试前:设置局部梁宽功能,开发使用接口自测,完成整个迭代期间多个接口9测试,接口测试发现bug:15个,开发自测用接口测试保障产品质量,

提交测试后:功能自身(接口覆盖内容,交叉测试&集成测试&用户验证)0BUG

2、大大降低UI自动化比重,接口覆盖209条用例占总用例比重68%

3、接口测试能够快速反馈产品质量情况

 

 

 

初探敏捷

阅读数 702

没有更多推荐了,返回首页