BuzzFeed: Finding Bugs at Buzz-Speed

May 2, 2019
John Kensinger
John Kensinger
👉Read the Case Study👈

 BuzzFeed is a leading multi-channel digital media company that delivers news and entertainment pieces to a global audience. Its vast network includes BuzzFeed Originals, BuzzFeed Media Brands, BuzzFeed Studios, BuzzFeed News, and BuzzFeed Commerce, all of which create authentic content that engages audiences and fosters social impact. 

I spoke with Jeremy Back, Staff QA Engineer at BuzzFeed about his team's approach to testing for functional and visual issues on the BuzzFeed and Tasty apps.

What you'll learn:


Beginning the Search

BuzzFeed vetted five separate companies, going through a variety of demos and gauging various services to understand what kind of value was offered.

They based their interest in these companies on various factors:

  • Quality of the test results
  • Speed to get test coverage, the number of unique testers per test cycle
  • Type of testing they were capable of
  • Type of bugs received
  • Ease of communications

So, what put test IO on top?

Hint: “[It] enabled [Jeremy's team] to do additional forms of testing, carrying out further efforts that [they] didn’t have time to focus on prior.”


The test IO Difference

Jeremy had initial concerns with crowdtesting, as sometimes the quality of findings is sacrificed for the quantity. Often, the goal of testers quickly becomes to create as many tickets as possible as opposed to fewer high quality ones. 

BuzzFeed started with a limited number of tests, and after seeing a clear and present value, opted for test IO’s unlimited testing support.

Today, Jeremy says, “Bugs are being found that, while we could find them, would take us 48-72 hours to find them in our regressions suite, where test IO is finding them in less than 24 hours.”


Buzzing Results

Jeremy shared that on-demand device coverage has been one of the greatest benefits of working with test IO: being able to go into the platform and select the exact device they’re having trouble with. 

It can be easy to say “let’s just automate everything and see what happens,” but when you’re dealing with content-heavy, evolving applications, you must ensure your user flows are solid and that test coverage keeps up with the development roadmap. 

To ensure the above is taken care of, read the entire case study here.


Interested in learning more about how different companies work with test IO to leverage crowdtesting? Visit the Customers page for more case studies and stories.

Read More

January 17, 2020
QA Squads: a new offering from test IO, amplified by EPAM

Going beyond software  Customers come to test IO for many different reasons. Sometimes, an internal product or QA team needs a force multiplier for real-world testing – to extend the existing QA team’s processes and activities beyond their internal team. Other times, it’s crisis mode – perhaps QA leadership has left the company, or there is a critical product release upcoming that […]

November 25, 2019
iOS testing: TestFlight or Resigner

Here's our guide to which method you should use you to distribute your IOS app to the crowd.

November 15, 2019
Exploratory Testing vs. Test Case Testing

Exploratory testing emphasizes creativity and learning. Test Case testing emphasizes planning and execution. Which one is right for you?

Ship Faster, Sleep Better

Get a Demo
twitterfacebooklinkedin