I'm in the process of writing Access Control tests for a system in the Utilities industry. A component of the system is accessed depending on the role of the User (Role Based Access Control). There are two layers of Roles - The top layer is an Organisational one. i.e whether the User accessing the system is from an organisation that supplies Electricity, Gas or is a maintainence company, etc.... The second layer of Access control checks the Job role of the user, for example whether the user is a Call center user, a engineer, a Customer Service agent, etc... This latter level of Access Control is set by a Power User in the organisation. Access is controlled to around 15 sub components within the system, some of which can be accessed by a particular user and some of which cant. Some of the components also link to one another.

To add, a user can be a member of multiple organisations (for example a Gas Company and a Electricity Company) and can have multiple Jobs within that organisation (a call centre agent and a Service manager). With all this, permissions will be set cumulatively.

I'm writing tests but I'm not being strategic in designing my tests, which may mean I have too much coverage (duplication) or maybe not enough.

With all the different permutations, what is the best way of designing tests for this system which is to be tested manually?

3 Answers 3


I do not have idea that if you are expert in automation testing or not. If you are then you can create automation script for each role and you can specify diff. logic that if role is call center executive then specified things should be accessible. So you can do that for each and every role.

Why I am telling you to use automation because suppose in future if you add new role with diff. access permission then you will have to test that new role as well as already created role. As a tester you will have to check for regression that if you add new role then already created role/access should nor disturb. So in this case automation will done your work very quickly for regression testing.

If you want to go by manual testing then you can create test cases for each role and access. For ex: if role is manager then it should allow to access these menus , these items etc and then you can run manually all test cases.

so in whole flow of testing from start to end your focus must on role based access.


You can design your test in a spreadsheet and fill out all the combinations. Look for and remove redundant cases. You can incorperate this matrix into your automation by using columns for User/pass to login then try to acess certain pages and use the matrix to assert acess is granted or not. Your automation will be lightweight and rely on the spreadsheet for all its data. This saves you from writing a test for each case.


if you (i.e. management) are willing to take some risk you can use N wise testing.

But anyway, everything should begin with you having clear understanding of what is being tested. For that you should be organized and be able to track everything, a simple example would be using tables to cross features and test cases (Excel is really good at this)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.