AOL Answers

In the year 2006, Avichay Nissenbaum and a small group of Israeli entrepreneurs founded Yedda, an online service that matched answer-seeking users with experts in any given field. Avichay said the group’s thesis was that “questions and answers are essentially the DNA of web content.”

As it turns out, their thesis was spot on. After years of increasing popularity, Yedda was officially acquired by AOL. Today, the company is known as AOL Answers.

During this transition, most of the company’s technology and processes would remain the same. Users would still be able to search thousands of ad hoc Q&A discussions and submit media, images and videos of their own. What would need to change was the company’s testing methodology. As an Agile shop, it was the task of Osher Frimerman to find a testing solution that could keep pace with the company’s aggressive development schedule.

“We sometimes release as often as three times per week,” said Frimerman. “So it was important that we find a way to test as quickly and efficiently as possible. That’s why we chose uTest.”

This brief case study will show how AOL Answers leveraged the uTest community for functional and exploratory testing. Subject matter includes defining the scope of testing, tester selection, project management and other aspects of the uTest experience.

Test Cycle Details and Results

Despite its simple user interface, Frimerman explained that behind the scenes, AOL Answers is actually a very sophisticated application, as it uses an advanced matching algorithm to identify experts. So while students were responsible for moderating the content, uTest would be called on to perform functional and exploratory testing on the application’s more complex features. This would ultimately include social media integration, privacy & security settings, browser compatibility, JavaScript issues, load performance and other areas of concern.

As the testing progressed, Frimerman quickly realized the benefit of having a flexible group of expert testers.

“For every test cycle we asked that at least half of the testers should be new,” said Frimerman. “The reason being was that we wanted at least some of the testers to be having their first experience with our product. That way we could avoid dealing with bugs that had already been reported, while also getting some fresh perspective.”