Types of Testing for Microsoft Dynamics 365 Finance and Operations

Types of Testing for Microsoft Dynamics 365 Finance and Operations

Testing types for Microsoft Dynamics 365 Finance and Operations one version D365FO

ERP implementation projects require different types of testing during the testing phase of the project. Each type represents a different objective, scope, and depth of testing.

Feature testing
Feature testing, also known as function testing, is standalone testing of individual features performed by the QA resources or business analysts. Primarily, there are two sets of features to test here: custom features being developed by the project development team to fill the gaps, and standard or ISV solution features being configured by the business analyst.

Testing of custom developed features
Testing of custom features by the project team involves unit testing, which is standalone testing of code artifacts, and is usually performed by the developers to ensure that individual code elements are working as expected. In software engineering terms, unit testing typically refers to automated testing. It provides many benefits that include finding bugs earlier, providing a safety net of tests for changes that are made later, and improving design. Over the long term, unit testing improves customer satisfaction and developer productivity.

Testing of standard and ISV solution features
While the development team is doing custom feature development, business analysts are usually busy working on collecting configuration and master data and setting up the standard solution as per the requirements. The second part of feature testing is about testing the standard and ISV product features. This includes configuration such as parameters, reference data, workflows, security, and master data, and then testing transactions such as sales orders, purchase orders, production orders, and journal entries.

System integration testing
After feature testing, the next part is to test various subprocesses and processes together. By this time, the core configuration is already done, some level of data migration is also done, key custom features are developed, and various systems and solutions are integrated. There are various parts of system integration testing, and they usually get tested in parallel. The following are the testing categories that typically falls under system integration testing.

Process/system testing
Process or system testing involves testing subprocesses and processes. In this phase, typically all major processes are tested with system configuration and master data. Depending on the implementation scope and requirements, the testing team will test processes such as record to report, order to cash, procure to pay, and plan to produce. The objective of this testing cycle is to identify the correct configuration of parameters, missing master or reference data and any additional bugs or potential gaps.

For a simple business process example, consider the testing of the Order-to-Cash process beginning with a single order transacted through its entire cycle. The process starts with creating a sales order, picking and shipping the product, and then invoicing the order. Along the way, the system updates the inventory and accounting. Finally, payment is collected from the customer, the payments are applied, and customer balance is updated within the accounts receivable module.

Data migration testing
Either you are replacing the old legacy system or upgrading from the previous version, the business will need legacy data migrated to the new system. Data migration testing is basically testing the data integrity and data quality. No matter how you decided to migrate the data, the testing team needs to analyze the migrated data and perform validation and transactions at the end of the data migration to ensure that the data migrated is complete and accurate to do future transactions. For example, if open sales orders are migrated from the legacy system, you need to ensure that you are able to ship and invoice these orders and ultimately, collect cash.
You also need to ensure that numbers, such as order count, account balance, and inventory levels, match between the legacy system and new system to make migration complete and accurate. A solid data migration strategy should also define the parameters for the success of data migration testing.

Integration testing
Testing the integrations with other systems that have been developed is just as important as the features and functional testing of the product itself. Integration testing is performed across applications to verify the seamless flow of information. All individual applications must be tested independently and made ready for integration testing. You will need an integrated environment across applications to perform this testing. For example, Finance and Operations requires integration with the CRM system; in this testing process, you will probably create customers in the CRM system and expect them to flow to Finance and Operations.

Performance/load testing
Performance testing or load testing is a process of identifying performance issues and solving them. It is important to conduct performance and load testing and tuning before going live to eliminate the issues that can impact the business negatively. It does not matter whether you have high volumes or not; you still need performance testing. At this stage of the project, the development of custom features is complete and functional testing is in progress. This is the time to validate the overall performance of your Finance and Operations system. The primary goal is to ensure that the solution will accept peak load without any major issues.