diff --git a/README.md b/README.md
index eaefbb0..75a2660 100644
--- a/README.md
+++ b/README.md
@@ -131,6 +131,7 @@ This section contains a summary of the 100 mistakes in the book. Meanwhile, it's
   * [Not using testing utility packages](#not-using-testing-utility-packages-httptest-and-iotest-88)
   * [Writing inaccurate benchmarks](#writing-inaccurate-benchmarks-89) ([Read the full excerpt 👀](https://teivah.medium.com/how-to-write-accurate-benchmarks-in-go-4266d7dd1a95))
   * [Not exploring all the Go testing features](#not-exploring-all-the-go-testing-features-90)
+  * [Not using fuzzing]() (community mistake, credits: @jeromedoucet)
 * [Optimizations](#optimizations)
   * [Not understanding CPU caches](#not-understanding-cpu-caches-91)
   * [Writing concurrent code that leads to false sharing](#writing-concurrent-code-that-leads-to-false-sharing-92)
@@ -582,6 +583,7 @@ The `iotest` package helps write io.Reader and test that an application is toler
   To prevent the observer effect, force a benchmark to re-create the data used by a CPU-bound function.
 
 #### Not exploring all the Go testing features (#90)
+
 * Code coverage
 
   Use code coverage with the `-coverprofile` flag to quickly see which part of the code needs more attention.
@@ -598,6 +600,10 @@ The `iotest` package helps write io.Reader and test that an application is toler
 
   You can use setup and teardown functions to configure a complex environment, such as in the case of integration tests.
 
+#### Not using fuzzing (community mistake)
+
+Fuzzing is an efficient strategy to detect random, unexpected, or malformed inputs to complex functions and methods in order to discover vulnerabilities, bugs, or even potential crashes.
+
 ### Optimizations
 
 #### Not understanding CPU caches (#91)