Early in my career as a tester, a developer gave me a ten-minute introduction to Ethereal (as it was called then). I don’t remember why, we were probably trying to debug something. But ever since, Wireshark (as it is called now) has been my most trusted companion. Hardly a day, and never a week, goes by without me poring over tcp dumps.

Curiosity is an important characteristic in a skilled tester. And there is really nothing that can satisfy curiosity like raw network logs, at least not when you’re working with any kind of server-client or other networked architecture. The error in application A – does it happen because B sent the wrong data to A? Or maybe A sent a wrong request to B in the first place? Or perhaps B is sending the correct data but A is interpreting it incorrectly? Wireshark will tell you!

Application logs can only take you so far. Even if the application offers ridiculously verbose debug log levels (as some do, which I love), you still have to trust the application’s presentation of the data. Sometimes that’s enough, but even then it is often faster to whip out Wireshark than to configure the required log levels, restarting the applications and then set everything back to normal again afterwards to be free of the disk-space-eating log file monster.

And network tracing is not just good for debugging! It is an excellent way to get to know and understand the APIs and communication protocols used by the applications you’re testing, and spot opportunities for new tests. Wireshark and similar tools can seem daunting at first, but they’re really not that hard to get started with, provided you have a basic grasp of networking concepts. Check out http://www.wireshark.org/docs/ to get started!