We’ve just released our new platform configurator that easily generates the code you need to configure your automated tests to run on Sauce. You can select the automation API, device type, operating system, and browser version you want to test with, and it will automatically generate a snippet of code for those desired capabilities. You can toggle between code generated for different languages. (more…)
Posts Tagged ‘selenium’
We’re excited to be releasing support for testing on Chrome and Firefox beta and dev versions for Mac OS X, Linux, and Windows. The beta and dev versions are available for both automated and manual testing. And to give you access to new platforms as quickly as possible, we’ll continue to add support for bleeding edge versions the day they’re released. (more…)
HomeAway, Inc. is the world’s leading online marketplace for the vacation rental industry. With over one million live vacation rental listings in 190 countries paired with a family of 50 websites and hundreds of applications thanks to a series of acquisitions, quality is their top priority. To get ahead of the curve, Carl’s team is trying to automate and use best practices like continuous integration as much as possible. We were also thrilled to hear that they’re using Appium, a cross-platform test automation framework powered by Sauce Labs, for their mobile testing. Carl also says Sauce fits perfectly into their testing process.
Watch the video below to learn more about their path towards continuous delivery, and how Sauce fits into that story.
The Selenium Conference is a volunteer-run, non-profit event presented by members of the Selenium Community. The goal of the conference is to bring together Selenium developers & enthusiasts from around the world to share ideas, socialize, and work together on advancing the present and future success of the project.
“Recently at Sauce Labs we decided to retool our documentation system. This decision came after accumulating docs in a number of template systems and repos which were difficult to standardize and maintain. The result of this effort was a new markdown-based docs site available at docs.saucelabs.com.”
For all the details, be sure to check out Chris’ post – just click the image below to view.
Want to contribute to Sauce Labs’ documentation? In the spirit of open source, we’ve housed them in GitHub. Submit away.
On Saturday, August 2nd, we will update our Selenium and Chrome default versions to meet current, stable implementations. This update affects users that run automated Selenium tests on Sauce.
Default versions of Selenium and Chrome are used only for tests that don’t have a specified browser version. Users who choose to assign Selenium and Chrome versions to their tests will remain unaffected.
Below you’ll find more details about the updates.
Currently the default Selenium version is 2.30.0. Following the update on August 2, the new default Selenium version will be 2.42.2. We advise you to test the new version (2.42.2) in advance using the following desired capability:
If you run into any issues with the new default, note you can continue using the previous version (2.30.0) after Saturday by making the test request the selenium-version desired capability referred to below:
Currently the default Chrome versions are Chrome 27 and Chromedriver 1. Following the update on August 2, the new default Chrome versions will be Chrome 35 and Chromedriver 2.10. We advise you to test the new versions (Chrome 35, Chromedriver 2) in advance using the following desired capabilities:
"browserName": "chrome" "version": "35"
By requesting Chrome 35, Chromedriver 2.10 will be used automatically.
If you run into any issues with the new default, you can continue using the previous versions (Chrome 27, Chromedriver 1) after Saturday by making the test request the “version” desired capabilities referred to below:
"browserName": "chrome" "version": "27"
If you see any issues after moving your tests to these new versions, we suggest checking for known issues on https://code.google.com/p/selenium/issues/list or contacting the Chromedriver and Selenium user groups.
We sat down with Senior QA Manager Sage Rimal to hear how they use Sauce Labs at Campus Explorer. Sage shared how they’ve automated their tests on Sauce, and have since reduced their testing time from 72 hours to 72 minutes.
Watch the video below to get the latest!
Want to share your story? We want to hear from you! Submit a request here.
Last year Sauce Labs cofounder Jason Huggins was part of the tech surge team of advisors who worked to fix the site and home of “Obamacare” through the power of test automation. He’s decided to take another leave of absence from Sauce to help the Ad Hoc and the Marketplace 2.0 teams to further this great cause.
Here’s what Jason had to say about the state of the government and automation:
Long term, government needs to get better at software development, including test automation. For now, the best way to fight that fight is by example. If the Marketplace 2.0 team can help the government avoid last year’s drama when open enrollment begins again in October, then we’ll have a good story to share with other departments and agencies. But if we get a repeat of last year, then it’ll be a lot harder to convince government officials to change their ways.
-Jason Huggins, June 23, 2014
While we’ll miss him around the office, we’re confident this is a worthy cause.
This is the first of a three part series by Matthew Heusser, software delivery consultant and writer.
Every now and again and opportunity comes along that you just can’t refuse. Mine was to teach the one-day version of my class, lean software testing, in Madrid, Spain, then again the following week in Estonia. Instead of coming back to the United States, I’ll be staying in Europe, with a few days in Scotland and a TestRetreat in the Netherlands.
And a lot of time on airplanes.
The folks at Sauce Labs thought I might like to take notes and type a little on the plane, to share my stories with you.
The first major hit in Madrid is the culture shock; this was my first conference where English was not the primary language. The sessions were split between English and Spanish, with translators in a booth making sure all talks were available in all languages.
The Testing Divide
Right now, in testing, I am interested in two major categories: The day to day work of testing new features and also the work of release-testing after code complete. I call this release testing a ‘cadence’, and, across the board, I see companies trying to compress the cadence.
My second major surprise in Madrid is how wide the gap is —and I believe it is getting wider —between legacy teams that have not modernized and teams starting from scratch today. One tester reported a four-month cycle for testing. Another team, relying heavily on Cucumber and Selenium, were able to release every day.
Of course, things weren’t that simple. The Lithuanian team used a variety of techniques I can talk about in another post to reduce risk, something like devOps, which I can talk about in another post. The point here is the divide between the two worlds.
Large cadences slow down delivery. They slow it down a lot; think of the difference between machine farming in the early 20th century and the plow and horse of the 19th.
In farming, the Amish managed to survive by maintaining a simple life, with no cars, car insurance, gasoline, or even electricity to pay for. In software, organizations that have a decades-long head start: banks, insurance companies, and pension funds, may be able to survive without modernization.
I just can’t imagine it will be much fun.
Batches, Queues and Throughput
Like many other conferences, the first day of ExpoQA is tutorial day, and I taught the one-day version of my course on lean software testing. I expected to learn a little about course delivery, but not a lot —so the learning hit me like a ton a bricks.
The course covers the seven wastes of ‘lean’, along with methods to improve the flow of the team – for example, decreasing the size of the measured work, or ‘batch size’. Agile software development gets us this for free, moving from ‘projects’ to sprints, and within sprints, stories.
In the early afternoon we use dice and cards to simulate a software team that has equally weighted capacity between analysis, dev, test and operations —but high variability in work size. This slows down delivery. The fix is to reduce the variation, but it is not part of the project, so what the teams tend to do is to build up queues of work, so any role never runs out of work.
What this actually does is run up the work in progress inventory – the amount of work sitting around, waiting to be done. In the simulation I don’t penalize teams for this, but on real software projects, ‘holding’ work created multitasking, handoffs, and restarts, all of which slow down delivery.
My lesson: Things that are invisible look free —and my simulation is far from perfect.
After my tutorial it is time for a conference day – kicked off by Dr. Stuart Reid, presenting on the new ISO standard for software testing. Looking at the schedule, I see a familiar name; Mais Tawfik, who I met at WOPR20.Mais is an independent performance consultant; today she is presenting on “shades of performance testing.”
Performance Test Types
At the end of her talk, Mais lists several scenarios and asks the audience what type of performance test would blend efficiency and effectiveness. For example, if a release is entirely database changes, and time is constrained, you might not execute your full performance testing suite/scripts, but instead focus on rerunning and timing the database performance. If the focus on changes is the front end, you might focus on how long it takes the user interface to load and display.
When Mais asks if people in the organization do performance testing or manage it, only a handful of people raise their hands. When she asks who has heard of FireBug, even less raise their hand.
Which makes me wonder if the audience is only doing functional testing. If they are, who does the performance testing? And do they not automate, or do they all use Internet Explorer?
The talk is translated; it is possible that more people know these tools, it was just that the translator was ‘behind’ and they did not know to raise their hands in time.
Time For A Panel
At the end of the day I am invited to sit on a panel to discuss the present (and future) of testing, with Dr. Reid, Dorothy Graham, Derk-Jan De Grood, Celestina Bianco and Delores Ornia. The questions include, in no particular order:
- Will testers have to learn to code?
- How do we convince management of the important of QA and get included in projects?
- What is the future of testing? Will testers be out of a job?
- What can we do about the dearth of testing education in the world today?
For the problem with the lack of education, Dorothy Graham points to Dr. Reid and his standards effort as a possible input for university education.
When it is my turn, I bring up ISTQB The International Software Testing Qualifications Board. – if ISTQB is so successful (“300,000 testers can’t be wrong?”) then why is the last question relevant? Stefaan Luckermans, the moderator, replied that with 2.9 Million testers in the world, the certification had only reached 10%, and that’s fair, I suppose. Still, I’m not excited about the quality of testers that ISTQB turns out.
The thing I did not get to say, because of time, that I want to do is point out that ISTQB is, after all, just a response to a market demand for a 2-3 day training certification. What can a trainer really do in 2-3 days? At most, maybe, teach a single technical tool, turn the lightbulb of thinking on, or define a few terms. ISTQB defines a few terms, and it takes a few days.
The pursuit of excellent testing?
That’s the game of a lifetime.
By Matthew Heusser – email@example.com for Sauce Labs
Stay tuned next week for part two of this mini series! You can follow Matt on Twitter at @.
Have an idea for a blog post, webinar, or more? We want to hear from you! Submit topic ideas (or questions!) here.