ERROR: Content Element with uid "13450" and type "dce_dceuid16" has no rendering definition!

How to be a good test automation engineer in five days

Nowadays software development life cycle shall become shorter and shorter. DevOps and Continuous Integration is a must.  So is test automation. However, the requirements are changing frequently at the beginning of the projects. Automated test cases would change so frequently that making them immediately is wasting time and money. What can we do?

The answer is better automation. Not only the test cases, but the test design can also be automated. There are several tools do this. Unfortunately, for these tools the learning curve is long. Their output may be manual or automated test cases. However, for automated test cases, you should have some development knowledge and when the specification is changing you shall modify some code. Script-less tools, on the other hand, need running application.

We introduced a new method Test Design-Driven Development, by which the whole development life cycle becomes shorter while improving the code quality. Here the test cases are generated from a test design specification, which is a simple extension of Gherkin language. The test design specification is a series of constraints such as

Gherkin – feature Login
Logged in:
WHEN Login name IS Hall AND Password IS 2@A9ih
WHEN Login button IS #pressed  
THEN Message IS successful login

From these constraints (accepatance criteria), the tools’ compiler can generate both manual and automated test cases. The automated test case is something like that:

SelectWindow( “Login” );
SetValue( “Login name”, “Hall” );
SetValue( “password”, “2@A9ih” );
ClickOn( “Login button”);
VerifyValue( “Message”, “successful login”);

Here  “login name”, “password” and “message” are keywords. Developers make their code based on these acceptance criteria. In this way, the test automation code can be generated from the implementation-independent specification.

The key advantage of this method is that test design remains implementation-independent, thus manual testers or business analysts can do it. Maintenance is cheap as only the specification is modified, while the executable test cases are generated. The extended Gherkin syntax supports describing test design specification in a hierarchical way. In this way you can design simple Gherkin descriptions which form very complx test cases. Another advantage is that when the code is ready so is the test automation code.

Zoltan Hraboszki

Zoltán Hrabovszki ist Berater und beschäftigt sich seit mehr als 20 Jahren mit der Automatisierung von Tests. Aktuell arbeitet er mit István Forgács an der Zusammenführung von BDD/BDT und KDT mit dem Ziel, die Aufwände für eine Automatisierung drastisch zu reduzieren (Test Design Automation). Er ist Initiator und Gründungsmitglied des Hungarian Testing Boards, Geschäftsführender Gesellschafter der Firma 4TestDev GmbH.