Skip to content

Developers and Testing – Part 3: Improving Your Testing Skills

ArcherPoint’s technical staff pose questions, find answers, and share new discoveries about Microsoft Dynamics NAV

In this four-part series, ArcherPoint’s Matt Traxinger discusses the relationship between development and testing, how to improve your testing skills, and an alternative approach to testing. If you’re just joining us, be sure to read Part 1: Developers Don’t Make Good Testers and Part 2: The Importance of Quality.

We all do our best to sufficiently test changes to our Microsoft Dynamics NAV databases. No one wants to introduce bugs into the system or cause trouble for other users. But very few people actively try to get better at testing. Fortunately, I’ve got good news: It’s not hard to get better. It is, however, a life-long learning type of activity. We’ll start with a few quick tips and go from there.

First, you have to lay the foundation, and that means making sure everyone understands the requirements. Accurate requirements and assumptions dictate everything from budget and timeline to the test cases to confirm the functionality. They set the direction for all of the work. Whatever your role, you must do this if you want to succeed.

Graphic illustrating building skills

If you want to be a successful tester, you have to understand the product from other perspectives. Developers, you need to understand the functionality; otherwise, you might be building something that already exists. You won’t know that you can copy code from another area to fit your needs. I guarantee that you will break things…I did.

Consultants and users, you need to understand a little of the technical side. I’m not saying you need to be able to write code, but you do need to know the names of the objects involved in the major processes (Sales Header table, Sales-Post Codeunit, etc.). For example, when a developer modifies a posting routine for sales orders, you should test posting sales credit memos as well. By understanding the objects that were changed for the modification, you can extrapolate information about other things to test.

For the end users who might be reading this, do not over-rely on your Partner to perform your testing. Do rely on them for planning, guidance, or help to create and document a testing plan. At the end of the day, remember that it is your system. Too many times I have heard customers say that they have tested, but haven’t (ledgers never lie) or that they didn’t test in the upgraded database because it has always worked “just fine.” It’s great that you think so highly of your Partner, but we’re people, too.

Finally, ask questions. No one knows it all. There is so much functionality built into NAV, and over two million lines of code to support it. In the introduction, I said this was a life-long learning exercise and I meant it. Find others in your organization to supplement your skills. Learn from and help each other. It’s the only sure path to success.

In the final part of this series on testing, we’ll discuss the different testing options that are available to you. Many organizations don’t even realize that there is more than one option, so hopefully, it will be enlightening for everyone.

If you are interested in NAV development, check out our collection of NAV Development Blogs.

For step-by-step instructions on how to perform specific tasks in Microsoft Dynamics NAV, see our collection of How-To blogs.

Blog Tags: 
Read ArcherPoint's Blog Follow us on Twitter Follow us on Facebook Follow us on LinkedIn Link to our RSS feed Join us on Google+ Watch us on YouTube