Testing Your Modifications Properly in AX 2012
As we all know, testing modifications in Dynamics AX 2012 is part of the development process. Many times, when a Design Specification is passed on to the Developer, table and field information is provided in the document, stating where the data shall be retrieved. This information is great to have, as it allows the Developer to build out the modification more efficiently, since the information will simply have to be validated instead of needing to be located (this goes back to creating a good specification document).
BUT, even though the table/field structure has been defined, there still needs to be valid test data in the system to allow proper testing of the modification. Business Analysts need to remember that most Developers are NOT functional consultants. The Developer may have basic knowledge within a module, but may not know the intricacies of how to create the needed data. This means that the Business Analyst really should look at this in a couple of ways when preparing a Specification Document:
- Look at the base process that is being modified. Does data exist for the base process so the standard process can be completed in the Development data? If not, data will need to be created, OR the Specification Document will need to provide detailed steps to create the necessary data.
- Is all the related data in the system? For example, you have individuals that take orders, and this user is tracked in the system. If the requested modification is to retrieve either address or contact information for that individual, is the underlying data there? The individual may have been created, but is the phone number, address, etc. also in the system.
- Custom data. If the modification creates custom data, is the underlying existing data that the customization enhances in the system?
This may seem like a minor part of the process (or at least a minor inconvenience to the Developer), but in reality this can cause large inefficiencies in the creation of a modification. If the Developer has to constantly go back to the Business Analyst for questions on where the data comes from, or the data simply doesn’t exist, how can you effectively test the modification prior to having it go to User Acceptance Testing?
Keeping these key points in mind will avoid confusion, decrease time spent in testing and ultimately result in a smooth and efficient development process.