You might not have noticed anything about it yet, but after 260 hours, spread over 5 months, of designing, coding, writing, and reviewing on my side, my first book, and the first book on test automation for Microsoft Dynamics NAV / Dynamics 365 Business Central has been released last week. Finally, a wish came true, an ambition, started probabably back in 2011 with my series on NAV and Test-Drive Development. Having been a tester in the Global Localization Development team at Microsoft (and having to leave just when we were getting into test automation) the inner testing fire was lit again by Bas Graaf's NAV TechDays 2011 presentation High-Quality Test Automation for NAV Applications. And I have kept it glowing, and got it burning more and more over the years past. By blogging, by talking at various conferences, and not the least, by pushing automated testing into the development practice of my main employer, The Learning Network (TLN). Against the flood in the early years, as little to none of us seemed to dare to step into it. Well. except Microsoft, but, yeah, Microsoft, that's not us and they initially did not make it easy for us to get on it.
You know, I already launched the idea of a book on test automation to Packt in November 2011, but, sign of the time, it was never picked up. Disappointment? Well, in way, yes, but you know, I still have the portfolio manager among my contacts on LinkedIn. I am not a real hard-hearted guy. I surely do not want to be one.
All the years following there wasn't a real change in how automated testing was looked upon. True, it did evolve; maybe I contributed to that. I hope I did, sure. But like many others Packt did not react. Until last summer. Even though I knew I was going to put me up with a hell lot of work, I also knew the tide was the right one: Microsoft enabling us more and more, more people picking up, and not the least AppSource requiring test automation. So I reposed my idea of a book on test automation to Packt and Packt agreed. Yeah, I could have done it on my own, like various others do and to whom I have been looking with all repsect, but I needed others to get those things organized that I would have had a hard time to manage while also focusing on the designing, coding, writing, and reviewing. Being a quality focused person, both with respect to the product and the process, there is a lot of things at Packt I kicked against, but I am sincerely grateful for their "dedication and endurance", as I wrote down in my original acknowledgement, but which did not make it as it was beyond the 450 allowed maximum number of characters. Here starts the part for which I am mainly writing this post, being the...
...in the book due to protocols at Packt and the scope of the book.
I owe a lot to my two major contacts at Packt: Roshan Kumar (Content Development Editor) and Snehal Dalmet (Technical Editor). I know I haven't made their lives always easy as I had clear ideas on how I wanted to put things down. Both of them have done there utmost best to go with my flow and still justify things within the Packt protocols. Working remotely I did not have the fortune to meet them live, but I recon that some times the go-with-Luc's-flow did make steam escape from their ears. A big bow towards you both, Roshan and Snedal.
The proof is in eating the pudding as we say, and this surely applies to the topic of the book. The knowledge that I am sharing with you is based upon a lot of things I learned from others by reading, arguing and listening. But it has matured by having been able to apply it in real live. For that I owe my main employer, TLN, and specifically my team, Team Dynamics: Bert Kootstra, Gert Kleinjan, Jack Reitsema, Marcel Müller, Martijn de Blaauw, René Brummel en Stefan Venhuizen.
Another major influence to the book, who als fell of the 450-characters-including-spaces table, is my peer MVP James Crowter. A great, a tall, a knowledgable, and a challenging guy. The guy with whom I did the 2017 NAV TechDays presentation on test automation, in retrospect an important step in cristalyzing my thoughts and ideas that made it to the book. And not the least James the owner and managing director who apparently has the gift to form a great team around himself and invests in them. For the latter he asked me to introduce his whole team to test automation and about a year ago I performed two functional and two technical workshops with them, including James himself (and the other James who was a reviewer and wrote the foreword to the book). It was a great experience with all this dedicated and jolly nice people, and learned me a lot. It also brought me to the from customer wish to test automation concept for a number of presentation and the key part of the book.
Approx. 200 pages is a lot of space to fill when you start. A huge fan of Kansas when an adolescent the first line of one of there songs returned in my conscious a zillion times when writing, and still a vast amount of pages to go. Nevertheless the pages got filled and some topics had to be left untouched, among them the following:
Let's see if I can find time to get back to so more frequent blogging, or others to step in, like James Pearson did with respect to the last bullet: Testing Microsoft Dynamics 365 Business Central from VS Code.
I guess I have said what was left unsaid in the book. I sure hope, when you acquire the book, it helps you get on test automation as we need to, our clients need us to! And even more: I hope you can enjoy it as much as I do.
Thanx and good to hear, George
It is a great experience to read this book on test automation and I must say some amazing business tactics according to the market trend. The assignment help australia is a cheap approach for college students in order to get help int their academic work.