Given BDD is user-centered approach to development, it makes sense to start showing you how you can use BDD in the context of user acceptance testing (UAT) . If you are new to BDD, you can read my previous intro post.
What is user acceptance testing?
Essentially any testing you do will eventually be contributing towards making sure that the system is accepted by users in the sense that it meets user requirements. However in most cases the users will be interacting with Dynamics 365 CE UI and they expect the UI to provide the features they need. So in this post I will focus on how we can use BDD to ensure the application will deliver the expected user experience.
What tool do you need?
I will be using the popular SpecFlow framework. This will allow you to define our requirements and drive automated testing.
I will also be using EasyRepro framework. This will allow you to interact with the CRM UI as part of automated testing.
If you are new to EasyRepro and UI Automation, you can read my previous posts on this.
How do you document the requirements?
In SpecFlow you document the requirements in Gherkin language using feature files that contain scenarios. Each feature can have multiple scenarios. Think of these specifications are your acceptance criteria for your user stories.
Most likely you will first have high level discussions with your users around what they need, as you get to details and have grooming sessions with your team, you will arrive at the BDD requirement specification. This is the agreed scenario that the system is expected to provide.
Feature: Introductory phone call In order to provide excellent customer service As a customer service I want to arrange a follow up phone call with new customers Scenario: Follow Up Phonecall on Account Creation Given I login to CRM When I navigate to Sales and select Accounts Then I click on New command And I set value of name to RandomString of 8 And I set value of telephone1 to '123456789' And I set value of websiteurl to 'http://dynamics.microsoft.com' Then I click on Save command When I go to social pane and select Activities Then Activity timeline count should be equal to 1
How do you ensure requirements are met?
Firstly as you can see from the above, the specification can be easily understood by the business user and it is specific enough for developer and testers to implement and verify. The chance for different team members to have a different understanding is very low.
Secondly you can take this to the next level by linking your specification to automated tests.
How do you link scenarios to tests?
Luckily SpecFlow does most of the hard work for you. Essentially every statement in the scenario has an equivalent piece of code that executes as the test automation framework runs through the scenario. Let’s take a look at a few examples.
Given I login to CRM
The first line in the scenario will basically translate into the below method that will open a new instance of the browser pointing to CRM.
[Given(@"I login to CRM")]
public void GivenILoginToCRM()
{
string url = Environment.GetEnvironmentVariable("CrmUrl", EnvironmentVariableTarget.User);
string user = Environment.GetEnvironmentVariable("CrmUsername", EnvironmentVariableTarget.User);
string pass = Environment.GetEnvironmentVariable("CrmPassword", EnvironmentVariableTarget.User);
xrmBrowser = new XrmBrowser(options);
xrmBrowser.LoginPage.Login(new Uri(url), user.ToSecureString(), pass.ToSecureString());
xrmBrowser.GuidedHelp.CloseGuidedHelp();
xrmBrowser.ThinkTime(500);
}
Let’s take a look at another scenario line.
Then I click on New command
In the second case we have added the parameter ‘command’ to the method. When this scenario line executes, it will pass ‘New’ to the method.
This is great because you only need to write the code for the click command once and you can re-use this in many scenarios. Eventually you will have handlers for most of the user actions. So creating automated tests will not take very long.
[Then(@"I click on (.*) command")]
public void WhenIClickCommand(string command)
{
xrmBrowser.CommandBar.ClickCommand(command);
xrmBrowser.ThinkTime(1000);
}
You can take a look at the full implementation of this scenario on GitHub.
What have we observed?
- We can use Gherkin/SpecFlow to clearly define requirements using specification that can understand by all team members
- We can use SpecFlow/EasyRepro to link specification to automated tests
- Once grammar and implementation are created for a specific action, this can be re-used in other scenarios
- Using BDD we can ensure the system will meet the user requirements
Note this particular scenario that I can described can be useful to define smoke or regression packs that can be run as part of automated build/deployment to ensure your high level acceptance tests are regularly tested and working.
Whats next?
In the next post I will show you how you can apply BDD to other types of tests.
Wael Hamze 