Getting Started with Error Tracking

This article was created in partnership with Sentry. Thank you for supporting the partners who make SitePoint possible.

Writing code can be fun. Testing it is another matter. Of course, SitePoint readers always produce bug-free applications but errors can still slip into the best production code. How can you detect those issues?…


Writing software to test software is one option. Unit and integration testing can be adopted to verify functions and interfaces accordingly. Unfortunately:

  1. It can be difficult to write tests when product requirements are evolving.
  2. Are you sure your tests cover every option and pathway?
  3. Who’s testing your tests?

Tests help, but the industry still releases software with bugs because it’s impossible to cover every eventually. Does a bug occur in a certain browser, on a particular OS, at a specific time of day?

In addition, browser testing is notoriously complicated owing to:

  • Multiple devices and applications. There’s a long tail of old, new, and obscure browsers across desktop PCs, tablets, smartphones, TVs, games consoles, smart watches, IoT devices, and more. It’s impossible to test everything.
  • User control. Any user can choose whether to download, block or modify any part of your application. For example, Firefox will block Google Analytics when tracking is disabled; recording an Analytics event could cause the whole application to fail.
  • Network failures. Even if the user permits every file you throw at them, there’s no guarantee they’ll receive all images, CSS, JavaScript and other assets. Travelling or using flaky hotel wi-fi exacerbates the problem.

User Feedback

Have you ever watched someone using your software? They always do something you never expected. I wince every time I see someone enter a URL into the search box.

Humans are adept at finding their own methods to complete tasks based on previous experience. Those processes may or may not be efficient, but they’ll rarely match your expectations because your experiences are different. A bug may occur because a sequence of tasks is tackled in a manner that seems illogical to you.

Additionally, the majority of users will never report a bug. They won’t know whether the fault occurred in your app, the browser, or the OS. Many may blame themselves, will not know who to contact, or simply switch to a competing product.

Users who do report issues will rarely be able to describe the problem unless they have software engineering expertise. It’s frustrating to be faced with dozens of “ProductX doesn’t work” issue tickets.

Ultimately, should we rely on customers to report problems?


Logging errors is a possibility but:

The post Getting Started with Error Tracking appeared first on SitePoint.

Source: Site Point

Republished by Blog Post Promoter