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 come along with producing so many different mobile builds per year.
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?”