Wednesday 18th September 2019,

BBT Implemented: Security Authorization Testing


What is Security Testing?

In a general sense, Security Testing tests typical security requirements that can include elements from confidentiality, integrity, authentication, availability, authorization and non-repudiation.

This article will be discussing how BBT can be used to test user authorization.

User Authorization

There has always been a need to test how users with certain access rights can only access designated areas of the system.  These access rights are defined by certain sets of rules usually tied to a user type or role.

A simple example would be to compare the Administrator role and the Guest role in Microsoft Windows.

Administrator Rights

Guest Rights

  •   Install and uninstall software
  • Use installed software
  • Access all files on the system
  • Read files from specified locations
  • Change and delete other user accounts


Windows Guest accounts are severely limited in what they are able to do.  These limitations were designed and predefined by Microsoft.

When a system environment is created, control over what can be accessed is highly critical to the overall security of the system.  In most cases, the system designers will want to predefine these user rights.  For example, users in the finance department should only be able to interact with the financial database and other related systems.  Users in the purchasing department should only be able to interact with the purchasing database and their related systems.  Creating a “finance” user role and a “purchasing” user role would be required.

User Authorization Testing

Complete testing of what each user role can do most likely would involve many test cases, and that is only for the “happy path” of testing.  In other words, testing to see if only a finance user can access finance systems as well as testing to see if only if a purchasing user can access purchasing systems.

Imagine if there are many more user accounts in this environment.  The “happy path” test cases would encompass each one of those user roles and their designated systems.  What can get overlooked are the negative test cases.  If there are many other user roles in the system, there is a need to test if a user role cannot access the other systems in the environment.



BBT Implemented

By using BBT to identify contexts and outcomes based on the user role requirements, one can easily identify all possible “happy path” test cases.

Using the exact same contexts and outcomes, BBT will also identify all possible negative test cases as well.  BBT will automatically see that a finance user role cannot access the purchasing systems and create negative test cases for that.  It does not matter how many different types of user roles there are, as long as all the “happy path” contexts and outcomes are identified.

BBT Implemented: Example

In the slide below, multiple tiers of users are depicted for each finance and purchasing role.  This kind of granularity can be quite common when there is a need to further restrict users within departments.  It is easy to see that certain tiers of users can do only certain actions.


In the slide below, the inverse of the previous slide is depicted.  All negative test cases generated from the “happy path” contexts and outcomes are mapped to each other.

In this particular example, 14 contexts and outcomes were created.  These 14 contexts and outcomes will generate 20 “happy path” test cases and 44 negative test cases.  In other words, BBT reduced the effort to generate all possible test cases down to just 14 contexts and outcomes.

BBT has the power to transform and revolutionize your security authorization testing with perhaps the biggest win of them all – identifying all possible negative test cases.

To see more examples go more in depth on how the BBT Tool works, reference the blog on BBT optimization.

Like this Article? Share it!

About The Author

Comments are closed.