Neal selected AscentialTest because he recognized the potential for designing a class of solutions to solve a class of problems. He understood the power of building small, reusable components that could be glued together and scaled up to form a broad solution.

Using AscentialTest’s snapshots, he built a matching set of object definitions to normalize the thick and thin client user interfaces. This layer allowed all of the test components to be shared across platforms. Instead of having to build separate tests for the WPF and Web versions of the Dynamo GUI, he cut his work in half by building one set that could reference either object repository.

Neal also built a validation mechanism to ensure the integrity of numerous complex file conversions. His approach involved parsing data from the Chrome developer console and XML files stored in the file system and comparing sets of data to expected results. He also used AscentialTest image capture and compare features to ensure that graphics were rendered properly.

The ability to have deployed agents on various target machines was also an important component of the solution. Neal needed to ensure that he could drive the GUI hard and fast from multiple client machines in an industrial fashion, sending thousands of workflows through the engines to confirm proper allocation of memory and other system resources necessary for the system to hold up over time.

Because Neal’s solution is not embedded in the application code, he can continue to run the regression tests without being impacted by change as the back-end technologies continue to evolve or be replaced. He believes that one of the strengths of a productized offering like AscentialTest is that he is assured that his test assets are permanent. He cites a recent announcement that the Selenium ‘Keys’ command will be deprecated soon, making it necessary to modify tests to keep them running. Because AscentialTest is a complete solution, there is no need to search for plug-ins and apply workarounds. The Zee testing language is fully formed, and aspects of the product will not be deprecated in the future.

Starchive chose to implement AscentialTest based on the recommendation of Matt Osiecki, Head of Automation at LSTS as he saw the large benefits that Starchive would see by choosing this solution. Because of his recommendation, Starchive began utilizing AscentialTest. The initial automation build was focused on performance testing.

AscentialTest is now used to track performance times when uploading, downloading, as well as general page load times within Starchive’s application. The tests are run daily which document performance times in a client facing dashboard and the results are compared to daily, weekly, and monthly results. Any test results that are abnormal are automatically reported to the client within an “Automation” Slack channel. The performance tests are now able to run after any change in the application on both frontend and backend which allows Starchive to see the immediate performance impact of changes.

Another position in which AscentialTest is bolstering Starchive is in its ability to identify objects based on innumerable attributes such as color, position, webtext, parent objects, and others. Dynamic IDs which would normally break open sourced framework automation can be defensively defined within AscentialTest, giving it the definite advantage.

The ability for rapid development was another significant advantage of using AscentialTest. The test case creation and maintenance within AscentialTest proved to be much more efficient than when compared to manual or traditional automated frameworks.

Regarding maintenance, the tests built in AscentialTest are composed of steps and even sub-steps. These building blocks are then used across a variety of different tests. When a change occurs on the frontend, the step that is impacted can be updated, which updates all references and tests containing the step. Because Starchive consistently rolls out new features, a feature change that affects 1000+ test cases would take days to update within a manual suite, but can be done in minutes with AscentialTest’s prowess.

With reference to the creation side of things, Step, the building blocks of tests, can be reused within a test or across multiple tests. Once the steps are created within AscentialTest, it is a simple process to drag and drop them into a new test, instead of building an entire new test from scratch. This means that reusing previously created steps can  significantly reduce the hours spent on test creation.

Starchive also shows huge improvements in the verification process via AscentialTest. Before, verifying upload/download/management of thousands of files would be cost-prohibitive and nearly impossible, with the likelihood of  human error  if done manually. Now, a verification step can be created to verify a file’s image, title, created by date, along with 30+ other properties. This step can be rerun on every file uploaded/download/edited, verifying each file in seconds, while not consuming person hours.

Philips selected AscentialTest because they recognized the potential for designing a solution that could be used across platforms. Using AscentialTest’s drag and drop interface, the team uses snapshots to create object definitions that are recognized across all three platforms. They benefit from an array of options for defining objects that were difficult to recognize with other testing tools that they evaluated. Philips heavily relies on the ‘RenderText’ and ‘RenderImage’ capabilities of AscentialTest. ‘RenderText’ allows them to validate text that is drawn on scanned images. In the past, tests that require verification of that text had to be completed by manual testers. Vinay estimates that the team can automate 15% more tests because of this text recognition feature. Likewise, ‘RenderImage’ has allowed for the recognition of images for both navigation and verification of tests.

Because of the image-centric domain of PACS, Philips requires very sophisticated image ‘capture and compare’ capability. Zeenyx worked closely with Philips to enhance the existing image verification capabilities of AscentialTest. Several features were added to provide the ability to more specifically focus on the ‘area of interest’, apply masks, and tolerate for pixel and color differences.

Philips also cites AscentialTest data options as a critical component to allow the tests to be shared across platforms. By making use of ‘Project Data’, ‘Plan Data’, and ‘Attributes’, Philips is able to easily change key pieces of test configuration data in a single location to launch tests against different versions of PACS in the various test environments.

Vinay explains that the team creates two files for each page in the target application, one with the object definitions and a second with a meta-layer of steps for driving and verifying the application. Test developers use those components to build the automated tests via drag and drop.

Vinay says that the pace of automation has increased because of the reusable nature of the test components. As the more objects and steps are created, the time required to build new tests continues to decrease.

The bulk of the tests that the team has created to date are used for their ‘Smoke’ and ‘Regression’ tests runs. Recently they created a ‘Sanity’ test comprised of a handful of tests that were ‘ported’ to test six localized versions of PACS, created for different language markets. The team was surprised that it took only two days to port a test to all six languages using AscentialTest’s ‘Translate’ feature.

Gordon selected AscentialTest both because it provides support for PowerBuilder and because it’s easy to learn and use. Students were hired to convert their well-documented manual tests into automated tests. Gordon said that he spent only an hour or two training the students to use AscentialTest. Over the course of a summer, two students automated 1075 tests. The regression suite comprises a comprehensive set of tests that cover all aspects of the NDSR application. When the project started, NDSR was built with PowerBuilder 12.5, but was recently converted to PB 2017. Tests are separated into different plans by functional area. One plan, which runs for a couple of hours, generates a thousand reports which are compared to baselines that have been previously captured. Reports contain a large number of calculations that need to be validated. AscentialTest is used to find any differences that are later examined.