Posts Tagged ‘testing’

JIRA is Just a Click Away with Our New Plugin

May 3rd, 2016 by Ken Drachnik

As more and more devs work in agile teams, they need tools to plan, track, and release software and many of them use JIRA. As a tracking tool, JIRA is amazing for collaboration and project planning. For many teams, JIRA is the place of record for everything in the software development lifecycle. We have found that many of our customers use JIRA and the #1 product ask was to integrate Sauce Labs’ test results with JIRA so it would be simple to track all the tests associated with a project in one place.

Let’s say you are running an automated or manual test on Sauce Labs and find a bug. You want to add it to JIRA so that someone on your team can take a look or so that it can be prioritized in the backlog. Historically, one would have to download all the Sauce assets, login to JIRA, create a ticket, and upload the assets again. This can be tedious when you’re running lots of tests.

With Sauce Labs for JIRA, this is all simplified and automated. With the click of a button you can now create a JIRA ticket directly from your Test Details page. The plugin gives you the option to upload the screenshots, logs, and video link to your tests, making it easy to share out among your team.

To download Sauce Labs for JIRA, visit the Atlassian Marketplace: https://marketplace.atlassian.com/plugins/sauce-jira-integration/cloud/overview.  To read more, visit our JIRA integration Docs page.

Happy Testing!

The Sauce Labs Ecosystems & Integrations Team

3 Simple Strategies to Get Started With Automation

March 24th, 2016 by Joe Nolan

If your test automation team’s directive is to automate X amount of tests, and you have no strategy as to which tests they should focus on, you are wasting your time. Before you begin writing your first line of automation code, make sure you have a strategy in place. Otherwise, you will have a ton of ineffective tests to maintain.

Don’t Choose a Random Goal

How many times have you been told that the goal of the team is to have X amount of test coverage? This is an arbitrary value picked out of the sky. What is it based on? If a UI automation team were to cover 80% of the stories in a sprint, they would never get done in time.

We all know how fragile UI automation is! How many times will a designer make a change that directly affects the UI and breaks the test? This is almost manageable during a sprint while you are working closely together, but how about when the product is sent to be translated to another language? The translator inevitably comes back with suggestions to allow for phrases more common and translatable. Bugs might be entered and UI changes made by a maintenance team with no heads up to the automation team, and Bam! — You have broken tests that need to be investigated. (more…)

The Importance of Mobile Testing

November 12th, 2015 by Greg Sypolt

It is a digital world, and all Generations have embraced the mobile revolution. It’s no surprise that millennials are leading the way. I saw a statistic recently that 85% of Millennials owns a smartphone. Next time you are waiting in line, take a look around.  Statistics don’t lie.

Source: http://www.statista.com/chart/3760/mobile-etiquette/

Source: http://www.statista.com/chart/3760/mobile-etiquette/

The mobile revolution has only just begun. The importance of having a mobile testing strategy is critical to our app releases.

What makes a great mobile app?

There are multiple elements that can influence a great (or bad) mobile app. The team works so hard developing an app (from idea, planning, writing code, and testing), the last thing you want to hear is negative feedback instantly after releasing the app. As long as the focus is on simplicity, understanding your users (audience), and the performance of your app, you are heading in the right direction. (more…)

iOS 9.1 Beta Support and Speed Improvements

October 16th, 2015 by Ken Drachnik

With a number of reported problems on iOS 9.01 and 9.02, Apple is in beta with a 9.1 version that is supposed to fix issues and become the stable release.  We have iOS 9.1 beta ready now, so you can start testing and be ready for the general release predicted for late October or November.  Check out all our browser / OS combinations at our platform configurator.

At Sauce we are constantly improving our service by making it easier to integrate with CI systems, upgrading our UI and, lately, improving reliability and speed.   We’ve just finished part one of a project to speed up the generation of VMs so you can test even faster.  Our Windows VMs are now faster than ever, so check ’em out.

Automated Mobile Testing with Real Devices

September 8th, 2015 by Ken Drachnik

Mobile testing has long been a manual process – limited by the devices you have close at hand or at best, a painfully slow process in the cloud.  Sauce has long had emulators and simulators to let you speed your tests by automating them in the cloud. Sometimes, however, emulators are not enough and you need to test on real devices.  We are happy to announce the public beta of our Real Device Cloud. That’s right, we’ve put hundreds of Android and iOS devices up in our cloud so you can automate your tests across emulators and real devices with massive parallelism. That means you can now test fast – just break your tests up into manageable bits and run them in parallel. There’s no waiting, there’s no reservation system – they are available and ready to test whenever you are.

We anticipate opening The Real Device Cloud by the end of the month so you can start testing all your mobile apps.  Download the datasheet.

The Real Device Cloud

  • Instant Availability – Get access to the most popular* iOS or Android devices with no waiting
  • Over 80 mobile emulators and simulators
  • Massive Concurrency – Run your tests in parallel to reduce your total test time
  • Integrate with your CI tool of choice – automate all your tests using the top CI tools like Jenkins, Bamboo, Travis, Team City or Circle CI
  • Test Native, Mobile Web and Hybrid apps
  • Access back end databases – that’s right, you can test your app in our cloud and have secure access to your backend data and websites for a true end-to-end test.
  • Full reporting – instant access to videos, screenshots and all the data for your tests so you can analyse your results quickly
  • Enterprise features – account and team management lets you provision test resources as needed and SSO integration means you don’t have to go to IT to add another tester to your account
  • Professional Services and Training – we have people and partners to help you get started with Appium or if you’re already proficient, our experts can help your team become super users

* The Real Device Cloud will open with Apple iPhone 6 and Samsung Galaxy S4 and S5 phones.  We will be adding more device types in the near future.


Sign up for the beta program today.

Can You Test it All? Test Coverage vs. Resources

September 3rd, 2015 by Ashley Hunsberger

During nearly every project I have worked on, the question Can I test everything? always comes up.  The answer is (usually) a resounding NO. Sometimes it’s because of time, sometimes it’s lack of people. How can we still ensure a quality product, even if we can’t cover it all? Sometimes, we have to test smarter.

The usual suspects

The typical scramble to finish testing and get something released is usually (in my experience) a result of one of the following (or a combination thereof):

User stories that are WAY too big.  When user stories are too large, it makes it difficult to break out tasks and identify all the acceptance criteria. They also become more difficult to plan for unforeseen scenarios, and can often blow estimates out of the water.

Complex Workflows. Depending on your feature, the workflow could be very complicated, and it can be difficult to anticipate how a user is actually going to use the product. This makes it more challenging to find every possible scenario for end-to-end tests. Even if your user stories are small, the overall workflow comprising all user stories can still result in missed tests if it is too complex.

Not using Test Driven Development. If you are still living in a world where Development works on their own and throws it over the proverbial fence to QA, you are opening up doors for late surprises to enter, and blocking bugs that hinder your testing progress. (more…)

Should You Have a Dedicated Automation Team Within Your QA Department?

September 1st, 2015 by Israel Felix

If you’ve led or managed QA teams that have included an automation test team, you’ve probably been in a situation where you had to decide whether you should keep them on board. Normally the decision needs to be made when there is a change in leadership, wherein the new management comes with a mandate to consolidate groups and reduce costs. This situation also tends to arise when working with startups or small companies when they are ready to put together or augment their QA teams. So should you have a dedicated automation team?

Typically, there are two camps with regards to dedicated automation teams. There are those who believe that we should have dedicated automation teams, and those who believe that QA engineers should handle manual testing and automation testing. From my experience working in QA within both small and large companies, I almost always prefer to have a dedicated automation team. However, there are a few scenarios where having a QA team that takes on both roles might make sense.

Time to Market

For automation to be done right, it needs to be a full-time job. From developing the framework and creating the libraries and scripts for different platforms to executing and debugging failures — it will all simply consume too much of an engineer’s time and compromise the actual testing and release date. As you already know, time to market and keeping a release on schedule is top priority, so testing needs to get done, no matter what. (more…)

New! Support for OS X 10.11 and iOS 8.3, 8.4 & 9.0

August 12th, 2015 by Ken Drachnik

El Capitan 200 px wideIn our continuing effort to make Sauce Labs the best place to test, we’ve just added some additional OSes and Browsers. In addition to Windows 10 and the Edge Browser we announced last week, today we are extending the platforms we support to include released and upcoming iOS and OS X operating systems:

OSX 10.11 El Capitan (beta)
iOS 8.3 and 8.4
iOS 9 (beta)
Safari 8.0.7

To use any of these platforms visit our platforms configurator.

When we ask our users what it is they love about Sauce one of the most common responses is the wide variety of platforms we provide our users. In an ecosystem of increasing complexity, we know our customers have a lot of devices and platforms they need to test against. Our humble aspiration is to make your life a just little bit easier by having the platforms you need when you need them.

Sign in to start testing

Appium + Sauce Labs Bootcamp: Chapter 2, Touch Actions

June 15th, 2015 by Isaac Murchie

This is the second in a series of posts that discuss using Appium with Sauce Labs. In the first chapter, we covered Language Bindings. This installment discusses Touch Actions; Chapter 3, Testing Hybrid Apps & Mobile Web; and Chapter 4 is about Advanced Desired Capabilities.

One aspect of mobile devices that needs to be automated in order to fully test applications, whether native, hybrid, or web, is utilizing gestures to interact with elements. In Appium this is done through the Touch Action and Multi Touch APIs. These two APIs come from an early draft of the WebDriver W3C Specification, and are an attempt to atomize the individual actions that make up complex actions. That is to say, it provides the building blocks for any particular gesture that might be of interest.

The specification has changed recently and the current implementation will be deprecated in favor of an implementation of the latest specification. That said, the following API will remain for some time within Appium, even as the new API is rapidly adopted in the server.

Touch Actions

The Touch Action API provides the basis of all gestures that can be automated in Appium. At its core is the ability to chain together _ad hoc_ individual actions, which will then be applied to an element in the application on the device. The basic actions that can be used are:

  • press
  • longPress
  • tap
  • moveTo
  • wait
  • release
  • cancel
  • perform

Of these, the last deserves special mention. The action perform actually sends the chain of actions to the server. Before calling perform, the client is simply recording the actions in a local data structure, but nothing is done to the application under test. Once perform is called, the actions are wrapped up in JSON and sent to the server where they are actually performed! (more…)

Appium + Sauce Labs Bootcamp: Chapter 1, Language Bindings

June 1st, 2015 by Isaac Murchie

Appium logo w- tagline {final}-01Welcome to the first in our new series, Appium + Sauce Labs Bootcamp. This first chapter will cover an overview of Appium and its commands, demonstrated with detailed examples of the Java and Python language bindings.  Later we will follow up with examples in Ruby. This series goes from fundamental concepts to advanced techniques using Appium and Sauce Labs. The difficulty is Beginner->Advanced. In Chapter 2 we cover Touch Actions; Chapter 3, Testing Hybrid Apps & Mobile Web; and Chapter 4 is about Advanced Desired Capabilities. (more…)