Testing does not need to be a tedious burden that delays releases. Building an automated framework to facilitate testing early and often in the SDLC as part of a CI/CD pipeline is working smart. Adding a deployment pipeline to facilitate rapid deployments is also smart. Maintaining a tedious and burdensome approach to more manual and less effective testing late in the SDLC is not so smart.

Why Testing Early and Often in the SDLC is a Must

Let’s assume we all agree that testing is a necessity. But why delay development progress when you are at your most creative and motivated right at the start of a new project? Well let’s start with these six good reasons to test early and often in the SDLC and ideally as part of a CI/CD pipeline.

  1. Issues found early in development are far more easily and cost effectively fixed.
  2. The overall software development life cycle (SDLC) time can be greatly reduced.
  3. There is much less time pressure than when testing is left until late in the project.
  4. Testing won’t be viewed as an irritating bottleneck by developers or management.
  5. Staged testing will help promote a quality awareness culture amongst developers.
  6. Improved customer satisfaction with better quality software delivered more quickly.

Build Your Test Framework First

In an ideal world you would suspend all development in order to build your test framework (or harness), before any coding is done. Very few of us though live in an ideal world and most will need to look to a more pragmatic approach. The probable reality is, that if you want to get ahead of the game for your next project and for all those that follow, then you will need to schedule in time on a regular basis to design and build your test framework. I would suggest at least four full dedicated days per month with little or no distractions. Otherwise your test framework will simply become “manana fodder” (i.e. it will never happen).

So the reality is that you may have to build your test framework over an extended period, but if you start with a well thought through outline and then build it in discrete usable sections you can benefit progressively as it evolves. Then one day you will have your complete automated test framework and the development team can get on with what they are best at and probably really want to do. This will without doubt prove to be a worthwhile investment that will provide long term benefit to both the development team and to the business itself.

Automate All Framework Tests

Automation is the best friend you have when it comes to your CI/CD pipeline. Automate all tests, then automate the automation itself. This will free you up from the manual, repetitive and error prone tedium to work on the more rewarding stuff. But remember that just because you have automated it doesn’t mean you can’t evolve and improve it as with anything else.

Bear in mind though that if you automate a test that is flawed you simply exacerbate the problem, so it’s important to make sure that all tests are performing as intended. For this we may need a set of tests to test the tests, but let’s not get too carried away as good enough rather than perfection should be the goal here. You can always make it better later. It’s also true that things change from time to time and your test framework needs to evolve with these changing needs and environment, rather than being a static thing.

Test Early and Often

The earlier and more frequently you test, the easier it is to identify and pin down an exact issue. The sooner issues are identified the easier they are to address. It’s also good practice to fix issues as they are found, rather than letting a list build up to fix later. This greatly reduces the likelihood of any issues muddying the water by masking or causing other issues.

The more often you run your tests the more easy it becomes and if your test framework is fully automated then running tests should be pretty much non-disruptive to development work. I say pretty much as you will need to stop and fix as you go, but the compensation for this is that a test early and often approach reduces your overall SDLC time.

Test in Parallel Groups

You can run multiple tests at the same time in groups so that you don’t have that frustrating wait for each test to complete individually. This means that you get and can act on test feedback more quickly, thus reducing the overall time spent testing in the SDLC. When the dev team receive test feedback rapidly and consistently, they are less likely to get stuck into something else and will thus remain far more focussed on the immediate task at hand. Don’t underestimate the time to come back up to speed with one piece of code when you have already wandered off into another.

Deployment Pipelines

You can enhance CI/CD using deployment pipelines to increase the speed of deployment. This means that when you build your code, integrate or make a change to your code, you automatically test this code on production like environments. A deployment pipeline will usually have multiple stages for testing in development, testing and staging environments.

Some of these test stages will be short and some longer. By triggering fast-running stages before longer-running testing suites, you can get feedback sooner about your code viability. Once you have automated test suites a good place to start with implementing a deployment pipeline is to make deployment to any environment a fully automated process that happens on demand in minutes. By doing this you can get feedback sooner and make the path to production faster and more repeatable.

Summary

So you can continue to do testing the hard, tedious and less reliable way or you can work smart to get ahead of the game. Building an automated framework that facilitates continuous parallel testing in your CI/CD pipeline along with a deployment pipeline to facilitate more rapid deployments will pay significant dividends, far outweighing any upfront investment.