Speak the same language

When you start defining your framework for automation, a very important decision has to be made. Which language am I going to use to write my automation scripts. This can be a though decision, so investigate this thoroughly.

What I’m going describe is a decision me and my team (testers and developers) made when we started to set up our automation framework for our mobile application.

The mobile application we are building is developed on two platforms or operating systems, Android and iOS. So the first question, “Are you going to buy a tool that drives both platforms?” This can be expensive and in some cases difficult to maintain. There are some open source tools you can use, but you have to rely on their maintenance support when you encounter some problems with the tool.

Most of those tools have their own language. There are tools that uses Java and that is the coding language for Android, but it will not work for iOS. Some translation is needed as the tool has its own language and needs to translate the requests to Android and/or iOS.

This can give some serious problems when debugging is needed between the automation tool and the mobile app. Developer and automator speak a different language and it is difficult to determine who needs to change to make the automation working (again). Hence, a developer will ‘never’ be involved in automation.

The situation is different when the automation is written in the native language. The automation scripts are written in the same code as the application. The developer even can write the automation scripts.

As you write your automation in native code, that means that for your automation you have to create an Android script and an iOS script. Is that a problem? Perhaps. But you have support from the developer when needed.

To make automation steps transparent to the stakeholders, you can write you automation scripts in a domain specific language. This is a language that everybody can understand. An example of that is Gherkin. In a Given – When – Then fashion you describe a test to be executed. A challenge for the automator is to find means to drive to mobile app by using these Gherkin scripts, also known as feature files. By creating some specific code, a line from the Gherking script is parsed and converted in an actionable item to drive the App on the mobile device.

An other way to do this is to create an automation script for an actionable item for each OS separately but with good framework agreements you can reach a level for which your scripts are written in your own domain specific language. Classes, methods and functions will be readable and reusable.

Further, a third party automation tool can be vulnerable to changes on the iOS or Android operating systems. If the operating system changes significantly, some conversion scripts need to be created/written to update the existing automation code.

If you look it from another angle, the tester and the developer can work together easily. The tester can get involved in the creation of unit tests or UI tests. Hence, the tester can even write those tests by pairing with the developer. In the mobile world there is a big challenge for the tester. The tester has to learn two languages, but with the guidance of the iOS developer and Android developer, the tester can do that.

On the other hand, the tester will get in depth knowledge which tests are done during unit test and UI test. The tester can make sure that each UI test is covered on both platforms. For unit test this is a bit more complex, because unit test can be code(-language) specific. Still it’s doable.

By learning how to read the code and do some coding yourself as a tester, debugging on code level will become easier for a tester. When the tester finds a problem, some root cause analysis can be done by the tester. The tester can do some pair testing with the developer to go in depth to investigate the problem and find the root cause.

The ultimate step will be that the tester is doing the root cause analyses and comes up with a fix for the problem which can be code reviewed by the developer. When the fix is accepted the code can be pushed to the main develop build or the production build.

So, I see a lot of advantages for a tester to speak the same language as the developer(s) in your team. You will get support for sure from them, while learning and improving your coding skills.

One Comment Add yours

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s