When we talk about test automation, majority of the automation engineer tend to drawn towards standard approach of investing their limited time and effort on wildly popular UI automation. I personally have spent enough time to fairly evaluate both approach i.e UI automation and API automation. Investment in right approach will let you reap huge benefits and give you sustainable quality proof deliverable, checkout below article where I have covered my evaluation on this:
2 Likes
Hey Priyanka,
Welcome to the MoT Club. Is it possible to give or add some wider context to the post so an active discussion can occur? 
2 Likes
Thanks Jesse :). Appreciate your feedback
1 Like
My guideline is to not automate by UI what I can automate by API.
Also is the question if you automated check BY or THE api/ui.
Both are entry points to a, often complex, backend.
And can also be checked on its own.
We have UI automation which only checks that the client works, that different views can be opened.
Part of that is a working connection to the backend, but no check of the backend, the functions, itself by the UI actions and checks.
1 Like
Nice one, @sebastian_solidwork.
This reminds me of @mwinteringham’s TaTTu and TuTTu.
Source: Video.
- Are we Testing the API or Testing Through the API?
- Are we Testing the UI or Testing Through the UI?
I like perspectives here and glad that we all agree to common notion of what is emphasized in summary shared article. Moving as much as possible to lower levels than solely testing through GUI will save bucks and effort in many ways. This by no means indicates that we don’t add test for client at all but do it in meaningful manner and for cases which cannot be covered by API
1 Like