Doing software testing in cloud environments offers economies and scalability possibilities that are intriguing...
to software development companies and departments. Interest is high because purveyors of "the cloud" promise to reduce software development and testing expenditures while maintaining or increasing the Quality of Service (QoS). Do those claims hold up? If so, how can software testers, in particular, prepare for this platform shift? That's what we'll explore in this tip.
You may be familiar with cloud computing, but let's just cover the basics just in case you aren't. Cloud computing is a new software service solution that holds an entire infrastructure and environment in one location, which is accessible to specified individuals via the Internet. Both hardware and software may be housed in a cloud environment. Predecessors to cloud computing include Software as a Service (SAAS), a service solution which is similar to cloud computing that allows users to access the software/hardware onsite or via an Internet connection; Service Oriented Architecture (SOA), which could also be accessed either onsite or offsite; and Application Service Providers (ASP), which hosts applications.
Being safe about cloud testing
Since cloud computing systems hold vast amounts of corporate information and can only be accessed through the Internet, the availability of the Internet and the reliability of its connection are two facets of cloud computing that users depend on the most. And, although the software and/or hardware infrastructure is harbored "safely" in a cloud computing environment, the network will not always be trustworthy.
Well, it's obvious that there are a number of things that can go wrong, such a weak telecommunications signal, a storm or an Internet provider going out of business. For these reasons, it is a good idea to prepare a backup plan for accessing the Internet. Think about purchasing a secondary connection, in addition to your primary one, that can be available when you need it most. You may even be able to configure the system to cutover or re-route to the secondary line if the primary line experiences too much traffic at one time. If you choose to do this, just be sure that your backup wire is not from the same provider as your primary connection.
Keep in mind that computers used in a cloud environment will never be 100 percent reliable; there will always be viruses and other glitches that may slow down the system. So, even with the best Internet connection, a robust computer that can handle high processor and memory speeds and has a large hard drive space is a must.
Cloud environments cannot be externally controlled by the companies using them, which means problems with quality are difficult to fix once the cloud is fully integrated with the corporate system.
In an ideal situation, a specific environment would be created for testing each application -- development, configuration management, training, etc. -- thereby helping to ease change, versioning, release management and identify quality assurance issues. Talk with your vendor to find out if replicated environments are offered as a part of the service. In most cases, though, such a luxury typically defeats the purpose of using cloud in the first place, as it is not very cost-effective.
It is in your best interest to work with the cloud service provider to construct a quality assurance "staging" area where all of the testing, configurations and setup are finalized prior to going live. You should test during this beginning phase until you're satisfied that you have the best cloud service solution to suit your needs.
Key best practices for cloud testing
When possible, test the cloud applications in a very similar, or the same, environment to the one in which it will be accessed when it goes live. The testing should scrutinize the application's performance, reliability, speed, security and functionality. Recently, the traditional functional testing, also known as regression testing, is being used more than any other kind to validate cloud; which is a one-pronged approach. To truly ensure an operable cloud environment, performance and reliability tests should take the front seat, during which probes can be used to capture statistical data and report on the consistency of the application.
The strength of cloud computing's security barrier for user-protection and corporate compliance is crucial, especially if your company will store sensitive information in the system. Formal security testing tools and even hacking techniques are some of the most effective methods for testing the security of a cloud environment. And, a disaster recovery test will help you confirm that the vendor is reliable and responsible when faced with an emergency.
A cloud computing test plan should also be created at this point and should include a detailed log of every single testing activity and issue that arises. Prepare a list of metrics that you want to be reported to the vendor, such as defects or errors found, the speed of service, reliability and so on. These indicators will help top management and staff address the maturity and consistency of the cloud vendor's processes.
If these steps are still not enough to put you at ease, create an audit of the system's log file and reports and prepare an internal and external communications plan with the vendor. Get in the habit of holding at least one weekly meeting during which you discuss future changes, status, metrics, and outstanding action items. The more communication you have with the vendor, the better they will understand your priorities and the better service you will receive.
In-house policing of cloud QA
Once your company had decided to use a Cloud service solution, there's still plenty for QA managers and testers to do in house. For instance, make certain that the developers and/or users have what they need to do the task at hand. Naturally, there will be need for planning testing of applications for future projects.
Policing employees' storage habits is a key in-house project management practice. Developers, testers, managers and users should not continue to save important files on their computer desktops and various locations on the corporate network instead of using the cloud system as the central source. Retrieving data can be a nightmare if you don't have access to a computer that has all the important information on it. Even worse is having to search through lines of folders on a corporate network for a document that someone else authored and saved somewhere.
To prevent improper file storage, QA managers may need to mandate that all employees use the cloud architecture when saving files. They could enforce correct file saving by adjusting the read- and write-privileges on each computer that has access to the cloud system. Another option is using local proprietary lockdown software. For instance, you may allow data-entry personnel to use the Internet for cloud applications, but prohibit them from obtaining write-access to their desktop so that data cannot be transferred to that location. Or, cloud users may be prohibited access to public Internet sites, such as email, which could be used to share sensitive corporate information. Another solution may be to use Internet machines with comprehensive capabilities instead of a traditional desktop computer, which could potentially save money and reduce the risk of data misuse
In general, be prepared to relinquish a certain amount of control of the system either way. While you must be cautious about getting good service level agreements and preparing well, those are not good reasons to dismiss using cloud services. I suggest getting started with cloud services with software products that are already stable and well-tested. It is also useful for a solution with products that will be developed within a Cloud environment, as long as R&D remains consistent.
Regardless of the reason you choose to use cloud, however, using the techniques discussed above may help you get the most out of the service while remaining cost- and quality-effective.
About the author: John Scarpino is a director of quality assurance for a large corporation, has been a QA test engineer for 14-plus years and is a university instructor in Pittsburgh.