[Day 2/5] APIvsUI - Define what API testing / UI testing Is
What a great start of the event! I’m so excited to see all the participants.
At the moment, the API and UI Teams have the same number of points! Let’s see if the situation changes today.
Day 2 Task:
Define what API testing / UI testing is.
Here are just several things that you can cover in your answer:
Why is it important to test?
What are the major elements of the testing process?
Is automation a “must-have” nowadays?
Also, don’t forget about bonus tasks to earn more points!
We are looking forward to reading your comments here.
Accomplish any of the bonus tasks to earn more points:
- +2 points - Invite your colleague to the competition.
Mention a nickname of this person by using @ in the competition’s daily topics. You can invite as many people as you wish. NOTE: A person you invite should be a new Community member registered after the event start.
- +2 points – Make a post on social media about your participation in the competition.
Your post should contain: @SmartBear, the #APIvsUITesting hashtag and the link to your comment in the Community.
- Leave your comments on a conversation of the day. 1 comment = 1 point to the team score.
- The competition will be held on March 25-29.
- Join the competition any day and participate in any daily conversations.
- Feel free to leave comments for any teams.
- Rewards! A team with the biggest score will win. Active participants from each team will be rewarded.
Participate in all conversations – find them using the #APIvsUI tag.
SmartBear Community and Education Manager
Our AUT is integrated into multiple downstream applications where it uses parent application 's API to communicate and get data. It is important to test the sample API call in multiple applications. We thought it is a good candidate to automate.
Example: Downstream application will post a request to the parent about User permissions and API should respond with valid and corresponding permission details. AUT has around more than 100 types of permission which combinations come around 250+. In this case, manual testing is a hard/dull process.
Solution with Ready API: Created a test case with all the combinations in the data-driven approach and It will execute. This way automation covered all different combinations and validated every single combination.
This gives us a lot of meaning on the ROI and making a solid statement on the quality of the product. When it comes to this kind of scenarios then Automation is the best and "must-have" one.
Microservices (APIs) basically define the business logic of the application being designed. And web API is a server-side interface that contains endpoints that relay information through request-response protocols.
Now, the question is why the testers require to automate or manually test the APIs:-
It's because for "Complete Coverage" . !!! UI testing, either manual or automated, is still just testing the presentation layers to make sure the end user experience matches expectations and meets functional requirements. But, in API testing we have to check the major thing which can be called as white-box testing. All the client requirements and business development criteria has to be checked here. And also, clients are really worried about these things. Another better things is, in the era of AGILE testing approach, we will have to wait for the product to be developed and then UI testing. The API testing can be done ahead of UI availability. That's the most important criteria which keeps API testing always on top of UI testing.
The major elements of testing process are:-
- Test Strategy or Test Plan
- Test design
- Test Execution
- Test Closure
And YES, automation is a must for any testers whether they belong to manual or automation dept. The demand of test automation has continued to grow and now some teams are completely eliminating manual testers and hiring only testers with test automation skills including manual skills. This is because of the continuing shift towards AGILE development, which includes whole team approach for quality and test automation for continuous integration. So, YES, if you call yourself a tester, you should have automation/manual both knowledge.
With the emergence of extreme programming, test-driven development and other agile methods, UI testing have become an important part of almost every QA effort. At the same time, many applications provide application programming interfaces (APIs) to allow code-level access to functionality. These APIs, just like any other interface into the product, must be tested before they are released to the end-users. This article will examine the key similarities and differences between these two types of testing, focusing on the tools, the people involved in each, and the approaches taken to get the best results for your time and effort.
Since both API-testing and UI-testing target the code-level, we can use similar tools for both activities. The most commonly used UI-testing tools, such as the JUI test framework, can also be used to build your API testing harness.
In many organizations we’ve worked with, the UI testing and API testing activities are owned by different teams. UI testing is almost always an activity that is owned by the QA team; developers are expected to build UI tests for each of their code modules (these are typically classes, functions, stored procedures, or some other ‘atomic’ UI of code), and to ensure that each module passes its UI tests before the code is included in a build. This practice makes a lot of sense because it helps the developers solidify their code. Often times, this effort requires debugging and bug-fixing in real-time.
API testing, on the other hand, is typically an activity owned by the QA team, staff other than the author of the code. API tests are often run after the build has been created, and it is common that the authors of the tests do not have access to the source code; they are essentially creating black box tests against an API rather than the traditional GUI.
Another key difference between API and UI testing lies in the test case design. UI tests are typically designed by the developers to verify the functionality of each UI. The scope of UI testing often does not consider the system-level interactions of the various UIs; the developers simply verify that each UI in isolation performs as it should.
API testing, like other activities owned by the QA team, must consider the ‘full’ functionality of the system, as it will be used by the end user (in this case, another program). This means that API tests must be far more extensive than UI tests, and take into consideration the sorts of ‘scenarios’ that the API will be used for, which typically involve interactions between several different modules within the application.
So if your product contains an API that must be tested, how should you approach the task? First of all, recognize that API testing is a testing activity that happens to require some coding, and is usually beyond the scope of what developers should be expected to do. The testing team should own this activity. Secondly, recognize that traditional testing techniques such as equivalence classes and boundary analysis are also applicable to API testing, so even if you are not too comfortable with coding, you can still design good API tests. Finally, recognize that you will not be able to test all possible scenarios that are possible to use with your API. Focus your testing on the most likely usage scenarios, and also apply techniques such as Soap Opera Testing and forced error testing using various flavors of data type and size to increase your confidence in the test coverage.
I kind of jumped the gun on day 1 providing my view on UI & API testing it seems :
... choice for me personally is API testing, seeing it enables a shift to left in testing and helps to deliver quality even before a front end comes into play. UI automation for me now is mostly pure front (cross-)browser related tests, like logging in/out, check hyperlinks, sorting, filtering, etc.) and serves more as a regression test, while the API testing really covers the most part of the functionality (positive, negative testing, performance, security, authorization, authentication, flowtesting, destructuve, concurrenty, ...) + trying to cover new features each sprint.
I think @avidCoder also sums it up really nice.
I'd like to add that API testing also enables easy test data creation. As a test driver often forgot about, test data really makes all scenario's test-able. Perhaps in the front-end it's not possible to create anything, only visualise, so... what happens when field x = "" or number Y = "0" or text Z = "an absurd long string", or what if you do not have enough data to test front pagination etc. I remember in my previous project running against a null pointer exception incident in PROD just because there wasn't any test data available that matched that data in PROD.
So, you can/must make use of API testing to facilitate test data creation!
I see automation also as a must-have skill as a tester. In Agile driven teams it's no longer sufficient to be able to just trusth on your functional testing skills, technically you need to adapt as well. On top of that it's also important to be able to think at a strategic level. So in my view, the test profile moves towards a general profile that not only uses test competences but also includes sufficiant business (analyst) knowledge, technical (developer) skills and test (managerial) vision. The best agile teams are those that can communicate and work together across the boundaries of their profile.
API Testing can be seen as a gate that ensures the application is behaving as intended & well within the scope of the requirements.The benefits of API includes broader scope of testing & early initiation of testing to identify bugs in the initial stages itself. The output will be a more cleaner & a product that adheres to the protocols & the requirements it is designed for.
UI Testing plays a crucial role to Interaction & Customer friendliness . A poorly tested UI product will never last long irrespective of how well the application was developed or was tested at different stages prior to UI. UI Testing is the final impression that can make or break the deal. Bad UI leads to frustration & good UI enjoys appreciation from customers.
Test Requirement Analysis, Test Plan/Strategy, Test Design, Traceability Matrix, Bug Tracking are some of the placeholders that play a crucial role in ensuring the quality of the application being tested & its adherence to the requirements.
Coming to automation, it is a unit that every industry needs to survive in today's world. Planning test strategy in initial stages makes it easier to plan the scope of automation & how much of it is needed. Identifying the areas that can be automated is the key. Well defined scope for automation will not only enhance maximum coverage but helps focus on tests that need to be run manually.
That's my opinion on API/UI Testing !