Facebook’s No Testing Department Approach: An Interview with Simon Stewart


In this TechWell interview, Facebook's Simon Stewart digs into his company's shocking approach to testing, which is that they don't have a testing department. He also talks about the challenges and pressure that comes along with producing so many different mobile builds per year. 

The first half of this interview can be found here. 

Josiah Renaudin: You mention in your talk that Facebook has no testing department, and that this could be a future trend for other companies. Should this statement scare testers, or do you believe they still have a place in software? Do they need to adapt and gain an extra set of skills to remain marketable?

Simon Stewart: Should it scare them? No way! It’s an amazing opportunity. The trick will be to articulate the unique value or perspective that you bring to a company, and find a way of providing that within the framework and DNA of the particular organization you’re part of.

I see the trend of ever-quicker releases continuing (you can see it in the practice of continuous deployment that some companies follow), and that means that testers will need to be creative about how they do their work. It also means that they need to be able to repeat their work at scale, and I think that leads us towards a world where all testers need to code (unless they’re happy repeating the same thing, over and over and over and over again at super-human speed with no mistakes)

In order to enable fast release cycles, feedback loops need to be as tight as possible. There’s no space in this for QA to be kept at arm’s length or until the end of the process (which is madness: “Quality” isn’t something you can add as an afterthought). As such, I imagine that an effective “next-generation” QA will need to be technically competent and to have very good “soft” skills --- after all, no one likes to hear that their work is faulty. They may find that collaborating closely with a developer will allow them to move as quickly as they will need to. Or they can learn to code and avoid needing someone to translate thought into something a machine can understand.

One refrain I hear occasionally is that knowing how to program will somehow “damage” a tester, because they understand how the software and machines work. My view is the exact opposite: Knowing how something works gives better insight into potential flaws. Essentially, I think that understanding how to code widens the set of tools available to a tester, without diminishing what they can do in the slightest.

In my experience, one problem is that the “follow a script” end of the QA market has negatively colored people’s views on the role, and that means that for far too long being a tester has been seen as a poor relation to being a developer, and that’s just not true. Hopefully the rise of automation will mean that this misperception will evaporate, but it will come at a cost.

Josiah Renaudin: What kind of pressures to you feel when releasing one of your new monthly builds, knowing the magnitude of your audience?

Simon Stewart: I think that there’s a distinction to be drawn between fear and respect. Releasing a new version of the site or the app is rapidly becoming a routine process, and it’s hard to fear something that’s routine. On the other hand, we deeply respect the people who have chosen to spend their time on Facebook. One of the mantras of our release engineers is that no release should ever leave a person worse off than they were before.

That means that the pressure of maintaining quality, functionality, speed, and all the other things that people care about is constant, and I think it’s something that everyone’s aware of. The teams I’ve worked with have been very keen to adopt tools and techniques to make sure what they write is as solid as possible, and I’ve seen teams and individuals go to great lengths to make sure that people using Facebook have a smooth experience.

One of the aspects of working at Facebook that I really enjoy is that despite this pressure to deliver an amazing product, when something goes wrong the focus is always on identifying what happened and identifying the causes rather than who did the wrong thing, and the actions we take to rectify systemic issues tend to be lightweight, trusting that our staff are all people doing the best that they can. I’ve worked in other environments where the opposite happens: where blame is placed on individuals or teams, and where rectifying problems leads to heavyweight processes that ultimately lead to a moribund software development methodology.

When someone releases a new feature on the site, they are responsible for ensuring that it works when that feature goes live to the world. I think that this aspect, of owning a feature from inception to release, gives each of our engineers a good insight into what’s needed at each stage of the process, and it helps highlight the importance of automated testing.

Josiah Renaudin: Have you been a part of what you’d consider a botched release at Facebook? If so, can you describe that experience?

Simon Stewart: On campus, there are posters on many of the walls. Your question reminds me of the one that reads, “What would you do if you weren’t afraid?”

User Comments

1 comment
Violet Weed's picture

I had to LOL LOL at Mr. Stewart's naive opinions about testing. Just to clarify, I've been a software engineer (aka 'programmer') since the age of 10, paid for the work since the age of 12... I'll be 66 in a few weeks. The 'idea' that testers have to be programmers, what? does Mr. Stewart think he INVENTED THAT?? Back in 'the day' (the 60s for me) as programmers we were also the testers. Today there is still a place for developer-testing tasks... it's still now as it was then called unit tests and component tests. There is still a need for manual testers as well not just for automation engineers. Faster and faster releases... yeah, that's called 'chaos reigns supreme' just as it did for many failed projects 'back in the day' (see previous 'back in the day' comment). While it's true that any idiot can be a 'coder' today what with OOP etc, it takes a special person to be a REAL programmer and an even more special person to be an effective 'stand in the gap' tester. As for the question "What would you do if you weren't  afraid?" MY answer is somewhat longer than can be written in a comment (it'll be in my book, covered in depth). But for ME, I'd be EXACTLY WHO I HAVE ALWAYS BEEN, since the only fears I have  had in the past 50 years had to do with situations that would take me almost out of my depth, such as flying my twin-engine through hurricane weather, or breaking a young stallion to saddle when his favorite mare is whinnying to him from the sidelines. As for my teams, the key to reducing fear to the level of a blood-sugar testing pinprick is easy... build trust, have integrity as your obvious key word, etc. etc. but the bottom line is build trust. Want more? Wait for my book.

August 11, 2014 - 3:37pm

About the author

Upcoming Events

Apr 27
May 03
Jun 07
Jun 07