But the same also holds for people who are "independent testers" and unaware of the same issues.
What I found is that software developers are bad at testing edge cases while they are in the creation mode (when they focus on happy path), but that good engineers switch to breaking mode once they try to cover things with sufficient tests. TDD also encourages breaking things first, but really, this is a mindset change that is usually skipped.
Fuzzing isn’t going to find either of the issues I mentioned. It’s useful for finding the kind of issues most developers I have worked with are well aware of, though may not specifically test for.
why do you think that fuzzing won’t try inputting the alternate question mark in your input?
For what it’s worth, if fuzzing is unlikely to, then I think so is manual testing unless you get really lucky or an expert is trying to break your system because they know of frequent issues with Unicode handling.
But the same also holds for people who are "independent testers" and unaware of the same issues.
What I found is that software developers are bad at testing edge cases while they are in the creation mode (when they focus on happy path), but that good engineers switch to breaking mode once they try to cover things with sufficient tests. TDD also encourages breaking things first, but really, this is a mindset change that is usually skipped.