Thinks to Remember while Testing a Multi-Tenancy Application

As we are aware that there are many organizations moving on cloud these days and multi-tenancy is a way to reduce cost and increase resource sharing on cloud. There can be various risk involved while building a multi-tenant application such as ‘Data Security’, Tenant isolation etc. In lieu of that just wanted to share with everyone, the things to remember while building or testing a Multi-tenant application.

[Wiki: http://en.wikipedia.org/wiki/Multitenancy]

Multi-tenancy refers to a principle in software architecture where a single instance of the software runs on a server, serving multiple tenants. A tenant is a group of users sharing the same view on the software they use. With a multitenant architecture, a software application is designed to provide every tenant a dedicated share of the instance including its data, configuration, user management, tenant individual functionality and non-functional properties.

1. Tenant selection for testing: - categories your tenants/clients/customers on the basis of feature or functionality they use. As we cannot test every tenant and every feature we have to sample out tenants based on some parameters.
2. Test Tenant specific Data Isolation: - Populate Database with ‘Categorized tenant’ data and validate data isolation/data security is maintained across various tenants. i.e. one tenant data should not be visible to other tenant.
3. Feature/functional isolation:- Validate that any feature/functionality which is switch on for one tenant should not impact same feature on other tenant. For example: - suppose there is a feature which shows a display message and it’s configure for tenant A, the same display message should be isolated to other tenants.
4. API Management:- All APIs fetching data from the system should be tenant aware. A tenant alteration at user level should be restricted. For example if one tenant tries to see data of other tenant by just changing some id on the UI should be restricted. OR exposure of Tenant id to user should be restricted.
5. Schedule Jobs:- All scheduler services should now run for specific tenant. Execution of one Batch task should only add/modify/delete data of that particular tenant.
6. Integration services:- All Integration services should be tenant aware and should add modify delete data for their respective tenant.
7. Data purge policy:- Removal of one tenant from the system should not affect other tenant. Data should be isolated in such a way so that its purge does not create problems for other tenants.
8. Cashing: - cashing should maintain data isolation at db and browser level. For example if the same browser is used to test two different tenants, data isolation should be maintained. Similarly if a db query from UI is executed from two different machines from two different systems, data isolation should be maintained.
9. Automation:- should run for multiple tenants in parallel to each other. This will emulate real time production environment for us. As much as we test tenant in parallel for different functionality, we are more secure towards functional failure.
10. Data corruption:- should not affect other tenant data. For example suppose one tenant has organization tree and somehow there become a cyclic relationship between a child and parent node. This will keep a query running infinitely. This should not affect other tenant’s performance.
11. Uniqueness of object:- Validate for Object uniqueness across various tenants. No two objects should get created/modified/deleted across tenants using similar ids.
12. Tenant wise File Management:-Apart from database there are some file system object’s that need to be validated for tenant specific view. For example Tenant Logo, Tenant data views etc. we should validate that such file based resource should not be visible for the tenant who owns them.