A smarter way of doing automation within the sprint (5 mins read)

Through this article, I am going to explain how to complete test automation before developers start to develop the application.

A Simple login module is taken as an example. Consider the below user story with 2 acceptance criteria (AC).

User Story - As a user I want to log in to ABC application using valid login credentials.

• AC1 – Until user enter a username and a password, login button should be disabled.
• AC2 – Once user enter valid login credentials and click on login button, user should be directed to home page.

This is the style guide provided from product owner. (from Google)

Definition of Done (DoD)

• Story should be implemented
• Story should be tested and test cases should be automated

As all of you know, automating all the test cases of a story within the sprint is a very challenging task. Therefore, most of the time automation tasks are getting spilled over to future sprints since the development is getting dragged till the last moment.

Let’s discuss a smarter way to overcome this automation challenge

As a tester, I have identified three very basic test cases to cover above ACs.

• Login button disabled check
• Login button enabled check
• Successful login check

It took around 10-15 min to identify those test cases and add to test management tool.

At this point even though the developer has not started the development of this login module, I have started to automate the login module.

What?? You mean to tell that you are writing automation codes for the application which is not even implemented yet??

Of course. That is what I am going to discuss here.

I have started to write automation codes from test layer. For that I have added “LoginPageTest” class and added three test methods with meaningful names where a non-technical person also can understand. Please refer the below screenshots for further understanding.

Once I have done implementing the blue print of the test case, I have committed the code, so that developers can refer it to get an idea about the testing scenarios. (They can cover those areas in developer testing to prevent defects)

However, you can see there are seven errors in my test class. Now I am going to fix one by one by adding required classes and methods.

I have created a “LoginPage” and "HomePage"classes and added required methods. Also, I have created “BasePage” class since I have extended page classes from “BasePage”

Now you can see there are only two errors (refer below screenshot) in "LoginPageTest" class.

Let’s fix them now.

Now you can see there are no any errors in "LoginPageTest" class. Please refer below screenshot.

However, still there are few errors in "LoginPage" and "HomePage" classes. Those are for element locators. You can fix these by adding dummy x-paths. (Please refer below screenshots)

Now you can see there are no any errors in automation code.

Stand up now, go to developer’s cubicle and have a chat.

Tester: Bro! Can you please tell me the id/name which you are going to use for username text box, password text box and login button?

Take those inputs and update your element locators accordingly.

Now you have completed your automation within the sprint and can be pushed to the remote repository.

Also this automation suite can be configured in CI/CD pipeline so that it can be executed against developer’s code of the login module.

We can cover a similar user story with automation within 30 mins. ??

Advantages of this approach.

• Tests are ready in early stage of the sprint, so developers could identify test scenarios clearly while developing. Hence developers try to make those tests pass.
• Clean and clear code (I have added only required methods in my java classes. So that there are no “method abc() is never used” warnings in IntelliJ IDEA.)

Enjoy!

Husny Jiffry

Senior Quality Engineer - Sysco LABS, Sri Lanka.