This is the final blog entry of a three-part series that we started about shift-left testing. 

Part one of this series introduced shift-left testing and the concepts and methodologies behind it. You can read more about the history of shift-left testing, here. You should also check out part two of this series which explained the benefits of shift-left testing. 

This is part two of our shift-left testing series. A few weeks ago, we released part one, which explained the concept of shift-left testing and provided an overview of its methodology and history.

The shift-left testing methodology moves the testing part of web development closer to the beginning of the process instead of leaving it at the end. When you shift testing to the left it ensures that developers are testing earlier and more often.

Your team might consist of a number of expert developers who consistently produce high-quality work, but if they don’t communicate well, your projects will inevitably experience regular hiccups. Prioritizing communication and collaboration is just as important as implementing high-quality standards. Incorporate the tools and suggestions below to create a more open and transparent development workflow and get all of your team members on the same page. 

Our CEO, Alex, led a session at Baltimore DrupalCamp 2018 on Shift Left Testing for Continous Collaboration. Shift left testing is the process of moving the testing phase to the left. Usually, testing occurs to the far right in the delivery pipeline which, if you’re moving left to right, is at the end of the development process. However, by testing early and often, you can easily isolate bugs and remedy them faster.

Talk to a number of different web development teams and you’ll find that they each have unique aspects to their workflows. Whether their process remains consistent or they regularly iterate to optimize efficiency, no team works in exactly the same way. 

Regardless of your team’s quirks, using feature branches is a best practice when it comes to web development. 

The Probo team is excited to announce that the Probo Shell is live!

Previously, users could only run and change the code in the probo.yaml files and view the results from the outside.

Now with the Probo Shell, users can connect directly to their build container with SSH, as well as view logs quickly all within the Probo.CI App. This means developers can view or change settings even after the build has completed.