WGU: Modular Based Automation with qTest Manager

Author: Paul Baker, Software Engineer II at WGU

The Problem

  • Write scalable and maintainable tests that are robust and respond well to change
  • Write a scalable and modular framework that is agnostic enough that we can add, extend, and retire components without major re-writes.

Why We Built This Integration

The WGU automation framework is built with a modular architecture. Taking influence from concepts that belong to both Object Oriented Programming and Functional Programming. This modular plug and play nature is used as an industry standard for software development and a practice used across engineering verticals. In the same way, an electrical engineer can replace a component with a Thevenin equivalent circuit, we design automation components with interfaces and abstractions that can be interchanged.

An example that many SDETs and QA engineers are familiar with is the WebDriver interface. Firefox, Chrome and IE are very different browsers. Yet, we can use them all the same way because the WebDriver interface provides an abstract interaction between a test and the browser itself, which allows them to be interoperable. This concept doesn’t make the code base future-proof, but it makes it future-robust. Maintenance can now be performed on all the mechanisms that run tests without needing to change any of the tests themselves.

We use qTest Manager in the same fashion. It is an another module of our framework. qTest Manager becomes the test result aggregator for all documented tests. We maintain automation for multiple projects and leverage the qTest rest API to maintain our association with a given test in code and a test case in qTest manager. This allows us to refactor and change code arbitrarily without incurring the overhead of maintaining test-case association manually. 

Any QA can run automation from their machine either from their terminal or their IDE. However, by furthering the idea of modularity we can make the automation tests themselves a component that can be an interchangeable piece of the process. To allow any user to run automation we front a web service that handles all the interactions that are normally associated with choosing and running automation. Ultimately this allows us to create a number of generic bamboo jobs that can run any number of tests without having to create specific bamboo jobs that need to be maintained separately and updated for different variations or combinations of parameters. (See Below) 

Tools Used

  • qTest Manager – Collects results from bamboo
  • Bamboo – Tests are running on Bamboo
  • Docker (Selenium Grid) – For Linux browsers
  • SauceLabs (Supplement our grid) – Handling Mac and Windows

Test Frameworks

  • Java Spring
    • This provides the glue and facilitates ALL the interactions with all other testing frameworks in a way that is industry standardized. (Not standard just to the domain to testing, but in the broader modular standardized way that is accepted by enterprise)
  • Selenium + Selenide
  • Espresso
    • I’m personally still evaluating this, it might change. It was just the first thing that was discovered to work with our mobile team. 

qTest APIs


Utilizing qTest has given us a way to standardize our test aggregation. We now have a single repository that acts as the ultimate source of “truth” for how to test an application, which is vital to the success of our organization.

About WGU

Western Governors University (WGU) is a private, nonprofit, online American university based in Salt Lake City, Utah. The university was founded by 19 U.S. governors in 1997 after the idea was formulated at a 1995 meeting of the Western Governors Association.

Powered by Zendesk