Software testing doesn’t have to be time-consuming

Jul 13, 2020 / by Nikhil Sharma

Speed of software delivery always depends on testing. Look around, it takes a well thought, well written and well tested software to disrupt the market. Take any one of the components off the recipe and a business will lose its competitiveness in the market and dig its way to an early grave. This phenomenon has become rampant with the advances in technology. Currently, businesses are under intense pressure to deliver a continuously enhancing experience to the end user. They want to build better software faster and deliver it quicker than their competitors. Offering a product with superior quality faster lays the difference between growing your business or going out of business. 

  What does potentially prevent you from delivering a good quality software at a rapid pace? Correct, it is testing. Testing is an often overlooked and an often underestimated effort in the software development and delivery processes. The advent of cloud technologies, software as a service, infrastructure as a code, microservices etc. and a shift from waterfall mode of doing development to leaner agile and DevOps ways have given businesses the muscles to accelerate their release cycles from yearly to monthly, to weekly, to daily, to many times in a day. Nevertheless, even with all the muscles, one can deliver a piece of software only as fast as one can test it.  

Software delivery accelerates with continuous automated testing

Does testing have to be an overlooked or an underestimated effort? Does testing have to be slow and mundane? Does testing have to be a bottleneck for your businesses? Well, the answer is a big no. I believe that one man’s bottleneck is another man’s opportunity. And the opportunity lies in turning testing as your competitive advantage. Once you got that right, your offering will not only have a better quality rather you will create value at unprecedented rates and stay ahead of your competition in serving your customers. 

You have probably heard of shift-left and shift-right testing methodologies. Shift-left testing is a more proactive approach towards testing wherein testing takes-off early in software development and is conducted often. On the other hand, shift-right is a more reactive approach wherein a software is shipped as quickly as possible and the testing happens with users. Shift-left testing is one of the core themes in DevOps, which come under continuous testing. One just cannot  continuously develop, integrate and deploy without continuously testing. 

DevOps maturity for a business determines the state of their continuous testing. Looking through the infinity loop of DevOps, typically the developers in your team are continuously building new functionalities on top of the existing code base, which is then integrating with other in-house or 3rd party applications and made accessible. In order to provide quick feedback to your developers about the software’s functionality, you need to test the new functionalities, ensure the new functionalities have not broken any existing functionality i.e. regression testing and ensure the ecosystem of applications works together end-to-end, all of this needs to happen continuously.

The businesses relying completely on manual testing will in no time experience a bottleneck in their Quality assurances. It would not take more than few iterations to realize that you need more testing than your resources permit. Scaling headcounts, which is not very effective may postpone the problem. Consequently, corners will be cut in testing, product quality will suffer and sooner or later you will lose the edge. 

Test automation starts with attitude and reasoning

Continuous testing just cannot happen without automating testing. Test automation has been around for decades, but for many this might be a relatively newer term. Every now and then I come across organizations who are yet to reap the benefits of test automation. Businesses are reluctant because it might look like an expensive investment at upfront, while the manual testers are worried about losing their jobs. There are two questions to ask:

  • Would you rather invest, be disruptive and make your returns outdo your investments or would you rather lose your competitive edge? 
  • Would you rather still farm with your hands and keep your jobs at hand or would you rather use your farming knowledge in inventing tractors and in making the process more efficient? 

To a large extent, test automation is understood and implemented as an automated execution of test scripts. It undeniably is the very core of test automation, software robots churning test automation scripts day-in and day-out, without getting a burn-out or bore-out, without becoming blind to regression and at insane speeds.  I must say that there is a lot more to test automation than automated execution of test cases, but that is where every test automation journey begins from.

Success or failure of a test automation project, like any another project is dictated by how well it is governed. You need to know your whys, hows and whats before embarking on this journey. Why are you going to do test automation? How are you going to do it and measure it? What are your goals? 

Test automation strategy dictates test automation success

Test automation should be thought similar to how development is thought about. A clear strategy is going to define the success of your test automation project. For instance, development teams just not start writing code and building architecture independently, in a chaotic and unsynchronized manner. There are clear business-related goals to what development teams should be developing, architecture is built around on how to optimally serve the end-customers, coding language and ground rules are jointly selected, proper processes are put in place and regular monitoring keeps the teams on track. Similarly test automation needs a proper strategy, architecture, common frameworks, common guidelines and monitoring.  

Empower humans with robots and vice-versa

The strongest and the most successful candidate for test automation is regression testing. Major chunk of software testing efforts is spent on regression testing. The core idea of which is to ensure that any new changes in your software have not broken the existing functionalities. As you can very well imagine, every new feature becomes an existing functionality at some point and hence the regression testing is an ever-increasing phenomenon for an evolving software. Not to mention that the frequencies of conducting regression testing and your software release cycle are directly related. Consequently, the more you develop and the faster you develop, the steeper your regression testing efforts are going to grow.

Mostly regression testing is a large sum of repetitive task, which you might have guessed is the sweet spot for any automation. Automation of your regression tests will not accelerate your testing, it will also free up your resources for an equally important testing effort, exploratory testing. Exploratory testing, as the name suggests is testing by exploration. It is the more creative part of testing as against regression testing, which is the sweet spot for humans.

Human efforts should be re-directed towards enabling robots to churn test automation and in turn robots should empower humans to focus on more imaginative aspects of testing. The near ideal testing scenario is when the robots are augmented with human ingenuity.

Once again, does testing have to be an overlooked or an underestimated effort? Does testing have to be slow and mundane? Does testing have to be a bottleneck for your businesses? Well, the answer is a big no.

Start Free Trial

Topics: DevOps, Test Automation

Nikhil Sharma

Written by Nikhil Sharma