How is test case design different for GUI & API?

Question

Is there really any difference in designing test cases for the API and the GUI for any product?

I am writing functional GUI test cases (CRUD feature) for my application. Can I use the same test cases for the API testing (mainly CRUD related test cases) or could there be some test cases which can only be executed using API testing?

Answer 1

• The user interacts with the GUI
• The GUI interacts with the API
• The API interacts with the back end

In theory the GUI tests should cover all the API tests, right? Well, what about when the GUI prevents the user from submitting invalid data? You still need to test that the API handles these cases sensibly. Each layer should be tested separately:

• GUI: Acceptance tests
• API: Functional tests
• Back end: Unit tests

These are not the only tests that exist. There are integration tests and more.

You should find that there is some overlap between each layer. Some GUI tests will not interact with the API, but some will and will execute the same code as in the API tests. The same for the back end tests. There will be some tests that can't (in theory) or are too difficult to be tested from the API, so need to be unit tested instead.

Answer 2

Yes, API and GUI are different from a hardware product or command line enterprise software and as such requires specialized approach and techniques.

But GUIs and APIs are usually a very thin layer above the actual business logic and features, when designing a test you you obviously check that the GUI itself (colors or location of elements for example) or API (relevant fields have relevant values for example) works as expected, but we need to remember though that those have a purpose and they do not exist for the sole purpose of being there.

The color of a button or the value in a response field of an API deliver a message to the user, clicking a checkbox has more behind it than the visual part- it actually acts on some information and influence how the software works.

To summarize, GUI and API are only tools for testing the product specifications and do not stand by themselves.

Answer 3

Note: I will talk about testing itself since the documentation of certain activity is only but a product of the activity itself.

I'm not sure is your question is about "the testing for ... is different" or if the "the testing design for ... is different".

The second point talks about the heuristics for exploration, the "meta-hows". E.g., HICCUPPS:

• History. We expect the present version of the system to be consistent with past versions of it.
• Image. We expect the system to be consistent with an image that the organization wants to project, with its brand, or with its reputation.
• Comparable Products. We expect the system to be consistent with systems that are in some way comparable. This includes other products in the same product line; competitive products, services, or systems; or products that are not in the same category but which process the same data; or alternative processes or algorithms.
• Claims. We expect the system to be consistent with things important people say about it, whether in writing (references specifications, design documents, manuals, whiteboard sketches…) or in conversation (meetings, public announcements, lunchroom conversations…).
• Users’ Desires. We believe that the system should be consistent with ideas about what reasonable users might want.
• Product. We expect each element of the system (or product) to be consistent with comparable elements in the same system.
• Purpose. We expect the system to be consistent with the explicit and implicit uses to which people might put it.
• Statutes. We expect a system to be consistent with laws or regulations that are relevant to the product or its use.

The first point talks about the result of using the heuristics, the "concrete how", the exploration itself. And every context (and product) will have different outputs of heuristic application.

Answer 4

Usually for UI testing I'll focus on the major work flows/use cases. You mentioned the CRUD operations. I'll have a test for each of these to make sure it works. Typically you can black box test these imo. "If this UI goes out tonight, and these work flows pass, the UI should be good"

For API's i usually have 1 or multiple tests for each endpoint and verify the response is what is expected, and typically I grey or white box test this. "If this API goes out tonight and these end points behave as expected, the API should be good"

Answer 5

The main difference in designing the GUI and API test-cases is the parameters verified and its expected result

• GUI test-cases mostly validate the user flow and test-cases will comprise of the Pre-requisite, Steps to perform and the expected results at the user end
• On the contrary, API test-cases will include endpoint details, the C/R/U/D operation to be performed and the expected API responses

Many software testing companies prefer both GUI and API testing as in GUI testing, while validating a user flow, multiple APIs are called at the backend that communicates with each other. This communication between the APIs is difficult to test during API testing as endpoint of each API individually tested.