Book Image

Microsoft Dynamics AX Implementation Guide

Book Image

Microsoft Dynamics AX Implementation Guide

Overview of this book

Microsoft Dynamics AX is Enterprise Resource Planning (ERP) software that supports multi-site operations across various countries, providing international processing within the company. It is an ERP solution with a lot of features and functionality, and it provides support across the fields of financial, distribution, supply chain, project, customer relationship, HR, and field service management. This book is all about simplifying the overall implementation process of Dynamics AX. The purpose of this book is to help IT managers and solution architects implement Dynamics AX to increase the success rate of Dynamics AX projects. This all-in-one guide will take you through an entire journey of a Dynamics AX implementation, ensuring you avoid commonly-made mistakes during implementation. You’ll begin with the installation of Dynamics AX and the basic requirements. Then, you’ll move onto data migration, reporting, functional and technical design, configuration, and performance tuning. By the end of the book, you will know how to plan and execute Dynamics AX right, on your first attempt, using insider industry knowledge and best practices.
Table of Contents (23 chapters)
Microsoft Dynamics AX Implementation Guide
Credits
About the Author
Acknowledgments
About the Author
About the Reviewers
www.PacktPub.com
Preface
11
Testing and Training
Index

Testing


Testing is the process of validating the system and processes to meet the business requirements. It includes testing the custom as well as the standard features, along with the migrated data, integrations, reports, and security aspects of the solution. It is an area that is most often underestimated and, as a result, hampers the success of your project.

A very common misconception is that testing starts after the development phase is over. The primary goal of testing is to provide feedback on the product as soon as possible. Identifying any issues in the requirements phase prevents them from becoming a part of the design. Similarly, identifying any issues in the design phase prevents them from being coded. The cost of fixing a defect depends on the phase where it has been detected; the cost of fixing a defect in the early phases of SDLC (Software Development Life Cycle) is much lower than in the later phases. The farther you go with the backlog of testing/validation, the more debt...