‘Shift Left Testing’ Clarified

This is a concise version of the article on my Medium blog.

“Shift-Left Testing” has become a hot term in the software industry since 2019.

The concept of Shift-left Testing is not new

Below is a slide from a great presentation: “Continuous Integration at Facebook” (in 2015). As you can see, “Test Locally” (functional testing) has been moved to the immediate next step of the “Write Code” at Facebook. As a matter of fact, I have been developing software in a similar way for over 10 years.

Shift-Left Testing is really another name for “Test Early”, though the definition of Shift-Left Testing is vague just like many fancy new terms, such as CI/CD and "Release Early; Release Often".

The benefits of Shift-left Testing?

You have probably seen a long list of benefits of Shift-left testing elsewhere. Here, I will just emphasize one: “The earlier a defect is found, the cheaper it is to fix it”. Actually, this is one of a few things I still remember from my software engineering course at Uni. And, of course, this rule is absolutely true in practice.

In my view, this is a good enough reason for projects to adopt Shift-left testing.

What kind of testing do we do in Shift-Left Testing?

The answer is automated E2E (UI) functional testing.

Shift-Left Testing must be E2E Functional Testing

The term “shift-left” indicates moving the testing activities that were previously done on the right (i.e. at the end of a development cycle). This means functional testing that was performed by testers. Unit testing is not included in Shift-left testing. According to Test Driven Development, unit testing has already been on the left, 😊. (for more information, check out my article, Unit Testing Clarified)

For E2E tests here, what I mean is a user story level test via UI (in a browser for web apps).

Shift-Left Testing must be Test Automation

The definition of Shift-Left testing (or Test-Early) is vague on whether the tests are executed manually or automated test scripts. In my opinion, Shift-Left testing only makes sense if it is done via automation.

Some might argue “I can move manual testing left”. No, you cannot, at least you won’t be able to do it in a practical repeatable process. Don’t forget that, according to the definition, Shift-Left testing is the first half of “Test Early, Test Often”. How can you do “Test Often” (which includes the meaning of regression testing) with manual testing?

Here is an example. For an insurance app (in which I worked with a few clients): lodging one claim might take 5–10 minutes by an experienced manual tester/business analyst, without making a single mistake. Therefore, testing often is not possible with manual regression testing.

After all, test automation is fundamental Agile practice, the enabler.

Who conducts Shift-Left Testing?

Programmers, manual/automated testers or business analysts.

The role of programmers in Shift-left Testing is obvious. As there is no heavyweight design stage in agile projects, programming is the left-most activity involving a visible user story implementation. In other words, Shift-left testing moves left to get programmers involved.

Since I have been practising shift-left testing since 2008, in group or solo projects, I believe a programmer can do both development and testing If he/she has a testing mindset/skills (automation), I will write a separate article on how I practise Shift-left testing.

How left exactly is it in ‘Shift-Left Testing’?

You might have heard of “Acceptance Test Driven Development” (ATDD, which is rarely mentioned nowadays, replaced by BDD) before? In theory, testers can design or even write test scripts before a user story is implemented (based on mock-ups or meetings). However, in reality, it makes sense that real testing starts with a first-draft implementation that has been deployed on the dev/test server.

How to succeed in Shift-left Testing?

Solid Test Automation and Continuous Testing Process. Check out the full article for more.

--

Further reading:

• My eBook: “Practical Web Test Automation with Selenium WebDriver”
• My eBook: “Practical Continuous Testing: make Agile/DevOps real”