I’ve heard this question asked so many times, “Should developers write any of the automation?”.
Sadly, I believe many of the people that I’ve heard asking this particular question are either people who primarily write code and like to refer to themselves as developers or coders, or those who sometimes might write some code but often refer to themselves as testers.
When I hear the term ‘developer’ I don’t tend to differentiate between people whose main job might be writing code, to those whose job might focus more on testing. I like to consider anybody who writes a line of code, whether for a front end, API, back end, unit test, integration test, UI test, or anything else that could be written in code, to be a developer.
Over the years I’ve heard many responses and opinions on the question of who should be writing the automation, many which in my opinion, are quite questionable.
“If I do not write the automation people will question what it is that I do?”
I’ve seen people whose main focus might be testing on a team not only avoid having the people who code day in, day out on the team implement the automation, but they also do not ask for their input or opinions. They also wouldn’t dream of even asking them to review what’s been implemented.
When I’ve observed this behaviour before on a team I wondered why that individual might be acting in this way. This person identified themselves as a tester and we spoke briefly about this behaviour that I’d seen. Sadly, they were worried that the higher-ups where they worked may question what it is that they do all day if the ‘developers’ started writing all the automation? As you hopefully know, there’s also an awful lot more to skilled testing than just writing automation, it’s also a mindset. The other thing to understand is that most automation isn’t testing, it’s checking. The checks simply check the things that you tell them to.
I also wonder whether it is an education thing, do businesses actually understand or know what it is that testers do? Looking at many job adverts for ‘testers’ over various job websites, I honestly don’t believe they do and I see most job adverts playing buzzword bingo.
“But if I share my knowledge, why would they need me?”
I think unfortunately people can also often become quite precious about things which really doesn’t help the team to work as effectively as they could be. Just because somebody might have worked on a particular feature or set of features around a particular area of the software for a while, I’ve seen people become quite protective of it. Individuals and teams should be sharing knowledge, collaborating and working together. I’ve seen people who have believed that having “knowledge is power” and the fact they didn’t let anybody in to understand how things worked meant that it was a bit of job security.
“We should be working as a team, not in silos” – Lisa Crispin
“But it isn’t my job”
“Testing isn’t my job”, “I just need to build the thing”, “I don’t have time to implement tests, we can add them later”, “Our users will test the software and give us feedback”. Ummm… funnily many of the times I’ve heard people say those things, they were working more as part of a fragile than agile team.
Tests can enable individuals and teams to get quick feedback. The tests when they fail enable them to get the feedback to know when things might not be working quite as expected.
“Quality is the responsibility of the whole team” – Kristine Corbus
Teams should be using the skills and knowledge of each team member to their advantage, working together to get things done as efficiently as possible to enable them to deliver working software to the best of their ability, as quickly as possible.
Urgh, that horrid acronym, SDET (Software Development Engineer in Test). Whenever I see this term I hate it. Not only because many people in this role just strive to automate as much as possible, but because I believe many people in this role do not have the foundational understanding of software testing. To perform testing properly is a skill. I also believe that sadly, many places where they have these roles, they have them because they believe they do not need testers, they just need people to write the automation which will be enough? There are also those who do not have SDETs or testers at all – but that’s probably for another ranty blog post.
In my experience, many SDETs tend to focus just on writing automated end to end checks, and it’s not just the things which add value, they automated EVERYTHING. Not because they believe they should (often scarily because they might think they need to), but because they can! Testing again is a very highly skilled role, it’s a mindset. People who believe in ‘automating all the things’ can be very dangerous to a software delivery project which reversely can start to slow delivery of a project down due to slow feedback, lots of noise to try and decipher when things go wrong, as well as having more things to maintain as the project evolves.
We are in this together
Then there are the people who care. The people who believe that testing is a concern for the whole team. I’ve been very fortunate to work with teams where everybody has cared about why, what, and how they develop software and work to ensure it’s the best possible product that the team could deliver.
I’ve also unfortunately been on teams where this wasn’t a concern of the whole team and this spoke volumes in what we actually output and delivered to our customers.
If you identify as a tester and have no desire to write automation, don’t. If the very thought of it makes you feel pressured or scared don’t do it. You should be doing things that make you happy and that you enjoy. You should be working as a team, using your individual strengths to get things done.
If you do have a desire to learn automation but do not know where to start, start with your team. Let them know that you want to learn. Pair with the people who write code day in day out and share knowledge and ideas 💡