Building tests for role-based security, which limit user access by login, could be among the most challenging test scenarios. Testers will be most successful if they dialogue with compliance and thoroughly vet business processes.
That’s particularly true when building use cases, according to test industry veteran Linda Hayes. The reason? Hayes says it’s because of the complexity of role-based permissions in many business processes as well as the importance of insuring the integrity of often sensitive information. She offers several guidelines to help develop tests based on a holistic viewpoint of applications with critical role-based security features.
Forge a Foundation
“Testing role-based security involves the verification that user roles are enforced by the software, so the natural foundation of your test effort is the definition of these roles and rights,” says Hayes. And unlike large commercial apps like ERP and CRM, many of which provide configurable roles and settings, “customized or internally developed systems, or those that integrate with disparate legacy applications may require additional effort,” to deliver such security.
Hayes illustrates the need for roles within an application using a hypothetical payroll system. “Most employees probably have no access at all. Payroll clerks may be authorized to use the system to enter time card information, but are unlikely to be able to peruse salaries,” she says. At the same time, supervisors may be capable of managing benefits, but only a senior manager may see compensation or add or terminate employees. “In other words, various capabilities of the application are selectively exposed based on the role of the user.”
Begin building a matrix that includes users along one axis and application functions along the other.
Check Corporate Compliance
Once you know what people’s roles will be and the capabilities desired of each, the next step, she says, is to be sure that those definitions comply with corporate policies. “This could be as simple as obtaining sign-off from your corporate security officer, or as involved as interviewing application or functional area owners, or reviewing corporate policy handbooks.”
With validated definitions in hand, it’s time to begin testing the system’s compliance to the roles you’ve defined. But this step is not quite as simple as checking off boxes in your matrix. Applications often require “multiple navigational steps to access a particular function, window or field” and sometimes input of data values to permit or trigger navigation or functions, she says.
“This means that your test plan and cases must encompass a more holistic view of the enterprise and the application, encompassing the business processes and supporting environment,” Hayes says.
Know Your Business Processes
Business processes are the tasks performed by an application’s users. “These are scenarios or workflows that describe a path through the application to accomplish a particular task, such as entering a product order or shipping goods,” she says. Each role is associated with a set of processes, and some processes may be linked to more than one role, she adds.
More complex processes also exist, sometimes spanning multiple applications and roles. These too must be incorporated into any comprehensive test plan, because “without a test plan that mimics the interrelationships between users, processes and data, comprehensive coverage cannot be achieved.”
Also a critical part of the test plan is to verify permission as well as prohibition. “Most of us think of security in terms of denying access to unauthorized users, but it is perhaps even more critical to permit it to authorized ones,” she says. “While exposing data or capabilities to the wrong user may violate internal control policies, refusing necessary access may prevent one or many employees from getting their jobs done.”
Want to read more? Hayes expands on this topic in a past issue of Software Test & Performance magazine. In the full article, she covers testing environments and permissions, data strategies, the enterprise calendar and ideas for integrating role-based testing.
Author:
Edward J Correia