[length warning 600+ words]
QA's job is to find bugs in your code and if the engineering team has done it's job right the only ones that they will find are what is known as an "edge case".
It's the kind of situation where if the sun and the moon are in exactly the right place relative to where you are on earth you get a total eclipse of the sun (or the moon). Every day the sun rises & sets, every day the moon rises and sets, almost every day you don't get an eclipse and you never get one that everyone can see.
Edge cases are the odd situations. Here is a - long winded - example: you receive a file every day of a bunch of calendar items for the upcoming 90 days that you import into your software. You don't control for contents of the file. You receive it each day. There may be multiple calendar items associated with each day. Some days don't have any information because there aren't any information for that date yet. Each calendar event has a unique ID.
If the calendar event changes when you get the updated file you'll know because there will be changed information associated with the same ID. If an event is deleted, it won't be in the file. You'll know that it is deleted because it was there before and as there are other events on the same date you'll know its missing.
This is a simplistic way of doing things, but the kind of situation that I see in the real world. Everything with this system works except that there is a flaw, an edge case that wasn't spotted by the original designers of the architecture.
The edge case: If the last event in the file is the only event on the last chronological day in the file and subsequently gets deleted the updated file won't contain the event or any events for that date and you won't know from the contents of the file that the event was deleted. Yes I know there are other ways to work out it is missing, but let us assume that the architecture is as described.
Now some people think, "that's just an edge case, happens once in a blue moon, and the side effect is that you have an extra event in your system which you can manually delete, it's not that big a deal" and they don't fix it. Maybe it happens once every couple of years.
I have a different philosophy. First I have to understand why the problem exists - in the above example I detailed what the problem is but in most cases the underlying issue won't be known. You'll have an extra event that shouldn't be there and you'll have to figure out why, what caused the edge case.
Once I know why, I can decide how easy it is to fix and fix it or accept it - after documenting it for the next engineer who goes looking when it happens again.
The thing is, every time I have gone looking at the code that created the situation for the edge case I almost always find a bigger problem. Often a latent bug. I look at the code and think "how have we been getting away with this". It's the kind of code that shouldn't work but does because of some other quirk. It may even be code that an earlier version of myself wrote.
In summary, I always look into edge cases because for me, it is often a sign that something else is not quite right and the edge case is highlighting it. Better to fix it before the bug becomes more than just an edge case.