By Seth Watts
There’s a lot of buzz surrounding the word virtualization these days. It’s a popular concept, yet not everyone knows what it means. Virtualization is really quite simple; basically, it boils down to using software to simulate hardware or another piece of software.
Hardware is expensive and virtualization offers an opportunity to use less hardware to accomplish more. Probably the most popular example of virtualization is a virtual machine, which is the use of software to simulate a computer. A number of my colleagues here at IDT have Apple laptops, but use VMware software to run a Microsoft Windows virtual machine. They are using the Apple laptop hardware to natively run the Apple OS X operating system, but inside OS X they are running a piece of software that is simulating a Windows computer. Both Apple and Windows experiences are facilitated by the Apple hardware, simultaneously.
Have you ever partitioned your hard drive into sections? Surprisingly, this is a form of virtualization. The operating system is simulating multiple hard drives, although only one exists.
Consider Java, .NET, or Flash. All of these technologies utilize a form of virtualization known as a runtime environment, where a layer of software acts as a machine that aims to consistently execute code across multiple platforms. A runtime environment is usually specific to processor architecture, so you have one version for Windows, another for Mac and another for Linux. Each version of the runtime environment should interpret a piece of code in the same way, regardless of the underlying processor architecture (hence the old Java slogan, ‘write once, run anywhere’).
Many of us connect to secure networks using VPN (virtual private network) software. This technology uses the Internet and packet encapsulation to simulate a physical connection to a private network. Since a packet of data is wrapped within another packet of data, it is protected from prying eyes on the journey across the Internet.
Virtualization in Software Testing
So how does IDT, the authority on automated software testing, utilize virtualization in daily testing? I would like to share with you two of our virtualization secrets to automated testing success: virtual quality assurance nodes and virtual elements of the production environment.
One of the challenges of testing is allocating enough resources to the testing effort. Some pretty smart folks at our company addressed this problem early on by establishing a virtual quality assurance node farm, using VMware ESXi hypervisors. The number of virtual machines that a hypervisor can support is dependent upon the specifications of the server it is running on, but for ballpark discussion’s sake, each of our servers can handle running between fifty and one hundred virtual machines. IDT releases software that runs on Windows and Linux, so a farm of virtual machines of that magnitude has allowed us to allocate CentOS, Windows XP, and Windows 7 machines to each engineer, explicitly for testing. This empowers each engineer to continuously test on multiple platforms, without disrupting activity in their (virtual) development environment.
Another challenge of testing is to simulate aspects of the production environment in the test environment. The options for virtualization differ with the various levels of testing. At the unit testing level (individual code functions), IDT utilizes virtual mock objects to simulate components that are inaccessible. Whether it is a connection to a production database or incoming socket communication, objects can be virtualized at the class level and used in unit tests to simulate the production environment. In addition, we use virtualization to enable us to efficiently conduct system testing across a wide range of configurations.
Virtualization is an integral part of technology use and development in the 21st century. It broadens possibilities and capabilities. Most likely, you are using virtualization every day. It is critical to the work we do here at IDT.
Seth Watts is a software engineer at Innovative Defense Technologies (IDT). He is a contributing member of the ATRT: Test Manager and the ATRT: Analysis Manager development teams.