When the extremes sneak up on you
We’re looking to tackle one of the testing conundrums that trips up a lot of product developers. So we’re sharing our knowledge on Edge Cases.
What are Edge Cases?
Edge Cases is the process of testing for boundary conditions. Essentially looking for extremes on product usability for maximums and minimums along with any outlier functionality.
Most software engineers and designers go down the ‘happy path’. They test the environments the way they expect a user to use it; focusing on which buttons they think end users will press, how they’ll use the device and what scenarios they might put that product in.
A lot of bugs are caused by scenarios most people don’t think to check.
Why don’t people do Edge Cases?
The cost of testing or fixing a bug that’s only encountered by 1% of users can be way out of proportion cost wise, especially when compared to testing that’ll affect the other 99% of users.
Sometimes this means the bug might not be worth fixing, but you probably still want to know it’s there.
Take an audio system as an example. When turned to maximum volume most systems will undergo distortion. However, since people rarely listen to music at this level it doesn’t make commercial sense to fix it.
- They don’t think of it
Catching all the possible errors is difficult to do, we’ll come on to how to capture these later but there is one key factor that can affect this and it comes down to having the right sector experience.
Do you have domain experience?
In order to accurately think up all the possible bugs you need to fully understand the sector or end users who are going to use this product.
For example, did you design it in the UK but are sending it to the Middle East where outdoor temperatures are far higher.
Is it going into a medical environment where there are extra safety issues to consider for patients or potential fire hazards when placed in proximity to other equipment (interference may also be a factor).
Application can be another example, power engineering motors are different to a small motor, some can fly off and break entirely when used in the wrong setting.
John Crouchley, Ignys Firmware Engineer, recalls an example of when an edge case happened on a Rolling Road. The device connected a big motor to a big roller. A vehicle was then placed on the roller.
When the vehicle was accelerating the motor simulated resistance, decelerating the motor simulates inertia. However, the Edge Case occurred when the system was left on with no vehicle, this meant even a breath of air could cause the system to ‘see’ acceleration and assume a vehicle was in place. This caused no end of issues including overspeed trips on the roller.
- They trust the end user
Designers will often omit bugs, seemingly not of relevance and get caught later because someone didn’t use a product as intended.
“That’s just user error”
Trusting the end user to use a product wisely can lead to complications especially where safety is concerned, at the very least company reputation could be damaged.
Another reason errors might be missed is if the issue only occurs if end users undertake two abnormalities at once; for example pressing two buttons at the same time.
This is where two edge cases combine. For example an audio speaker at max volume distorts the audio, if at the same time there is feedback from a microphone then this can result in failure of the system.
These corner cases can create some very weird effects.
For example consider a case where a system has been designed to create invoices. What happens if the following cases occur simultaneously?
- User inputs a value of 0 causing the invoice to be invalid
- 1,000 other users do the same thing at the same time
- System is overloaded and cannot process all the work it has
Does the system fail or recover gracefully and are the users kept informed of any issues that may arise?
How to tackle Edge Cases
Here are our top tips for avoiding edge case complications.
- Be aware that Edge Cases exist and factor them into testing.
- Document and test for as many of them as you can
- Add in catch alls, to shut down the device if such an error occurs preventing any damage or malfunction.
- Talk to people and not just the end users. Talk to experts in the field and colleagues who may have a different insight. Often a tunnel vision approach to a project can mask less obvious testing opportunities
- Talk to us. The Ignys team spend all their time on Electronic Design and they often spot pitfalls that are less obvious. We can carry out a design review of your product or revisit older products to check for obsolescent components.
Have a question on edge cases?
Article Authorship: This article was created as a collaboration between two of our Ignys team.
John Crouchley Ignys Firmware Engineer with 40 years experience in software engineering and more.
Hannah Ingram Marketing Manager with technical marketing experience in radio communications and healthcare NPD.