The time I did bad work
Huib Schoots gave a great talk at TestBash 3 (video of Huib's presentation) in which he discussed how he, as a professional tester, refused to do "bad work". (He also wrote an exceptional follow-up blog post on this specific subject, "Refusing to do bad work...")
The term "bad work", as defined within the context-driven school of testing, is summarised by James Bach as:
Bad work is any work that YOU think should be done
differently in order to reasonably fulfill YOUR obligations to your client, project, company, or society in terms of the Context-Driven Testing principles as YOU interpret them.
You may experience pressure to perform bad work or to allow your work to suffer due to the impact of other people’s bad work.
These words really rang true with me, as I realised that I'd once knowingly performed this kind of "bad work". Worse, at the time, I mistakenly thought that it was good work. Fellow testers, hear my confession...
I was working in a scrum team which was responsible for delivering incremental updates to our website. We were frequently asked to do work for other business teams, particularly regarding code changes required for advertisers, which led to this one particularly bizarre situation.
During our sprint planning meeting, the team was presented with a previously-unseen work request: We'd been asked to implement links on all of our product pages, to a particularly disreputable site. This was at a time when SMS subscription services were everywhere, with many providers exploiting loopholes and customer naivety. Typically, you'd send them a single text message (to get a single amusing ringtone or sound effect) and you'd be unknowingly opted-in to receive expensive follow-up messages on a weekly basis. One such provider was now looking to advertise all over our website.
But it was even worse than that. The salesperson responsible for gaining the contract, in what he presumably thought was a moment of inspiration, had mocked-up some screenshots for their client and embedded them in the contract, showing that their links would sit within our existing navigation, styled to look like they were part of our content (and therefore would be likely to have a higher click-through rate). The client, of course, had gleefully agreed to the contract, as long as it was implemented exactly as mocked-up.
That was FAILURE #1. Why did the salesperson do this? Did they fancy themselves as a designer? Or did they know it to be a (clearly!) effective sales technique? At the very least, they gave no thought or consideration for our users, and by not communicating with the webteam in advance, it showed a lack of respect for us as well.
As a team, we were absolutely dumbfounded. Even our Product Owner said that his hands were tied. What could we do? Ordinarily, if the story had originated in-house, we would have reject the story for sure. But this had been handed-down to us from higher-up in the organisation, and there were signed contracts in place; even if we weren't in a legal bind, the company wasn't making a habit of turning-down income.
So, what did we do? Trapped in the headlights and with our hands seemingly tied, we practised what James Bach terms "pathetic compliance". We felt that there was nothing we could do, so we implemented the changes as requested, even though we knew that our users would hate them.
That was FAILURE #2. Even an unsuccessful challenge could have gained us credibility within the organisation, and reduced the chance of similar situations occurring in the future. By silently accepting the decision, we were arguably as at-fault as the salesperson who first thought-up the change.
For me, as a tester with a particular interest in a high-quality user experience, it was an agonising situation. We'd been asked to implement a UI change which was confusing and deliberately (some may say maliciously) misleading.
This is the point at which I made my biggest personal failure: I decided that I could make peace with the situation if I tested the functionality to the very best of my ability. I still have a copy of my test plan; it's an impressive-looking beast, which identified some serious bugs with the integration, including several issues with the client's website where inbound links weren't working correctly.
That was FAILURE #3. It's where I did bad work. I made the mistake of confusing "ensure it's functional" with "ensure it's fit-for-purpose". I delivered a high-quality feature that none of our users wanted, and - to an extent - I was happy with my work.
Of course, there was fallout. We might have completed the contract and pleased one of our advertisers, but the lost goodwill from users (who vocally complained on our forums that it was a "scam") must surely have outweighed the financial benefits. Users were, of course, quick to point the blame at the website development team, meaning that our external reputation suffered even though we delivered the requested functionality on-time.
It wasn't an isolated incident. Several sprints later, after more similar battles with advertisers, I left. It's my redemption of sorts - Huib says "If all else fails, leave!" which (although I didn't have the advice at the time) is what I did. I'm stronger as a result of it, and when I look critically at the work I've done in the years since, I know I've not fallen into a trap like this again.
Of course, I'm not perfect. I'm still learning to question everything. I'm still guilty of sometimes losing sight of my mission (typically when trying to make sure "all of the tests have been run" during a pre-release regression cycle, when the more pressing questions are "what tests have been run, and why, and what can that tell us about the quality of the product?")
Thankfully I have access to a vast network of peers and colleagues, both within my company and the wider testing community, with whom I share a growing amount of trust and respect. I'm hugely grateful that I can have open and frank discussions with experts worldwide, giving me the confidence to push back when I encounter requests for bad work, meaning that situations like this can now mostly be consigned to the "amusing anecdotes" bin.