Improve quality with functional & API testings
There are many different levels of testing available — functional, API, integration, unit, security, etc, and you may be wondering this:
Well, you can choose to do either one but you can improve quality by doing a combination of functional and API testing! In fact, every single clicks/actions performed on the application are actually API requests behind-the-scenes! Thus, it makes good sense to combine both types of testing. In this article, we’ll run through how both types of testing can be done as a whole using one of the features of a simple product, Task, defined below:
And oh! The team informed you that there’s no documentation available for this newly developed feature. On top of that, no one in the team has time to do a walkthrough of this feature with you.
Step 01: Analyse & analyse the feature!
Assuming there is an ‘Add Task’ feature page as shown below.
Whatever questions or assumptions you have in mind, write them down! Afterwards, play around with the feature! Once we start doing so, we might be able to find a few or all the answers to our questions! However please remember that at this point of time, these are our assumptions; we’ll need to check with the product team to confirm our assumptions.
Do take note of the API requests while exploring the feature. This will help us to come up with test scenarios.
Step 02: Plan test scenarios & test cases
During your exploration, you should be able to identify some of the critical paths, the positive and negative flows, and also the edge cases.
Supposedly this ‘Add Task’ feature only makes one POST API request (with a single parameter “taskDescription”) for every new task added.
Let’s start defining the test scenarios for functional testing and the test cases for API testing.
Caveat: This is not an extensive list for test scenarios and test cases.
We purposely leave out identifying the category for test scenarios 2–15 at this moment since it is quite impossible to categorise them into either positive, negative, or edge test scenarios without any requirement knowledge.
Notice that there’s an additional column (Test Scenario S/No. Mapping) in the API Test Case table, and some of the test cases have the “S/No” indicated? This shows that that particular API test case has a similar test scenario!
You may ask: “Is it necessary to do the same test case for API?”
Well, our answer is yes since validations that have been applied during user’s input (i.e. on the frontend client) doesn’t necessarily mean that they’re applied for the API request (i.e. on the backend server)! Well, we cannot assume that validations will definitely be done on both the frontend and the backend right? 😏
We’re sure you may have encountered before that the validations are done on the client side but not on the server side. Don’t believe it? Let’s take a look at the (functional) test scenarios and API test case:
After executing the above API test case, the actual result is as follows:
The expected and actual results don’t match! Hence, there is a need to do another check to see if this task with only <space> input is added in the ‘List Task’ page. If this task is displayed in the list, then there’s a discrepancy in the tests!
Step 03: Execute!
Once all the test scenarios and test cases have been created, it’s time to execute the tests! Do note down all observations while executing the tests. Here are some things to look out for with each of the following test scenarios:
For the API test cases A — H (refer to the API Test Case image above), check for any discrepancies. For instance, is the actual result of API test scenario A the same as test scenario 2? Do the same check for test scenarios 3, 4, 9, 11, 12, 13 and 15.
Since we have no way to verify that the task is added correctly in the database, we will need to check the ‘List Task’ page to see how the newly-added task is being displayed. For the API Test Case H, check the number of characters displayed for the added task in the list.
Step 04: Team check-in
Now that you have the execution results, observations, and assumptions of all the test cases, it’s time to check in with the team and verify the results. After the clarification, the test cases should have a confirmed Pass/Fail status. Test scenarios can also be re-categorised into positive, negative, or edge cases; do update your test cases where necessary!
Step 05: Bug Report
Lastly, no system is perfect and has zero bugs. After checking and confirming with the team that those are really bugs, don’t forget about raising bug report(s) for the failed test cases.
Step 06: Test Completion
The testing is considered completed once all the bugs have been resolved and re-test of the test cases have confirmed pass.
Both functional and API testings work hand-in-hand to ensure that each feature of the product meets the requirements. It is always better to come up with the test scenarios and test cases so that the testing can be more targeted.
We hope this article can help you to visualise how functional and API testing can be linked to each other. Feel free to share with us your experience when doing both functional and API testing in your product.
🧙🏼♀Team Merlin 💛
Application security is not any individual’s problem but a shared responsibility.
