Well, testers will report whatever discrepancy they observe in the UI but the question is about the process of handling it.
Whatever is pushed in testing environment should be testable. You guys are doing it the right way by reporting everything. But, it seems like an issue with development process that is resulting in side effects and in agile they will just focus on current sprint.
And yes, UI testing is different from backend service testing, but with UI, the scope of testing of impacting areas is huge. So, regression testing plays an important role here.
First let’s discuss the problem:
Ideally, the side effects of the UI changes should be minimum.
Following the UI style guide, developers write common code. For example; code for website banner is common. Font site, hexadecimal code and other related UI aspects of a section are setup in a way that every developer can use it whenever working on the banner part. Such code does not result in side-effects. So, if you make any change to this code, it will only affect every place wherever the banner appears but nothing else.
So, I am somehow concluding that the development process has issues.
If a developer is working on a UI piece for which he cannot use already defined style then he will not directly write the custom code but will request the UI designer for it. Designer will do some research on already defined styles and suggest which one the developer should use or will create a new style that adheres to developer needs and will also specify which other parts of application can use this new style. In our project, there was a dedicated designer responsible for managing the UI style as the project was UI heavy. And whenever, he changed a particular style, he exactly knew which parts of the application would be affected because of this change.
Now talking about the solution, if your UI code is frequently impacting multiple areas of application then that’s absolutely is an issue with development process. If developers don’t know about these side effects then that’s an issue and even if they know but park the side effects to handle in future then that is also not a good approach. Your team definitely need to sit and and come up with some suggestions how this can be handled.
Apart from this, what I would suggest is to let the testers log defects for the impacted areas (it is actually good that they are doing it). But fix only defects that are in scope of the sprint. Then have a stabilizing sprint after every 3 to 4 sprints where developers don’t pic any new work but fix the issues that are open (which were created by testers as side effect of particular piece of code). They should log every issue that they see but should focus on working on the ones that affect the current sprint. Any issue affecting the current sprint should get developer’s attention.