A Reading from the Book of Ruby

February 21st, 2013 by Dylan

The following is a post by Dylan Lacey. Kinda. He’s chosen to do it in interpretive dance  easily digestible image format.

Source - http://www.flickr.com/photos/jeffgunn/6663212147/

This is San Francisco.

I am currently in San Francisco

 

I was recently there…

http://www.flickr.com/photos/hostingreviews/8057709725/sizes/m/in/photostream/


http://images.wikia.com/uncyclopedia/images/c/cf/Developers.gif
http://www.flickr.com/photos/glasgowamateur/6268228233/in/photostream/
sauce_horiz_340_over

…because I am the new Ruby Developer Evangelist at Sauce Labs.

http://www.flickr.com/photos/antichrist/132623505/

My job involves taking a fair few of these;

http://www.flickr.com/photos/cogocogo/6204578958/

And sharing a lot of these. It’s a burden.

http://www.flickr.com/photos/hostingreviews/8057709725/sizes/m/in/photostream/

http://www.flickr.com/photos/nasonurb/8291759460/http://www.flickr.com/photos/infomatique/8136256947http://www.flickr.com/photos/infomatique/8136256947

I’m here to help get Ruby developers up and running, helping them to Drink the Sauce.

http://www.flickr.com/photos/otto-yamamoto/3655977700/

It’s SO awesome.

http://www.flickr.com/photos/farnea/395147027/

I’m insanely thrilled to be working with such smart people on an amazing product!

My bailiwick is to make it better for Ruby developers to use Sauce Labs’ stuff, including improving the gems, writing better documentation and building the community. Plus, it’s a unique opportunity to use my personality to insult people all over the world! If you want to offend your manager, disrupt your office and get kicked out of your favorite bar for getting shouty about whether RSpec is better than Test::Unit, let me know. And if you want help with the Sauce Gem or tests from Ruby land, hit me up.

You can find me on (T) or (E)

(This post was originally from Dylan’s Blog and all images herein are CC Commercial Licensed, you’ll find their attribution in their alt-text)

Share

Introducing ChemistryKit — a Ruby version of Saunter

February 11th, 2013 by Dave Haeffner

This is a guest blog post by Dave Haeffner, the founder and Captain of Arrgyle (a boutique QA consultancy), and the co-organizer of the DC Selenium Meetup

Too often teams know what they want to accomplish with Selenium automation but get roadblocked by the infrastructure necessary before they can create their first script. Element 34 took this problem head on and created Saunter, an open source test automation framework that removes those roadblocks and says, ‘Here, do it like this’.

Money Where Our Mouth Is

With so many tools to choose from, and different ways to approach automated testing, we think Saunter goes about it the right way. So much, in fact, that we just ported it to Ruby (after adding a little bit of our own flair, of course).

Introducing ChemistryKit – a simple and opinionated open source web testing framework for Selenium WebDriver that follows convention over configuration. It’s wired ready for your Continuous Integration server and integrates with Sauce Labs for cross-browser execution in the cloud. Borrowed from Saunter, built in Ruby.

Hop In

Assuming you’re running a current version of Ruby (e.g. 1.9.3), it’s easy to get started. A simple `gem install chemistrykit` will do the trick. Don’t worry about finding a place to stuff it into your existing project, it can live in its own repository.

ChemistryKit is executed from the command line and is quite similar to Ruby on Rails. `ckit` for ChemistryKit is a lot like `rails` for Ruby on Rails.

Let’s take a tour

Executing `ckit` will display the available commands with some description:

ckit

Let’s generate an example test framework and call it something clever like… ‘example_test_framework’. This is done with `ckit new example_test_framework`

ckit_new

This generates the base file and folder structure you need to get started.

Put `cd` into the directory and get ready to generate some page objects and test scripts (known colloquially as ‘formulas’ and ‘beakers’). Generating a formula will generate both a formula and a beaker. But for this post, we’re just going to demonstrate a quick hello world example with a beaker.

A Simple Example

`ckit generate beaker ohai`

ckit_generate

The beakers are written using RSpec and generated with a predefined tag. This is the default tag that is executed if none are provided on execution.

Here is a rudimentary example of accessing the browser object that is instantiated by ChemistryKit on execution (e.g. @driver) and using it to load Google.com:

ckit_beaker_1

Additionally, you can wrap your test steps in it/do blocks (with descriptor text), like so:

ckit_beaker_2

Kicking The Tires

For a quick sanity check, ChemistryKit is wired to run locally out of the box with Firefox. So once you have a test written, just run `ckit brew` to run your test suite on your local machine. You should see Firefox appear and load Google.com.

When it’s done, you should see something like this in your terminal:

ckit_brew

Drive It To The Cloud

Best of all, connecting ChemistryKit to Sauce Labs is as easy as 1, 2, 3.

Step 1

Open _config/chemistrykit.yaml and set ‘run_locally’ to false, and ‘ondemand’ to true.

ckit_config

Step 2

In the _config directory, rename saucelabs.yaml.example to saucelabs.yaml.

Step 3

Add your Sauce Labs username and key to _config/saucelabs.yaml.

ckit_sauce

Now any time you run `ckit brew` your tests will execute in Sauce Labs under your account.

Are We There Yet?

Now you’re ready to add your newly created test framework into your version control system, wire it up to your CI, write some more beakers, and start getting quick feedback. Bravo!

Check out the getting started guide on the GitHub project page for more info. And for ChemistryKit related news, updates, and examples, be sure to keep an eye on Arrgyle.com.

Dave Haeffner is a man on a mission — to help people achieve their potential through effective technology use. He has spent the last 4 years working in the Quality Assurance space, helping various companies achieve better software quality with less effort. This is the current focus of his company (Arrgyle), which emphasizes the use of sound strategy, simple process, and open source tooling.

Dave is also the co-organizer of the DC Selenium Meetup, has spoken at various Agile conferences, and holds a Master of Science in the Management of IT from the University of Virginia.

Share

Dr. Testlove or: How I Learned to Stop Worrying and Love Automated Testing*

February 4th, 2013 by The Sauce Labs Team

This is a guest post by Brent McNish, the co-founder and CTO of Deliberator. Deliberator is a joint customer of Sauce Labs and Solano Labs (makers of Tddium).

* with apologies to Stanley Kubrick

 Pre-testoric

The image of the head-down coder hacking away Tasmanian Devil-like, paying lip service to writing tests, is a thankfully less and less accurate cliché these days. But that wasn’t always the case. These guys (and girls) used to be everywhere. They didn’t get into development to do testing! Look, the code works! Job done. Next feature, bring it on!

Yes, once upon a time the “who needs automated tests” dinosaurs ruled the earth. And I was one of them.dinosaur

I began my web development career in a large IT consultancy. We had testers, and test managers, and elaborate test plans. They would catch the bugs because it wasn’t a developers job to test. Then I left to co-found my first (bootstrapped) startup, as the sole developer, with a single co-founder. And in Bootstrapped-Startup-Land, you don’t have testers, and test managers, and test plans. There is just you. And your code.

And every line of code you write, someone, somewhere, is also writing a line of code, and they might have the same idea as you. And they’re going to launch their feature before yours. And they’re going to beat you. So each line of code is precious. And you don’t want to “waste” it on a test.

So I still wasn’t interested in testing.

When each feature was completed, I manually tested it, then my co-founder tested it. Then I fixed any bugs. Then we both tested it again. Then, when it worked, I moved on to the next feature.

Then things that had worked would break. So I’d go back and make them work, then move on. Then, later, they broke again. A mantra began in my head, quietly at first, then with increasing volume: “Write some tests, write some tests…” But where to find the time with all this bug fixing to do?

Yes, that way madness lies.

(Unit)ed we stand

So I began writing tests. This was a baptism of fire as, of course, there was now a large backlog of untested functionality to tackle. But I gritted my teeth, girded my loins (whatever that involves…), dove in and began writing unit tests. And, you know, a funny thing happened.

Slowly, very slowly, assertion by assertion, I learned to love testing.

I began to take actual pleasure (pleasure! imagine that!) in crafting a test and then seeing the little green icon in my IDE ping to life when it passed. Knowing that my new feature was fit to go live. And more importantly, that I hadn’t broken something else in the process.

So, this was job done right? Sure, this didn’t test the front-end. But that’s what humans are for right?

Wrong.

The extra confidence and speed I gained from the unit tests simply seemed to manifest itself in more front-end bugs. Dammit!

Seleniummmm

Then I discovered Selenium. This was Selenium 1 (aka Selenium RC) so not the most stable and robust framework ever. We would often see a test fail then pass immediately after without any change to the code or data in between. Hmmm……

selenium logoEven so, automating browser tests seemed like magic. It was mesmerizing to watch the tests running. A never-tiring invisible hand filling in form fields and clicking buttons. (Ok, maybe I’m just easily mesmerized).

It was fortunate that I found watching the tests so entertaining because boy were they s-l-o-w. A full run would take around 90 minutes. It also sent the CPU fan on my laptop crazy and made using it for any other purpose at the same time a painful ordeal. The upshot of this was that I didn’t run the Selenium tests very often. Which meant they grew more and more out of date. Which meant that I was even less likely to run them.

So we ended up falling back on manual browser testing again. Doh!

Hot Sauce

But, wait, what’s that sound? Enter stage left, our hero on a white horse….. it’s Sauce Labs! Yes, I remember distinctly the day I came across the Sauce Labs website. I instantly Skyped my co-founder “Praise the Lord!” or words to that effect. “Selenium is re-born!”

And for us it really was.hot-sauce-small

After a very small amount of painless integration, there they were, our browser tests running in the cloud. Sweet! The test sweet, ahem suite, still took a long time to run but it was now fire and forget. Just kick off the tests and get on with your normal business. (Although I did kinda miss being able to fry eggs on my Macbook when the tests were running locally. Those were damn good eggs!).

Almost as big a deal as being able to run our tests in the cloud was that we now had a complete record of every Selenium test run, including a video of the test running! Add to this the ability to do ad-hoc cross browser/OS testing with Sauce Manual and test against our local dev build with Sauce Connect, and it’s fair to say we were pretty ecstatic! This was by far the best situation we’d been in test-wise and the quality of the code showed it.

Carpe Tddium

But, you know, I’m hard to please. My two biggest remaining niggles for me were the speed of the Selenium test suite execution, and the fact that our unit and Selenium test results weren’t integrated. I’d come to accept these limitations, until…

What’s this, the rumble of horses hooves again? Here comes the second hero of our piece, Tddium, charging into the fray!

tddium logoThe claim of Tddium to completely lift the testing burden – unit and Selenium – into the cloud, and run both in parallel blew me away. To the extent that I was dubious as to how well it would work. But the answer? Very well indeed! Now add in Tddium’s Github integration and Continuous Integration support and…. wow… just….wow.

I am currently running 8 Tddium workers in parallel and the run-time for my complete suite of unit and Selenium tests is down from around 2 hours to 15 minutes. This has been a game-changer in my development routine. I’m now much more ready take risks and try stuff, knowing I can get such quick and comprehensive test feedback.

Continuous Inspiration

So yes, my conversion is now complete. From throwing code over the wall to ‘those tester people’, to being forced by necessity to slowly embrace automated testing, to now realising the full potential of automation with Sauce and Tddium, it’s been quite a ride. And it’s not finished yet. I still know that, someone, somewhere in another startup is still writing that line of code, and they might have the same idea as me. But now I’m not worried that they’re going to launch their feature before us. And they’re not going to beat us.

Unless they’re using Sauce and Tddium too….

Dammit!


Brent McNish is the co-founder and CTO of Deliberator, a new social network for ideas. Deliberator brings people together to create, debate and propagate solutions to the complex problems of the day. Join the debate at www.deliberator.com

Share

So You Want to Run Tests in Parallel… Now What??

January 15th, 2013 by The Sauce Labs Team

This is a guest blog post by Sarah Goff-Dupont, Product Marketing Manager for Atlassian Bamboo

Fast feedback on code changes has been a bit of an obsession ever since the Agile2012 conference got me thinking about how important this is for agile teams in particular–partly because turbo-charged feedback is a natural work-in-progress limiter. How so? Getting results back to devs so quickly that they don’t have time to start in on another issue keeps everyone focused on the task at hand. That, in turn, fosters an efficient development process. And efficiency, in my never-humble opinion, is what agile development is all about.

TooMuchWIP

 

 

 

 

 

 

(Caption: Faster feedback could save this poor imaginary developer from juggling 3+ coding tasks!)

Running automated tests in parallel is a great way to reduce build times and get results to developers and QA engineers faster. Today I’m going to dig back into my long-lost career as a test automation engineer and share with you the technique we used for running tests in parallel. ‘Cuz it was super-slick and I loved it. I’ll use Atlassian Bamboo (which integrates nicely with Sauce Labs, btw) as my example CI tool as we walk through it.

TestNG Groups FTW!

If you’ve never used TestNG before, you might think that’s a typo above and that I meant “TestING”. (Google’s autocomplete certainly thinks it’s a typo, so hey: you’re in good company.) But no. TestNG is an automated testing utility, much like JUnit. In fact, you can use it in combination with JUnit, WebDriver, Selenium, etc. And the reason you’d want to is Groups. By sorting your test suite into groups, then creating separate Jobs in Bamboo to run each group, you can speed up your testing stages by 100% –and likely, better.

TestNG is designed for Java tests, but can also be used for Ruby projects. And it’s not the only framework to offer groups. Proboscis for Python and PHPUnit also have them. JUnit has “categories”, which largely serve the same purpose, but are rather clunky and make TestNG’s groups look like a bacon-wrapped Ferrari by comparison (sleek, fast, and yummy).

BaconFerrari

 

 

 

 

Implementing Groups in Your Test Code

Like a handful of other testing frameworks, TestNG takes it’s cues from an @Test annotation. Inside that, you can place a number of attributes, one of which is Groups. Group names are both dynamic and arbitrary –small sentence, big implications. First, you can create a new group on the fly just by assigning a test to it. No need to declare and define the group in a separate file. The act of assigning a test to a group will also create that group, if it doesn’t already exist. (Now, that’s a double-edged sword because it also means you can end up with a group called “smoke_test” and another called “smoke_tets” if you’re careless.)

Second, you can devise whatever system (or systems) of meaning you like for your groups. Slice them along functional area of the application, by level of the code stack, by whether you currently expect the test to pass, etc. And tests can belong to multiple groups. So a single test might conceivably belong to the “user_authentication”, “API”, “smoke_test” and “in_development” groups. TestNG even supports groups of groups. I haven’t played with that personally, but it’s pretty bad-ass and their documentation on it is helpful.

TestNGgroups-1

 

 

 

 

 

 

 
(Caption: Quick pro-tip: TestNG doesn’t like it when you use a hyphen in group names. Use the underscore instead.) 

Of course, if your application’s super-structure doesn’t know about TestNG, you’ll get all sorts of errors and your builder won’t know what do with all those groups at runtime. So be sure to declare TestNG as a dependency for your project or module.

Using Groups in Bamboo Builds

Back in Bamboo, set up Jobs based on the groups you’ve defined in your test code. If you’re executing tests via Maven, Gradle or Ant, this is pretty trivial. In the example shown here, I pass a group name into Maven as an argument. When it’s time to run the tests, TestNG will scour my project, pull out all the tests belonging to that group, and run only those. Doesn’t matter if the tests for that group are located in different classes or packages. As long as they’re in the same project or module, TestNG will find them.

TestTaskConfigWithGroups

 

 

 

 

 

Note that because each Job has it’s own working build directory, you’ll need to pull the test code into each Job. A source code checkout Task is generally the simplest way to do that. If your code base is large, you can take advantage of the option to check out from a sub-directory in your repo and only pull down that part of the tree. Another option is pulling down all the test code in the very first Stage of your Plan, then zipping it up and passing that as an artifact to downstream Jobs.

Agents of Change

It’s probably obvious, but splitting your test suite into 10 batches isn’t going to help you much if you only have 1 or 2 build agents. Of course we’d love if everyone bought a Bamboo license that supports lots of agents so they can really take advantage of parallelization. Maybe that’s feasible for you, and maybe not. Either way, be mindful of your agent count when considering how to split up your test suite so you’re not just spinning your wheels.

You can take this idea of parallelized tests about as far as you want. There’s no restriction as far as TestNG or Bamboo is concerned. Many of our own CI builds have over 20 test groups running simultaneously. Again: you’re limited only by the number of build agents you’re running.

ParallelJobsJIRACI

 

 

 

 

 

 

 

 

 

 

(Caption: How do you run over 17,000 functional tests in less than an hour? Parallelization, baby!)

A Parallel Universe

As with most things in build engineering, there are several ways to accomplish parallelized testing. Tinkering with custom scripts or your suite.xml are two other common approaches. For big multi-module projects, it might make sense to split the suites/groups into separate repositories and run a Job for each repo. Regardless of which method you chose, you’ll get the most bang for your buck by focusing your parallelization efforts on integration-, API- and UI-level tests. Unit-level tests already run quite fast, so they’re unlikely to be the bottleneck in your builds. (Extra credit for the over-achievers: many testing frameworks allow you to run unit tests multi-threaded!)

If you’re new to test parallelization, congratulations on making it all the way through this blog! Check out our new automated testing resources page  for more helpful tips & tricks.

—–
Sarah Goff-Dupont is a former test automation engineer, and a fan of anything that makes life easier for the nerds. Like Continuous Integration and automation, for example. Because manual testing gets boring. Her heros include Margret Thatcher, MacGyver, and her mom.

Share

Running Automated Tests in Parallel (Part 1)

November 26th, 2012 by The Sauce Labs Team

This post was originally written by Alan Parkinson of Hindsight Software. One of Sauce’s authorized partners, Hindsight Software specializes in building tools and services around Selenium and test automation. It has been reprinted with his permission.

Automated functional tests provide valuable feedback to developers by notifying them when they have completed or broken functionality. The value of these tests can be maximised by providing the test results in the shortest possible time. The reason being the problem is likely to be fresh in the developer’s mind and quicker for them to fix.

A typical functional or UI test suite can take many hours to run because the tests can only be run sequentially. The main cause for the sequential tests is the dependence on data. Common practice has test cases clear the database of the application under test and populate it with the required data before it starts. This high level of database manipulation does not allow the tests to be run in parallel because each test will interfere with the database at different times, therefore corrupting data required used by other tests.

The common solution for long running test suites is to break them into batches and run each batch on a separate machine with its own instance of the application under test and its database. This is easy to achieve using spare hardware, Virtual Machine’s or Cloud computing resources. You don’t even have to write code for spinning up new machines, or access remote machines, as Continuous Integration (CI) servers like Jenkins and Bamboo provide functionality for running builds on multiple computers. This feature is better known as Slaves or Agents.

The majority of the popular testing tools have ways of grouping tests together and we can use this feature to create our “Batches” of tests. These features are known as “categories” in JUnit, “groups” in TestNG and “tags” in Cucumber, Lettuce and Behat.

To continue reading this post, jump over to the Hindsight blog

Share

The Eschaton: What The End Game Looks Like For Testing with Selenium

November 13th, 2012 by The Sauce Labs Team

This is the first in a series of posts by QAOnDemand, which offers self-service QA scripting and testing. For more info, visit http://qaondemand.com.

In theological circles, “The Eschaton” is defined as the end of time. In fact, there’s a whole field of study called Eschatology that studies what the end of the world looks like. While I have to believe their office parties are pretty grim, they’re definitely on to something. Visualizing the end result of what you’re building before ever laying down any foundation can lead to better decision-making, which is a key thing to keep in mind when setting up a mature testing environment for the first time.

To help you with this effort, I’ve devised a zombie readiness kit that includes how to set up the five key components for building a mature testing environment with Selenium:

  • A place to store your tests (source code repository)
  • A place to run your tests (Sauce Labs or a Selenium server)
  • A mechanism to trigger your tests (continuous integration server like Jenkins)
  • A place to log and track defects (a bug tracker like Bugzilla)
  • An army of human testers to test what cannot or has not yet been automated

While you can certainly test software without all five in place, it’s radically more productive with everything integrated and running smoothly. I’ll be diving into each component in more detail, so let’s get started with the guide!

A place to store your tests.

The Z: drive of your network is not a place to store tests. Neither is Dropbox. Your tests belong under source control. All of them. And by all, yes, I mean both manual test scripts and your test automation code.

There are many reasons why bringing your test assets under source control is a good idea, but here‘s the top 26:

A) Continuous integration servers are designed to pull from repositories. This means that if you put your test code in a well-organized repository, it’s relatively easy to configure your CI server to pull the latest copies from the repo and execute your tests automatically. Plus when a test fails, it’s also easy to take a quick look at your revisions to see if a recent change to the test code could be responsible for the failed test.

B) Products like the Atlassian suite are designed to broadcast repository activity. This is a good thing. Too often, QA gets a siege-like quality where we only come up from the dungeon when there’s a problem or free food. The truth is that by continuously broadcasting QA test results into the main communication streams of your company, you normalize the process of QA for everyone outside the group. QA test results become less of an interrupt and more routine. That’s a good thing and a worthy goal.

C-Z) Revision control. If your test code isn’t under revision control, then you’ve been living in the woods too long. You’s ignorant so listen up! If it’s worth doing, it’s worth keeping track of. The ability to trace changes over time is one of the most underrated tools out there. If something breaks and you’ve got to pop open the code, the first thing to look at is what has changed. Did the code change? Did the test change? With Git, CVS, SVN, Merc, whatever, you can easily see the evolution of your test code. It solves so many problems and enables so many good things such as skills development, accountability, and humility.

A place to run your tests.

You’re reading this on Sauce Labs‘ blog so this hardly needs mentioning, but there’s a nuance here worth talking about. One of the best qualities of Sauce Labs is the visibility it creates. The value in being able to rerun a test or capture a screenshot cannot be overstated. Whether you’ve provided a manual step-by-step set of instructions or you’ve provided a link to a screen cast, the first step in remediating a bug is to reproduce it and observe it in action. So if that “place to run your test” is “Joey’s Laptop,” then you’re going have a bad time. But if it’s a generally available service that anyone can access, it’s going to be a whole lot more fun.

A mechanism to trigger your tests

We see a lot of test teams “kicking off” tests manually. This is fine; there are lots of cases where you need to do this, but it’s waaaay better when a continuous integration (CI) server does this for you. Getting your CI to manage your test execution is tricky. Now I’d love to tell you there’s a simple script ./make-it-so.py, but alas, there is not. There are different types of builds, different deployment scenarios, and different types of check-ins that should fire off different types of tests.

But the net-net is that in the end, you want your QA process to be seamlessly integrated into the development process. And increasingly, CI drives development. Consider this question: In five years, is continuous integration and automated deployment going to be more or less prevalent? Is it going to be more common or less common? The answer is yes, so why bring up the rear of the parade? Get out in front. The sooner your QA process is wired into your CI, the easier it’ll be in the end.

A place to log and track defects

I’m going to move quickly through this point because most of you probably have this at some level. The one feature I’ve seen in the last few years that’s really been a huge boon to development is tying tickets to checkins, such that you can see the code that is related to the ticket. This makes it infinitely easier to quickly find the business requirements associated with a ticket and cross-reference it to the code itself. If you can tie your test code to tickets in a similar fashion, it’s so much the better because you’ve created visibility for both the created tests and related revisions. I highly recommend you select bug-tracking software that does this. It’s absolutely worth every expense.

An army of human testers to test what can’t (or has yet to be) automated

In its heart of hearts, quality assurance is a request for an opinion that is inescapably a human observation. “Does it work as you expect?” can sometimes be described in a way that can be automated. Sometimes it can be described in a way that a tester with nominal knowledge of the system can test. Sometimes it takes a domain expert to tell if something works as expected.

The point is, human testing always has been and always will be a part of QA. Anyone who says it can be completely automated is either an academic or a fool. So plan for it and work towards an end game that uses human testers in a productive and efficient way. We think it’s helpful to break up the problem of organizing human-based QA work into three buckets using the following guidance.

  • a) Automate the simple stuff that’s easy to maintain or is tedious. Automate the routine stuff that won’t break often, but when it does, it’s catastrophic. There’s no shortage of people who will tell you that with a good framework and their secret sauce, you can automate everything. You can’t. And more importantly, it’s not worth it. Automation is fundamentally an economic problem, not an engineering problem. You should only automate that which the cost of automation is meaningfully less than the cost of just running the check repeatedly by hand when needed. The bottom-line? Don’t get dragged into complex automation strategies. Automate the simple routine stuff in a simple and routine way.
  • b1) Outsource the intermediate stuff, such as layout, copy writing, new features, and regressing fixes on a well-defined but complex bug. Outsourcing works great where cultural nuance, domain expertise and a qualified point of view don’t matter all that much. The overhead is much lower than it used to be and in the sage words of Eric S. Raymond: “Given enough eyeballs, all bugs are shallow” .
  • b2) Outsource the creation of simple automation — you know, like writing your Sauce Labs tests. Just sayin’. When a well-defined bug gets checked, have an outsourced team write an automated test to check it again. Test harnesses with a thousand tests get built one test at a time. ***
  • c) Use your domain experts as big guns. Focus them on the hard stuff – subtle features that require an understanding of how the code works or how a customer sees the world. If your in-house QA engineers are testing to see if your upload feature correctly kicks out an error for oversized files or disallowed formats, then you are wasting valuable expertise. Again, it’s helpful to think about testing as an economic problem and price your top talent. Give your top dogs a fully loaded cost and socialize the notion that it’s not a few hours, it’s a few dollars. Remind people of what they’re asking for in economic terms – that a detailed, cross-browser, multi-platform manual test by your in-house team is easily a $1,000 request. A simple question to posit: “Is that the best way to spend $1,000?”

So, what now?

In conclusion, take time to work through your endgame. Almost all QA work is time-bound, meaning we all work as hard and as fast as we can testing until the clock runs out. If nothing explodes during testing, we ship. It’s not fair, but that’s the way it is. So if you don’t block off some time each cycle to build toward a better way of doing things, then you’re selling yourself and your team short. Hopefully this post gave you a little perspective on what that end-game could look like.

In the next post, we’ll get into specifics of some of the tools we’ve found to be most helpful and more specifics about what works for us.

*** Look, QAOnDemand basically does B1 and B2 for a living. We see a lot of people’s QA efforts. Our services are structured and priced to make it easy for you to say yes to modest outsourcing. We’ll knock out your intermediate testing without crushing you with a big contract or a lot of overhead. Plus we offer a decent free trial with no strings attached, so give it a go. We’ll also bootstrap your Sauce Labs environment for you if you haven’t done so already. It’s much easier to add to a working system once it’s set up correctly. Net-net, a little help in the beginning goes a long way. Ok, ’nuff said.

Share

Testing Your Mobile Apps with Behat & Sauce (Pt. 2)

October 31st, 2012 by Shashikant Jagtap

This is a guest blog post by Shashikant Jagtap. It is the second post in a 2-part series on configuring Behat with Selenium and Sauce to test mobile devices. Part 1 is here. You can read more about the author here.

Last week, I did a guest post that talked about some of the great new additions to latest release of Behat and how to integrate that with Sauce. In this part of the blog series, we’ll cover mobile test automation in the cloud using Apple Sauce and Android Sauce with Behat. Let’s get started!

Create Your Sauce Account

So far, we have successfully implemented features to run locally in a browser. Now it’s time to add some Sauce to it. First, you’ll need to sign up for a Sauce Labs account. Once you’ve done that, you will see your own personal Sauce USERNAME and SAUCE-ACCESS KEY [SAUCE-API-KEY] on your account page, which we’ll use to configure the Behat tests with Sauce Labs.

Sauce Connect [Composer]

Before we continue, we should figure out with we’re testing internal application. If yes, then we need to use ‘Sauce Connect‘.

During the set up process covered in the last post, we downloaded Sauce Connect and Sauce-Config with Composer. It should be in the ./bin directory. Assuming that you have made Sauce-Config and Sauce Connect global, you can configure your account with Sauce Connect as follow:

$ sauce_config YOUR-SAUCE-USERNAME YOUR-SAUCE-API-KEY
Successfully configured Sauce to use account YOUR-SAUCE-USERNAME
$ sauce_connect

This will launch Sauce Connect, which tests your internal applications by reading your local configuration.

You can also start Sauce Connect using the following command once you have downloaded the jar file:

java -jar Sauce-Connect.jar YOUR-SAUCE-USERNAME YOUR-SAUCE-API-KEY

Note: We don’t need Sauce Connect for this tutorial as we are testing live websites.

In order to run Behat Tests on iOS and Android devices, we need to create profiles and run tests with those. Mink Extension has Selenium 2/WebDriver, which prvides different capabilities. Selenium 2/WebDriver for Mink has three options:

  • Browser: Here you can specify the ‘desiredCapabilities’ of the webdriver eg. iPhone, iPad, Android, Safari, etc.
  • wd_host: Here you have to provide your Sauce credentials, such as your username and API key e.g SAUCE-USERNAME:SAUCE-API-KEY@ondemand.saucelabs.com/wd/hub
  • capabilities: Here you can define the platform and version of the device. You can use Sauce Capabilities here e.g {  “platform”: “Mac 10.8″, “version”: “6″}

The list of supported Browsers, OS, Devices can be found on SauceLabs’ Available Browsers page. You need to select ‘webdriver’ and ‘php’ code from the dropdown in order to see which combinations are supported for PHP and Behat.

iPhone Sauce:

In order to run test on iPhone, we need to create the ‘iPhone’ profile in the ‘behat.yml.’ Just paste the following code into your ‘behat.yml.’ We need to set the browser parameter to ‘iPhone’ and add the Sauce credentials in the ‘wd_host’ parameter. We also need to select the proper ‘platform’ and ‘version’ combination from ‘capabilities.’

iPhone:
  context:
    class:  'FeatureContext'
  extensions:
    Behat\MinkExtension\Extension:
     selenium2:
      browser: iphone
      wd_host: SAUCE-USERNAME:SAUCE-API-KEY@ondemand.saucelabs.com/wd/hub
      capabilities: { platform:Mac 10.,version: 6}

Now, run your test with ‘iPhone’ profile like this

$ behat -p iPhone

You can see the job running live on Sauce Labs if you visit your account page. Watch the video of this test on Sauce Labs.

iPad Sauce

In order to run test on an iPad, we need to create the ‘iPad’ profile in the ‘behat.yml.’ Just paste following code into your ‘behat.yml.’

iPad:
  context:
    class:  'FeatureContext'
  extensions:
    Behat\MinkExtension\Extension:
     selenium2:
      browser: iPad
      wd_host: SAUCE-USERNAME:SAUCE-API-KEY@ondemand.saucelabs.com/wd/hub
      capabilities: { platform: Mac 10.8,version: 6}

Now, run your test with the ‘iPhone’ profile like this:

$ behat -p iPad

You will see the job running on Sauce Labs. Watch the video of this test on Sauce.

Android Sauce

 

 

In order to run test on Android, we need to create an ‘Android’ profile in the ‘behat.yml’. Just paste following code into your ‘behat.yml’.

Android:
  context:
    class:  'FeatureContext'
  extensions:
    Behat\MinkExtension\Extension:
     selenium2:
      browser: android
      wd_host: SAUCE-USERNAME:SAUCE-API-KEY@ondemand.saucelabs.com/wd/hub
      capabilities: { platform:Linux,version:4}

Now, run your test with the ‘Android’ profile like this:

$ behat -p Android

You will see the job running on Sauce Labs. Watch the video of this test on Sauce.

Generating HTML reports

Create an empty directory called ‘report’ to store reports generated by Behat.

$ behat -p iPhone -f html --out report/report.html

This will generate a nice looking HTML report in the ‘reports’ directory that looks like this:

Build Features With Apache ANT 

We can run all the feature files in one go using a build tool called ‘Apache ANT‘. You need to install it using the installation guild on ANT documentation. Next step is to create ‘build.xml’ file into your project. Copy build.xml from GitHub. You can now run all the features using the command:

$ ant SaucyBehat

Source Code and Usage on Github

If you have any issues while setting up Behat with Sauce Labs, be sure to check out the source code with build script on GitHub. The source code is in a repository called ‘SaucyBehat-iOS-Android‘, and there is documentation on how to use this repository in the README file.

Summary of Steps

  • Clone Repository
$ git clone git@github.com:Shashikant86/SaucyBehat-iOS-Android.git
$ cd SaucyBehat-iOS-Anroid
  • Download Composer
$curl http://getcomposer.org/installer | php
$php composer.phar install
  • Update ‘behat.yml’ with YOUR-SAUCE-USERNAME YOUR-SAUCE-API-KEY
  • Run Selenium Server if you wish to tests locally. Don’t need to run selenium to run tests on Saucelabs.
  • Execute build to run all tests using Apache ANT
$ant SaucyBehat

Watch the Video Demo on Youtube.

Final Thoughts

Mobile test automation, while challenging, is becoming a bit easier and simpler with the help of Behat, Mink Extension and Sauce Labs. Dependency management using Composer makes our life easy while handling third-party repositories and simple configurations in Behat make it possible to run our BDD features on mobile devices with help of WebDriver’s desired capabilities. As of this poisting, we are adding Sauce’s Capabilities to Mink Extension. Stay tuned for more exciting stuff related to Behat and Sauce Labs!

LINKS & RESOURCES

Source Code on Github : SaucyBehat-iOS-Android
Video Demo on Youtube :  Behat Installation & iOS-Android -Saucelabs Demo
Behat Official Documentation : Behat Docs
Sauce Labs Documentation PHP : Getting Started with PHP and Webdriver
My Blog :  Let’s BDD PHP
About Me: SHASHIKANT JAGTAP

Share

Testing Your Mobile Apps with Behat & Sauce Labs (Pt. 1)

October 26th, 2012 by Shashikant Jagtap

This is a guest blog post by Shashikant Jagtap. You can read more about the author here.

Hope you enjoyed my last post ‘Adding Sauce To Behat‘, which covered the basics of Behat and BDD . This is a follow up post, as Behat has changed drastically since then.

Behat is an amazing BDD framework for PHP applications. It recently added some great new capabilities, including the use of Composer and Behat Extensions. Composer is a dependency management system for PHP applications that helps us manage all the third party dependencies in one place. Another great feature Behat added is ‘Behat Extensions’, which lets you extend Behat by adding extensions of your choice. MinkExtension is one such extension that software QA engineers can use effectively, and it has everything we need to configure the features of Sauce Labs into it.

Mobile Test Automation + Sauce Labs + Behat

Sauce Labs announced support for iOS and Andriod devices in August, allowing the Behat community  to enjoy the benefits of Apple and Android Sauce. Mobile automation testing is more challenging than web applications and desktop applications testing because mobile apps are new in the market and don’t have proper industry standards yet. Mobile applications tend to lack proper automation tools and infrastructures for a variety of the mobile devices out there.

One of the major issue in mobile automation is setting up an environment  for mobile devices, which usually requires a high level of QA and infrastructure skills. Sauce Labs solved most of the these problems by providing cloud support for mobile automated testing, so this post will explain some great new features of Behat 2.4 (part 1 of this blog series) and its integration with Apple Sauce and Android Sauce (part 2).

Let’s start with the Behat installtion.

Remove previous Behat installation [Pear]

In the last post about Behat, we installed Behat with ‘pear’ packages. The Behat version installed with pear packages is no longer supported so be sure to read the Behat installation guide for further information. Now, let’s uninstall the old version of Behat and install a new one. Open your terminal and type in the following commands.

Check your existing installation with this:

$ which behat

If you installed Behat with the pear package, you will see something like this:

$ which behat
/usr/local/pear/bin/behat

Remove this Behat vesion by running:

$ sudo pear uninstall behat/behat
uninstall ok: channel://pear.behat.org/behat-2.3.5
$ sudo pear uninstall behat/gherkin
uninstall ok: channel://pear.behat.org/gherkin-2.1.1

Remove ‘Mink‘ too, as we are going to use ‘MinkExtension’:

$ sudo pear uninstall behat/mink
uninstall ok: channel://pear.behat.org/mink-1.3.3

Behat 2.4 installation [Composer]

Now that we have removed the old version of Behat, we won’t find anything in binary when you execute the ‘behat’ command:

$ behat
-bash: /usr/local/pear/bin/behat: No such file or directory

Now create a new Behat installation directory. Here we have ‘/opt/behat’ directory with all the permissions.

 $ sudo mkdir /opt/behat
$ cd /opt/behat/
$ sudo chmod -R 777 /opt/behat/

Composer.json

Create the ‘composer.json’ file inside ‘/opt/behat’ and add all the third-party libraries, packages, dependencies into it like this:

$ sudo vi composer.json

Add the following dependencies in the json file (you can add more as per your project requirements). You can find more packages on the Packagist website:

{
"require": {
"behat/behat": "2.4.*@stable",
"behat/mink": "1.4@stable",
"behat/mink-goutte-driver": "*",
"behat/mink-selenium-driver": "*",
"behat/mink-selenium2-driver": "*",
"behat/mink-extension": "*",
"sauce/sausage": ">=0.5",
"sauce/connect": ">=3.0"
}, "minimum-stability": "dev", "config": { "bin-dir": "bin/" } }

Note that we have included packages for Behat, Mink, and Mink drivers such as Selenium & WebDriver. We have also included the MinkExtension and Sauce Connect packages in order to use them in the projects. MinkExtension creates Mink instances in each sub-context or it could be used as a subcontext on its own. You can read more about it on the MinkExtension documentation page. We will demonstrate how to use MinkExtension and Sauce Connect later in this post.

The next step is to download composer.phar file consisting of all the above packages. Let’s do that with the following commands:

$ curl http://getcomposer.org/installer | php
$ curl http://getcomposer.org/installer | php
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
Dload  Upload   Total   Spent    Left  Speed
100 11038    0 11038    0     0  88692      0 --:--:-- --:--:-- --:--:--  307k
#!/usr/bin/env php
All settings correct for using Composer
Downloading...

Composer successfully installed to: /opt/behat/composer.phar
Use it: php composer.phar

This will download ‘composer.phar’ file, but let’s confirm with this:

$ ls
composer.json    composer.phar

Now install it using the following command:

$ php composer.phar install

This will download all the dependencies. You can see it in the ‘Behat’ directory. Once it has finished downloading, your directory should look like this:

$ ls
bin        composer.json    composer.lock    composer.phar    vendor

It will also create a composer.lock file that will contain the list of installed packages and their associated versions and vendor/autoload.php file that can be used to autoload all the dependencies in your project. You should now be able to use any class from your installed packages. Now, you are ready to run Behat using ‘./bin/behat’ command.

$ ./bin/behat

Don’t forget to make ‘./bin’ directory executable so that we can execute all the binary from outside:

$ cd /opt/behat
$ sudo chmod -R 777 bin/

Access Behat Locally

You can now access Behat locally from where you downloaded composer. OR you can make it global.

$ ./bin/behat

Check the Behat version:

$ ./bin/behat --version
Behat version DEV

Make Behat Global

Now, let’s create a global symlink to access Behat from anywhere.

$ sudo ln -s /opt/behat/bin/behat /usr/local/bin/behat

Make Sauce Connect Global

You can also run Behat and sauce_config, sauce_connect from anywhere. It completes the Behat2.4 installation process.

 $ sudo ln -s /opt/behat/bin/sauce_config /usr/local/bin/sauce_config
$ sudo ln -s /opt/behat/bin/sauce_connect /usr/local/bin/sauce_connect

Note: You may need to restart your terminal session to get the newest version. 

$ which behat
/usr/local/bin/behat

If you had any trouble with the previous commands, watch the video demo of the Behat installation with Composer on Youtube.

Creating Our Behat Project

Now, let’s create our first Behat project by running the following commands.

 $ sudo mkdir SaucyBehat
$ sudo chmod -R 777 SaucyBehat
$ cd SaucyBehat
$behat --init
+d features - place your *.feature files here
+d features/bootstrap - place bootstrap scripts and static files here
+f features/bootstrap/FeatureContext.php - place your feature related code here

Behat has already created a ‘features’ directory to write feature files. We need to implement the step definitions in auto-generated ‘feature/bootstrap/FeatureContext.php’ file. Let’s first create a feature file to check Sauce Labs features:

 $ sudo vi Sauce.feature

Add the following feature:

Feature: SauceLabs Documentation
In order to learn SauceLabs features
As a Software Tester
I need to see resources
@javascript
Scenario: Access feaures
Given I am on "/"
When I follow "Features"
And I saw page loaded
Then I should be on "/features"
And I should see "Check out our features."

We also need to create a configuration file called ‘behat.yml’ in the project root directory. It should use MinkExtension. Let’s create ‘default’ profile to run tests locally:

default:
  context:
   class:  'FeatureContext'
  extensions:
   Behat\MinkExtension\Extension:
    base_url:  'http://saucelabs.com'
    javascript_session:  'selenium2'
    goutte:              ~
    selenium2:

We have now created a ‘default’  profile, which uses the Context ‘FeatureContext.php’ and the Extension called ‘MinkExtension. Mink Extension provides different drivers such as Selenium,  Selenium2 [WebDriver] etc. We have used ‘Selenium2′ driver to run tests. Read more about MinkExtention here or watch it on GitHub.

Now, we need to update ‘feature/bootstrap/FeatureContext.php’ to use ‘MinkExtension’. In order to do this, we need to extend the file to ‘Behat\MinkExtension\Context\MinkContext’ instead of ‘BehatContext’. First we need to  delete all the code from unnessesary code from FeatureContext File. Now, it should  look like this:

/**
* Features context.
*/
class FeatureContext extends Behat\MinkExtension\Context\MinkContext
{
}

We are set to run the Behat feature locally.  Now we need to download the Selenium Server and run it in the background.

$ /path/to/seleniumjar/ java -jar selenium-server-standalone-2.25.0.jar

Let’s run ‘Behat’ from the root of the project. (Remember you always have to run ‘behat’ from root project directory unless you provided PATH in ‘behat.yml).

 $ behat

You can see test running in the browser. It will complain about the ‘UnDefined’ step, which Mink didn’t understand. We need to copy that code snippet and implement it in the FeatureContext.php file using clean MinkApi’s. Here is the implemented step to get the feature working. Now, FeatureContext.php file will look like this:

 /**
* Features context.
*/
class FeatureContext extends Behat\MinkExtension\Context\MinkContext
{
/** * @Given /^I saw page loaded$/ */
public function iSawPageLoaded()
{
$this->getSession()->wait("5000", "document.getElementById('pricing-table')");
}
}

Now if you run the Behat command again, you will see that the tests passed like this:

Feature: SauceLabs Documentation
In order to learn SauceLabs features
As a Software Tester
I need see resource
@javascript
Scenario: Access feaures         # features/Sauce.feature:7
Given I am on "/"                # FeatureContext::visit()
When I follow "Features"         # FeatureContext::clickLink()
And I saw page loaded            # FeatureContext::iSawPageLoaded()
Then I should be on "/features"# FeatureContext::assertPageAddress()
And I should see "Check out our features."# FeatureContext::assertPageContainsText()

1 scenarios (1 passed)
5 steps (5 passed)
0m35.164s

And that’s it! In part 1 of this tutorial, we covered, Behat, Sauce Connect, Mink, installing Selenium with Composer and running Behat tests in local browsers. In part 2, we will learn how to run Behat tests on Mobile devices using Sauce Labs.

Share

Testing GitHub’s Wiki in the Cloud

June 4th, 2012 by The Sauce Labs Team

This is a guest blog post by Matthew of Bootstrap Online LLC. Matthew is a volunteer committer on Gollum, the Git powered wiki used on GitHub.com. Checkout Matthew’s GitHub profile and hire him to work on your open source project.

Gollum is GitHub’s open source wiki software used by GitHub.com, Nature, and others. Gollum uses Selenium 2 WebDriver with JUnit 4 (Java) to test its live preview feature, which requires a real browser. The WebDriver tests can be run locally with ChromeDriver for development, and are automatically executed by Travis-CI using ChromeDriver.

The first version of live preview used window.location.origin, which is undefined on Firefox. Fixing the issue was not difficult, but the tests should have caught the problem. The previous testing strategy for live preview consisted of waiting for users to report bugs. In one issue, a user said that if live preview was not properly tested, it would be removed from the wiki software. Clearly something had to be done and I emailed Sauce Labs for help.

Sauce Labs’ Cloud enables testing across a variety of browsers. Following the Sauce documentation produces sequential tests using one file per operating system and browser combination. Three operating systems (Windows Server 2003, Windows Server 2008, Linux) each with two browsers (Firefox, Chrome) means six files.

JUnit’s parameterization feature enables consolidating all of those tests into one. The problem with the default parameterization implementation is that the tests are named using only numbers. This makes identifying which test failed difficult. Parallel-webtest, previously on the Sauce blog, created DescriptivelyParameterized, which enables meaningful test names while still using parameters.

To run the tests in parallel, parallel-webtest provides a ParallelRunner that extends DescriptivelyParameterized. Running cross browser parameterized tests in parallel is not helpful unless you have more than one browser to test on. I could either setup a local cloud, which realistically was not an option, or use a hosted cloud to run the tests. Leveraging Sauce Labs’ OnDemand service enabled Gollum’s tests to complete in nearly 40 seconds when run in parallel. Without the hosted cloud option, I would not have been able to easily run the tests across different environments.

As tests run in the cloud, the results (success or failure) must be reported. I accomplished this by using behrica’s test watcher and saucerest-java. The finished Gollum tests now work on three environments – local, Travis-CI, & the Sauce Cloud – with no duplication of test logic. The code is available on GitHub.

Share

Getting Started With Web Testing Using Selenium & Sauce Labs

February 9th, 2012 by Will Iverson

This is a guest blog post by Will Iverson, David Drake, Osama Khalaf, and Adam Herbst of Dynacron Group, a technology consulting firm based outside Seattle that provides software development (Java/.NET) and BI/DW services based on Continuous Delivery.

Dynacron Group staff started working with Selenium nearly four years ago. The biggest problem we had was execution time – we had a limited number of browsers and during launches, test & release jobs would start to pile up as we were waiting for the limited browsers in our homebrew Selenium grid to be available.

To solve that problem for a new project we started almost a year and a half ago, we decided to use Sauce Labs. To make it as easy as possible for the test team, we created a parallel execution framework to make it dead easy to run the tests, and a template project to make it dead simple to get started.

By standardizing the parallel execution framework and template project, a tester can pretty much just sign up with Sauce Labs, follow a few basic configuration steps, and start writing test suites that leverage parallel execution in no time. Most people start with the Selenium Recorder, just pasting commands in from the clipboard to start and then pretty quickly graduate to just writing stuff in their IDE of choice.

Let me explain why parallel execution is so cool: we write 200 tests. We run those tests in parallel across five browsers (Firefox, Chrome, Safari, and two versions of Internet Explorer). That’s a thousand tests. If we ran those serially, one after the other, it would take the better part of a day. By running fifty parallel browsers, we can finish that test suite in fifteen minutes.

The Sauce Labs site can give you an overview of the other awesome features (recording video of every job, step-by-step screenshots, and Sauce Connect to name a few) – but nothing is as nice for us as the time-to-market advantage.

For more information, check out:

Tutorial

Just download this tutorial and follow the instructions to get started.

webtest-quickstart

Webtest Quickstart is the template project. This is where you’ll want to go to get started quickly.

If you’re just starting on a new Selenium test project, you might consider using JUnit to manage your test cases. The webtest-quickstart project can provide a simple starting point for importing your IDE tests into JUnit and running them in maven.

To get started, just download the the webtest-quickstart project from github, or use the maven archetype from the same site. Inside the project, you’ll find sample test cases for many different testing situations. There are samples for running tests against a site running on your computer, or against websites on your network. Best of all, the parallel-webtest library gives you the ability to easily configure how tests are run. The project pom has sample profiles for running your tests in your own browser or in several different Sauce browsers in parallel, all from the same test code.

parallel-webtest

Parallel Webtest is the library that handles the parallel execution & configuration.

At its heart is a JUnit base test class that manages the browser lifecycle. It configures and launches the browser before executing a test class, and cleans it up afterwards. This isolates the test code, promoting cleaner test methods. Browser selection and parallel configuration are handled with a few configurable system properties; the same test code can be run in serial or parallel, locally or remotely, against one browser type or many. As a result, a test suite that once took four hours to run can be finished in as little as fifteen minutes using the same build server.

The webtest-quickstart and webtest-quickstart-archetype are open-source. Both are available on Dynacron Group’s Github account. If you have a chance to try it out, let us know what you think at info@dynacrongroup.com. And happy (faster) testing!

Share