Battling experience rot from a software testing perspective

At MoT we use Intercom, and as useful as it can be. It’s also frustrating how fast it changes. Just as I’m getting use to all the new releases and design, they go and change stuff again, and again.

People call this experience rot. There’s a nice article here on it from a design perspective.

The above article talks about how designers should say no. 1000 no’s for every one yes. I’d love to hear stories of this from a software tester’s perspective.

  • As a tester have you had the opportunity to say no?
  • Do others listen to you?
  • What responses that you give work best?
  • Are there a good list of software testing type questions you could ask whenever something new is prosposed to be added?
  • What other stories could you share?

As a tester, I haven’t had the authority to kill a new feature by saying “no”. But usually, when I have been in a testing role for some time, the people with the authority listen when I advise that something is a bad idea. But it doesn’t mean that they won’t go through with it. The decision to add an unnecessary feature typically takes place outside of the design team.

An example: In a previous project, someone got the bright idea of adding some extremely complex calculations to the UI, which would only add confusion to anyone who uses it. (Putting it in context, I’m pretty bright, compared to the typical user of that product, and I found it confusion) I immediately got up on my soap-box and touted the merits of not confusing our end users. It was only then that we learned that the change was required by law in one of the countries where our product was used. So the change had to go through. We did, however, manage to change the feature description so that it was easier to use (or ignore) and was not visible to anyone who wasn’t required to see it. So that is something.

2 Likes