In an ideal world, there would be a simple CRUD API that would do everything and you’d just need to test that API. However, reality is far from this ideal world. In a normal world, there are different usages of API’s and depending on the usage, we need to test that API.
One of the most use cases that I’ve seen is the implementation of API with different user-roles, with different permissions given to each user. Each of the user role comes defined with its own set of actions and then you’d need to test all the user-permissions with the actions mapped to them.
In today’s world, APIs are used to build complex systems that require different users to perform various tasks, and each user has different levels of access and permissions to perform these tasks. For instance, a social media platform like Facebook has different user roles like a
page admin, etc. Each of these user roles has different access and permission levels. A regular user cannot post or moderate content like an admin can. Therefore, it is essential to test the API with different user roles to ensure that the system is working as expected for all users.
I’ve always pointed out that as a tester/QA, the primary question you should ask is Why? Why do we need to test user role specific apis or Why give priority to this specific functionality?
If you look at the OWASP Top 10 list of vulnerabilities here, you will see that
Broken Authentication, is one of the prime reasons of security issues/vulnerabilities. If there is an API, where there are different roles and these roles are not properly authenticated, then it may lead to a lot of un-authenticated people getting access to resources, which they are not meant to access.
Let’s say a simple facebook user, who has only permission to post something, or react in a group, somehow gets the group or page level admin privileges due to broken authentication, which was not caught during testing, then it will create a lot of unnecessary issues for the users and well as the actual page admins.
So testing with different user roles also helps in identifying and fixing issues that may arise due to incorrect access and permission levels. It is the first line of defence for an API, which needs to be protected at all costs.
For example, consider the above case, it may cause data breaches or other security issues. Therefore, testing with different user roles is essential to ensure that the API is functioning as expected.
Testing with different user roles involves testing an API with different user profiles, each with different levels of access and permissions. This allows developers to ensure that their API is working correctly for all users, regardless of their role in the system – which in turn allows the business to build confidence in the product that the product will cater to different level of user accesses.
Important Things to Consider
Here are some important points that QA testers should keep in mind when testing APIs with different user roles:
- Identification of the the different User Roles and their privilege/permission
The first step in testing APIs with different user roles is to identify the various user roles that exist within the system. This involves understanding the different levels of access and permissions that each user role has. This understanding helps in creating test cases for each user role.
For example, in an e-commerce platform, there could be various user roles like a
regular user, a
payment gateway admin, etc. Each of these user roles has different levels of access and permissions. A regular user can only buy products, while a seller can add products and manage orders. A payment gateway admin has access to payment information, but not product information. Understanding these different user roles is essential to create test cases for each user role.
Now when considering these roles and permissions, a very thorough and detailed analysis is required for the roles where the permissions overlap. For the above example, a seller, who has a permission to add products and manage orders can also be a user of the system. Right. So when testing these scenarios, where there is overlap of the permissions, it is imperative to know how the roles and permissions play out. A tester should ideally created scenarios that cover this kind of overlap and pay special attention to them, because more often than not, these are the scenarios that might create issues
- Business rules/definition for each role and permission
Once you’re done with identifying the roles and permissions, it is always a good idea to know what these roles and permissions means to actual end users. And you need to do this, because as a QA, you have to think pragmatically – both from a development point of view as well as an end user point of view. It is very critical that you, as a QA, know the fine line in between. At the end of the day, the business – which may be the client or the end user, will understand the humane or the non technical side of the story and not the technical side of it. So it becomes very important to have a clarity of thought on how the user roles pans out in terms of the end user prespective.
- Define the Test Strategy
Now that you have clarity on the roles, clarity on the business implication and understanding of the rules, what can we do as a QA? We need to define a solid test strategy if possible. Now this is very hard and fast rule to have a test strategy for this kind of API’s alone – but if you have the bandwidth, and resources, it will great to have test strategy set for these kind of api’s. Also if you cannot do a standalone strategy for this, it would be a good idea to include this in your overall test strategy, and make a note of it.
Now the question comes what should be have a part of test strategy for these api’s –
- Define the objective of the tests – Have a clear defined objective of the tests that you’re trying to perform. Now on an api or a collection of api’s which have user roles, it is imperative that there may be a number of different tests that might be run. – contract, blackbox api tests, security, performance to name a few. In your objective, have a clear definition of what you’re testing and what is the need for that test.
- Scope : Define the scope of the test – are you going to be testing the api’s only? are you going to test the complete UI+API integration ? Have a proper definition of what is the scope of the tests that cover the api’s.
- Approach: You can define the approach that is being used to test the apis. If you’re having an automation suite do the pre, post heavy work like test env creation etc, mention that too.
- Environment and test data – As mentioned in the above step, you might want to create different users which simulate different users and also some users whose access might overlap. So you can mention that in the test data set-up. Also how can you set up those user profiles – using databases, fake services, fake user profile etc.
- Deliverables – What are the end deliverable of the tests.
- Schedule – The start and end timeline of the tests , also taking into account any incoming holiday, PTO or any other leaves that might occur in between etc.
- Risks – One of the major things to cover is the risk part. What is the risk associated with testing the api’s. How and when that risk can come and how is the plan to mitigate that should also be mentioned. Let me give an example – so in one of our projects, the service that we use to create the fake test data, is a micro-service, that is hosted on a on-prem instance of K8s. This service is deployed every day and sometimes the deployment fails due to resource crunch. So that is a risk which can affect the test data creation.
- Create Test Scenarios/Test Cases
Once the test scope is defined, the next step is to create test cases for each user role. Test cases should be designed to validate each user role’s access and permission levels and ensure that the API is functioning as expected for each user role. Test cases should also be designed to test different scenarios such as error handling, data validation, and authentication. I had posted this article some time ago where I wrote about what to test in an api. This can be taken as a reference point to create different test cases for the combination of different user roles and their associated permissions.
Let me list some 10 examples of such test cases – please see that these are just examples and should not be in any case taken as what test cases can be added – these are just tip of the iceberg.
- Verify that the API correctly handles user authentication and authorization for each user role.
- Ensure that each user role can access only the resources and perform only the actions that they are authorized to do.
- Test various scenarios for each user role, including positive, negative, and edge cases, to ensure that the API behaves as expected.
- Test the API’s response for error handling and ensure that appropriate error messages are returned.
- Verify that the API logs all user activity, including successful and unsuccessful attempts, for auditing purposes.
- Test the API’s performance under different loads and ensure that it meets the performance requirements for each user role.
- Ensure that the API is secure by testing for common security vulnerabilities such as SQL injection, cross-site scripting (XSS), and cross-site request forgery (CSRF).
- Test the API’s compatibility with different operating systems, browsers, and devices that may be used by users with different roles.
- Ensure that the API is well-documented, and that the documentation is accurate and up-to-date with the latest changes.
- Provide comprehensive test reports that include test results, issues found, and recommendations for improvement, to assist with further development and maintenance of the API.
- Pre-Test Setup
Once we’re done with setting up with the test cases, or simultaneously too, we can work on creating the test environment and the test data that can be used to test the apis.
The test environment refers to the hardware and software environment that will be used for testing. This includes the hardware specifications, operating system, browser versions, and any other software components that are required for testing. If there is any external dependency on the test environment that that needs to be kept in mind too.
The test data includes the data sets that will be used for testing. This includes the input data, expected output data, and any other data that is required for testing. The test data should cover all possible scenarios and use cases. When setting up the test data, for example, if you’re setting user profiles, then each user profile should correspond to a specific user role , with the user permissions that you need to test.
Now that you’re done with the set up of the test data and the environment and if the product/module is testable, then you can start with the testing of the api’s. Keep in mind that you can have multiple variants of testing done on the api’s using the test data created in the pre-test step.
There might be functional testing, which involves testing the API’s functionality with different user roles to ensure that it is working as expected. Functional testing should include tests for each user role, different scenarios, and different endpoints.
If the tests involves testing the API’s integration with other systems or components or with the UI, then Integration testing should include tests for each user role and different endpoints to ensure that the API is correctly integrated with other systems.
We can also include some amount of performance testing involves testing the API’s performance under different loads and stress levels. Performance testing should include tests for each user role and different endpoints to ensure that the API is performing as expected under different loads.
One of the key things to tests in this scenario is the security testing, which involves testing the API’s security features to ensure that it is secure and not vulnerable to attacks. Security testing should include tests for each user role and different endpoints to ensure that the API is secure and that user data is protected.
Finally, it is essential to document the test results. Test results should include details on the test scope, test cases, test environment, and test outcomes. Documentation should also include any issues or defects found during testing and their resolution. If you’re using some test management software, then that would be handy and you should update the outcomes/results of the tests in that. Also in many places, the practice is to use an simple excel, which can also be used.
However and whatever be the medium of test results – excel, html reports in case of automated tests, it is important that the reports contain certain important aspects like test case name, the test scenario, the pass fail status, the combination of test cases – if you’re using a data driven approach kind of etc.- and also, if that report can be published/hosted some where, that would make it easier and accessible to other members of the team.
- Post Test Cleanup
It’s always a good idea to clean up anything residual test data after your testing. – this may include cleaning up the test environment, deleting of the user profiles created for testing, any critical or user data that might be used for testing, if any, should be removed post testing is done.
The above mentioned points are in no way a definitive guide to testing the apis with user roles. There might be more challenges than what meets the eye. The above pointers are something that I’ve practiced and followed over last couple of years. I would be interested in knowing what other approach people follow. If you’re reading this, please comment.