Quality Assurance And Testing For Follett Destiny Discover Universal Search
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.
Optimize and stabilize test automation workflow
Improve automated tests result
Enhance and optimize customer workflow
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.
From the technical perspective, the project includes
- Geb (browser automation solution)
- Spock (Java testing framework)
- Groovy (test development language for the Java platform)
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.
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.
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.
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.
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.
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
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
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.
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.
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