Delivery Speed and Testing Software: A Balancing Act

Wercker is a Docker-Native CI/CD Automation platform for Kubernetes & Microservice Deployments

Scott Fitzpatrick
June 12, 2018

One thing every developer can—or at least should—agree upon is that testing software is an integral part of the software development process. If it were up to the development team, no application would be released without rigorous testing, ensuring no bugs made their way into production.

However, testing thoroughly while meeting other development goals can be tough. Nearly all DevOps organizations work with tight deadlines that don’t allow for an infinite amount of time testing an application.

The question then becomes: How can we strike a balance between testing and delivery speed? What can we do to ensure that we test a new product thoroughly before a production release, without delaying the release?

Below are a few tips and strategies to assist in finding this balance.


Utilize Agile methodology and Continuous Integration

The iterative nature of Agile software development offers several advantages related to testing software thoroughly and continuously, throughout the development lifecycle. The basic tenets of the methodology provide for a testing approach where testing begins early in the development process. Working within the structure of a sprint allows software engineers to develop and integrate individual features that can then be tested by QA and the rest of the testing team—which is then followed by acceptance from the product owners.

This concept of starting early and testing continuously (rather than waiting around to do a majority of the testing at the conclusion of the development cycle), is known as shift-left testing.

The Agile development process and shift-left testing are advantageous for the purposes of balancing quality with delivery speed, because they allow for testing on a smaller scale. The product can be tested from the moment the first few features of the application are coded, all the way through the application’s maturity into the finished product that will be released to the customer. The ability to test software continuously as individual features are developed and committed means that the tester will have less to focus on and fewer moving parts to worry about. Tighter focus will lead to the discovery of bugs earlier in the process, which leads to more bug-free features as the development lifecycle winds down.

This brings us to Continuous Integration (CI) and the undeniable benefits of committing functional code as often as possible to a common repository. Through CI, developers get their code in a working state and then commit to a common repository, which can then be deployed to a test environment. By utilizing this process, the DevOps team will always have an up-to-date and functioning product that may not be entirely complete, but can be tested at any time.

Through the use of CI, testers will be able to work with the product earlier and get feedback to the software engineers so that any issues they discover may be resolved long before the deadline for release. This tends to provide peace of mind to the DevOps organization—They can rest assured that the application is being developed at a reasonable rate and exists in a state that is free of major issues (and mostly free of minor ones as well).


Periodically schedule bug bashes

Another helpful tactic for testing thoroughly under difficult deadlines is to schedule the occasional bug bash. A bug bash is a set period of time in which members from all different units within the organization temporarily put aside their other responsibilities to bang on the application under development, in an effort to turn up as many issues as possible. Basically, the DevOps team freezes the code base, and members of the development team, along with testers and Operations folks, will use the application during the set time period, and record bugs that they find in a central repository.

Several benefits can come out of the process if bug bashes are performed on a semi-regular basis (maybe once per month for a two- to three-hour time frame). These benefits include:


  • Preventing a large build-up of issues. Bug bashes tend to quickly turn up multiple bugs within the application under construction. Taking the time to focus on testing every dark corner of the application and finding out where the problems are via a bug bash once per month, or even every two months, will lead to fewer issues making their way to the end of the development process. Bug fixes can then be worked into subsequent sprints. As deadlines approach, you can rest assured that minor kinks were worked out long ago.
  • Different perspectives. A bug bash calls upon members from all parts of the organization to test (this means product testers, developers, and maybe even some who can be considered end users throughout the organization). With participants from differing professional backgrounds, you will benefit from testing from different angles. For instance, a developer may test for SQL injection within a form in a web application, while an end user may simply test to ensure that same form submits properly. This juxtaposition can be very beneficial in the effort to find both obvious and more subtle bugs.


Testing your product thoroughly while adhering to difficult deadlines can be a tall task for any development organization. Finding a balance is key to ensuring that the software being developed maintains a high standard of quality, despite a fast-paced development cycle. Efforts to test early and often by utilizing shift-left testing, CI, and occasional bug bashes can help decrease the stress of this balancing act, and lead to a bug-free product in production.


About the Author

Scott Fitzpatrick has over 5 years of experience in software development. He has worked with many languages over the years, including Java, ColdFusion, HTML/CSS, JavaScript and SQL.


Topics: Containers