OmniTest – Parallel Automation Scripting Solution

Proper Disclosure

I am an active member of OmniTest’s development team, and have been for more than half a year. However, while I get paid for my development work, this article is unsolicited, and will not entail any monetary or other compensation from Omnisys or any other company.

Background

Omnisys, a leading provider of systems engineering, software testing and development solutions from Israel, has recently presented their PASS (Parallel Automation Scripting Solution) product – OmniTest.

OmniTest joins the growing marker of “automation wrappers”, which offer simplified automation capabilities for the manual tester. These are not automation engines per-se, but frameworks and automatic code-generators that use existing automation engines (e.g. QTP), while keeping them hidden from the user’s view. Basically, it’s all about putting a simplified and structured GUI mask on the raw capabilities of the automation engine.

Automation wrappers allow inexperienced users to generate lots of automation tests, in a relatively short time. This process allows companies to draw on their pool of manual testers to greatly expand their automated test coverage, which is usually sacrificed in building elaborate and robust automation frameworks. An example for a famous automation wrapper is HP’s BPT – Business Process Testing (though in my opinion, it’s quite clumsy).

I, and many of the power-users I know look down on automation wrappers. For us, they are too restrictive, and prevent us from reaching the full potential and richness of our code frameworks. While this is all true, most companies don’t have automation experts and power users to relay on. For them, automation wrappers present a clear advantage over building a mediocre automation array, which is bound to fail eventually.

OmniTest’s Concept

So, what could OmniTest bring into the market where HP itself is a major player? It is built specifically for its target users, which turns out to be a lot. All the “automation wrappers” I’ve encountered are designed for the novice automation tester. They talk of “object classes”, loops, recovery scenarios and flow-charts; completely forgetting the fact that their intended users are not automation programmers (who, as noted above, don’t care much for automation wrappers anyway), but your everyday run-of-the-mill manual testers.

OmniTest was built with the common manual tester in mind. It doesn’t speak of logic, methods or exceptions, but uses the everyday testing terminology: Test steps descriptions, and expected results. The user doesn’t build a “script”, but a regular test document, just like he used to when he was working in Word / Excel / Quality Center, or any other test documentation solution. The only difference is that the language used is a bit more formal (but still human-oriented).

OmniTest’s Test Document

When OmniTest saves this test document to QC / excel, it also generates the relevant automation code, building a corresponding QTP test that can be immediately run. This basically means that you get two for the price of one: for every manual test you write with OmniTest, you get a QTP test, with no additional cost.

This process solves another common problem (even with automation wrappers) – discrepancies between manual and automated tests. Usually, the manual tests are updated regularly throughout the AUT’s builds and versions, while the automated tests slowly become outdated. OmniTest solves this problem by providing a single point of maintenance to the test documents, and replicating the changes both to the manual and the automated test steps.

Using OmniTest

This review isn’t meant as a product walk-through or guide (for that you can go to the official OmniTest website), so I won’t go into all of OmniTest’s features and details. I’ll just do a quick introduction to the main work cycle with OmniTest, which is creating a Test Document.

OmniTest’s Main Screen

OmniTest’s main screen is divided into three main areas – the toolbar on the left, the step generator on the top right, and the test document on the bottom of the screen. We’ll focus on the Step Generator, through which we’ll build our test steps.

The step generator

The step generator is used to add step descriptions (i.e. the actions the tester performs) and the expected results of those steps – just like you would in any STD. Simply select the relevant option from the top radio buttons, and you’re good to go.

You can select an action from the available actions combo, or you can narrow the available actions list by first selecting a Category. OmniTest comes with many built in Actions and Categories, but you can easily add more of your own. Each action has its own set of fields, which complete it to a meaningful sentence (for example, in order to click a button, you must provide the button name). The entire process aims to be as familiar and immediate to the manual tester as possible.

Once all the fields have been filled, the full sentence is presented, and you can either Apply it to the currently selected step, or add it to the Next step. Repeating this process with many step descriptions and expected results produces a complete test document.

When Test Document is completed, you can save it to Excel / to Quality Center. Behind the scenes, OmniTest will produce the corresponding automated test, and save it alongside the manual one.

If and when you’ll need to update the test document, you can simply open it via OmniTest, edit and save it. OmniTest will immediately update both the manual and the automated test with the updated steps.

There’s much more to OmniTest than the short process I’ve reviewed here. You’re more than welcomed to find out more at OmniTest’s official website.

That’s too good to be true

Well, obviously, every structured process has its price tag. As all automation wrappers, OmniTest processes the manual steps and builds an automated script out of them. This means that the manual steps have to be written in a formal language (note that the actions are selected from a closed list), and that they have to be fairly simple and direct.

There is no overarching framework, no collective script memory, and no dynamic command editing. OmniTest’s killer feature can also be regarded as a shortcoming – it’s simple. That makes it the first automation wrapper which is specifically designed for manual testers – your test document is just a collection of test steps. Power users might find this laughable, but they are not OmniTest’s intended audience.

Omnitest does require an initial QTP mapping work on the AUT – building relevant object repositories and making sure the built in actions work out of the box on your application. What about complex and non-standard applications? Well, OmniTest can be easily expanded to work in these situations as well, though building the expansion will probably require an automation engineer. However, once the expansion is built, working with OmniTest remains as simple and as intuitive as before.

Summary

OmniTest is an automation wrapper which is built specifically for manual testers, rather than for automation novices. As with all automation wrappers, complex and robust programming possibilities are sacrificed in order to present a simplified and accessible system. OmniTest uniqueness lies in “going all the way” towards the manual tester, rather than presenting a hybrid which doesn’t serve the manual testers nor the automation programmers.

If you’re an automation expert, OmniTest is not for you. However, if your company is short on automation experts, and is seeking to quickly produce working automation test coverage for its AUT, OmniTest might be just the tool for you. Along the way it will help you solve other pressing problems as synchronizing your manual tests with the automated ones, lowering your maintenance costs, etc.

You’re invited to learn more in OmniTest’s official website.