Adventures in San Francisco – part one, meeting Sauce Labs

I recently got the opportunity to travel to San Francisco for Google I/O. Having never been before and I thought it would be good to meet up with a few of our technology partners.

The first on my list was Sauce Labs.

saucelabs

Sauce Labs are a great company that provide a VM farm where you can run your automation tests on a huge range of OS and browser combinations, in their words:

Less time testing, more time innovating. Accelerate your software development process using the world’s largest automated testing cloud for web and mobile applications

After a tour of their office, I sat down with Brent Hedgpeth, Chris Broesamle and Neil Manvar to talk test automation and continuous integration.

ci-pipelines

To give some context on how we work, the in-season (Net-A-Porter & Mr Porter) frontend team is broken into sub teams based around user journeys. I work inside the Product team, responsible for the product catalogue (listings, details and search). While at saucelabs we looked into our test and release strategy and ways we could potentially improve. Here is our current strategy:

Current Testing Strategy

Some key things to note here is we work directly on master. Some enablers that allow us to do this are:

  1. Using TDD gives us confidence in our code coverage
  2. Pair programming means we can avoid code reviews and pull requests

We are a small team of four developers and two test specialists which means if someone breaks the build they sit right next to you and you can give them a nudge, so it’s not really a big issue. We wanted to avoid pull requests as we noticed they could reduce flow as they waited for a developer to approve. However speaking to Neil there are potential problems with our current approach:

  1. If the team grows or works remotely, master could become less stable
  2. Working on build scripts changes can make master unreleasable

This could be solved by implementing the test scripts on pull requests:

Testing Strategy Proposal

Although this adds an additional step this would give the developer confidence their code works as expected before committing to master. If the work had also been paired the need for another developer to approve the request could also be removed so it would not have an effect on flow.

While there we also discussed if they were going to start supporting larger screen resolutions, a large percentage of our customer base use 1400px plus width screen so this is super important for us. Since chatting this feature has actually launched and you how test on multiple large resolutions for El Capitan! You now have the follow resolutions available:

  • 1024×768
  • 1152×864
  • 1280×960
  • 1376×1032
  • 1600×1200
  • 1920×1440
  • 2048×1536

You can implement the resolutions into your Sauce Labs configuration using capabilities:

caps = {browserName: 'chrome'};
caps['platform'] = 'OS X 10.11';
caps['version'] = '50.0';
caps['screenResolution'] = '1600x1200';

It was a really interesting meeting and I learnt a lot, the Sauce Labs team were great and I can’t recommend their platform enough.

Next I was off to visit two of the largest names in San Francisco, Google and Twitter but I will save that for part two.

(Parts two, three and four.)

Print Friendly

Leave a Reply