专栏首页软件测试那些事测试左移=工作不饱满=少跑用例不登记Bug少搭环境开发帮忙做测试还不漏Bug<祖师爷说de>

测试左移=工作不饱满=少跑用例不登记Bug少搭环境开发帮忙做测试还不漏Bug<祖师爷说de>

随着测试左移话题的持续,为了体现我们35+从业者不仅仅是多吃了几年饭,特地去了解了一下“测试左移”的来源。

在”开发百科”这个网站上,提到了这个词条 https://devopedia.org/shift-left

这个网站是这么考据测试左移的,

随着传统瀑布模型的局限性的显现,在上个世纪九十年代,逐渐出现了很多新的,目前被认为是经典的软件开发模式。这些模式提出者的一部分代表人物,受邀在新世纪的2001年初的美国一个滑雪场聚会,吃饭喝酒聊天滑雪之余,提出了敏捷宣言“Agile Manifest”。而在同一年的年尾,一个来自康柏公司的软件测试工程师Larry Smith提出了“Shift-left testing”这个词,来描述“一种更好的集成软件项目的质量保证(QA)和开发部分的方法。”[百度翻译]。

https://www.drdobbs.com/shift-left-testing/184404768

二十年后,作为后来者重读了一下这篇文章。通过作者分享的很多他在True-64项目中的个人经历,终于明白了作者所说的测试左移是怎么回事。

如果说测试左移是为了能够获得开发的认可,成为他们的一伙人、获得内建的可测试性、把开发的测试用例变成自动化用例、让开发帮你跑用例、从开发那里获得测试环境并大幅减少自己的测试环境、少跑用例并且不遗漏缺陷,少发现缺陷并且不用登记缺陷。那么,这样的测试左移你想要吗?

不过这样的测试左移有一个很严重的问题,就是会让你看上去工作不饱满。作者提醒你一定要个自己的测试经理和项目经理做好汇报沟通。

在需求澄清阶段就开始写用例

I was actually involved while the functional specification was being written, so I wrote the testing specification at the same time and began coding the new authorization tests at the same time as coding began on the new authorization code.

获得与开发工程师的紧密沟通和认可

In this manner I obtained high bandwidth, person-to-person communication with development engineers.

I got early and useful earfuls of information about the areas they were worried about, which warned me where I needed to focus my testing. I also became known to them. They soon picked up that I, too, was an engineer of some talent, and I became part of the team, rather than just a check-off box in a QA plan.

内建的可测试性

I simply noted that I required certain optional messages to a system log. With that one line in my specification, I hugely simplified the test program because the authorization code was now designed to be easy to test. This was essentially free.

Testability was built-in, not tacked on. Indeed, it saved so much effort that I finished my test program long before the authorization code itself was ready to be passed to QA.

把开发的测试用例变成自动化测试用例

I merely adopted them from developers who wrote them as a matter of course and adapted them to automated use.

从开发那里获得测试环境

Here was an opportunity to avoid a lot of that hassle: I just started using the development test systems.

I could run my tests in this downtime and report the results directly to the coders.

少跑用例

Once the official base level came around, I could safely eliminate many tests based on my knowledge of how they ran in the prebase-level tests.

Once I knew that a certain patch worked properly for both single systems and clusters, I did not need to retest it on QA systems in both modes in the actual base level.

如何在少跑用例的同时确保不遗留缺陷

This was controlled by making sure development's test systems were kept up-to-date with each new base level, and by doing a complete test run on certain critical base levels, such as the ones preceding the beta release or first customer ship.

使用更少的测试环境

For most base levels, therefore, I could reduce my QA hardware needs by at least 75 percent

发现更少的缺陷,不用登记缺陷

This system also meant I seldom found a bug on the QA side of things, and therefore did not have to report it through the expensive and painful bug-tracking system.

When I found a bug I simply walked over to the developer who wrote the code and ran the test for him or her. Without the overhead imposed by the cumbersome customer bug-tracking system, bugs could be fixed in minutes that used to take days — in fact, often enough I could get another run of my tests in proving the fix that same day.

开发帮忙做测试

Being able to pinpoint a precise test case in an automated suite meant I had little trouble communicating the exact bug to the developers, and their familiarity with me and my test work meant they could use the test suites themselves for unit tests.

会让你显得工作不饱满

This can make you look rather "under-utilized," as the managerial catch phrase so delicately puts it, at least to your own management in QA

By working smarter, not harder, you can get far more done. But don't let it look too easy.

哪有那么多道道,不就为了更好工作更好生活。不信的打工人,自己去看原文

https://www.drdobbs.com/shift-left-testing/184404768

文章分享自微信公众号:
软件测试那些事

本文参与 腾讯云自媒体分享计划 ,欢迎热爱写作的你一起参与!

作者:风月同天测试人
原始发表时间:2022-01-22
如有侵权,请联系 cloudcommunity@tencent.com 删除。
登录 后参与评论
0 条评论

相关文章

  • 测试左移与测试右移

    测试左移以及测试右移,能够让测试拥有更多的主动权,有更充足的时间进行测试,同时不会像之前因为质量差风险高每次都延期上线,并且产品的线上质量也能有保证。

    wangmcn
  • 测试如何发挥更大价值?聊聊测试左移和测试右移

    为什么我把测试工作做得挺好的,线上环境还会出Bug?这些Bug可能是因为当初设计时就有的漏洞,也可能是部署不当带来的问题。

    ITester软件测试小栈
  • 腾讯TMQ在线沙龙回顾|测试左移实践

    测试左移实践 活动时间:2017年6月28日 QQ群视频交流 活动主题:TMQ在线沙龙第二十三期分享 本次分享的主题是:测试左移实践 共有214位测试小伙伴报名...

    腾讯移动品质中心TMQ
  • 测试应该如何处理跟开发之间的“敏感”关系?

    从整个产品研发的角度看,开发是产品的制造者,产品就相当于他的‘孩子’,而测试的工作是去找这个“孩子”身上的毛病。相信,没有一个人喜欢别人对自己的孩子各种挑错。

    测试开发技术
  • 测试经验分享:做一个靠谱的软件测试人员(一)

    王豆豆
  • 《软件工程之美》打卡第五周

    上周因为临时公司有紧急需求,大部分时间都投入到工作上,所以就暂缓打卡的计划,这周正式进入远程办公的第一周,继续把专栏的学习计划滚动起来,这周会分享宝玉老师的极客...

    用户1130025
  • 小谈 Java 单元测试

    总之有无数种理由不想写UT,作为工作不到三年的菜鸟深有体会。之前在点评工作的时候,团队的“UT”都集中于RPC的服务端。为啥带双引号? 因为RPC的服务端没有页...

    芋道源码
  • 程序员没朋友?删注释,学甩锅,这么干就对了!

    昨天我分享了一篇关于收入的个人感悟,没想到如此受欢迎,得到了很多大佬以及读者的点赞。

    程序员小浩
  • 软件测试面试常考题目总结

    开发首先要规范好编码,出低级错时不要指责,内心指出错误。让他们自己进行测试,反思找出错误。

    wangmcn
  • 这款神器大大提升了协作效率!

    最近对 API 接口协作的软件研究了好久,市面上的软件都下载用了一轮,下面给大家介绍其中的最强「神器」 Apifox。

    物立
  • 什么是单元测试?为什么要做?

    点击关注公众号,Java干货及时送达 什么是UT? UT(Unit Test)即单元测试 UT有什么价值? 大部分的开发都不喜欢写UT,原因无非以下几点: 产...

    Java技术栈
  • 软件测试面试题(含答案)[通俗易懂]

    测试经验越多,测试能力越高。所以我的职业发展是需要时间积累的,一步步向着高级测试工程师奔去。而且我也有初步的职业规划,前3年积累测试经验,按如何做好测试工程师的...

    全栈程序员站长
  • 我用这一招让团队的开发效率提升了 100%!

    我在一家做微信营销的公司干技术 leader,带 40 多个人,公司名就不说了。在这个位置上做了好几年,把团队从小带大,公司虽然不算风口浪尖上的高增长业务,但技...

    物立
  • 功能测试面试题

    在您以往的工作中,一条软件缺陷(或者叫Bug)记录都包含了哪些内容?如何提交高质量的软件缺陷(Bug)记录?

    找Bug
  • 2018总结与2019规划

    时间也是过得很快,不知不觉又过了一年。这一年发生了很多事,但是好像又过的很平淡。回想起来自己好像做过好多事,但好像又没做过什么事,在这里我再次回顾一下去年的一些...

    Masimaro
  • 不是广告--如何学Java,我说点不太一样的学习方式

    提问的人里有在校大学生、有刚参加工作的、有想转行做程序员的,还有一部分是最近找工作不顺的。

    乔戈里

扫码关注腾讯云开发者

领取腾讯云代金券