What is Trustiness | A Tester Perspective

Seth Godin put up a good post about the difference between trust and trustiness. He mostly pointed at corporations that showed their trustiness through PR campaigns and made a pretty strong comment about it in the last few paragraphs:

The difference should be obvious. Trust experienced is remarkable, trustiness once discovered leaves a bad taste for even your most valued customers.

The perverse irony is this: the more you work on your trustiness, the harder you fall once people discover that they were tricked.

Combine this with James Bach’s guide to faking a test project (that’s a pdf link) and you can probably guess where I’m going with this.

There’s been a lot of talk recently about how test is dead. Whether it’s being sarcastic about when test can be dead or the definition of testing. Testing is still very much alive, but is still evolving.

Tying this into the Trustiness idea again. As a tester, are you trusted or do you ooze trustiness? Are you submitting bug reports to look busy or as you find them? Taking a note from faking a test project: how detailed are your bug reports? How much do the developers you work with trust your bug reports when they see them?

Companies are always looking for ways to save money. Regardless of how people centric they are, they need to spend the least possible and make the most possible. Too many times testers get the short end of the stick in regards to timelines, resources, and budget. How do you stay relevant in your organization and prove that the money spent on you is worthwhile?

With stories about test being dead and end-users getting used to seeing bugs in their free/beta/trial software out there end up with quotes like this from Testjutsu:

At Google, the majority of the tools they produce are free for the end user. Their model is based on building things that people will use (for free) and building advertising into it. If it doesn’t work perfectly, oh well. It’s not like you’re paying money for it.

However, an increasing amount of times there are large bugs in paid for apps, OSes and Hardware. Which lead to posts titled “Software Bugs are a Regular Part of Smartphone Life for Windows Phone and Android users“.

I’m not trying to say that you should release something only when all bugs are fixed because that would take too long to release. But a bug that’s considered minor or not reported internally can come across as an issue that affects the trust level of the brand. This, in turn, can could come back on you because “Why didn’t you find that during testing”.

So are you trusted or full of trustiness?

 Image Credit: elycefeliz on Flickr