I wish more teams could get past the split between roles with QA and DEV, that the idea was as evangelized as DevOps is.<p>IF your browser test isn&#x27;t written in high-level concepts (page objects at the very least), and if your developer making UI changes isn&#x27;t getting immediate feedback to also update the library of test code he&#x27;s affecting, yes, it&#x27;ll be fragile and will suck up too much developer effort. (I&#x27;ll stop short of asserting the opinion that the UI developer should be changing the tests&#x27; reflections of his UI components BEFORE making the changes themselves, but I don&#x27;t think that position is entirely unreasonable)<p>It should not be hard to find a balance of engineering practice (reuse, modularity, etc.) that gets you a degree of maintainability that is economical (utility provided by the system exceeds that consumed) -- just like any other kind of code.<p>Anytime someone messes with an interface, they should have roughly one place to adjust things for their changes. Dashboard controller and views get completely rewritten app side? Dashboard page object (maybe) gets rewritten test side.<p>Things should be written in the first place for maintainability -- XPaths&#x2F;selectors chosen carefully, using user-facing labels if possible, WITH collaboration from the UI side -- no stupid duct-tape shit because you don&#x27;t have a good way to get at something (like &quot;the fourth input following the
second instance of the word &#x27;Account&#x27;&quot;).<p>Like any kind of code subject to change, you must invest in engineering for robustness in the face of that change.<p>No, you can&#x27;t have a mandate from pointy-hair types to pour unskilled, unplanned effort into a system or practice because it sounds nice and expect to break even, but no shit -- that has nothing at all to do with browser automation.<p>Depending on the economics of the team, product, even the code-illiterate guys running the selenium recorder in another timezone and sending in bug reports any time it complains have their place (for instance, in a year-long release cycle of mostly stable line of business software where there are few UI changes because they&#x27;d require big change-orders and rewriting all the documentation) -- you have to design your strategy for your product.