All around NAV dev …

… and test. As you might have noticed: the sub title to my blog. [:D]

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. [H]

Sunshine vs. Rainy

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:

  • requirements aren't always precise
  • users always tend to find ways of doing unexpected things
  • the coding hasn't be done well
  • end-user and development team seem to talk a different language

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.

Read More

[So far haven”t found a lot to mention here, but over time I imagine the list will grow.]

Leave a Reply

Your email address will not be published. Required fields are marked *