测试左移=工作不饱满=少跑用例不登记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