First time
I heard about Worksoft Certify was a short introduction to it in a presentation
that showed the new trends within software testing.

The promise
of “scriptless automated testing” seemed like a good portion of sales
grease, because I’ve heard of “scriptless” testing before, and as you
might have guessed, they were not scriptless at all, but simply capture/replay

I then saw
a video, and yes, it seemed that it was true – no scripting – not a single line
of code!

Even then I
was skeptical – could it really be true?

Then last
week, finally, I got my hands on the product as I attended a Worksoft Technical
enablement course. There it was the mystical product that kept stating that no
lines of code were used / generated.

And yes, it
is true – someone heard my prayers smiley

Certify does not generate code, you don’t need to know Java, VB scripting, C++
or whatever language regular automation tools are using for their scripts.

That being
said, I will emphasize that knowing just a slight bit about programming is definitely

So how does
it work?

Certify is a “fat client” which needs to be installed on the machine on which
you will create and execute your test connecting to the product database in
which all the objects, processes etc. are stored.

From that
client you create your process. “Proces? I thought we talked about testing,
creating scriptless testscripts?” – well – I had to swallow that one as well.
Proces is testscript! This naming, and here I’m guessing, are named due to the
fact that Worksoft Certify was built for testing SAP solutions. So they use SAP

But back to
the product. You create a new process, name it, save it, go to steps, right click
in the steps window, choose New, in the field Application Version you choose
Select using LiveTouch. And then you are off and away – easy as that. From here
of you record your movements in your SUT (System Under Test), after recording
your actions and your checkpoints you then modify your “script” steps by adding
variables where needed, set up test data that you need for your variables, and
then you can run your automated test.

After a few
hours of working with the product I could create quite advanced test scripts,
which will work every time, now, and in a year. I was amazed!

Yes, it is originally
made for SAP but you can test HTML, .Net applications and a lot of other stuff,
as long as it is GUI based.

Being built
for SAP it “plugs” in to SAP Solution Manager, you can import requirements and
test scripts from SAP and export reports back to the solution manager. If you
set it up together with RQM you can actually export the SAP blueprints, get
your requirements in automatically, get test plans and test cases created
automatically, then you can add your test scripts (sorry – processes), run them
– report back to SAP solution manager, log defects in the SAP solution manager
incident handling etc. – AWSOME!

A very
smart trick in Certify is that it knows the SAP objects, and it knows them by
version, so if a new version has update, added or deleted objects Certify knows
that, and will inform you about it! We are talking about semi-automated script maintenance.
How would a changed object be handled in an old-school test automation tool?
You would have to find every single script where the object is used and modify
the lines of code. Here Certify automatically updates the object and then you
again can run your script – and it still works!

Another thing. You can reuse your processes, use them as child-processes. For instance Log in is the same for all functionality in my application, and I can therefore create a process that runs the log in and add that as a child process to my other processes, creating easy to maintain end to end test. Because, if something changes in my log in porcess, I simply change the one process and all of the processes where this process is a child to will now be running by the new changed process!

So my
verdict? well, I think you already know that;

I’m impressed! It’s by far the most innovative
tool I’ve seen in many years!