Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It only takes a minute to sign up.
Sign up to join this community
I'm new to testing. So let me know if I'm asking the question in a wrong way. I'm just curious about Web service and web automation testing.
Example : If there is a web service for calculating the sum two values and also a web page developed using that web service. Using the web automation it's possible to test the UI as well as the functionality of it.
So my question is, what is the point of testing web service separately?
Actually you should test web application after your WebService testing is done.
Web Service is an architectural pattern that just allows you to invoke the functions remotely using a widely known HTTP protocol standard (unlike some other remote functions invokations approaches). That is why the client (in your case - a web page) is just one of the possible ways how the functionality can be invoked.
In such the topology you should concentrate on Web Service testing primarily when you do a System Testing phase and use web automation as an extention to perform System Integration tests.
The above approach is worth using because of the client does not necessarily use the full range of the features web service provides. The user also is free to modify the requests the client sends to the service so that quite a big part of negative tests would also be missed.
Web service testing independently is needed to ensure the API calls working as expected independent of the web page. In this way, we can confirm that the API calls are working as expected irrespective of the web page elements/functions.
There are many points where tester doesn't feel confident about the application. When a tester performs Automation testing there may be many challenges so web service testing is still very important to know what they need to do, rather than doing it first to learn costly lessons later. The trick is to have an automated tool which can shorten the testing of web service.
Many different webpages can use the same web service. So you need to test both:
Web Services should be tested before testing the functionality via the user interface.
As per one of the articles that I read about web service testing; 70% of testing related to any functionality can be considered as Done if web services related to that functionality have been thoroughly tested.
Reasons for doing the web service testing prior to functional testing (there may be many though):
Many times, there are different teams working on the development of UI and web services.
The UI of the application under development is not finalized.
There may be other reasons as well but these two are on top of my head right now.
In above two scenarios, it makes a lot of sense to do the web services testing separately without waiting for the UI. So, that most of the issues related to web services are caught even before the UI is ready and integrated.
This saves a lot of time when the integrated application is tested from UI. This should ideally result is lesser defects during testing which further results in lesser rework.
And even if the UI is not finalized and is being changed continuously; you are still confident that there won't be any surprises at the time of testing because web services have been thoroughly tested.
However, in my opinion, it won’t be a huge value addition to test the web services if the UI is present. You might test a few things that a user is not allowed to do from UI but that doesn’t make a huge difference.
Essentially it all boils down to unit vs. integration testing.
Unit(component testing) is cheaper to test as it gives faster feedback which is very helpful in regression/maintenance/refactoring activities.
