4

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 ?

8
  • 1
    Down voters, it would be more professional if you tell me, how i can improve my question ?
    – Jimmy
    Sep 26 at 23:26
  • 5
    There are grammatical issues, but I don't think downvoting it is appropriate. I've upvoted the question because it is generally understandable.
    – Nelson
    Sep 27 at 0:27
  • 7
    Why can't they change the test themselves? With you reviewing and approving their Pull Request of course. Sep 27 at 2:10
  • 2
    Eliminate siloed QA and have the front end devs responsible for front end tests?
    – mxyzplk
    Sep 27 at 12:52
  • It seems to me that there should be a way to automate fixing the tests. Sep 28 at 3:19
12

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.

3
  • Why should not I say that it is stressful ?
    – Jimmy
    Sep 26 at 23:40
  • @Jimmy, Do they stand behind you and wait for you to fix it when this happens? In any case, I'm not sure I agree with Joe. You can say it's stressful. But you could also say that these interruptions make you less productive, in addition to the extra stress they're causing you. Sep 27 at 2:15
  • 7
    @Jimmy the reason for stress is likely this: your other tasks gets postponed, and somebody is waiting for this. so the urgent renaming leads to delays. tell the manager about any delays. once the manager accepts the delays, the stress is off you. if he tells you to not do it on the urgent, the stress is also off you.
    – Benjamin
    Sep 27 at 6:20
11

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.

2

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.

1
  • I don't see what "metaphorically" is doing here. Sep 28 at 3:17
1

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.

1
  • I agree with this answer. However, I would make a different suggestions, sit down with the stakeholders and explains the reason changing the IDs are a problem. Once you sit down with the stakeholders, come up with a policy on what the names will be in the future so you avoid the endless cycle of changing (k9_field_01, not_a_dog_field_02) to (dog_field_01, cat_field_02). Or simply take the work load to your boss and ask what they want you to focus on
    – Donald
    Sep 28 at 21:01
0

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.

-5

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.)

5
  • 4
    our ids are static so they are not automatically generated. Also, we agreed that automation tests are necessary for this product. So, everything we did is correct. By, the way this is not a technical question. it is a question about team-work and solutions in work-atmosphere.
    – Jimmy
    Sep 27 at 0:48
  • 2
    If the IDs are part of the spec, then that should've been followed?
    – Nelson
    Sep 27 at 0:49
  • 1
    @Jimmy - What Nelson is suggesting is that if you guys have decided to use static ids, then perhaps a good approach to your solution is to suggest that the specs also define how ids should be named, so that changing them frequently on the whims of a specific developer doesn't break the tests or future code. This way, neither you nor the developers get to dictate anthing on either naming the ids or when they should be changed.
    – sfxedit
    Sep 27 at 7:38
  • 3
    Nelson, you are technically wrong. Automatic UI testing needs something that is predictable. QA and developers have to work together to create this. And it looks like the developers break things without any regard.
    – gnasher729
    Sep 27 at 9:39
  • If there are IDs that should not be changed, that must be part of the specification. QA can't arbitrary create failure cases like a misnamed ID. I can easily create automated test to test for a specific variable name, but if that's not part of the spec, that's wrong.
    – Nelson
    Sep 27 at 15:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .