Hello,
this is very complex topic and I am afraid there are multiple opinions and there is not any universal guide how to do a good automation. But, here are my two cents:
What UI developers must do
IDs. Trust me, it’s enough. If all HTML elements had their own unique ID, life of tester would be awesome. Unfortunately, this is ideal world and it is not viable. You should ask your developers to add IDs to (at least) inputs, all types of select boxes, divs (holding any kind of data to be tested) and so on. Ultimately, all object you’ll interact with should have their IDs (or most of them).
Note: It is possible to write tests even without any ID, but it is really hard to create and maintain such tests.
What API developers must do
If you are planning to test API as well, then API endpoints should return clean responses with correct status codes - most used would be 200-204 and 400-404. I saw many apps which didn’t care about proper 4XX codes, it just returned 400 (or 500 in even worse case) with custom message - that’s what you want to avoid. You want to easily verify expected API result from status code and response body is only a secondary test (even failure handling is a kind of API testing).
What is nice-to-have
Most of modern applications use asynchronous loading, what means it may be difficult to determine, when the page is completely loaded. This is a problem for automated testing, you must always wait for correct element in order to test it (or any other related object). You can challenge your developers to add a support for “load indicators” - hidden element, which is created when page or view is fully loaded and it is a green light for your test - as soon as element is present, you can start with getting data from a page, because you know that it is fully loaded.
What a good automation tester should do
-
Write robust and reliable selectors. Few tips here
https://docs.katalon.com/katalon-studio/docs/xpath_katalon_studio_tips.html
-
Write robust tests without false-positive results
The greatest danger of automated test is false-positive result. You’d probably never find the error in tested feature, when automated tests says OK. One of good ways to avoid such a situation is to use (I call it) failing conditions. (fail the test every time when very specific condition is not met)
if(responseStatusCode != 201) {
KeywordUtil.markFailed("Object was not created as status code is not 201.")
}
There is some chance of false-negative result (e.g. when your API returns 200 on successful POST object), but false-negative result is a way better than false-positive.
“It is better to manually re-test failed test than a hidden issue behind successful automated test” - Marek Melocik, 2019.
Everything else (design patterns, coding style, choosing which libraries you’ll use, …) is really up to every tester, there is not any good and bad answer. I can recommend page object model, but if other design pattern suits you better, it is perfectly fine. Just write great selectors and use them in reliable tests and everything would be fine.