The Testing, not the Testers

Occasionally I see posts and discussions, where testers are indignated that this and this company has no testers. How could they! Or similarly when a product is released publicly with significant issues: See – it’s because they have no testers! Or that the testers are not taken seriously. OMG!

Previously, I might have been indignant too about those observations. But as my experience grows, the causation fails. I had failed to see the context and see outside my own box of thinking. I can learn to be better by remembering my favorite Weinberg quotes:

1. Things are the way they are because they got that way

There are plenty of established organisations that don’t have the need for professional testers. Recently I’m working with a large local union. They have no IT team either – besides a small team called IT vendor management. In that team they do have a few release- and test managers, but the testing has to be done either by union office staff or by their IT vendors (and that’s where I come in, I’m more of a test coach though). In this context the testing is done either by those with the business skills or those with the technical skills.

Similarly, in 2018 I was assigned to a 30+ people IT development team that had been existing since the 1990’es. They had never had any testers. What they did have was continuity, about half of the team had been in the team for 10+ years. They knew every nook and cranny of the IT solution landscape: the main system, order entry and processing systems. And they cared deeply about the quality of the whole thing – the IT system consultants did their own testing, and had been doing so for years. With testing, not with testers.

Locally we also have five banks that share the same IT company. The IT organization is an independent company that provides the same domain technology to all the banks. Just with a bit of flavouring and branding, which is actually very common with industry specific solutions. The banks themselves have no testers, neither have the IT organization. But with every new release representatives from the banks are brought in to test and review the solution. The people participating are not testers, but they are doing testing. They go back to do their full-time job as process admins, customer advisors at the end of the testing.

2. No matter how it looks at first, it’s always a people problem

And obviously there’s no causation between lack of testers and buggy releases. Plenty examples exists of IT deliveries with loads of testing – and yet having a buggy launch. Locally I can think of all the large public IT projects that have failed significantly. Both the national land registry solution and a regional hospital solution have taken years to recover from the failures.

While they did have a lot of formal testing that discovered the issues. Management decided that the deadline was more important that quality. Thus they reduced all the formal testing activities to window dressing and cargo cult adherence to what the testing should be about. I have stories to tell over beer about how senior management have added testing activities, for them to look good in a political gameplay.

3. You’ll never accomplish anything if you care who gets the credit

What is left when you actually consider the story and the people aspects – is an indignation on behalf of the tester as unique playmaker in IT deliveries. Really, It’s not. Sorry. I understand if you feel attacked on your brand. I have had that feeling too – other people have been having that feeling for years. You will only be taken seriously if the work you do taps valuably into what matters to the decision makers. If you whine about not being taken seriously, you need to up your game.

Sometimes it happens that the tester is the hero and unique playmaker in making quality happen. While it’s nice to be the hero, a hero culture is not healthy. We know now, the hero becomes the bottleneck. Even a hero needs a team and a whole team approach to quality matters more than the individual role. I am strongly aware that even my current work is under pressure: Someone else will eventually do it.

Let’s continue talking about making the testing smarter and not single out that this is for testers only.

11 thoughts on “The Testing, not the Testers

  1. Yes, I see this. But perhaps a company that has concentrated on reducing time to deployment above all else has, at some point, decided that the testers are the problem, that it is the testers who are finding reasons not to release when the management considers the product is “good enough”. Yes, it’s still the testing, not the testers that’s important; but without testers, there’s no-one to advocate for proper testing. That’s not “complete” testing, or “comprehensive” testing, but the most amount of appropriate testing in the time available. Perhaps the test technique that testers need to develop the most is the art of negotiation with their own business managers.

    Liked by 1 person

  2. And another thing. A company that is liable to suddenly declare its testers to be superfluous because they are seen as an impediment, part of the problem of not releasing to schedule, is unlikely to provide the sort of work environment that contributes to feelings of security in the rest of the professional team (especially developers). (Certainly when I worked for such a company, the dev team themselves melted away pretty fast when the hatchet men went around the rest of the IT section.) And such companies are therefore unlikely to ever build up the extent of deep product knowledge that your model of testerless testing relies on.

    Liked by 1 person

Leave a Reply

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

You are commenting using your 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.