We create banking software and we use this product for testing. We have different business units and we set up an enterprise license, so everybody feeds into it from each of our business units.

We have about 750 websites and approximately 50 mobile apps, and we will test the different types of browsers against our automation. A good section of the work we do is running automation against different combinations, and that will expand into mobile devices once we kick off the new year.

For the most part, it's heavy automation, but there is also testing that is manual, where they can log in and pick their devices or browsers.

Our environment includes VMs on the cloud, as well as public and private devices. we have the CrossBrowser and we have the private and public cloud.

We primarily use Sauce Labs to test browser compatibility. It's mostly functional rather than performance testing. We use a combination of tools, but Sauce Labs is mainly for compatibility testing. Selenium is our backend, and it also has compatibility testing, but we're not making use of that feature. Selenium is for capturing. 

Our custom framework for testers combines Selenium and third-party vendors to do some of those performance metrics. At the same time, we use Sauce Labs to test cross-browser compatibility for the top five browsers that the government requires us to support. 

We automate tests of our on-premise solution with Sauce Labs via tunnels. Sauce Labs allows individual testers to log in and test whatever they need, but we don't do it that way. Instead, we use the automation features through tunnels, and our CI/CD process will run tests for us through Sauce Labs. It returns metrics on compatibility and usage for us to review.

Our two major platforms are Windows and Mac. We don't run tests on Linux. Even though we build everything on Linux, we don't support that for our end-users. We test our applications on the two main operating systems and variations of Safari. OS X testing is the main reason we started using Sauce Labs because we needed to test our applications on Safari, which isn't available on Windows. Initially, we purchased some Macs to do compatibility testing, but that didn't prove helpful at all. 

We also need to test on all Chrome variations because there are multiple versions we need to support. When we launched, Microsoft had just released Edge, so very few of our users had it, but just about everyone has migrated from IE to Edge by now. Testing on variations of Firefox, Chrome, IE, Edge, and Safari is our essential requirement. 

It's easy to set all that testing up on Sauce Labs. We could use a virtual machine to run applications on all the browser variations, but you need to get people in there to connect to it, and a homebrew solution is way too complex. With Sauce Labs, it's all already there. We just spin it up, specify the version we need, and we're done.

Sauce Labs doesn't give us immediate feedback on every code commit. That's not how we have it set up. We've got a multistage process, so it goes through a code review for quality when we do the commit. We have unit tests that happen along the way, but when we do a full-blown merge and are ready for a release, that's when we actually launch our tests, and the tests run overnight. There are thousands of tests, which is why we don't do it on every code commit, but we do it every night. When a nightly job runs, we run a full regression test on that to get the results the following day.

We use Sauce Labs in our CI/CD pipeline for our mobile app.

I work on the team that develops the mobile application for Discover, and we run about a couple of thousand tests per day on Sauce Labs devices. Whenever our developers are contributing code to our application, we'll run a bunch of tests on Sauce Labs devices, and every night we run a full suite of 1,000-plus tests on those Sauce Labs devices.

We use it for automated testing. For our company, we do web testing automation. We run our test suites containing Java-based scripts and automate the entire mobile or web application. We've 500 to 600 scripts, and we execute them on Sauce Labs. Sauce Labs provides different browser versions and mobile devices where we can execute our tests and get the results. That is how we use this solution.

We use it for automation testing of our e-commerce product. We also have some apps that use React Native and they deploy to mobile devices. We also do responsive mobile testing. That means we test anything that hits a website with a browser, or on a phone through React Native, through Sauce Labs.

We also use their VMs and their video recordings.

We use the automation testing and the ability to run it against many device configurations. It's very convenient.

When I started with my current company we had a fairly lean tech department and Sauce Labs was originally implemented for a piece of software we had just written that helped implement web testing.

As things got bigger, and we got sucked into and were merged with another company, the number of teams and how they use Sauce Labs fundamentally changed. It went from everything running through just this one piece of software, and it managed all connections, to the point where we let everybody run tests now against the tunnel, if they're inside the network. Every use case for every team inside the company is going to be somewhat different. The majority of our approximately 85 teams that run things through Sauce Labs are web-based, and use it for tests that are run almost 24/7. We have engineers on those teams who will push changes to some type of front-end. There's a grouping of tests, depending on the team, and those tests are set via Jenkins and CI/CD to execute constantly.

Sauce Labs is a SaaS service hosted on the company's cloud. They have a number of cell phones and mobile devices housed on their cloud, and my team can perform tests on these devices from around the world. We have about 50 users right now, including business analysts, testers, automation, QA, developers, product owners, and third-party vendors. 

My company is quite large. My team supports the various different IT teams around the business who then work with their business partners. For example, if you think about our research and development division, our clinical trials division, and our manufacturing division, each one of those business groups has their own IT teams who build tools that the business team needs to do its jobs. My team provides the tools that the IT teams would need to build the tools for their teams. So, we are two or three layers removed from the broad side of the business.

We are the team who provides this solution to other groups. However, in terms of our usage, because the company has done things by paper signatures, official paper, and hand documentation for a long time, there has not been a whole lot of progress yet on the automated testing sector. Therefore, our usage is very small compared to other businesses of our size. 

We have 25 concurrent VM licenses for Sauce Labs today. That provision amount has not changed in my time here because it has never exceeded that capacity. So, it is a slow, upward trend, but it is very slow right now.

We have been using Sauce Labs to test various browsers and OS combinations as well as test our applications. Our existing automation scripts are written in various technologies, which could be Java, JavaScript, Selenium, Cypress, etc. Jenkins is the tool that we use to typically run our jobs. Through Jenkins, they get scheduled and run in Sauce Labs. This is where we choose to run them, through various browsers and OS combinations.

We use Sauce Labs core and whatever services that we choose to go with, like browsers and mobiles. From there, we can choose the browser and OS versions, etc.

We have two kinds of applications using Sauce Labs in our company. One is the website, and we're using it to test across browsers, such as Chrome, Safari, Firefox, Edge, and mobile, to see that all the components we have in a web page work. 

The second product we use the solution for is our driver application. We make and deliver pizza. Every time an order is received, we dispatch a driver to bring it to the customer. We have an application for driver dispatch on iOS and Android, and we run test cases for those as well.

My company uses Sauce Labs to run all smoke and regression tests for our application.

We primarily run our tests on Chrome 83, but we occasionally run on other versions (81 or 84) to check to compatibility. Our smoke suite runs on a nightly build, and regression on a bi-weekly basis.

For building out new automation features, we have to have a passing Sauce Lab run before creating a pull request. Doing this ensures that our new automation features will run on other environments and not just locally.

We use it for a lot of end-to-end UI test automation.

We really just use the visual test automation, not the performance, for our product teams.

We mainly use it to run our test cases for different platforms. We're able to run it for multiple browsers and multiple devices. We use it for about 90 percent of our CI/CD test cases.

We are using it for automated testing and not for visual testing or performance testing.

I'm on a team called the "Quadrant Three Mobile" team. Our focus is mobile testing and mobile browser testing. Sauce Labs provides iOS simulators and Android emulators that we use in our tests. It's running on our private cloud, and we have a Sauce tunnel set up to communicate between our environment and the Sauce Labs environment.

We don't often use the Sauce Labs UI to track the tests we need to do. We have a UI on our end to do that. However, we log in to the web interface to view the dashboards to see the test strength and what was triggered or to search for specific tests exact testing. The Sauce Labs dashboard has links to videos of the actual test runs, which helps us deal with debugging issues and test failures. 

Quality control engineers are the main users of Sauce Labs at the company, but developers also use it for making the CRM code base. They run tests on Sauce Labs mid-development to ensure their piece of work is going well.

They are our preferred vendor for all our mobile and browsing test needs.

We have been using it for mobile applications and multi browser testing and multi-device testing.

We use the Sauce Labs test automation VMs to help our quality assurance engineers run automated tests concurrently, using a platform that we build in-house.

We use the browser VMs and we definitely use it for end-to-end testing. We may use it for performance testing, as well.

The way that we use it is pretty straightforward.

The primary use case for this solution is for automation testing on mobile and web on our testing environment so we can implement continuous integration and continuous delivery into the workplace. With the automation practice being used we are able to deliver more and possibly deliver daily after each build is created in theory. With the automation, we can now focus time testing the higher traffic areas or higher risk areas that could possibly crash or cause a bad experience for the end-user of either the web or mobile application. 

It is usually used for manual and automation testing for different browsers and OS.

Uses:

1. Running image comparisons on different devices

2. Run test cases on mobile and desktop OS and browsers

3. Running test cases on both production and QA

4. Sauce proxy helps us to run tests locally

5. Sauce lab analytics provide better experience to analyze failures and get run timing of test cases

6. Using it for both manual and automation

7. Can help to do compatibility testing of code in different OS

8. Reduce manual overhead

Our healthcare company has a QA team who uses Sause Labs to review various metrics.

For me, as a software engineering manager, I am able to see who from my team is logging on, when are they logging on, and other things in regards to activity within the environment.

Our company has different divisions, like research and development, manufacturing, and research laboratories. There's also a department called Global Infrastructure Services. In total, we have five or six areas. In some cases, Sauce Labs is only used in a segment of a department. Take, for example, research and development. They might not use it in the laboratories, but they have a digital health section that works on apps or digital solutions for medical diagnostics.

In this example, the primary use case is developing different software applications for medical diagnostics. They use Sauce Labs for testing applications in different operating systems and environments. We do regression testing across various ways someone might use an application. Instead of securing physical machines, they use Sauce Labs to do that. Many of the applications are internal to the company, so we use Sauce Connect to link up to the internal network to test those applications.

We do a combination of parallel and sequential testing in Sauce Labs. Whenever you log in, you see all the tests on the dashboard. You have concurrent and parallel tests running, but some people will also use a sequential one.

We have several healthcare products across the healthcare continuum, and we use the Sauce Labs platform to test our applications across different browser and OS combinations. We also use it to do mobile testing across different mobile devices that we may not have. It's not easy to set up these different configurations, so the cross-browser and cross-OS platform in the cloud gives us the ability to test across these different configurations without having to set them up or maintain them.

At this point, we are trying to focus on API testing.

My role is with a central team that helps other teams. If another team is struggling then we reach out to them and offer assistance. Because of this, I am familiar with how some teams are using the product. If on the other hand, a team is doing well and doesn't reach out, then I don't have any insight into how they are using the solution or how well things are going. 

At our company, Applause, we offer software testing as a service and we always get a lot of interesting, uncommon or challenging use cases from our clients. We sometimes get ones that require specific devices or browsers to work. For example, we have clients who want to mix testing on desktop browsers and apps or test on multiple apps to achieve some kind of scenario; perhaps you are at a restaurant, and you are ordering something on your personal phone/tablet, which shows up on the restaurant's tablet or desktop browser. 

Our clients are not only looking for executing the test cases manually, but their target is to automate all of them and be able to integrate that into their CI/CD pipeline and get faster feedback about the stability of the changes that the development team produces on a daily basis.

Sauce Labs covers all of our automation needs and also allow us to do manual testing in case we are verifying bugs or testing something else.

We use Sauce Labs for mostly our automated testing on cross-browser and emulator devices. Our team mainly focuses on web product testing so using a third party vendor to help with the external resouces is a must. There are many cases that we need to run our test on multiple browsers like Chrome, Firefox, IE, Edge etc. Sauce Labs has all the options for us. Of course, because our products are mostly web based, we need to ensure the cross-browser testing for every release cycle. Instead of doing it manually on many real devices, we use Sauce Labs since they provide many emulator devices.

I am part of the QA team. I am implementing this solution. Right now, we are also trying to implement this solution in order to gather results in the testing process.

We have several stores around the world, more specifically around Latin America. We are trying to automate many tasks for the mobile applications that we are building. We are also trying to automate many web tasks in order to upload items to the tool.

Our CI/CD (Continuous Integration / Continuous Deployment) QA Pipeline interacts with Sauce Labs when it goes to run the necessary automated tests. Our automated tests exist for normal web browser tests (we specify to run on the latest Chrome version, on Mac OS) as well as mobile tests where are mobile tests run on various Android and iOS devices to verify that our apps are working properly on multiple systems. We use a 30 VM (Virtual Machine) farm from Sauce Labs, which gives us enough VM's to get through all our tests in a very reasonable amount of time.

We use Sauce Labs for the following:

- Executing automated functional tests across multiple applications in a combination of about 5 browsers/os. These include IE11, Safari (latest), Edge (latest), Firefox (latest) and Chrome (latest).

- Running manual exploratory testing across the same browser mentioned above to get a hands-on view of the application running in each of the environments.

- We use the screenshots and videos to share the bugs or issues found with the teams to assist in the resolution of the bugs.

My primary use case is for cross browsing testing of the largest eCommerce site in Latin America.

Our primary use case for Sauce Labs involves running automated test cases for our web application. It works as a remote testing environment to execute these test cases efficiently and effectively.

The Primary use caes would be the following :

• Using the device farm and also using the ability to use the virtual and real devices for the purposes of software Quality Analysis testing.
• There are projects that sometimes require a variety of devices to perform software testing on and having the repository of devices to choose from that my company might not have greatly assisted with this use.
• Especially in handling massive loads of users. Since there is virtual emulation as well as device farms with actual devices this allows a great number of devices for a team to test with.

As we began architecting a CI/CD pipeline in our SDLC, a need quickly arose for left-shifted, continuous testing of our web applications in real browsers. Specifically, a service that could integrate seamlessly with our Jenkins CI servers and executing tests continuously against our Dockerized applications and firewalled environments. Furthermore, our company does not have the resources to implement and maintain a proprietary Selenium Grid for test distribution. Sauce Labs addresses all of these concerns, and furthermore offers a platform for manually debugging applications in any combination of platforms, browsers, and devices needed, either from an automated test script or from a manual test session. The largest selling point for our needs is its relatively seamless integration with our Jenkins CI servers, including detailed playback and test reports per build job, as well as easy configuration of the proxy tunnel used to access our firewalled environments and desired browsers-under-test, right from the Jenkins UI via their Sauce OnDemand Jenkins Plugin.

We use SauceLabs for Mobile, Browser and Backend testing.

Our QA requirement is to test our apps against all major browser platforms including Safari, Firefox, Chrome and Internet Explorer.

Apart  of visual and functional testing of the application components, we also collect network traffic produced by the apps for further analysis. With latest update, accessing har files got supported natively by the SauceLabs.

For mobile testing we leverage Sauce Connect tunnels as we need to connect the application under test to the corporate network and collect the produced traffic as well.

Using Jenkins to call Selenium tests running from Serenity BDD with Gradle. It is very easy to get tests going in this manner.

Testing a browser-based application. We have a hotel booking site which is used across a wide variety of platforms. Starting out, we are mainly used for manual checks. However, we are in the process of getting automation.

Mobile application testing.

Sauce Labs was very easy to use for basic needs, but using Sauce Connect was very confusing. I am a technical person, but the documentation needs to be a little more easy to understand for non-programmers. The documentation on this site is more oriented towards the software engineer than to the QA engineer.

Validates our cloud application on multiple browsers. The application is based on Node and is hosted and deployed on the cloud. The application is supported on all major browsers.

It is a good web and mobile application automated testing platform. I am able to eliminate having to find a human with a specific device or browser and have them test.

We capture bugs before they make it to production. Once the setup is done, the automation tester focuses on automation testing. Without worrying about infrastructure, we let our testers shine, and ultimately, be more effective.

It provides zero maintenance browser instances.

Testing subscription videos for on-demand software, making them better quality and bug free for our customers.

Real time VM access for functional testing and manual usage.