How to convince your colleagues to write automated tests or why would you use Cucumber as an automation tool

How to convince your colleagues to write automated tests or why would you use Cucumber as an automation tool

How to convince your colleagues to write automated tests? I think that a lot of people have asked this question and probably already found a dozen of correct and incorrect answers. In this article I’ll try to describe the way, how the automation framework was successfully implemented for several teams in different companies. Also I’ll speak about the reasons why you might use Cucumber in a wrong way.

Project setup:

It is good when your project has a dedicated team to write automated tests. By a dedicated team I mean a team, which has a set of technical skills that corresponds the project needs. But it is not what happens in the most of the projects I’ve seen. Automation often comes later in the process and is implemented by developers or Test Engineers who have at least some automation experience. Of course, that is a valid scenario. But what are the downsides of this setup? First points that come in the mind are:

  1. Not all the Test Engineers have necessary technical skills to start writing automated tests.
  2. Developers write tests that nobody but they can understand and maintain.
  3. Test engineers and developers are not convinced that this automation actually makes sense.

As possible outcome you can have the test automation framework, which nobody can trust and keep it running just to follow the process rather than find bugs.

Who is writing tests?

After several tool evaluations, a key question appears: who is writing tests? From my personal opinion, developers shouldn’t write automation tests. Test engineers are the persons who can design good test ideas and also add details to it while writing an automation script. From my experience, developers are not the right persons to write automation, as mostly their tests end up in checking happy paths. Fortunately, other team members have agreed with it. So, having that clear I started thinking about the Cucumber.

Cucumber? Really?

When I came with the Cucumber idea to the next meeting, I got quite a negative feedback on this tool. One part disliked Cucumber as they had negative experience with it, because nobody had reviewed Cucumber steps as a part of documentation. The other part (mostly Developers) didn’t see a point of Cucumber. They didn’t want to have additional framework that would make their lives harder. One way or another, everyone has seen Cucumber as an overhead under actual automated tests.

Despite of the feedback on Cucumber, I proposed the solution that could be a compromise for everyone. So, we have come to the following agreement:

  1. Tests will be written in Cucumber
  2. We’ll write tests in the way that is convenient for our project and will not follow every of Cucumber principles
  3. We’ll not use Cucumber as a feature documentation
  4. Feature files should be written by Test Engineers
  5. Step definitions may be written by both Test Engineers and Developers
  6. We’ll implement page objects and use them in Cucumber steps (Note: You’re interested in page objects examples and best practices? You can read about it in this article.) 

Why did it work? In this setup: we are not using Cucumber as documentation; Developers will touch the code and not Gherkin steps; Test Engineers will not have to go deep into details and write tests in human language.

Not following Cucumber principles? Are you nuts?

As we don’t want to use Cucumber as a collaboration tool, we will use separate step for the interaction or assertion, as it would be in an regular automation tool.

You’ll say that Cucumber shouldn’t be used like that? Yes, I know. In the beginning we tried to make tests compact and readable but that made our step definitions full of duplicated actions, as we have thousands of page objects and long UI flows. So, we chose maintainability over readability. Also, why should we add a layer of complexity for collaboration that will not happen? Our main goal is the automation of our application. Readability of business flows is on the 2nd place.

This way of using Cucumber did work for us but I still had a feeling that I was doing something wrong. As soon as I had a question to the Cucumber community, instead of getting answers I got the link to this article: The world’s most misunderstood collaboration tool. Luckily, I had a chance to attended Automation Guild Conference, which content was extremely useful, and I strongly recommend to attend the future events. So, there I had an opportunity to ask Matt Wynne about our case. Matt is the lead developer and co-founder of Cucumber Limited. He confirmed that Cucumber wasn’t designed to be an Automation tool only, and automation is not the strongest part of it. But they are happy if it works for others in a different way and nobody will blame you for using Cucumber as a poor Automation tool.

Why using Cucumber at all?

What is the point of using a tool as an automation one if it wasn’t designed for that? The practice shows that Cucumber steps are very good entry point to automation. Even a non-technical person can easily start writing steps, when step definitions and page objects are in place. You don’t have a feeling of doing something complicated, as you write your steps in human language and launch tests using a Play button in your IDE or dropping a line in the command line. Also, Cucumber is a great option for new colleagues. It is easier to understand what is happening in existing automated scripts or write a new one using existing patterns.

Here is a short example of using Cucumber in a “wrong” way with reusable patterns:

Scenario: Accepting the Event from events list
Given I login on default system using EventsAcceptingUser
When I open Events section
Then I see EventsScreen.recommendationHeader element
And I tap on EventsScreen.acceptButton
Then I am on YourEventsScreen

All the bold parts after Given/When/Then are the user data that comes from your data files (credentials or page objects). As you can see, it will be really easy to write another user flow using these patterns. All you need is to change user data to click another buttons or login to another user. For example:

Given I login on default system using EventsHostUser
When I open Events section
Then I see EventsScreen.myOwnEvents element

You can find a small mobile automation sample project with the same Cucumber approach in this repository. The mobile project itself is explained here.

Which programming language to use in your Cucumbers?

I might sound a bit subjective, but I think, that Ruby is the best language you can use in setup I have described above. Of course, there can be situations where your tests should use pieces of production code. In this case you’ll have to use the same language that your code is using. But in the situation where you’re starting from scratch and you don’t have experienced Test Engineers in one of the languages, Ruby looks like the best alternative. In Ruby you don’t have to use classes, constructors and other stuff that can look like something complicated for non-programmers. You can write procedures and use conditionals in any part of your code. It sounds simple, doesn’t it? Also in Ruby you can do a lot with writing a few lines of code that is not the case for other programming languages like Java or C#.

Results:

The fear of writing “complicated” automation scripts has disappeared after basic steps and page objects were implemented. Test engineers from other teams have started to write their tests and improve steps base.

I recommend trying Cucumber and you’ll see how fast and easy you can start writing automation tests using this tool.

 

One thought on “How to convince your colleagues to write automated tests or why would you use Cucumber as an automation tool

Comments are closed.

Comments are closed.
Skip to toolbar