“You’re a tester! You can’t tell developers what to do!”

Michael Bolton posted this tweet to which I responded. When Michael asked for more information I started to respond in a tweet, which turned into a thread, which grew to the point where it became ridiculous, so I turned it into a blog post.

It was a rushed migration of insurance systems following a merger. I was test manager. The requirements were incomplete. That’s being polite. In a migration there are endless edge cases where conversion algorithms struggle to handle old, or odd data. The requirements failed to state what should happen if policies couldn’t be assigned to an appropriate pigeon hole in the new system. They didn’t say we should not lose policyholders’ data, and that became highly controversial.

The lack of detail in the requirements inevitably meant, given the complexities of a big migration, which are seldom appreciated by outsiders, that data was lost on each pass. Only a small percentage was dropped, but in the live migration these would be real policies protecting real people. My team’s testing picked this problem up. It was basic, pretty much the first thing we’d look for. The situation didn’t improve significantly in successive test cycles and it was clear that there were would be dropped records in the live runs.

I approached the development team lead and suggested that migration programs should report on the unassigned records and output them to a holding file awaiting manual intervention. Letting them fall through a gap and disappear was amateurish. The testers could flag up the problem, but the fix should come from the users and developers. It wouldn’t be the testers’ job to detect and investigate these problems when it came to the live migration. My test team would not be involved. Our remit extended only to the test runs and the mess would have to be investigated by end users, who lacked our technical skills and experience. The contract wasn’t going to pay for us to do any work when live running started and we would be immediately assigned to other work.

The lead developer argued that her team couldn’t write code that hadn’t been specifically requested by users. The users’ priority was a rapid migration. Quality and accuracy were unimportant. The users were telling us, informally, that if a small proportion of policies was lost then it was no big deal.

The client didn’t offer a coherent argument to justify their stance and they refused to put in writing anything that would look incriminating in a post mortem, as if they thought that would protect them from a savaging from the auditors. They were too busy trying to force the migration through to get into a serious debate about quality, ethics, or how to handle the profusion of edge cases. The nearest they came to a defence of their position was a vague assertion that policyholders would eventually notice and complain that they’d heard nothing from the insurer about renewing their policies. There were some serious problems with that stance.

Failing to convert responsibly would have made us, as the supplier, complicit in the client’s negligence. There might not have been an explicit requirement not to lose data, but it was basic professionalism on the part of the developers to ensure they didn’t do so. It was absurd to assume that all the policyholders affected would notice before their policies expired. People would find they were uninsured only when they suffered an accident. The press would have loved the story.

We were dealing with motor insurance, which drivers legally must have. It would eventually have come to the attention of the police that the client was accidentally cancelling policies. I knew, from my audit experience, that the police took a very dim view of irresponsible system practices by motor insurers.

The development team leader was honest, but deep reflection about her role was not her style. She had a simplistic understanding of her job and the nature of the relationship with the client. She genuinely believed the developers couldn’t cut a line of code that had not been requested, even though that argument didn’t stand up to any serious scrutiny. Delivering a program for any serious business application involves all sorts of small, but vital coding decisions that are of no interest to those who write the requirements but which affect whether or not the program meets the requirements. The team leader, however, dug her heels in and thought I was exceeding my authority by pushing the point.

Frustratingly, her management backed her up for reasons I could understand, though disagreed with. A quick, botched migration suited everyone in the short term. It was my last test project for a few years. I received an approach asking if I was interested in an information security management role. Both the role and the timing were attractive. A break from testing felt like a good idea.

Edit: Reading this again I feel I should offer some defence for the attitude of the development team lead. The behaviour, and the culture, of the client meant that she was under massive pressure. There was not enough time to develop the migration routines, or to fix them in between test runs. Users were bypassing both her and me, the test manager, when they reported defects. They would go straight to the relevant developers and we were both struggling to keep track and enforce any discipline. The users also went behind her back to lean on developers to make last minute, untested changes to code that was already in the release pipeline into production. She made sure her team knew the correct response was, “**** off – it’s more than my job’s worth.”

Throughout the migration the users were acting appallingly, trying to pin the blame on her team for problems they had created. She was in a very difficult position, and that largely explains an attitude that would have seemed absurd and irrational at a calmer time. Her resistance to my requests was infuriating, but I had a lot of sympathy for her, and none whatsoever for the users who were making her life a misery.

There’s an important wider point here. When we’re dealing with “difficult” people it’s helpful to remember that they might be normal people dealing with very difficult problems. Don’t let it get personal. Think about the underlying causes, not the obvious victim.

2 thoughts on ““You’re a tester! You can’t tell developers what to do!”

  1. “So tell me, developer colleague, how you think a two-year custodial sentence will improve your lifestyle?” indeed, a half-decent prosecuting counsel could make that into insurance fraud if customers are paying for insurance policies that disappear into thin air. Two years might be getting off lightly.

    • The client staff insisted that they’d instantly and retrospectively reinstate any policies that had been dropped in the migration, just as soon as an aggrieved policyholder complained. That didn’t take account of the stress the policyholder would suffer.
      I don’t think a fraud charge would have stood up in those circumstances, but retrospectively putting drivers on cover who were without a valid insurance policy at the time of an accident or when they were challenged by the police is another matter altogether. In a similar case I knew the police had reacted very angrily, to the extreme discomfort of the insurance managers concerned.
      Since you made your comment I’ve added a postscript to offer some defence of the dev team lead. She was a victim, rather than one of the true culprits.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.