1. 17
  1. 5

    I thought about fuzzing today. When I was totally new to software engineering, I found the idea of fuzzing to be great. Perfect, I thought. Just randomly send inputs to see if my system breaks. As the practice of engineering become more ingrained in my identity, I started to dislike fuzzing. I did not agree with the idea of having a test that did not do the same thing, every time. “Tests, just as any code, should be deterministic”, I firmly believed. I would’ve had a hard time motivating why I held those beliefs. My gut was telling me that “I just don’t like it”. I want to design things, I wanted to decide what goes in, so that I could verify the output to be exactly what I expected it to be. As I’ve gained more experience, and many more years of software practice under my belt, I, today, realised that I have no problem with fuzzing at all, anymore. In fact, I really like the idea of fuzzing. Whatever finds the bugs.

    It wasn’t fuzzing that was interesting to me today. What was interesting to me was how I previously had formed an opinion about something, without having very much experience or facts about it, with only some kind of notion of “it’s not engineering”. It’s nice, sometimes, to find that you have grown in your trade and that you have matured.

    1. 1

      The only additional point I’d like to mention: fuzzing is just one piece of the whole “quality” puzzle and not the whole. It is necessary, not “necessary and sufficient”. :-)