Sponsored

Automation projects have a lot of problems which are common across the board. With the open source world of Selenium and others, there are many common areas where every new person struggles with. A group of people working in the industry for years tried to solve some of these challenges in their own way and named it ‘TestProject’.

What is it

In a nutshell I understood it to be kind of a cross breed between keyword driven and record play back but very different in terms of how it codifies the steps, how it interacts with the browser, saving and retrieving test data and so on. While this is an important feature of the ‘platform’, it’s not the main one from what I see. An execution and reporting engine is separate and different than traditional ones we see. Lastly the feature I liked the most, ‘Addons’ which is which is more like Chrome’s ‘Web Store’ where folks can build components and share them.

 

Collaboration

I feel the challenges automation faces today are very real and complex, and about to become extremely problematic which new technologies surfacing where we are not sure even how to test those in person! It might be impossible for any individual company / team to have breakthrough and will have to be a collaborative effort. The pace of change in technology, fragmented industries and changing market dynamics for software products all are very surreal threats which bog down evolutionary process of automation.

The part which resonated the most with me about TestProject was it’s a platform, not a tool. It allows you to have your individual code base and a very easy mechanism to share any libraries you develop which might help others through ‘Addons’. This should make it easy for teams to create solutions which can not only be shared across teams, but also across the complete platform.

While libraries are the most commonly shared ‘reusable’ resource, the platform allows to share elements (for object recognition), applications, data sources and parameters as well. Something I preach a lot under the ‘reusability’ pillars of framework design is to make not only your methods reusable, also leverage every other aspect of the framework.

 

Setup

With open source tools running scripts on multiple platforms (different browsers, different OS combinations), different execution environments can be difficult to manage. To make things easy, we usually have pre-defined test environments (machines, VMs, SaaS like Sauce Labs, Docker) and port our code in those prepared environments.

While this in theory sounds great, at times takes a lot of resources to setup new environments. Not only that, there is an upkeep cost associated with it. Automation is juggling between AUT versions, platform versions (browser, mobile OS), and the automation tool versions. Not to mention other tools you might have integrated for CI and others. At the end of the day all of this takes its toll and can mount into a sizeable effort if not managed properly.

In TestProject setting a new environment for any desired platform is easy, like how vendor-based tools do it. Install their executor and it takes care of the rest. The difference there is in the process of the setup. This being a SaaS product, can open, compile and run on any environment which makes it very easy.

This means you can flip the situation. Instead of making execution environments at the center of the equation, make your code base the center of the equation and you can easily change any environment into an execution environment for automation.

 

Accessibility

Eluded in the previous point, code access becomes very easy. Not just code access, but accessing the whole eco-system is very easy. Typically for someone wishing to investigate the automation code base, they’d have to log into an automation developers or execution environment. Trying to do it on ‘any’ environment is not possible and often needs some setup to be done first (IDE, Pre-reqs, SCM and so on) Since TestProject is a SaaS product, you just log in from anywhere and you can see everything. The code base, test suites, test execution results, all in one place accessible everywhere.

 

Architecture

The keyword plus record and playback architecture is something the industry has struggled with for decades, and we still do. While almost every automation tool has a keyword driven or record / playback mechanism, which is mostly the focal selling point, there is a lot of snake oil in the industry around this.

The need for such a framework in an organization is a valid one, however creating one which can be plug and play for any product is impossible. In TestProject, there is an opportunity where experienced folks can ‘create’ components which core testers can use as building blocks. While this still might not be fool proof, I think it might be a step in the right direction and would help teams looking to create such a solution for their product.

 

It’s the start

While there are some fundamental shifts in the way TestProject is designed, it’s just the start. The success may hinge on how well it solves the fundamental issues it was designed to overcome along with adapting to the changing environment.