Tag Archives: flakiness

Interesting Talks from Google Test Automation Conference 2016

There’s a lot of stuff going on in the software testing community at the moment, specifically in the field of automation, because of how software is now being deployed into various other platforms besides personal computers. Google needs to worry about testing their eyeglasses, virtual reality headsets, and cars. Others care about testing robots and televisions. This is why it is fun to watch talks from conferences, like the Selenium Conference or the recently concluded Google Test Automation Conference: I get to find out what problems they’re facing and see how they try to solve them, and maybe learn a thing or two. Sometimes I get to pick up a new tool to try for my own testing too, a great bonus.

Some favorite talks from the conference are:

About Selenium Conference 2016

I had time over the holidays to binge watch last years Selenium Conference talks, which was as awesome, if not more so, as the talks during the 2015 conference. Automation in testing has really come a long way, alongside the advancements in technology and software development, and this brings forth new challenges for all of us who test software. It’s not just about Selenium anymore. Mobile automation still proves to be challenging, and soon we’ll have to build repeatable test scenarios for the internet of things – homes, vehicles, stores, among others. Software testing can only get more interesting by the year.

Here are my picks for the best talks from the conference, if you’re curious:

Lessons From Ankit Mehta’s “Move Fast & Don’t Break Things” 2014 Kirkland GTAC Presentation

Ankit Mehta, a Senior Test Engineering Manager, recently shared his decade-long test engineering experience at Google by publishing the slides of his GTAC (Google Test Automation Conference) Kirkland 2014 ‘Move Fast & Don’t Break Things‘ presentation in public. It’s an awesome read. Here are a few takeaways:

  • For every couple of bugs fixed, one usually gets introduced. Because of this, it is more important to not have many bugs to fix right from the very beginning. Ankit Mehta’s motto is ‘Prevent bugs and not catch them,’ which is definitely better than let’s keep finding bugs after each new software version is deployed.
  • There should be a system wherein if a programmer writes code that breaks an existing test, the system will complain. If they check in code without a test, the system should also complain. This is all to prevent crappy code from finding its way into the codebase.
  • A set of test cases that are manually being run over and over again should be automated, unless in circumstances where the return of investment to automate is not there. Remember, however, that test should be independent of each other in order of which they run as well as other details, and to break huge test suites into smaller units.
  • Use hermetic tests, a test suite that can start up and run as expected on a single machine that has no network connection.
  • Have zero tolerance for test flakiness because even one flaky test out of so many could slow down everything. Flaky automated tests are often worse than not using automated tests at all.
  • Release to Production everyday.