After reading this article, I conclude that his definition of edge case is pretty different than mine. More specifically, he seems to describe handling all errors as edge cases, whereas I would consider most errors as errors, and edge cases are either a sub-set of errors or a sub-set of user-flows, depending on the desired result of the edge case.
My defnition of an edge case is “the area where an action (or parameter) transitions from correct to not correct.”
In examples: I am currently specifying a product where the output is an analog signal which can be between 4mA and 20mA. This is based on an input digital signal which is an integer between 800 and 4000.
To test the input at 799 and 800, 4000 and 4001 would be edge cases. The edge here is clear. This is easy to test.
But there are other edges which are not clear. A lot of my test work is based on this. In the same system, the output should be between 4.000 mA and 20.000 mA. According to the product specification, the values 3.999mA and 20.001mA should not be allowed. So any test where those numbers are possible as output would fit my description of an edge case. The trick is in finding the values where that is possible. If I can make the output fail with less than the minimum or more than the maximum, the next question DOES correspond with one of his “quadrants” (I have a problem with quadrants too, but if the model helps him, then I won’t complain). When the output is slightly wrong, what does the system do?
It is worth noting at this point that in an analog system, such as I am describing, the answer is usually different than a digital system, such as a web site or an app. Edges are usually better defined in digital systems. But one significant exception is in timing. The edge case for “how fast” is a very grey area. If the specification states, “This system should handle 100 messages per second” then sending 100, or even 101 messages in a second are not the edge cases. The edge may be 200 messages per second or even 2000 messages per second. The fun here is in finding just where the edge is. And in a lot of cases, it is VERY important to know both where the edge is and what happens when that line is crossed. Such as my 200 messages per second system. The client had 100 devices which were on a network, so we specified that it could be up to 200 devices to give the client room to grow. The client really liked our system, so they ordered 500 devices! That is now up to 600 messages per second.
In the timing case, we were lucky enough to have a very good IoT network protocol person who created a system so good that 600 devices wouldn’t even scratch the surface of the system’s capabilities. But what if they didn’t? What if we sent out the extra 500 devices and they crashed our customer’s network? (The answer, by the way, would have been newsworthy)
So to answer a wonder with some questions:
How do we design systems or tests for known edges?
How do we design systems or tests for unknown edges?
How do we design systems or tests for combinations of edges (aka corner cases)?
How do we design systems or tests for edges which change depending on the circumstances?