Testing in unknown territory Martin Jansson
A few years ago I switched company from a software company to a hardware focused company. I understood from start that this would be a difficult task in getting to learn the new technologies and platforms, but I did not see what this would do for testing.
When you test software that you are totally new, but where you have experience with the environment such as operating system as well as technologies used, you are still able to dig deep into testing and will probably find lots of bugs.
If you instead test something where you are both new to the software/hardware/system and to its environment you will have it a lot harder to find bugs. You will stumble upon things like… oh this went wrong, then learning ah I did not configure it correctly or oh it is supposed to work like that. You are unsure what to expect and what is actually wrong.
Think of yourself as an explorer where you have no knowledge about the gear you are using, where you have landed, what this green thing you stand is and so on. Do you dare explore? That hot red thing over there… let me just dip a toe. Oh it was lava.
So, when you find yourself in such a situation you should do some research, read lots of books and get to know what territory you are in. Having knowledge about the environment and platform you stand on will enable you to do a better job as a tester.
And it’s not only the machine environment that is new; you also need to learn:
* which type of bugs are important and which are not
* which are the best ways to interact with developers
* who are the customers, and what do they do with your software/hardware
I have worked almost ten years at the same company, and usually fall into the trap thinking that I already know the things listed.
But these things, as everything else, change.
You also need to learn what matters in the new environment.
Things that were important at one place could be totally irrelevant at another place. And vice versa.
But if you are new to the environment, you will also find other bugs than someone that knows the environment. So I dont really sign in on the “read all possible books” etc. Why not just dig into it, and then try to learn as it goes…Thats what the explorer does, even if I loose a toe or two. Instead explore, and then read whats relevant.
Yes, I will probably find other kinds of bugs in some contexts. In other contexts, what this article is all about is when you have too little knowledge about the environment so you will find things that you think are bugs but infact they are not.
Also, I wrote “read lots of books” not “read all possible books”.
For instance, when working with built-in systems you spend a lot of time on setup and configurations before you are able to start testing. It is very common that you do mistakes in these setups and configurations that leads to errors. These are caused by human error and are not always bugs. Hope this makes the article clearer?