Those of us who are parents have recently completed preparing our children for the start of a new school year. We shopped for clothes, pencils, pens, markers, notebooks, calculators, backpacks and a variety of other things to get them ready for their education this year. It is an exciting time to see our kids start a new year and to think about all the experiences they will have and all the things they will learn.
For parents, it can also be an exciting time because we get a little bit of breather from the kids since school and extracurricular activities take up a greater portion of their time. For the kids themselves, though, the school year likely brings a mix of excitement and dread. Excitement to be reunited with friends and make new ones and dread over homework and, worst yet, tests.
For those of us who are involved with software development, testing is also a source of anxiety for many. That’s because in today’s economy, the ability to release software quickly, consistently and with high quality has become critical. Testing software before it’s released is key to ensuring the quality of your applications, but the way testing has historically been done has been conducive to supporting the time-to-market goal.
A quick history lesson on why testing has become a bottleneck. Agile methodologies, DevOps and continuous delivery toolchains are modern practices that have been adopted and implemented to drive the speed of applications released into production. But modernizing the testing practices within the software development lifecycle hasn’t occurred at the same pace.
Why is that? Too many testing processes have been manual, slowing down the process and introducing the opportunity for human error. Additionally, a lack of visibility into the progression, status and results of QA testing has made it difficult for DevOps teams to determine if the code they built is truly aligned with the business and customer requirements. A telling stat is that 63% of organizations that implemented DevOps practices report that Testing/QA practices are a bottleneck.
So, how do we get there? Let the class begin …
The first thing to remember is that a true continuous testing initiative should be in the context of an overall DevOps program -- it's not just a QA-led initiative. With that in mind, there are three key tenets for success: automate, simulate and integrate.
Of course, there’s a lot more than just these three things to consider, but they provide a good starting point that can help guide your continuous testing initiatives.
The benefits of automation have been well-documented -- both within the context of software development and in general -- so I won’t rehash that here. But a study that we at CA Technologies conducted (via App Developer Magazine) illustrated the progress that needs to be made in terms of automating software testing. While 93% percent of testers say automation is important, only 20% say they have 80% or more test automation coverage.
Automate
Within the context of software testing, automation needs to start even before development begins -- within the planning phase of the SDLC. That’s where user story modeling comes into play. User story modeling allows you to automatically generate tests cases and scripts directly from the business requirements, ensuring that tests are aligned with both business objectives and user behavior.
Additionally, models are self-healing, meaning test cases are automatically updated when requirements change. Testing can occur when code is checked in without requiring human intervention. Automation in this manner has proven to result in higher-performing organizations. The 2017 State of DevOps Report (gated) noted that high performers were 27% more advanced in test automation than their lower-performing peers.
Simulate
Once the test cases and scripts have been automated, the next bottleneck testers often face is the availability of both testing environments and the related systems and interfaces.
Testing software requires testing it against the other applications and APIs that a given application needs to interface with -- and using production environments can be time-consuming and costly. To overcome this, virtualization can enable you to simulate these third-party applications and APIs. Simulating virtual test environments is a great way to remove the reliance on production systems for testing while still ensuring maximum test coverage. By leveraging virtualized test environments and systems, you can eliminate constraints for all types of tests, including unit, integration, security and functional tests. The requirements model can also include virtual endpoints and request-response pairs to further accelerate testing speed and coverage.
Integrate
With test cases automated and virtual test environments created, you are well on your way to achieving continuous testing. But you don’t have to do it on your own -- the open-source movement provides plenty of excellent testing tools you can leverage. The common ones include Cucumber, Selenium, JMeter, Gatling and Locust, but there are really too many to list. Open source is embraced by both developers and testers alike, and these tools should be treated in much the same way as a personal bring-your-own-device policy. If your developers are already familiar with them, it’s a good idea to incorporate them into your testing processes when possible.
Not only are these tools cost-effective (read: free), but leveraging open source enables you to tap into the innovation that’s constantly being driven by the broader open-source community. They should be embraced as part of your testing curriculum and also included in your integration strategy to ensure tests can be automated at scale.
The same goes for cloud-based testing tools and APIs. Leveraging open-source, cloud-based testing tools can go a long way toward both accelerating testing and lowering costs.
There is obviously a lot more involved in creating a true continuous testing practice, but focusing on automating, simulating and integrating is a good place to start studying -- to ace your tests in the coming software development “school year” and beyond.
