Not a Senseful Question: Is API Testing important than UI Testing?

It is usual for a tester/SDET to come across the question and discussion around API Testing versus UI Testing, asking which is better or more important. More questions which one might cross on the same topic are as below:

• Which testing helps the tester to find more bugs and faster -- API Testing or UI Testing? 
• Which testing is quicker and effective -- API Testing or UI Testing?
• Which testing is less flaky -- API Testing or UI Testing?
• Which testing helps to find risks and problems early in the development cycle -- API Testing or UI Testing?
• Which testing has less dependency and maintenance comparatively -- API Testing or UI Testing?
• Which testing provides quicker feedback on the health of product -- API Testing or UI Testing?
• Which testing needs little efforts and investment to build, execute and maintain -- API Testing or UI Testing?
• A tester can start testing with API before the UI is available, so which testing is effective -- API Testing or UI Testing?
• If API Testing is covered no need for UI Testing?
• Which tests cases while programming is in progress or yet to start -- API Testing or UI Testing?
• The APIs can be used to test web application service logic, so which testing is effective -- API Testing or UI Testing?
• UI affects the UX, so UI Testing is required; don't the API affect the UX? If both affect the UX, which testing is of priority and more influential?
• The testing of a system for data using API is possible before the UI is available, so which testing is effective -- API Testing or UI Testing?
• One can say it is functional just by using API with no UI, so which testing is effective -- API Testing or UI Testing?
• API Testing can reveal more details of services and web application server, which UI testing cannot with or without load balancers, so which testing is effective -- API Testing or UI Testing?

I hope that was not a big list of questions, and this list keeps growing if I share what I have come across as part of the reasoning. Probably, you might as well have witnessed such questions when discussing the API Testing over UI Testing.

The word "Testing" is vague!

I learn the word "Testing" is vague when used with no precise context and expectation. For example, "API Testing" does tell that subject of discussion and work is around API in one's testing. Also, it does not communicate precisely -- what in the testing of APIs. The same is for the testing of UI.

In most of our discussion, we see such words loosely said in conversation. As a result, it may lead to ineffective thoughts. For example, "Is API Testing important than UI Testing?". To me, this question does not tell -- What to provide as a response, so one can think about it and decide? On what basis the comparison is made for the effectiveness and in which context?

We can test API and UI for quality criteria as -- Functional, Performance, UX, Security, Accessibility, Simplicity, Usability, and more. Yes, we can test the APIs for UX.

How can one reduce the vagueness when the words become too casual?  

When used the word "testing" providing the context of expectation, it can reduce the vagueness in communication. For example, "Testing for the API functionality is important than the functionality of UI?" Now you see the difference and clarity with this question in comparison to -- "Is API Testing important than UI Testing?"

API and UI are individual operating entities in a System

To benefit the reader here, let me take Mercedes-Benz's car assembly line illustration. What can relate to APIs and UI here? Can the exterior of the car be seen as UI and internal as multiple APIs which take the input and respond for movement of the car?

So the question here is:

• Testing of functionality just for the internals of a car is enough?
• By doing so, there is no need to test for the exterior (UI) of the car?
• If yes, why would skilled people work in designing and testing the UI that is exterior of a car, constructing various scenarios?
• Testing for the security of a car internal is sufficient? Should the UI of also of a car be subjected to security tests? Ask the same for performance, functionality, and UX.

I have heard there OTA updates for the software installed in a car. This software can control the internal and external of a car is what I see.

I learn the API and UI are two individual entities of a system. Testing of one entity will not overrule the need for testing of other entities. Instead, it can complement and help testing better. If thinking testing of API is enough and no need to test UI, then asking what tests look repetitive is logical.

Why would people invest so much money, time, and resources in building the interactive UI? Why the world faces the problem with fragmentation in each segment? Having the engineering focus on the API segment alone is enough?

Why we usually have two teams working on APIs and front-end?  Why each of these teams are specialized and skilled in working at their areas and not in both?  If testing for API is sufficient, why there is a dedicated team for programming the front-end and its testing?  Answering these questions can arrive one at having a clarity.

Should the client be seen as UI?

What is UI in this context? The client end of the system will have code for:

• UI
• Rendering of UI based on context
• Processing the input
• Processing the output
• Processing and interacting with peripherals and its event
• And much more

To imagine the client's complexity, look at the exterior of your mobile phone device and how it interacts with internals for the input you provide. Think about the Push Notification you receive via an API and how it appears as UI in the notification tray. How acting upon the push notification in UI will respond? It looks simple case but not so when it comes to the handling of UI.

Seeing the client as UI and an endpoint to input the data and display is reasonable. But confining only to that will blind one. What was the need for the Developer Tool in a browser, if the API testing was sufficient? Every piece i.e. each entity in the software system is complex. Testing of one will not override the need for the other entity.

UI fails as hard as the API

I have been working on the server end and as well client end. I have experienced API functioning well but the client fails though it abides by contract. Should the client be seen as just UI?

The attributes of API will connect and communicate with the attributes of UI. If the API is functional and it does what is expected does not mean the client will be functional. The API is secure does not mean the client is secure. The API (service) is doing better in performance does not mean the client is also performing well. The UX can be annoying by the API while the UX of the client is well received. The context in which API is tested in isolation is different from the testing of a client.

To share one experience of me, the user entered the insurance details as in the insurance card. The API internally did handle the details differently in the presentation. As a result, the next time when API responded with insurance detail, the client crashed. It was the same data but presented in a different way which the client did not accept or understand. But when tested the API in isolation, API accepted the data in both formats. Then the business wanted the detail as expected by the client and not how the API presented it. Could the testing of API alone help me to learn the problem at the client end here? The API was vulnerable but not the client in one case. I used the API as an entry point for the attack. Eventually, the impact was reflected in UI with the response.

I have more such examples from my experiences, to say API and UI are two different entities. Testing for one in any quality criteria will not override the need for testing of the other. But it helps me to plan and design my tests well knowing them individually and how both interact.

How to respond for -- API Testing or UI Testing?

• Both are distinct, important, and needed
• Testing of each provide unique information and value
• Ask details for what to test and what is expected out of testing
• Rephrase the question asked to better one which is explicit with clarity
• Myths:
• Testing for API is important than testing for client
• Testing for API is sufficient and no need to test for client
• Testing for API will cover data which client do not cover
• As the automation pyramid talks of Unit, Integration (API) and UI layers, it is confused the client is UI layer.  UI is one part of the client and not the whole.
• Testing for API finds unique information which may or may not be found by testing client
• Identify what to test in these two distinct layers
• Both of these layers have their own state and behaviorial differences
• So trying to mock with stubs on other layer be it from API or from client, may always have something critical unlearned
• When testing in this way, usually the focus is one element of a software and so it is called Unit Testing
• Testing for the APIs and testing for the client have distinct weight and importance

    

2020: It Is Costliest If Not Shipped Quickly - Fixing few bugs later is okay!

When you read this post, I assume you are working in a team or organization which has imbibed Agile and its various approaches into practice.  I see it is more mindset and culture, than just saying it as a practice.  I have worked in team and projects which had Waterfall approach. I'm working with teams and projects which claims to be Agile in approach.

Here is my tweet and the question of @J_teapot.  His tweet is interesting and striking to me.  Hence, I write this post.  Thanks, @J_teapot for asking.  I enjoyed that question of yours.

Days of Waterfall

It was in early 2000s (to be precise 2005-2007), I worked in project which had customized waterfall approach.  The build to testing were delivered in iteration and not at the end.  In the course of project, it got adapted to Agile practices and as I remember it was around 2007-2008.  Yet the shipment of product being developed happened once in 3 or 4 months.  This shipment time remained as is Waterfall and in Agile.  If asked, why that slow in shipment when Agile, it was business decision.

In my initial days of career, I read this in text books of Software Engineering and Software Testing -- "Bugs are more costly to fix when found later."  The same was said by managers to we programmers and testers.  Those were the days where no much blogs and posts in web on Software Testing, Software Development and Practices.  Google, had just come in few years back, then.  It was the period where Software was getting into every spaces of business and daily life.  The pace of delivering software to various business space picked up its pace.  The technology platforms emerged and so the practices.

Days of Startup Era

In the era of technology start-up that is around 2012 and onwards, the shipment pace for "working" piece of software took cut from months to a month and to a week.  Then the era of programmers led technology start-up came in.  The idea of MVP (minimum viable product) and pitching to investors for series of funds, all came into the news.  If you notice, software was developed earlier and, in this date, as well.  The difference is the time and how it shipped, was the business call in major than being a tech call.  I see this is appropriate to remain in business, competition and for being relevant to needs of customer and market.  That change has to come in quick pace.

In 2020, this is no different.  In fact, the shipment pace has got much quicker and it goes in a sprint of 14 days (including non-working days).  You can refer to the train model of backlogs in a sprint for more details.  If did not get deployed and rolled out for install, business will be impacted as earlier.  Who answers for the investors?

The approach of software development has evolved and so the testing also has to adapt.  If had a "working" piece of deployment and serving the customers with value claimed, the team will be relieved; else, the trouble starts for team.  I have been here and I know it.  The MVP which claims to deliver the mentioned value, has to be delivered.  Whatever one builds or adds to MVP, should continue to deliver value claimed.  If there are bugs in shipment that can be bearable, then still fine unless it blocks the value claimed.

I have been in state, where the value claimed by business and MVP, not delivered after shipment and deployment.  The are several reasons as multiple works to ship one working software system.  Fixing that in few minutes and deploying it is expected besides the cost incurred out of it.  It so happens, the deployment and roll out goes while the testing is in progress or not yet started for that version of software.  In a way, it is a strategy and also a business call.

Ship it first - Mindset

In 2020, it is costliest if not shipped quickly; fixing few bugs later is okay.  That's a business call and a strategy.  We have to be there on time with service catered.  In my opinion, unless the value claimed to offer by MVP and product as a whole, is being delivered, all is in control despite the bugs in production.  That said, I'm not ignorant of bugs in production.  I will continue my work in finding them.  I have evolved to adapt my testing and skills to need of business, market and software system we build.

If asked what is right that is shipment once in months or once in a sprint (2 weeks, usually), both are right.  I hear few teams still ships once in 6 months today as well.  I work with teams which ships in a week and in two weeks.  Not to mention, I have worked where the requirement comes from business and shipment happens in few hours.  It is all about, where I'm here.  That as well defines the time available for testing.  I'm not sure what today's Software Engineering and Software Testing books say about fixing bug later.  Fixing later is not a habit but a situation needs today when it comes to business.  I wish, when a testers being technical and understands the business side, it adds value much more to the testing, team, business, organization, customers and to the product.

To summarize, it is business and market demand that has kept the shipment in a sprint.  Prioritizing the blockers (and bugs -- know & unknown) for shipment is a skill which a tech (programmers & testers) team has to groom in my opinion.  I see this is adapted in service industry and as well in the tech product organizations.