When I did software testing for HP, one group of errors I specifically tried to account for were corner cases. The common thinking was that it was always relatively easy to find many bugs - they were in the middle, so to speak. But product quality was always high in mind at HP, so we wanted to dig out odd little bugs that 'hid in the corners.' Besides that, an expensive piece of test equipment, especially one in a lab, can be used in all sorts of odd ways over the course of its life. And the definition of a corner case is a situation that happens under extreme conditions.
After a while I started thinking about extending this idea. What if you referred to a corner case in terms of how the system is used in general, instead of adjusting specific parameters. If the usage of a program, or software embedded in test equipment, or even a test station, is a three-dimensional space then what are the dimensions? To frame it as a physics question, what are the degrees of freedom?
One dimension would have to be the number of functions - all the distinct things that a user can get the software to do. If you use just a few of the software's features (typically the most common ones), then you are not likely to find a corner case bug. The most common features are usually thoroughly vetted by the design team. But if you use a lot of those features, in different orders, then you may find something bad.
The second would be time. That is, the more a program is actively running (not just idling), the more likely it is to encounter a problem. It may be a memory leak, but it could be some other problem as well.
The third and final degree of freedom is the number of users of the system. I've written programs that were buggy, but that was fine because I was the only one using it. I ran it a certain way, to do certain things, and it worked just fine. But if I gave that program to someone else, sure enough they would crash it. This can be generalized to, "The number of ways in which a program can be used and abused increases proportional to the number of users of that program." And this applies to inanimate users as well. If a program can be accessed and used by some other application, then that program is itself a user.
So, lay these three degrees of freedom on orthogonal axes and you have a Feature Space Cube (FSC). Down by the origin you won't find many interesting bugs. The farther out you go, the more interesting things can get. Think about the ramifications for a while, and the concept can be a useful way to picture a system, not to mention entertaining in a geeky sort of way.
1 comment:
Hi, Interesting blog this you have got here.
I came across this through wikipedia. I started my career as a board designer and then sort of was asked to take up manufacturing testing for modems more on the program management side due to lack of resources. It seems to be a little confusing because engg. says ur with operations and operations keeps reminding you how impt. engineers are to this field. So i have been on this sort of mission to understand what on earth is going on here and i stumble upon your blog. Keep blogging.
I guess what i have been trying to understand is what does it take to become a good test engineer, when exactly does test engg. become operations and when does it be come engg. or when does it become both.
I am also trying to figure out the skill sets that you would require to cover test engg. because the skill sets are seemingly different from that of a board designer. (I sort of am beginning to find board design uninteresting).
Would apreciate your feedback. Thanks for your time.
Regards
Vivek
Post a Comment