Smoke Testing Scripts for Dynamics 365 Apps: A Complete Guide

In the dynamic landscape of enterprise software, where Dynamics 365 applications are constantly evolving with customizations, updates, and integrations, ensuring basic system stability is critical. That’s where smoke testing plays a pivotal role.

Smoke testing—often referred to as “build verification testing”—serves as a first-level check after deploying a new build, update, or solution. It verifies whether the most important functions of a Dynamics 365 application are working correctly before proceeding to more detailed functional or regression testing.

This guide walks you through what smoke testing means in the context of Dynamics 365 apps, how to write effective scripts, tools you can use, and real-world examples of test scenarios.

✅ What is Smoke Testing?

Smoke testing is a quick, shallow test that verifies:

The build is stable enough for further testing
Major components are loading and functioning
No critical failures are present in core functionality

In the context of Dynamics 365 apps (Sales, Customer Service, Field Service, etc.), smoke tests usually validate:

Login functionality
Basic navigation
Key record creation and retrieval
Major UI elements and form loading
Entity relationships and business rules

Why Smoke Testing is Critical for D365 Projects

Whether you’re deploying a solution in development, QA, UAT, or production environments, smoke testing offers benefits like:

Quick Feedback: Catch issues early before more time is invested in deeper testing
Deployment Verification: Ensure solution imports, plugin registrations, and customizations are error-free
Risk Mitigation: Avoid embarrassing bugs reaching users in production
CI/CD Readiness: Acts as a gate for pipelines in automated deployments

Tools to Create Smoke Testing Scripts

You can write smoke tests in several ways depending on your preferred level of automation.

Manual Tools:

Azure DevOps Test Plans
Excel/Google Sheets Templates
TestRail / Zephyr / Xray for Jira

Automated Tools:

EasyRepro (Microsoft’s open-source UI test framework for D365)
Power Automate Desktop
Selenium + C# / Java
Playwright / Cypress (for portals)
Postman (for API-based smoke checks)

Structure of a Good Smoke Test Script

Every smoke test script should follow this format:

Element	Description
Test Case ID	Unique identifier
Title	Concise test case name
Preconditions	Any setup required before executing
Steps	Clear, repeatable actions
Expected Result	What should happen at each step
Actual Result	Captured during execution
Status	Pass/Fail

🔄 Example Smoke Test Cases for Dynamics 365 Sales

Below are common smoke test scenarios for D365 Sales:

1. Login Verification

Step: Navigate to D365 URL and log in using valid credentials
Expected Result: User lands on the home page

2. Create a Lead

Step: Go to Leads > New > Fill required fields > Save
Expected Result: Lead is created and visible in the view

3. Qualify a Lead

Step: Open an existing lead > Click “Qualify”
Expected Result: Opportunity is created, and Lead status is changed

4. Access Dashboards

Step: Open Sales Dashboard
Expected Result: Charts and views load without errors

5. Global Search

Step: Search for a known contact name
Expected Result: Contact appears in search results

Example Automated Script Using EasyRepro

[TestMethod]
public void SmokeTest_CreateLead()
{
    var client = new XrmApp(new WebClient(TestSettings.Options));
    client.OnlineLogin.Login(TestSettings.D365Url, TestSettings.Username, TestSettings.Password);
    
    client.Navigation.OpenApp("Sales");
    client.Navigation.OpenSubArea("Sales", "Leads");

    client.CommandBar.ClickCommand("New");
    client.Entity.SetValue("subject", "Smoke Test Lead");
    client.Entity.SetValue("firstname", "Test");
    client.Entity.SetValue("lastname", "User");
    client.Entity.SetValue("companyname", "Test Corp");
    client.Entity.Save();
    
    var createdLeadName = client.Entity.GetValue("fullname");
    Assert.AreEqual("Test User", createdLeadName);
}

This example simulates login, navigation, record creation, and verification—all core smoke test actions.

Smoke Test Checklist Template (Manual)

Here’s a sample checklist you can use for manual smoke testing after a D365 solution deployment:

Test Case	Description	Pass/Fail
Login	User can log in	✅
Load Home Page	Homepage loads with no errors	✅
Create Lead	New Lead can be created and saved	✅
Qualify Lead	Lead can be qualified to opportunity	✅
Load Dashboard	Sales Dashboard loads correctly	✅
Global Search	Can search for Contacts	✅

You can expand this based on modules: Marketing, Customer Service, Field Service, etc.

🔄 When to Run Smoke Tests in the Lifecycle

Event	Why Run Smoke Tests
After Solution Deployment	Validate imported changes didn’t break core functionality
Before UAT Starts	Ensure the build is stable for end-users
After Configuration Changes	New BPFs, scripts, or rules can cause regressions
After Platform Updates	Microsoft releases updates monthly—always validate afterward
Before Go-Live	Final confirmation everything works before switching to production

Tips for Writing Effective Smoke Tests

Keep It Lightweight
Don’t test everything—just the essentials.
Focus on Business-Critical Paths
E.g., Lead → Opportunity → Quote → Order
Avoid Data-Dependent Tests
Reuse or clean up test data to avoid inconsistencies.
Include Both UI and Backend Checks
Use API checks to ensure data integrity along with UI tests.
Document Clearly
Well-written steps and expected results help other testers and team members.
Tag and Organize
Label smoke tests by module or feature area in your test management tool.

Automating Smoke Tests in CI/CD Pipelines

You can integrate automated smoke tests into Azure DevOps or GitHub pipelines to enforce stability gates.

Example Flow:

Deploy new solution to UAT
Run EasyRepro test suite
If tests pass → proceed to regression/UAT
If tests fail → rollback or block release

Example Azure DevOps task:

- task: VSTest@2
  inputs:
    testAssemblyVer2: '**\SmokeTests.dll'
    searchFolder: '$(Build.SourcesDirectory)'
    testFiltercriteria: 'TestCategory=Smoke'

This allows for a fully automated, early warning system against broken builds.

Smoke Test Scenarios by Module

Dynamics 365 Customer Service

Create Case
Resolve Case
Assign Case to Queue
Search Knowledge Articles

Dynamics 365 Marketing

Create a Segment
Launch a Customer Journey
Schedule a Marketing Email

Dynamics 365 Field Service

Book a Work Order
View Resource Schedule
Create Service Task

Best Practices

Run Smoke Tests on Every Environment Especially UAT and Production (post-deployment validation)
Keep Tests Fast Aim for a total execution time of under 15 minutes
Maintain Scripts Regularly Update scripts as forms, fields, or processes change
Use Test Data Management Clean up test data or use sandbox data reset strategies
Review Logs Whether automated or manual, always review logs for failures or slow operations

Real-World Use Case

Client: Global Manufacturing Firm
Scenario: Deploying weekly updates to D365 Sales and Service
Approach:

Created 20 automated smoke test cases in EasyRepro
Integrated into Azure DevOps pipeline
Post-deployment tests run nightly and on demand
Catching 90% of critical post-deployment issues within minutes

Typical Execution Time

Method	Time (Approx)
Manual Smoke Test Suite (10–15 tests)	20–30 minutes
Automated Suite (EasyRepro)	5–10 minutes
API-based (Postman, Power Automate)	Under 5 minutes

Common Pitfalls to Avoid

Testing too much in smoke tests (shouldn’t become full regression tests)
Relying only on UI—combine with API and backend checks
Not maintaining tests regularly—leads to false positives
No clear pass/fail criteria—causes confusion in reporting
Running only on one environment—risks missing env-specific issues

Smoke Testing Scripts for D365 Apps