A use case is just one corner case, and developers working with code very often test just for that one corner case. A corner case can be described as a program error or software bug that occurs outside of normal use, or caused by parameter values and environments outside the intended acceptable range. I’ve learned that corner cases are more common than what developers like to admit, so much so that working code is just another corner case.
In my experience, the number one source of corner cases are assumptions hard code and baked into the source code, like assuming that your users have five digit zip codes, or use an English alphabet, or are based in a specific timezone, etc. Sometimes corner cases arise because someone cut a corner, didn’t check if an input parameter fit a certain criteria, was of a specific format, length, or within an acceptable range. Yet with all the assumptions we inadvertently leave behind in our code, I’ve seen developers take great offense and defend their code with the fervor of a religious zealot by saying, “you are not supposed to enter non-numeric values.” Even with the most stringent process and under tight deadlines, developers have been known to regress to the “if it compiles, ship it” mentality. You can cut corners in the design and implementation of a software program, but you most often will not cut the corner cases where bugs like to linger, hide, and build nests out of code. The number of corner cases is proportional to the complexity of an application.
Related posts:
One Comment
very well said :)