Sunday 1 July 2012

Take it with a pinch of salt

One lesson that I'm learning fast as a software tester is that you won't improve if you take everything you see, hear and read at face value.
In the interests of saving time and/or effort this is a very easy trap to fall into.  Perhaps the time when one is most susceptible to this is when you are inexperienced and are at the mercy of all the new information you are being bombarded with.  Ironically,  this could potentially be more harmful for those with more experience and responsibility, who believe they know everything there is to know and therefore stop asking questions.

It sometimes feels like there is no other option than to believe the information you're being given at face value.  At least if it's not acccurate you can use it as a baseline which can be modified as new information comes to light. 

One example of where I fell into this trap was when I had some testing to do on a new feature and I wasn't sure if the testing had to be done on all of the environments we use.  I didn't want to spend time duplicating my tests in different areas if this was not necessary.  As much as it would be ideal to test everything in every possible scenario and environment, this simply is not possible, so we try to fit the best coverage we can into our timescales.  So I asked someone if it mattered which environment I used to test the new feature on and they told me it didn't.  The person I asked has a lot more experience than myself so I felt I had no reason to question what I was told.  I duly carried out my testing and reported the results, not realising I had not been testing exactly what I thought I had.  In hindsight, if I'd asked a couple more questions I probably would have realised what should have been tested.  So I learnt an important lesson that it's much better to ask one question too many, at the risk of looking stupid, and get things right, than to avoid that question and end up making yourself look really stupid.

Another example where information can be misconstrued are bug descriptions.  It is very easy to think that the report you're writing about the bug you saw 5 minutes ago is as descriptive written down as it is reproducible in your mind.  When you've forgotten about that bug and then read your report a month later is it still as clear?  Even more importantly, is it clear to someone else?

I'm not saying people shouldn't be trusted but you need to know what they mean when what they've said or written looks to you like they mean something else.

I think the best way to combat this pitfall is to continue to ask questions until you are confident that there is no ambiguity left in your mind about what the facts are. This attitude and the frequency of questioning should not diminish with experience and if anything should probably increase.