Asking behavior change to allow easier testing

Question

I'm a QA engineer (the first and only one in my workplace) and I'm trying to automatize tests using Selenium + Java.

I'm working on an application where there is a calendar use to select the user birthdate.

In order to enter the birthdate, you have to click on a calendar picture (which will display a bigger calendar), then click on a year, then click on a month, then click on a day. So, it's a minimal of 4 clicks (but you are probably going to need more in order to select your correct birthdate).

I'm kind of new to Selenium, but since there aren't any ids on the calendar (nor name), I already know that I will need quite some time in order to automatize this (directly entering the birthdate is impossible).

Knowing this, would it be reasonable for me to ask (and push hard) so that the behavior of the application will change and would allow users (and me) to directly enter there birthdate?

And is there something I didn't think of that will allow me to more easily select the date on the calendar without changing the application behavior? Like making java change the html in order to enable the input linked to the calendar (so as to allow me to directly enter the birthdate)?

Answer 1

You should always be able discuss making the application more testable. Even better might be to pair implement the test with a developer, so they can feel the struggles. In agile teams creating enough test coverage is a shared responsibility. Working closer with developers is a must in my book, but also letting them implement and maintain end-2-end tests as well.

From a technical perspective, the calendar eventually populates a hidden input field. Try to fill the field with the JavascriptExecutor. I would only do this if the calendar widget is part of a well tested framework/library. If it is a custom inhouse widget I would prefer to have some tests use the actual component.

Answer 2

Have a think around the problem.

There may be no names or IDs, but as it's a calendar it's presumably showing text on the popup / overlay. As such you can can grab the overlay and then look within it for something like:

driver.findElement(By.xpath("//span[contains(text(),'2019')]");

Then do the same for the month / day.

There's usually something you can use to get a unique path to the elements for calendars.

Answer 3

I think you need to check before why is the input blocked, was this a requirement during implementation ? If so it might be harder to change it.

In case it wasn't in the requirements speak up and explain the gains you can get if it is changed. Communication is key in these types of situation.

With new developments just try to anticipate your needs and request the necessary changes while the development team is still working on it.

In terms of implementation I personally like to follow what the user is capable of doing even if it takes a bit longer to automate, it makes it in my perspective more realistic.

Answer 4

Well, in your particular case (if I am getting you right) you're talking about changing user experience because of bad tester experience. This is what one should avoid. Because adding additional field means changing user experience that could not be so well met by the users (for example because it will change the element aspect ratio which will make elements look less nice or because it will make the user use the input methods which are not very convenient on their particular devices)

However if we're not talking about UX this is the normal practice to improve testability of the application from dev side. They could add id's or assign cells with coordinates or use other approaches to improve control element location without changing anything from user prospective.