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:
- It can be difficult to write tests when product requirements are evolving.
- Are you sure your tests cover every option and pathway?
- 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.
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 Google.com 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:
- How do you log errors that are completely unexpected?
- Will the logging code still run if your application fails?
- How do you log errors in environments outside your control, such as a browser?
- A single error could be logged tens of thousands of times after deployment. Identifying critical flaws amongst known problems can be difficult.
Fortunately, Sentry.io provides a logging-on-steroids solution which can capture the most obscure problems.
Sentry.io developer accounts are free with commercial options for larger teams generating thousands of events across multiple projects. You can sign-up quickly using a GitHub, Azure DevOps, or Sentry.io account.
On log-in, you’ll be prompted to start a new project by entering its name and choosing a technology:
You may need to set-up multiple monitors to detect issues in your application’s browser UI, mobile app, and back-end server at the same time.
The whole process takes a few minutes. Once your application is deployed, any errors encountered by users – whether they are aware of them or not – are automatically captured and tracked in real time on the Sentry.io issue stream:
Identical problems are presented as a single entry which reports how many times it was triggered and how many users were affected. Further details can be examined to determine the product version, issue severity, OS, browser, IP address, dates, call stack, etc:
Sentry.io features beyond the basics include:
- configuration settings to define release versions, code repositories, server names, URLs, etc.
- user information, messages, tagging, and custom events
- user feedback widgets to record further information
- inbound message filtering rules
- issue assigning to team members
- bookmarking, resolving, ignoring, sharing and deleting issues
- activity and issue reports
- a command-line executable to report OS or build issues
- a full API to submit, retrieve, update, delete and manage event data
- on-premise installations
- robust security with optional two-factor authentication
- chat integration with Slack, HipChat and others
- commercial and community support options.
Sentry.io is logging more than 20 billion errors per month (mostly from my code!) Developer accounts are free and include 5,000 errors per month. Employ Sentry.io as the newest member of your Q&A team today!
Craig is a freelance UK web consultant who built his first page for IE2.0 in 1995. Since that time he's been advocating standards, accessibility, and best-practice HTML5 techniques. He's created enterprise specifications, websites and online applications for companies and organisations including the UK Parliament, the European Parliament, the Department of Energy & Climate Change, Microsoft, and more. He's written more than 1,000 articles for SitePoint and you can find him @craigbuckler.