How to Deal With Constant Changes in Automated Testing

Introducing test automation is an exciting time, however, if you’re unprepared for the changes it brings about, you’ll only be making matters harder on yourself and your team . There are a few common stumbling blocks when it comes to test automation. These include involvement, preparation the selection of tools at your disposal, managing the technical challenges at hand, creating an architecture for test automation and procedures for test data.

We’ll be covering these in greater details in future.

One extremely common concern when it comes to test automation is the need to rewrite many test cases when the system changes.

The solution is to create an architecture for automation where test cases are built up of smaller parts. This means that you will only need to change one place when the tested system changes.

Business Process Testing (BPT)

Business Process Testing is a technique to split test cases into a part per function in such a way that each step in the business process is automated individually and then reused to test the business process and similar business processes. Automation engineers create functions for each step of the process and non-technical testers or business specialists can combine steps to various test cases.

To understand the meaning, let us first clarify what is meant by a “business process”.

One of the first to describe business processes was Adam Smith, who wrote a famous passage that described how a pin was produced in a factory. He described it such –

“One man draws out the wire, another straightens it, a third cuts it, a fourth points it, a fifth grinds it at the Receiving top for the head: to make the head Requires two or three distinct operations: to put it on is a Particular business, to whiten the pins is another … and the important business of making a pin is, in this Manner, divided Into about eighteen distinct operations, Which in some manufactories are all Performed by distinct hands, though in others the same man will sometimes perform two or three of them.”

A business process represents a number of steps that together create a value for the user of the process. Let’s see how Adam Smith’s example leads to no clear process steps:

1. Draw Out Wire
2. Straighten Wire
3. Cut Wire
4. Point Wire
5. Wire gate Top
6. Make Pin Head
7. Attach Pin Head to Wire
8. Finished Whiten Pin

If this structure looks familiar, that’s because it should, as it is very similar to the structure of a test case.

By organizing test cases into business processes, even business-oriented users who do not fully understand code or testing tools can control what the automated tests will be testing.

Test automation is needed at all levels in order to ensure quality in agile projects but this is only possible if you think about the process and how to deal with constant changes.

From an economic standpoint automated tests become profitable after about 4-8 iterations, but the really big benefits of higher test coverage and increased confidence to improve and change the system to fit the needs are present from the first iteration.

Success in test automation is made much more likely if you follow these simple tips, although of course, the chance of success is largely dependent on the application to be automated and the involvement and skills of people involved. However, if your automation is set up correctly, you will find that you’re perfectly able and willing to deal with the constant changes that automated testing brings about.