August 23rd, 2016 by Chris Riley
Ashley Hunsberger, Greg Sypolt and Chris Riley contributed to this post.
Bringing test automation into your organization is not as easy as writing and running a Selenium script. It involves first getting buy-in, building a team, establishing a strategy, and picking the right tools. During the Q&A portion of a recent webinar hosted by Chris Riley, Ashley Hunsberger, and Greg Sypolt, the presenters realized that these aspects of introducing test automation are well known, but not well understood. In our first post of the series we discussed getting buy-in. Below, in the second post, we discuss how to build a test automation strategy.
Getting started with test automation is easy. If you have a technically minded QA team, you can usually create your test script, sign up for a test cloud, and run the script in just a few hours. But keeping a test automation environment going for the long term is not as easy as any of us would like to believe. QA teams are generally better at building strategy than any other. And when it comes time to build a test automation environment, strategy is a key first element to both getting started and keeping it going. Read the rest of this entry »
August 18th, 2016 by Alex Entrekin
There is no way to directly get HTTP status codes in the WebDriver API (see the lengthy discussion in issue #141). But that doesn’t mean you have to leave Selenium or go without any status codes in your test scripts.
In fact, some of the supported methods – proxies and tightly coupled headless browsers – should make you feel at home if you’ve transitioned from Selenium RC, or are comfortable with traffic sniffing proxies.
Headless Scriptable WebKits that Play Nicely with Selenium
But if you are, use GhostDriver to enable PhantomJS as WebDriver’s backend. Read the rest of this entry »
August 16th, 2016 by Chris Riley
Ashley Hunsberger, Greg Sypolt and Chris Riley contributed to this post.
Bringing test automation into your organization is not as easy as writing and running a Selenium script. It involves getting buy-in, building a team, establishing a strategy and picking the right tools. During the Q&A portion of a recent webinar hosted by Chris Riley, Ashley Hunsberger, and Greg Sypolt, the presentation team realized that while each aspect is well known, it is not well understood. And that is why in this four-part blog post series, we are going to address each one. This post, the first of the series, discusses getting buy-in.
The need and high-level direction for test automation is usually driven by those who do. In an ideal scenario, both the doers and the decision-makers come to the conclusion together that faster, more repeatable testing is more than just a cost-saver. It supports the initiatives of moving modern development practices forward.
But this is not the reality. Those who know what is possible need to sell the idea from the bottom up. For QA, there are many challenges to doing this: (1) QA teams often do not have their own budget; (2) you are not just convincing development leadership, you are convincing your peers in development and IT as well; (3) all aspects are not in your control (such as continuous integration and test infrastructure). So let’s answer questions asked during the webinar to give some insight on how to approach buy-in. Read the rest of this entry »
August 11th, 2016 by Chris Tozzi
Ever wonder where Selenium (the testing framework, not the mineral you get from eating clams) came from? Here’s a short history of the technology, from its origins more than a decade ago as a proprietary tool through the present era of Webdriver.
ThoughtWorks and The Origins of Selenium
Selenium originated in elder days – by which I mean 2004 – as a tool for testing web applications. It was developed by Jason Huggins, a programmer at ThoughtWorks.
That Selenium originated at ThoughtWorks is interesting. While no one in 2004 was talking about Agile infrastructure, ThoughtWorks was the place where Martin Fowler made his career. Fowler went on to become one of the major thought leaders behind the migration to microservices. While Fowler can’t take credit for Selenium, it seems fitting that the tool, which is an important part of automated testing for DevOps-inspired workflows today, originated in the same place from which the Agile infrastructure revolution later emerged.
Open Source Selenium
At first, Selenium was used only internally by ThoughtWorks employees. But that changed by the end of 2004, when the tool was open-sourced.
Read the rest of this entry »
August 10th, 2016 by Ken Drachnik
We have updated our OnDemand plugin for Jenkins with explicit support for Jenkins Pipeline. This update enables development and testing teams to easily create, manage, and run automated tests using scripts on Jenkins, resulting in faster testing.
The newly enhanced OnDemand plugin enables Sauce Labs users to skip the Jenkins UI and run tests directly via scripts. Previously, users had to work within the Jenkins UI to create testing tasks. While this is initially convenient, as automation grows and becomes more complex, the process of creating testing tasks becomes more complex, too. Now OnDemand enables testers to automate releases for complex and non-sequential tasks that previously required manual intervention.
Key benefits of the update include:
Create scripts to automate Jenkins operations
Save time by scripting test sequences that can automate testing, retry tests automatically and run processes in parallel. Developers and QA can more easily customize their Jenkins workflows and reporting results.
Automatically create test scripts for Jenkins
Use the Jenkins snippet generator to easily create Pipeline scripts to execute Sauce Commands via Jenkins. Users don’t need to know how to script in Pipeline – simply copy the code snippets to program workflows
The Sauce OnDemand Jenkins Plugin is available as a free integration. Download the plugin from Jenkins and read how to configure it on our docs page.
August 5th, 2016 by Bill McGee
Thanks to everyone who joined us for our recent webinar, “Selenium and Appium Training Courses from Sauce Labs“, featuring Sauce Labs’ Director of Product Marketing, Ken Drachnik, and Automation Specialist Kevin Berg.
In this webinar, Ken and Kevin announced the availability of our three new technical training programs – Selenium 101, Appium 101, and Sauce Labs Onboarding. They reviewed the course curriculum and class format, and gave a brief demo of the course environment. They also covered classes that are currently in development – Selenium 201, Appium 201 and Sauce Labs for Enterprise.
Interested in learning more about our new training courses? You can find more information on our training website.
Access the recording HERE and view the slides below:
August 3rd, 2016 by Ken Drachnik
In our ongoing effort to help developers and QA professionals quickly get up to speed with Selenium and Appium, we’re thrilled to announce the availability of our three new technical training programs – Selenium 101, Appium 101, and Sauce Labs Onboarding. Led by our experts, with in-depth knowledge of Selenium and Appium, class sizes are small and include lectures, demos, and interactive hands-on exercises.
Selenium 101 & Appium 101
Both the Selenium and Appium courses are available in several different formats. Instructor-led training is available both online and on-site, and features public curriculum available to all, or you can request a dedicated course that is customized to your specific business requirements.
- Selenium 101 introduces you to the Selenium automation API for testing web applications on desktop browsers
- Appium 101 introduces you to the Appium automation API for testing web applications on desktop and mobile browsers, and for testing native and hybrid applications on mobile emulators, simulators, and real devices.
Sauce Labs Onboarding
Sauce Labs Onboarding is a free, one-hour self-paced class designed to introduce you to Sauce Labs features to get you up and running with your tests.
In addition to providing you the nuts and bolts of automated testing, our courses also cover best practices and useful how-to tips, so you can start testing right away, and then develop better tests in a lot less time.
First classes begin August 17th – sign-up here or request more information.
July 28th, 2016 by Sahas Subramanian
In the Design Patterns for Scalable Test Automation webinar we discussed the importance of adapting proper patterns for the scaling and maintaining of E-E tests. A couple of additional important aspects for End-to-End (E-E) test stability are:
- Environment-agnostic tests – Tests should be independent, self-contained units, and should run against any environment without code change, and with no dependency on anything else (apart from the runner)
- Test data – How to prevent tests failing because expected data wasn’t available in the system
In the context of a web app (not legacy, thick-client applications), let’s take a look at how to deal with these challenges.
E-E tests need environment-specific configuration information such as the URL, role, user name, password, etc. Needless to say, hardcoding these parts of the test is not a good practice. It makes updates and maintenance difficult. A better solution would be to tokenize, keep the key/value pair separate and use them as part of the test flow. Different technologies offer different tactics to handle the need. Read the rest of this entry »
July 26th, 2016 by Chris Tozzi
If you’re a Java developer, you probably know and love JUnit. It’s the go-to tool of choice for unit testing (and, as we will see below, other types of testing as well) for Java apps.
In fact, JUnit is so popular that it’s the most commonly included external library on Java projects on GitHub, according to a 2013 analysis. No other Java testing framework comes close in popularity to JUnit.
But while JUnit is widely used, are all of the projects that deploy it getting the most out of it? Probably not. Here’s a look at what you should be doing to use JUnit to maximal effect.
First, though, let’s go over the basics of JUnit, just in case you haven’t used it before.
JUnit supports any platform on which Java runs, and it’s pretty simple to install. Simply grab the junit.jar and hamcrest-core.jar files from GitHub and place them in your test class path. Read the rest of this entry »
July 21st, 2016 by Joe Alfaro
A few years ago, while working elsewhere, I came upon a scene of two engineers literally screaming at each other over the top of their cubicle walls about some aspect of a project. “Oh good,” I thought, “they’ve reached the storming stage, things can only get better from here.”
As I talked about in my previous post, forming Scrum teams leads to emergent behavior on the part of individuals as they adjust to the new regime. The same is true of small teams; once formed, the way in which individuals interact with each other tends to undergo a sequence of changes as well. The behavioral scientist Bruce Tuckman labeled these stages as Forming-Storming-Norming-Performing. As unpleasant as the transitions from stage to stage might be, all teams must progress through them in order to reach the point where they are truly self-managing.
In the forming stage, teams cohere in relation to external influences, like goals and tasks, but tend to remain focused on themselves as individuals. This is reinforced in the way that we typically constitute technical teams, where each person is recruited for their individual technical strengths. Forming is typically a stage that is driven by intellectual and analytical considerations, since it focuses on defining the project, identifying tasks, and assigning team members who can fulfill them. Read the rest of this entry »