1 312 757 4944

Quality Assurance And Testing For Follett Destiny Discover Universal Search 

Test Automation Framework Evolution  

 

Background

Making 140 year history, Follett Corporation is the world’s largest source of books, education materials, and entertainment for Pre-K and K-12 schools, districts, and colleges and higher education campuses. The Company provides various technologies and professional services, print and digital sources both for students and teachers.  

Considering one of Follett products, Destiny Discover is a focus of much attention. This Follett ebook software is an interactive environment that enables users to book materials, create notes and bookmarks, as well as share them with other members. Being introduced in multiple application, target users may install Destiny Discover for Kindle, Nook, Mac OS X, Iphone/ Ipad, Android, Windows.

Follet Corporation has partnered with Forte Group Quaility Assurance and Testing team to achieve A-level product operation.

Business Goals and Objectives

  • Optimize and stabilize test automation workflow

  • Improve automated tests result

  • Enhance and optimize customer workflow

Challenges

When Forte Group took over this project, Follett Destiny Discover already had a few hundreds of automated tests, but they were extremely unstable and the results were only understandable by savvy QA automation testers.

How the initial automation test framework looks like

 

From the technical perspective, the project includes

  • Geb (browser automation solution)
  • Spock (Java testing framework) 
  • Groovy (test development language for the Java platform)

Density Discover is stuffed with JavaScript and that is the reason Forte Group QA and testing team chose Geb as the browser interaction tool to handle Angular forms on JavaScript.
Spock Java testing framework was used as the test and specification framework, so we combine the benefits of behavior-driven development and embed pure Groovy code right inside the test specification.

Solution

 

C
Core Application Program Interface for Test Automation Framework

First of all, Forte Group QA and testing team redesigned the existing automation framework to follow the User Interface (UI) of the product. A separate layer with hierarchy of pages and dialogs – according to the appropriate UI objects – has been created where generic code used to be. The maximum effect was gained from code reuse, which was especially valuable during the refactoring of the tests. Secondly, a layer of business related objects (User, Book, Bookmark, Note, etc.) was added. That layer helped ease the operation with sophisticated use-cases where the same entity was modified a few times, or used in multiple places within the same flow.

Tests Restructuring

 

L
Logging And Reporting

Initially, test results were available only from development environment and provided very poor information on test execution. Thanks to the extendable Geb architecture, we added a custom NonEmptyNavigator extension that allowed us to log every interaction with each control via Slf4j. Therefore, after each test execution we had an appropriate log file (per-test) with all valuable events. Regarding the reporting part, the default xUnit xml report (generated with Spock) was not clear enough. We wrote a custom Spock extension to generate an informative HTML report that could be clear for any team member.

Tests reporting and logging

A
Automatic Tests Pre-Setup

Additionally, the original tests were hardcoded with particular test-data right inside them. That caused it to become very unstable when a test broke something required for the next one. As a solution, we decided to move the test setup to database level. In other words, every necessary test object (like users, books, bookmarks) was loaded into a database just before any particular test execution.

Test data load


We were able to benefit from the introduction of the business objects layer at an early phase (building SQL queries became really simple). With increased test stability we could also accelerate the performance because most of the steps that prepared the test data via UI were replaced with quick data-loads.

C
Continuous Integration Implementation

As soon as tests became much more reliable and results were presentable, another problem arose: how could we share information with other team members? For this purpose, a few Jenkins jobs were configured for environment deployment and test execution. That allowed everybody to access nightly test-execution results as a user friendly html page

Continuous integration introduction

 

S
Scalability

Throughout the process more tests were implemented and our framework grew from a few hundreds of tests to more than a thousand. Moreover, new requirements came up – we needed to run tests against multiple browsers (Chrome, Firefox, Internet Explorer), and cover the same tests with other UI wrap. With new tasks came new issues. We had to figure out how to parametrize test execution for testing in different browsers / UI environment combinations; and speedup tests. Therefore, test execution time took three times longer. As a solution, we used Gradle instead of Maven, the old built system. Gradle is much more flexible for test execution parametrization; it allows custom scripting using Groovy with built files directly. Additionally, we configured a multi thread test execution (up to 6 parallel threads) on Gradle. We were eventually able to get a snapshot of a product status on any required environment or browser combination in less than an hour

Selenium grid implementation


The test automation framework structure was also redesigned. The project was split up into multiple modules. Common code was moved to the upper level so that it became possible for us to reuse generic logic and extend it for specific tests in particular subprojects.

M
Mobile Platforms

As the time goes by, new technologies bring new areas for coverage. Nowadays, clients want to cover mobile platforms with the same automated tests, but there is a persisting problem: there is not only a web-based version of the reader, but also a hybrid mobile app. To address that concern, we used Selendroid, a tool that implements a WebDriver client and API with the necessary hardware for Selenium grid android devices to be freely used in the same way as Internet Explorer or Firefox browsers from Geb. Reusing modules with common code, plus the possibility to add a few mobile-specific changes gave us the chance to perform the same set of tests for mobile platforms with lower pain.

Final test automation framework structure


Result

As a consequence, Follett Destiny Discover is provided with the advanced and accomplished automation testing framework that enables a Product Owner to hold in check application availability and operations. In this way, end user is released from unexpected errors and failures.

Get in touch with Forte Group QA Team Lead

to discuss quality assurance and testing services for your product

Industry

Education Management


Service

Quality Assurance And Testing


Technologies

Java/HTML, AngularJS, Groovy, Geb, Spock, WebDriver, API, Selenium, Gradle