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