Testing in The Cloud Using SauceLabs

Any developer familiar with the testing process will agree that it is pure evil. In a traditional set up testing requires setting up new environments at every turn which is being used sporadically at best. Not just a major chunk of your resources are lying idle for the most part, it also consumes a lot of time. For most of us testing is a non-critical business activity. But it is absolutely required, unless you want to meet your clients red faced.

Today the software development world has entered into the Cloud bandwagon, and everything is treated as a service. Sadly these benefits have seldom passed on to the testing side of the world. Well, not anymore. In this article I am going to show you how to set up your testing infrastructure in the Cloud using SauceLabs.

What is Testing Infrastructure?

Let us assume that you are building the next Amazon. You have hired a few awesome devs and your Before going mainstream, you might want to check how it behaves in different Operating systems, browsers, and resolutions. We also need to check how many parallel transactions your application is able to manage before it turns into the next IRCTC and drown. Obviously you will need some sort of infrastructure to back your team up. This is called as Testing Infrastructure.

Normally you will need to procure multiple systems depending upon your needs and configure each separately with the operating conditions of your choice. For load testing you will even need to set up a even more powerful, expensive system that effectively mimics your main server. Obviously this is going to cost, which is not feasible for a small organization.

Another problem is testing is not a full time task. It is only required when there is some change either in production, or the operating conditions. Other times your capital just sits idle in an air-conditioned room. The costs spirals up, and even before you realize you will be out of money to focus on other important tasks.

When Cloud computing came into existence a lot of discussions circled around moving your testing infrastructure to the Cloud. The idea is to attain efficiency by decoupling your testing team from testing infrastructure. When you set up your testing infra in the Cloud, it does two things- it eliminates the need for an upfront Cap-Ex, and it allows you the flexibility to scale up/ scale down your operations on demand, there by efficiently utilizing your resources. It also effectively removes the headache of having to configure each system individually. Unfortunately it is not all roses either. There are many doubts creeping over data integrity and security in the Cloud, which could easily retract anyone from making the move.

SauceLabs

SauceLabs is a cross-browser automation tool built on top of the famous Selenium Web-driver  For those of us who do not know what Selenium is, “It is a technology that allows programmers to send commands to web browsers to make them perform tasks as though they were being used by a human. In this sense it is like a robot for web browsing.”, to quote their website. Essentially Selenium gives you the freedom to test your pages across browsers automatically, through test scripts. A Selenium server (locally installed) then instructs your browsers (with Selenium extensions enabled) to test your app. However it is a pain to install and manage the complete Selenium suite, especially if you are mooting for cross browser support. You will also have to face the brunt of hardware failures, and maintenance nightmares too.

SauceLabs was developed by the same guys behind Selenium, as a solution to this problem. SauceLabs takes care of setting up the testing environment, only this time the setup resides in their Cloud servers. Then we can connect to those machines virtually from anywhere using any browser. Think of SauceLabs as a container having your testing environment, which you can access over Internet. We are now free of all the configuration related hoopla and we can focus on what really matters. Of course as with any Cloud setup you have the flexibility to fire up additional instances on demand, and even run parallel tests.

Getting Started

Once you sign up for a SauceLabs account, you get 200 free testing minutes, after which you’ll have to pay a small fee to continue using the service. Once you’re in the admin dashboard you can setup your test environment just by clicking the little pointer icon.

Once SauceLabs is done configuring your machine it lets you connect to your web-app for further testing. One interesting thing to note is all the browsers come with developer tools pre-installed to help you in debugging the issues on the fly. You can navigate through your app and verify it for both functional and non functional issues. SauceLabs allows you to raise bugs directly from the tool immediately. It automatically uploads the screenshot of the page where the bug is and a video showing how to reach the page. This should remove any ambiguity, if any during fixing the issue. It also generates a Selenium style log which should come in handy later on. The dashboard gives also presents you with a colorful, comprehensive overview of what is happening with your testing scenarios to keep your managers happy.

Automate your way in

Manual testing is redundant, time consuming, and boring. Selenium offers a powerful test suite to automate your testing. The best part is you need not circumscribe yourself to the language in which the application is developed. In fact you can write your test scripts with any programming language in which you’re comfortable with. For the purpose of this tutorial we’ll be using Ruby. This tutorial assumes that you’ve a working copy of Ruby installed in your machine.

Lets first get the dependencies out of our way with

gem install selenium-webdriver

We will now write a basic snippet to check if search works in CloudSpring.com. Have your access key handy.

require 'rubygems'
 require 'selenium-webdriver'</code>

caps = Selenium::WebDriver::Remote::Capabilities.firefox

caps[:name] = "Learning SauceLabs- CloudSpring"

driver=Selenium::WebDriver.for(
 :remote,
 :url => "http://saucelabs_username:saucelabs_accesskey@ondemand.saucelabs.com:80/wd/hub",
 :desired_capabilities => caps)

driver.navigate.to "http://CloudSpring.com"

element = driver.find_element(:xpath, "(//input[@name='s'])")
 element.send_keys "A newbie's guide to Amazon EC2"
 element.submit

puts "Yay! Search works."
 puts driver.title

driver.quit

Save this file as test.rb and execute it by

ruby test.rb

Your result should resemble this

Head over to the dashboard, and you will find the test log. It lists the steps followed and even shows a video of how the script executed.

The code we’ve written is self-explanatory (and utterly useless, mind you) but for brevity sake let us take a little detour.

caps = Selenium::WebDriver::Remote::Capabilities.firefox
 caps[:name] = "Learning SauceLabs- CloudSpring"

driver=Selenium::WebDriver.for(
 :remote,
 :url => "http://saucelabs_username:sauce_labs_access_key@ondemand.saucelabs.com:80/wd/hub",
 :desired_capabilities => caps)

Capability is what defines the scope of your script. This is where you define you executing environment like operating system, browser, and even the version. SauceLabs sets up your VM based on this. WebDriver separates where the tests are running from where the TI, or in this case the browser is. It connects to your VM and starts the execution on the environment you’ve set. This where SauceLabs makes our life a lot easier. We just specify which browser to work on on the script and it takes care of the installation and stuff. We don’t have to lift another finger unnecessarily.

driver.navigate.to "http://CloudSpring.com"

Now we’re instruct the browser to navigate to thew URL where you want to perform your testing. Your driver object will now have the entire page.

element = driver.find_element(:xpath, "(//input[@name='s'])")
 element.send_keys "A newbie's guide to Amazon EC2"
 element.submit

The find_element() traverses the DOM based on the parameters we pass. I’m asking the browser to look for an input field with the name ‘s’ and pass the search string to it.

Author’s Note: We’re essentially writing the same old Selenium scripts, and using SauceLabs as a platform to execute it. If you already have written any selenium scripts they should work the same way. For those of us who’re new to Selenium or can’t quite understand how WebDriver works, download the Selenium IDE extension for Firefox and you can create your test scripts directly from the browser itself.

In real time scenarios we’ll be using verify..() or assert..() methods to validate the scripts. But since this article is focused on how to move your test scripts to the cloud, I’m drawing the line here.

Security concerns

Many people have steered clear of Cloud just because they feel it is insecure. It is just that- a myth, but that is a discussion for another day. To dispel any such doubts that you might have the team at SauceLabs employs a new approach- Security through purity. They assure you that your cloud VM once used is completely destroyed with all the data and not reallocated to anyone else. Have a sensitive data pool to be tested. Fret’ not. They offer a secure service called SauceConnect to prevent any data leakage. With the initial barrier out of our way, I strongly encourage you to take advantage of this wonderful technology.

Wrapping up

Testing in the cloud, especially for startups, offers a huge array of things. You don’t have to pay a penny upfront and you pay for what you use rather than wasting resources. And with SauceLabs all your test scripts are automatically logged, eliminating the need for manual intervention. Of course we’ve just scratched the surface today and there is a long way to go before your application can be completely tested on the cloud. We hope to rectify that in the future articles.

What would you like us to cover here in the future? Feel free to join us in the discussion and let us know about your thoughts. Thanks for reading, and stay tuned.