Personalized Community is here!
Quickly customize your community to find the content you seek.
Check out the latest Business Central updates!Learn about the key capabilities and features of Dynamics 365 Business Central and experience some of the new features.
Download overview guide | Watch Business Central video
2021 Release Wave 2Discover the latest updates and new features releasing from October 2021 through March 2022.
2021 release wave 2 plan
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Community | FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
... and test. As you might have noticed: the sub title to my blog.
Last Sunday's great 'pat on the back' from Vjekslav Babic (once again: thanx!) explicitly mentioned the test part of my blog and, to be honest, next to the fact that it made me somewhat shy, it also triggered me that I had dedicated myself to write about testing also. I know I did in some post, but also have been struggling with this theme and as such haven't written a lot about it explicitly IMHO; at least not as much as I initially wanted too. However one testing theme had been bugging me several times lately, being sunshine vs. rainy. So today, motivated by Vjekslav, I decided to pick this up. As I abhor redundancy I first did some goo.., uhhh, binging on this and also consulted my testing mentor. But I didn't get a lot from that. Probably I am not a very good/persistent binger. Hope you still believe I was quite a good tester.
The most obvious thing we do when testing a piece of software is asking ourselves: what is this supposed to do? And when we have found the answer, either from well documented requirements, in-code comments or coffee-corner talks, we will test whether it does what it is supposed to do. Straight forward, like when the sun is shining. This is what we call sunshine scenario testing. In a nut shell you could say: this is what it's all about. Build and test software that does what it should do. Nothing more, nothing less.
Unfortunately - depends on your perspective - it's always more complex than this as:
There is always someone or something to blame. And although the sun was shining when we started, clouds are getting in the way and even produce rain. It isn't anymore what was supposed/assumed to be. Therefor we also need to test the rainy scenario(s); i.e. feed our piece of software with invalid input, try to overload it, approach it from a different perspective, etc. In many ways the role of a tester is one of a demolisher, be it a constructive one. And this doesn't start just when code is available. It should already start as soon as requirements are being conceived. In every phase of a software project there are things (i.e. deliverables and processes) to be tested.
[So far haven''t found a lot to mention here, but over time I imagine the list will grow.]
Business Applications communities