Blogs Banner
Performance testing of Microsoft Dynamics 365 (D365) – Learn from our Expertise & Experience

Performance testing of Microsoft Dynamics 365 (D365) – Learn from our Expertise & Experience

28th Nov, 2019

At Testhouse, we have spent an enormous amount of time in building a solution that meets both business & technical needs. The starting point of our journey in building this solution was not as easy we thought for various external factors playing a big role in today’s dynamic environment.


We tried to gather inputs required for conducting load testing of D365 and my team had a great learning journey. We were lucky to get a few information quite quickly due three major reasons 1) We did have a team of QA/BA combination with strong domain & technical knowledge; 2) We could easily connect with Microsoft, Testhouse being valued partner; 3) Testhouse could easily connect with major load testing tool providers due to existing strong relations & partnership


Here are a few pointers you need inputs prior to creating a performance test strategy


  • D365 – Environment (dedicated / sandbox), Modules, version, hosting details (on-prem, cloud etc) & current or expected volume of users and data.
  • Workload – Critical business scenarios, peak load & distribution of load across scenarios. Test data, ramp-up, steady-state, benchmarking details.
  • Load test set-up – Tools required (load testing, monitoring), Distributed load test agents etc..
  • Stakeholder – Involvement from various stakeholders from Business, IT, QA, Dev etc…
  • Acceptance criteria – SLA Response time, Server-side utilization, throughout etc…


We recently successfully conducted load test for one of our client based in the UK and following are the high-level details on our approach.


Our client had approached us to assist them in defining the performance test strategy and conduct load test for their D365 application which was customized to be used by agents from various locations for their contact centre.


We applied The Pareto principle – 80/20 rule to simulate more realistic load & this also greatly helped us identify the most business-critical scenarios. Most of our scenarios were spread across two key modules – Customer Engagement (CE) and Finance & Operations (FinOps).


As the next step, we had dedicated sandbox environment (with production backed data) was set-up for us to create load test scripts against agreed scenarios. As we already knew the pros & cons of various load testing tools available today, we had finalized the tool post a quick PoC (Proof of Concepts) with our client.


Choosing a tool purely depends on the client’s requirements & hence we urge our client to involve all the key stakeholders. For example, a few aspects such as time & budget plays a critical role in providing a cost-effective solution. Similarly, anticipated user load, number of scenarios, type of load test, on-premise or cloud deployment provide inputs in choosing the right tool available today.


We decided to go ahead with Micro Focus StormRunner load (LoadRunner Cloud) mainly for below reasons


We were looking for a tool that would help simulate more realistic load and help us get our scripts created in a short time. GUI protocol (TruClient – web) protocol gave us these key benefits. As we had agreed for a few cycles of load test, we had the option to choose both Vusers (VU) – Fixed license & VUsers Hours (VUH). StormRunner load utilizes cloud-hosted load generators and hence our execution was as per our expectations.


We have in past come across challenges in setting-up load generators especially for high volume users using high memory footprint.


One other good feature about StormRunner is the tool has features that help you effectively track your license consumption. You can, in fact, purchase VUsers Hours (VUH) online.


1 VUH is effectively 1 VUser executing a load test for 1 hour. You can Micro Focus online calculator to size your tests and get to know the cost well in advance to complete your planned test runs.


To summarize, we could help our customer identify bottlenecks and point out all the transactions that violated expected response time SLA. We also pointed out the key components of pages that took more time to load. We had used monitors for measuring the App, DB servers for CPU, Memory, Disk & other key metrics.


If you have any inputs to share or looking for additional information on our service offerings, solution approach, please do not hesitate to contact us

About the author

Shivaram | Director - Digital & Cloud Quality Assurance Services

The author is experienced in Application Lifecycle Management (ALM), Performance Engineering & Application Security and has executed high volume load tests using HP LoadRunner, Microsoft Visual Studio & JMeter for various applications across domains.