MS Dynamics CRM – Automation Testing: Validating Entities Access Rights Through Selenium Testing Framework

This post covers how to automate tests for validating access rights of MS Dynamics CRM entities, using selenium C# automation framework.

One of the most important components of MS Dynamics CRM is an entity. Entities are used to model and handle business data.

Learn more about our QA Services

Learn More

 

Entity Types: There are three main categories of entities.

• System
• Business
• Custom

Entities are associated with different security roles. These security roles are a matrix of privileges and access rights.

Usual access rights in MS dynamics CRM for each entity are as follows:

Create – Enables users to add new records.

Read – Enables users to view a record.

Write – Enables users to edit records.

Delete – Enables users to delete records.

Constraints of manually testing entities access rights

From the testing standpoint, we need to validate that the user’s security roles (user rights) for different entities are correctly configured. When we have multiple users in CRM, at times, it becomes difficult for a tester to manually validate security roles (user rights) for different entities.

In a testing scenario, manually verifying security roles (user rights) of multiple users for multiple entities is challenging and time-consuming, because the user must manually navigate through the entities one after the other and perform the access operations. This, in return, increases the company’s testing resources, time, and cost.

Automating effort for testing user rights

Here selenium C# scripting comes into play for minimizing our testing effort. We can develop a data-driven test framework. In this framework, all our test data is generated from some external files Excel, CSV, XML, or some database table. At times, testers also need to test the same feature/function of an application several times with different data sets.

This framework can be handy to test the application under test exhaustively for various test scenarios and cases without hard coding the data in the script.

We can define an excel template with the user’s credentials, entity names, user roles, and user rights Boolean values. This template can be defined as follows, but it may vary for different application domains.

The Automation Testing framework that we will be developing consists of multiple components and layers. Excel template is one of those components. The excel sheet shown in the picture above contains the following data:

• Username – A username that will uniquely identify the user and will allow him/her to test their user rights over different entities.
• Password – The secret password of the user which he/she will use to confirm his/her identity.
• User Role – The associated security role of the logged-in user.
• Entity Name – The name of the entity on which the logged-in user will verify his rights, e.g., reading that entity record, creating a new record against that entity, updating the entity record, deleting the entity record.
• Read – Boolean value (True or False)- This defined whether the user can perform a read operation on that entity or not.
• Create – Boolean value (True or False)- This defined whether the user can perform a create operation on that entity or not.
• Update – Boolean value (True or False)- This defined whether the user can perform an update operation on that entity or not.
• Delete – Boolean value (True or False)- This defined whether the user can perform a delete operation on that entity or not.

Defining testing framework layers

Now that we have developed our data source, we can move onto the next step, defining our framework layers.

The data-driven test framework is usually a three-layered architecture.

We have defined the test layer, which is reading test data from the excel file and validating the test cases with our test logic.

The test cases will be validated, followed by defined data in excel file one after the other for each defined entity and user.

Validating read access on entities

The test script will simply fetch rows from excel file and store data in the dictionary. Afterward, the script will validate the read access on an entity and validate the excel READ boolean value. If both conditions turn true, the test case would have successfully passed. However, even if one of the conditions is not met, the script will log the test case as failed.

Validating update access on entities

Once READ access is verified for a single entity, the script will try to perform an UPDATE operation on the same entity and validate the excel UPDATE boolean value. If both conditions are met, the test case is passed. In case the test case fails, it will be logged in the report.

Validating delete access on entities

After UPDATE access is verified, the script will move on and try to delete the record against the same entity along with validating the excel DELETE boolean value. All passed or failed cases will be logged in the report.

Validating create access on entities

Create access will be verified in the same manner as delete access. Please note that the verification of access operations on each entity should be sequential. For example, our excel has five rows for two users. This means that the script will need to validate user rights for one user on three different entities, and for the second user, it would validate on two different entities.

However, the flow of the scripts is sequential, i.e., after the script validates all entities for the first user, it will simply log out the user. It will then allow the second user to log in and perform their operations on the excel defined entities.

With our business layer, changes, maintenance, and scaling have become easier, which has allowed us to implement multiple classes for each operation. We have discussed a few of them below:

Excel Data Reader Class – reads data from excel based on our selected parameters.

Data Input Class -stores test data in the dictionary for test case manipulation.

Test Settings Class – For onetime setup.

The core layer is the framework itself. Its responsibility is to provide interfaces for upper layers, provide orchestration for a test run and reporting. Here is a selenium web driver, which is controlling the communication between our classes and doing the reporting stuff.

Reporting of test results

Extent report is also integrated with this framework, which will provide visibility for the end-user like how many test cases are passed or failed. A user can extract the following information from the test execution report.

• If a user has read, update, delete, and create access on an entity or not.
• The number of entities on which user rights are validated.
• The number of CRM users are validated for their user rights.
• The number of passed and failed cases.
• The sequence of test execution.

Conclusion

The purpose of this article was to teach readers about testing user rights on CRM entities with our layered automation framework. We also investigated how users can make use of the Data Provider to validate user rights over various entities without changing the test script. At AlphaBOLD, test automation is the core part of our development strategy, and we encourage our clients to minimize redundancies by incorporating the relevant test automation frameworks and appropriate strategies.

If you have any further questions or queries or would like to know about our test automation framework, please reach out to us using the comment box below.

If you have any question or queries, do not hesitate to reach out to us!