Tag Archives: Test automation

Testing Android At Facebook

March 14, 2014 Stephen Janaway 2 Comments

I spent a very useful and interesting day at SIGIST on Tuesday, presenting a talk on mobile testing, and listening to a number of talks from other speakers.

Simon Stewart’s presentation on how they test they Facebook Android application was very interesting. There is no Android team at Facebook, with all feature development taking place in the same team, irrespective of the platform. This helps ensure that the offerings are consistent across platforms.

They make a lot of use of test automation, (something that Facebook are famous for), and this applies to Android as much as other platforms, in particular a focus on unit testing and functional test automation using Selendroid.

Facebook have two main guiding principles for their test automation:

Signal > Coverage – ensure that the results of running tests are acted upon, and failing tests are fixed or removed.
Speed > Coverage – ensuring nothing takes more than 10 minutes to run, and running tests in parallel.

Facebook also use a lot of dog-fooding and make use of Google’s Alpha and Beta test programs to ensure a wide coverage of devices and test scenarios, in particular to fill gaps between their primarily automated test strategy.

I drew a mind-map of the talk which explains everything in more detail. Click on the image to get the full size version.

blog, Experiences, practices, Testing

Automated Functional Testing – A Test Activity?

January 28, 2014 Stephen Janaway 7 Comments

If you are a functional test automation expert then times are good. There’s big bucks to be made in the contracting game, companies are desperate for candidates to ‘automate everything’ and to get to this oddly perceived test automation nirvana that those who are either mis-informed or have hidden agenda’s seem to feel fit to promote.

This has made me think. Primarily about how we have got to this state? Is it because, as the testing community, we have wanted to own test automation? Is it because those outside of the test community see test automation as less important than the production code that it tests? Is it that we just built up an expertise and then protected it just for the money?

Some might say that what has actually happened is that we now have a situation where second rate developers now have a great way to stay in the development game. There is a danger, in the apparent supply-side crisis that we find the industry in, that companies merely employ anyone who says they know something about test automation, without doing the same due diligence that one would do for a development position. This would be a mistake.

In my mind there is a solution to all these problems, and that solution comes from treating test automation just like production code. And that means primarily using developers to write it. Sure, you may choose to have testers involved as well, where they have the skills and expertise, but let’s not try and force skills on people who don’t want them, and let’s not accept second rate people just because they can ‘do some test automation’. One advantage to using developers is that test automation becomes a team thing, and you are less likely to spend time playing catch-up when development slips. One downside; it’s going to look like the team has slowed down. Believe me, it hasn’t. It’s just got more effective, and is playing to the right skill-sets.

Don’t believe me? 🙂 Here’s a couple more examples from Rob Lambert and Amy Phillips which show where continuous or more frequent delivery has been successfully rolled out at New Voice Media and Songkick. The common thread – in both cases the test automation is a development activity.