# Curious Customer

DevFeed: [Curious Customer](<https://devfeed.tech/articles/curious-customer-31919.md>)

Original publisher: [Read original article](<http://blog.jayfields.com/2016/06/curious-customer.html>)

Author: Jay (noreply@blogger.com)

Published: 2016-06-28T15:24:00Z

Content type: opinion

Language: en

Sources: [Jay Fields](<https://devfeed.tech/sources/jay-fields.md>)

Topics: [bug](<https://devfeed.tech/topics/bug.md>), [Software](<https://devfeed.tech/topics/software.md>), [unit tests](<https://devfeed.tech/topics/unit-tests.md>), [test](<https://devfeed.tech/topics/test.md>), [error reporting](<https://devfeed.tech/topics/error-reporting.md>), [coding](<https://devfeed.tech/topics/coding.md>)

Tags: [bugs](<https://devfeed.tech/tags/bugs.md>), [context](<https://devfeed.tech/tags/context.md>), [customers](<https://devfeed.tech/tags/customers.md>), [developer](<https://devfeed.tech/tags/developer.md>), [error-reporting](<https://devfeed.tech/tags/error-reporting.md>), [software](<https://devfeed.tech/tags/software.md>), [testing](<https://devfeed.tech/tags/testing.md>), [tests](<https://devfeed.tech/tags/tests.md>), [unit-tests](<https://devfeed.tech/tags/unit-tests.md>)

## AI overview

A developer reflects on how bugs triggered by nonsensical user behavior created noise, context switching, and distrust in application data despite appearing minor. The article proposes having another developer use new features in staging as a "Curious Customer" to uncover issues that conventional tests may miss.

## Source excerpt

I currently work on a pretty small team, 4 devs (including myself). We have no one dedicated strictly to QA. A few years ago we ran into a few unexpected issues with our software. I hesitate to call them bugs, because they only appeared when you did things that made little sense. We write internal-only software, thus we expect a minimum level of competency from our users. In addition, it's tempting justify ignoring problematic nonsensical behavior in the name of not having to write and maintain additional software. But, when I wasn't in denial, I was willing to admit that these were in fact bugs and they were costing us time. The problems caused by these bugs were small, e.g. a burst of worthless emails, a blip in data flowing to the application. The emails could be quickly deleted, and the application was eventually consistent. Thus I pretended as though these issues were of low importance, and that the pain was low for both myself and our customers. I imagine that sounds foolish; in retrospect, it was foolish. The cost of developer context switching is often very high, higher if it's done as an interrupt. Introducing noise into your error reporting devalues your error reporting. Users can't as easily differentiate between good data, a blip of bad data due to something they did, and actual bad data, thus they begin to distrust all of the data. The cost of these bugs created by nonsensical behavior is high, much higher than the cost of writing and maintaining the software that eliminated these bugs. Once we eliminated these bugs, I spent notably more time happily focused on writing software. For me, delivering features is satisfying; conversely, tracking down issues stemming from nonsensical behavior always feels like a painfully inefficient task. I became very intent on avoiding that inefficiency in the future. The team brainstormed on how to address this behavior, and honestly we came up with very little. We already write unit tests, load tests, and integration te