First Agile, now Continuous Integration. Where does testing fit?
June 20, 2016
In the early days of building cars all pieces were "integrated" at the same time, so it wasn't likely that they'd get to the end of the process and fi...
In the early days of building cars all pieces were “integrated” at the same time, so it wasn’t likely that they’d get to the end of the process and find out the steering wheel wouldn’t fit. On the down side, if they had an idea for a new transmission they’d have to start over and build everything by hand again.
Similarly, software development used to mean that the GUI person would work alone, the database person would work alone, and the business logic person would work alone. Then, when everybody was done, you’d stick it all together and hope it worked. It never did. Everybody hated it because you’d spend months redesigning and hacking all the bits until they fit together. This style of development continued for years.
What was once referred to as the “application development crisis” meant it was nearly impossible to release a product that met all of the customer’s current needs. According to a recent article, “the Space Shuttle program, which operationally launched in 1982, used information and processing technologies from the 1960s. Highly complicated hardware and software systems were often designed, developed, and deployed in a time frame that spanned decades.”[1] Now, that example is extreme, but it’s still safe to say that by the time a development team was able to release an update, it either no longer met current demands or had become a minor part of the whole customer experience.
Lucky for us, Jon Kern, Kent Beck, Ward Cunningham, Arie van Bennekum, Alistair Cockburn, and twelve others came together 15 years ago to create the Agile Manifesto, which ultimately spawned Agile development, speeding development and making it easier to provide customers with the features and updates they demand.
Piggybacking on Agile development is continuous delivery (CD), continuous integration (CI), and DevOps. According to Michael Coté, DevOps is “sweeping changes to how the organization operates, end-to-end.”[2] It’s important to recognize that DevOps isn’t simple. It’s a process that is built on Agile development, and something that – when done correctly – can save time and headaches. When an organization can develop in Agile, while using CD and CI, they’ve likely become the poster child for the software release cycle. Mastering all these techniques is challenging, and something that almost every development organization struggles with right now.
To get a handle on all these tactics, it’s important to understand what everything means and what will happen if the process isn’t followed correctly. CI, for example, requires that all the parts of development fit together many times every day. When something doesn’t fit, the CI system tells the developers what went wrong so they can fix it immediately as the top priority. Each CI integration kicks off an automated build and test process to expose any defects and report the status as quickly as possible, making it much easier to manage, fix, and control code. The faster a bug is found, the easier it is to fix, resulting in a build that’s potentially releasable as quickly as possible. And with small changes to the code made frequently, new functionality can be released more quickly with minimum impact to the rest of the development team.
To maximize CI development, teams must work to detect as many issues as possible in each integration build while avoiding manual testing. Manual testing, much like development prior to DevOps and Agile, is mostly unnecessary and an extremely slow process. Focusing on testing through automation increases breadth, depth, and repeatability, and lets developers focus on features and other important aspects of their development. According to an article on the 11 Common DevOps Bottlenecks, “Manual intervention leads to human error and non-repeatable processes. Two areas where manual intervention can disrupt agility the most are in testing and deployments. If testing is performed manually, it is impossible to implement continuous integration and continuous delivery in an agile manner (if at all). Also, manual testing increases the chance of producing defects, creating unplanned work.”[3]
To avoid the pitfalls of manual testing, builds must be self-testing and produce integration results quickly. But all this works only when a development team understands and applies test automation. Teams have to write the tests, maintain them, and make sure they actually mean that the software is ready for customers if the software passes all tests. When done right, developers get the benefits of integrating all the pieces every day as well as the speed of automatically working software. When done wrong, teams get crashes, errors, and long build cycles. With many dynamic test tools unable to complete testing in time – especially at continuous integration speeds – developers should focus on tools like static code analysis (SCA) to keep up with fast-paced development environments.
Static code analysis tools are fast, scalable, and automated – perfect for CI. SCA in a CI environment complements dynamic testing because it finds issues in the code beyond those found at runtime and can help detect bugs earlier in the lifecycle (making it more cost-efficient). The ideal static analysis engine for CI processes only analyzes modified code and affected execution paths, rather than processing all the code all the time, slowing the process. It also provides the capability to work across multiple developers and fits into existing CI tools to distribute the analysis. Since SCA operates on source code and does not have to execute the code, it can perform a complete analysis of the submitted code changes in a bounded time frame. Quicker analysis means faster resolution of defects and a healthier build.
This new phase of continuous integration allows companies to once again increase their development cycles, adding even more automation to the development world. This improvement advances to the next phase of DevOps: Integrating and simplifying development tools in the development environment. Now the GUI person, the database person, the business logic person, and the entire development team can work continuously to ensure that customers have earlier access to updates and features. This takes us light years ahead of the assembly line of car making, and right into the universe of self-driving cars.
Rogue Wave Software
LinkedIn: www.linkedin.com/company/rogue-wave-software
Facebook: www.facebook.com/pages/Rogue-Wave-Software/340310722680802
YouTube: www.youtube.com/user/roguewavesoftware
References:
1. Varhol, Peter. “The Complete History of Agile Software Development.” TechBeacon. Accessed May 11, 2016. http://techbeacon.com/agility-beyond-history—-legacy—-agile-development.
2. “Go DevOps before Your Bosses Force You To. It’ll Be Easier That Way.” The Register. Accessed May 11, 2016. http://www.theregister.co.uk/2016/03/09/making_sure_your_bosses_get_devops/.
3. Kavis, Mike. “11 Common DevOps Bottlenecks.” Forbes. Accessed May 11, 2016. http://www.forbes.com/sites/mikekavis/2014/12/18/11-common-devops-bottlenecks/#723f67b214e1.
