How to implement automation when developing tests in parallel with development sprints

by Dan Martland, Technical Testing Director 

As we undertake many test automation assignments with a multitude of clients, we actually get asked this a lot.   

The key? To build things in a modular and well-structured fashion, working up from the generic to the specific. In most cases, the framework you are using will give you the fundamental components you need to navigate the app or system you are working on, like clicking a hyperlink or sending an API request. You then need to build on top of that for common actions or factors in your system, such as doing specific checks to make sure that returned value is right and that the system hasn’t raised an error. Then you can build on top of that again with more scenario focused components.  

That can be a more business scenario-style context, with things like login being a classic example, or even carrying out key activities like a product search or ‘add to basket’ in an ecommerce context. Or it might be a system-event context if you are looking at B2B interfaces – an incoming request via API triggering specific behaviour, that sort of thing.  

These can be built up into a library of common actions or events that have meaning and can be turned into key statements for Behaviour Driven Development (BDD) using the Given-When-Then structure.  

For example: given that I am a user logged in to the system, when I search for a product and when I click on the product, then I am shown the right description and the right level of inventory. You would have code behind the scenes which handles login, search, product selection, and ultimately checks the displayed information against the target value which might be either a pre-defined value or comparison of the value displayed versus information currently in the database.  

You might go as far as creating a mock or stub so that you don’t need to go to the actual database. That illustrates another potential benefit from automation – you can break dependencies with third parties or other components of the system, and both simplify your test execution and bring forward tests which would otherwise have to wait on something else being delivered.  

The key? Understanding how the system is constructed and then looking at how you can isolate the behaviour you want to test. This kind of very engineering-focussed testing can have lots of benefits.