What should I do if my colleagues make problem on my costs?

Question

I am a test automation engineer and I use Selenium to automate testing of our web interface application. I need to work with stable HTML IDs which are created by Front End Developers.

Unfortunately from time to time (once in a month) the Front End Developers change the HTML IDs to optimize their naming, which leads to the Continuous Integration pipeline breaking. They then come to me and ask me to fix the pipeline as soon as possible. The fix takes two hours, but it is very stressful for me to change my focus from my own ticket to their problem, and I get sad when somebody pushes me to do something ASAP.

I have discussed this problem with them multiple times, but it continues to happen again and again.

My understanding of the problem

I think the main root of this issue is that the Front End Developers do have any costs for making this problem. They break the tests and then simply push me to fix it as soon as possible. So, this problem should be fixed at my expense.

My solution to the problem

I think I should tell them that next time if they break the integration tests I will not fix it, or it would be my very last priority no matter how long would it take.

They can roll back their changes so the tests work as before. I already asked them to think twice about their naming of IDs so we do not need to optimize them.

Advantage and disadvantages of my solution

I think in this way they will learn that they should not break the test and then push their colleague. I am worried if my decision will disturb our team-work, or make them unhappy or demotivated. I do not believe in punishment but I need to somehow stop them.

What should I do in this case?

Alternatively, the Front End Developer who usually breaks the tests is leaving the team in 2 months. The other solution is to say nothing and just hope that, when he leaves the project, everything become fine. Is it a better solution ?

Answer 1

So, what should i do in this case ?

Single-handedly withholding your services, or deciding that fixing a broken build is your lowest priority doesn't sound like something you can decide on your own. This is particularly true when it happens just once per month.

Talk with your manager.

Explain the situation, how often it occurs, and ask what you should do whenever it happens. Then do that. Leave off the fact that it is "stressful" for you - it's not relevant to the problem at hand.

Answer 2

File a bug report every time this happened.

"The field "customer name" had its ID changed from "CustName" to "Customer Name", breaking the automatic tests".

"The field "phone number" had its ID changed from "Telephone" to "Phone Number", breaking the automatic tests".

Talk to your manager to get this bug report highest priority. And that's how you fix the problem from your side. I don't think (and I really hope) that I would never be so disrespectful to our QA team to break things and demand they fix it. If there was a sound technical reason to change these IDs then this needs to be organised and communicated to QA well ahead.

Answer 3

As someone in your exact position both in terms of job, and metaphorically I would advise you two things:

1. As others have already suggested, let your manager, and the FE team's manager know of this. And of why it happens.

   I'm actually quite surprised no one has already noticed the cause of this repeating issue and has put an end to it.
   (As a side note, "optimizing" names sounds like the FE developer is just making work for himself instead of doing actual value-adding work, especially as it's a routinely happening shenanigan).

2. If you want to take an initiative, suggest that aside from the usual HTML tags and attributes the FE developers need to do their job, all of you, i.e., yourself and the FE developers, agree on a special attribute, e.g. testAttribute that all the important tags get (it's up to you and the FE developers to decide what is "important tag").

   The rule is simple: once a tag has a testAttribute on production, the value of that attribute never, ever changes.

   So, if your table has a <td class="blah", testAttribute="aTestAtt">, the text aTestAtt, once it has hit production, doesn't change. Ever! Never!

   You can then model your test on the testAttribute instead of the "flaky" id or class.

Answer 4

As others point out already: Your proposed solution is detrimental to the whole company. You are intentionally blocking development processes which will result in missed deadlines. And you are preventing the frontend developers from delivering the best work they can, because you are discouraging them from fixing minor problems (like inconsistent id names) before they accumulate and turn into bigger problems (a huge mess of an application nobody can maintain anymore).

I would suggest a different course of action.

If you trust the frontend developers enough to not screw up things too badly, you might want to consider to enable them to fix such problems themselves. When you give them the access rights and necessary knowledge to make such changes to the integration tests themselves, then they no longer need to bother you when they break a test in such a trivial manner. They also become more aware of the cost of such minor changes for the CI pipeline when they are involved in the process of fixing those themselves.

Further, actively sharing your knowledge is a great way to improve your visibility in the company, and increases the bus factor of your position.

Answer 5

For the purpose of this answer I will assume that you really need the ids to stay the same in order for the tests to keep working. Also I will assume that the developers have good reason to change these ids now and then.

Working from there my solution is the following.

• The developers can change the ids, however they have to coordinate when they do this with you.

• If the change the ids without consulting you and this causes your tests/the build process to break, you will rollback all their latest changes and revert to latest working build. After that it is on them to check in their latest code without this breaking the build process.

Answer 6

You're not building the automated tests in a robust way.

I'm a front-end developer, and you cannot rely on IDs due to them sometimes being dynamically generated by the framework (I'm surprised you haven't encountered this: WhatsApp web is like this). Also, a normal end-user never interacts with the website via an element's ID alone, so that's not a proper way to perform automated testing.

You can, however, switch to using XPath element targeting using contains(), which allows you to target an element based on the contents. You should be targeting based on visible elements of the UI, like the menu name, and relative paths like the sub menu of another element, to do the automated testing.

Another way to think about this is like this. Does it make sense to have automated tests for a specific variable name? That's IMO what the IDs are. They're just "variable names" for the elements. If your test code critically must use specific IDs, then that should be part of the specification, but it is also an indication of incorrectly made code and specification (improper encapsulation, access methods, etc.)