This is a generic question, so I will give a generic answer: try to think of everything that can go wrong.

The first method for finding things that can go wrong is to go through a checklist of common implementation mistakes: off-by-one errors; not handling null/empty correctly; getting stuck in an infinite loop; etc. These are low-level edge cases -- problems you will find in code because pseudocode and high level descriptions often gloss over the details. For example, a binary search description will talk about "cutting the search space in half", but an actual implementation might have an edge case when the element you're looking for is right in the middle of the search space, or if the number of elements is even and there is technically no "middle" element.

The second method for finding edge cases is to have an adversarial attitude toward the algorithm. This is a higher level approach where you act as if your purpose in life is to find flaws in the algorithm. Sometimes this means thinking of really simple, "illustrative" examples -- for example, if you're looking at a sorting algorithm, you might consider an input that is sorted, an input that is sorted in reverse order, and an input where all elements have the same value. Other times you can try listing all of the implicit assumptions and then seeing if any of them might be wrong. For example, a graph algorithm might implicitly assume that there are no cycles in a graph, but perhaps that's not the case.