From Ice Age to Avengers using Appium

Lessons from Kite’s Robot approach

Let me start here with a boring hook: my personal experience in testing an app manually. As product development includes delivery in bits and pieces, it becomes monotonous for a QA team member to perform the same actions again and again. Every time I had to test something, I needed a fresh user, and so I had to sign up a new user manually. It’s more boring than it sounds.

This is where automation comes into the picture. What if we spent time in writing a code that would do all this boring work for us? What if it also did this work accurately?

The QA Team at Kite conducted quite a bit of R&D to find the right tools. We decided upon Appium, since it:

1. Is open source
2. Doesn’t require the source code
3. Doesn’t need any instrumentation
4. Has tons of support material easily available

Appium might, regardless, feel like rocket science to most of us. However, if you follow a proper approach, it’s possible to take full advantage of its capabilities.

In this post, I will be highlighting the drawbacks of a classical approach to Appium, and how our Robot approach at Kite makes Appium a relatively hassle-free experience. We used the Robot approach on Kite’s first app, Kite Cash. It was launched for experimentation purposes, and ballooned organically into a network of over 100,000 users in more than 1,100 cities.

Classical approach

In general, a classical approach makes tightly-coupled code, which is not maintainable, increases redundancies, makes refactoring difficult and is not scalable.

With those limitations in mind, let’s approach Appium as a story.

Classical scenario

Consider a login screen with a username, password screen and login button. If I enter the correct credentials and click ‘Log In,’ then I should be be able to log in and see the next screen.

While thinking of a test, we ask the following questions: What do we want to achieve? and How will we achieve it? Our earlier approach tightly coupled this What and How pair. However, if this pair is kept together, it makes it difficult for a QA to maintain and scale scripts. The problem is, inevitably, business requirements change and we have to go and change our test due to this coupling. Here’s an example:

What is to be achieved: passing the correct username/password should take the user to the dashboard screen.

• Enter username “hulk@spiderman.com”
• Enter password “HS@1235”
• Press ‘Log In’ button
• Verify dashboard screen is shown

Consider the code:

Let’s see what problems exist in this approach:

1. There is a high level of code duplication, which further degrades automation performance.
2. The code above is not readable. In fast-growing companies like Kite (and many others), new members join individual teams all the time. A new member won’t understand this code and its purpose if they joined after the code was written.
3. We won’t be comfortable in managing this kind of code in the near future, when application workflows increase.
4. Any new UI changes incorporated are difficult to include in this kind of code, because a lot of refactoring — at multiple points — needs to take place for it to work again.

Clearly, the classic approach might look easy, but as soon as the features in an application increase, it becomes a headache to manage this code.

Robot approach

What if we followed a approach where we only concentrated on What do we want to achieve? and not How do we want to achieve it? We would then create different classes for How and What. This way both How and What categories will be independent of each other.

The Robot testing pattern is similar to the widely-used Page Object Model, which is a design pattern meant for creating an object repository for UI elements for web-based platforms.

Currently, we rely on a manual user to perform actions. What if robots did all of this for us? In the Robot approach, we know that the screen allows us to enter a username/password without concerning ourselves with where these values are going.

Robot scenario

A robot exists on UsernamePasswordScreenBot, which passes values in the username/password fields, and clicks ‘Log In.’ Now, the screen changes and this robot only has control over the UsernamePasswordScreenBot class. From here, another bot takes on, say, a ResultScreenBot to perform actions further on next screen.

In other words, create a robot per screen, and it will perform the required actions.

Sit back, relax, and let the robots work for you.

This code explains what we want, that is, to be able to enter a username and password that should log the user in.

Comparison

Let’s compare the metrics and performance changes in the classical approach and the Robot approach:

1. Code duplication is minimized, since we place element IDs in one class, and use the same class every time.
2. Code readability has improved, since a new member who joins the team can understand what this code is doing more intuitively.
3. Managing such code and adapting to UI changes are both now easier. Change code in one place, and this change reflects itself everywhere. Consider an example: in the login flow, the ID of an element changes or a new field gets added. In the classical approach, we have to make changes at each point where we are logging a user in. In the Robot approach, we will just add or edit the elements in the UsernamePasswordScreenBot class and call it directly from there.

Robot testing scope

At first, we may think that bots are not clever enough to complete a Sanity test or cover negative flows. However, your bots will do negative, Sanity and regression testing through code such as the one below — giving you a few extra cherished minutes to spend on your lunch break. For this we need to create different methods and pass content.

The above code shows how you can create methods for all kind of data you want to pass in a single class. The classical approach concentrated on what to achieve and how to achieve altogether. We need to get rid of this ‘How’ component to make things simpler.

Time savings and capacity building

We’ve saved a notable amount of time and increased our capabilities by moving to the Robot approach.

1. Our test coverage has increased as compared to manual testing.
2. We’ve decreased the time it takes to complete a Sanity from a full day to 5–10 minutes.
3. We’ve decreased script creation time by 50%, and have resolved the issue of scalability.
4. With the script approach, we can create a regression suite that makes testing simpler and more accurate.

Conclusion

Being at a startup like Kite, I’ve had the flexibility to try out new things and invest time in research — it’s because of this that I’ve been able to come out with a new approach for using Appium. I come across better practices every day thanks to the highly supportive team I work with at Kite. Through open exchange, we were able to innovate in a way that made our work more effective, efficient and fun. If your workplace supports it, I encourage you to organize knowledge sharing sessions, and set up dedicated hours every week to experiment on new techniques; it’s the most effective way to develop long-term strategies to keep your teams tight-knit and constantly innovating.