Code does not live in a silo. Applications are dependent on a multi-tier stack, backends, operating systems, server configurations, and many components and frameworks. In order to do end-to-end testing there needs to be a location to test the entire stack. And test in a way it behaves as it would in production. The only way to do this is to delivery upcoming versions of the applications to a lab environment.
Just like quality assurance processes, development teams know they need integration labs, but rarely want to put them in place. The net result is that the responsibility and implementation of quality assurance is set aside and never fully addressed. But without a good integration lab, developers may catch issues only in their portion while missing issues associated with the entire application. Because quality assurance is such a huge issue, this post addresses the why and how of building an integration lab.
Development teams avoid integration labs because on the surface they seem complex and because no department wants to handle the implementation. While IT is definitely responsible for the private or public cloud infrastructure used for integration labs, they are not part the application. At the same time, developers can’t take responsibility for the lab, because they often don’t have a full picture of a project. In my opinion, integration labs belong to either QA or DevOps teams.
Focusing on QA “owning” the labs—or, at a minimum, policing their operation—let’s talk about how to build an integration lab. With modern cloud tools, the process is not that complex, but there are several necessary, key elements that contribute to successful labs.
The use of VMs, or better yet Docker containers, is a must for an integration lab. While it may be convenient to run tests on an old machine under the desk, they won’t be destructible and reusable like VMs are.
Ideally, integration lab instances should be available on-demand. For example, the entire team can share a lab, but developers must also be able to create their own instance for more robust testing. Luckily, if they break it, it’s no problem! CloudShare, and several other cloud management tools have had great success with this approach, as it has been proven to open the door to better quality and more exploratory testing.
If you leverage the power of software-defined networks, you can not only take single virtual or container instances of the application, but you can also take instances of the entire multi-tier application with networking as well. Allowing testers to test against the entire application, and not just a subset, is a vital aspect for an integration lab.
If you spend time upfront creating service virtualization for common testing tasks such as database calls, a sample database with data or other tasks, you can utilize service virtualization for greater comprehensive testing in the labs.
In a perfect scenario, each developer would get their own integration lab to throw away or spin up at any time, and for every commit, there would be a CI delivery process to their lab. Also in this perfect scenario, regular maintenance of the infrastructure—and the gold master container or VM—would be set up and administered by the QA team.
Although this version of an integration lab is still the dream scenario, I do believe this model is the most suitable for achieving impeccable quality assurance. Given that web applications have been integrated into large back ends like SharePoint and SAP by leveraging the power of the above tools, this setup should be possible.
Integration labs are the easiest way to create a bug firewall between code, unit testing, function testing and production delivery. In terms of preventing future frustration and the costs of bad software, enduring the initial pain of setting up an integration lab is well worth it.
To read more about Applitools’ visual UI testing and Application Visual Management (AVM) solutions, check out the resources section on the Applitools website. To get started with Applitools, request a demo or sign up for a free Applitools account.
Chris Riley is a technologist. Helping organizations make the transition from traditional development practices to a modern set of culture, tooling, and processes that increase the release frequency and quality of software. He is an O’Reilly author, speaker, and subject matter expert in the area of DevOps Strategy, Machine Learning, and Information Management.