Testing isn’t technically supposed to have stages.
Ideally, the process of software testing doesn’t have discrete intervals. Instead, testing would be conducted seamlessly throughout the coding process. This isn’t an ideal world, however, and so testing gets boxed throughout the development lifecycle in somewhat uneven clusters. At some points, testing barely happens at all. At other points, development is crammed with testing—but it can come too late to remediate bugs before they reach production.
For our latest infographic, we’ve decided to represent an ideal world, one where testing takes place equally at every stage of the development lifecycle. What does this look like?
As much as there shouldn’t be discrete phases of testing during software development, there really shouldn’t be discrete phases of software development either (at least under DevOps). To aid in understanding however, we’ve chopped it up as best we could.
What we’re calling the code phase is when you—a developer—are working solo while creating and updating product code. This means that you’re likely working off a branch of the code base that’s going to include a set of commits. Everything that you’re working on is reflected on a local copy of the source code. What tests should you be running?
Here’s the reality check—unless you’re really committed to shift-left, you probably aren’t testing and fixing defects this early in the software development phase. Even though there’s no technical barrier to testing at this stage of the game, many companies don’t do it.
Let’s start at the end—there are real benefits to testing as you’re writing code, as opposed to testing once you submit a pull request.
Importantly, this prevents you from committing to wasted effort. If you start coding and create an error or break an existing test, it’s easy to back up a few lines and rewrite them—whereas if you only test at the end of the process, you might find that much of your work is dependent on those few lines of error-stricken code. This means that you’ll have to slow down and rewrite a lot more of your work, creating a domino effect that could ultimately delay your entire project. This delay is anathema to the DevOps philosophy.
In addition, testing during this part of the SDLC really reinforces coding best practices. If your errors get identified as soon as you make them, the lessons you learn work their way into your muscle memory. In other words, early testing can make you a better programmer.
You’re a developer, not a pro tester, so one of the reasons we don’t see testing during the code phase is that developers don’t want to take time out of their coding schedule to create and perform tests.
But at mabl, we specialize in ways to make testing easy, unobtrusive, and automated. For example, mabl users can create workflows where a series of end-to-end tests run in the background using CLI and the local runner every time they hit “control + s.” This makes headless UI testing an automatic function whenever a developer saves their work, making it easy to integrate testing into the code stage.
Mabl users can also construct a series of more focused tests depending on what they’re doing. If they’re working on the user interface, for example, existing mabl tests will be tied to that specific feature of the application. Using mabl, you can automatically run these existing tests before you begin making changes. And those tests can be reused in other phases of the development lifecycle, reducing overall test creation time.
Lastly, there are a few final steps that you should perform at least once before you move on to the pull request. These include not just API and integration testing, but also the steps of adding new tests if necessary, and updating existing tests. If you created a new element or workflow within your application, you should write some new tests to reflect this. Meanwhile, you should update any tests that you broke in the process of writing new code.
To summarize, performing all this testing early in the development process reduces the burden of testing later. It’s much easier to course-correct in the coding phase of development, and doing so gives you much more time to mitigate any more serious challenges that crop up later.
This blog is the first entry in our series on testing for DevOps pipelines. To learn more, check out our posts on pull request testing, deployment stage testing, and testing in production.
See for yourself how mabl can help you improve testing early in development and throughout the entire lifecycle. Sign up for your free trial today!