The other day I was watching a show on TV about how food is made and I started thinking about software testing (because that’s what normal people do right)?
So much of what we have in our society is made on assembly lines and food is no exception. That candy you bought? Produced in an assembly line style environment. The loaf of bread and container of milk? Same thing. We still have artisanal food, but the reality is that most of what he eat is at least partially made in a factory somewhere.
How do you find meaning in what you do in the assembly line world? How do you find meaning in just being a step in a process. Do you actually feel like you have made something when at the end of the day, you’ve rolled out 240 candy canes per hour? I think that we as humans have an innate desire to create, but does a process like this allow you to create? Can we find meaning and fulfillment in a job like this? Can we meet our need to create things when most of what we build as a society requires the input of many different people?
I think we need to think about these questions, and not just in the assembly line context. These kinds of questions matter in the software world as well. It isn’t just physical goods that are too complex for most of us to make on our own. The software systems we build require teams as well. We may call this creative work, but very few of us create entire products. We work on one small piece that fits in with other pieces. Can we fulfill our need to create in this context?
What about those of us who’s primary role on the team is to test? What do we create? How do we scratch that creative itch?
I think this is why a common complaint among testers is that they get left out of decisions about what the product will do or look like. It’s why we talk about the need to shift left. It isn’t just because those things are helpful (although they usually are). It’s because we have a need to create something and to be included in the creative process. If all we are doing is checking someone else’s work to see if they did it correctly, we have no job fulfillment.
Before I started in the testing job I have now, I worked in a couple of QA jobs in factories. I hated them. Take this batch of paint. Measure it for various properties. Compare to the specification table the customer had provided and accept or reject. Boring work with nothing to point to. At least if I worked at a factory that made candy canes, I could look at a candy cane in the store and be proud of the fact that I had twisted two colors together perfectly. If I looked at a can of paint, all I could say was that I had told everyone they did their job correctly. Not only was the job boring, it felt like it wasn’t tied to something I was creating.
Now back to software testing. If my job as a tester is to compare the work someone is doing to a specification and accept or reject it, I’m not going to feel like I am producing something of value. We want to be involved in making something. We want to be able to point to the system proudly and say “I helped make that!” The human need for creativity is why we testers want to be involved in more than just checking if the product does x or y, but – and this is important – it is also why your team needs a great tester. All members of the team want to be able to point to the software and be proud of the fact that we made something great. If we can’t do that we will be demoralized as a team and we aren’t going to produce a lot of value in the long run. Testers help with this! Value your testers. Listen to them. They share the same desires you do. The desire to make something we can all be proud of. Let’s do this together!
offbeattesting 
Nearly everything we use in our everyday lives, from the devices we use to read or create posts like this, down to your candy cane, were designed and created for the first time by someone, somewhere, even if the end result you get in your hand came off a production line and was the result of a semi-automated process which required less in the way of intelligent input. Most of that design input just doesn’t come onto the radar of 99.9% of people who will use that product, but it’s there nonetheless.
The more complex our products get, the more they need proper testing to make sure that they work properly and, as doctors say, do no harm. Working properly is a part of the design process, the end result of a product being conceived for a purpose and then designed to be fit for that purpose, and finally produced to (hopefully) meet demand. In its simplest form, testing is about confirming that fitness for purpose. But the more complex the product, the deeper that testing has to go. I see testers as having a lot in common with test pilots, who take a new type of aircraft and explore all its performance boundaries, to see not only how high and how fast it can fly, but also how low and how slow. And if it is designed to carry passengers, they have to determine that it’s safe for those passengers to fly in.
The same goes for software. I used to work for the UK water regulator, Ofwat. My job was to test a data collection tool we had developed in-house for water companies to report their annual performance to us on a range of parameters and data items, from how many kilometres of water mains they’d replaced or refurbished in the past year down to how long it took them to answer the phone. But this was important, because we based decisions on water bills on that information – how much does this company need to fulfil; their obligations in the next five years, based on what it’s done in the last five, and how efficiently they’d been able to do that. If the data collection systems didn’t work properly, then we might have based those decisions on false data. If I didn’t do my job right, then ultimately everybody’s water bill in the UK might be wrong. It may not be much to point to and say “I helped make that” (and I wish more of my colleagues in the organisation had recognised that!), but I drew satisfaction from it.
LikeLiked by 1 person