Hi there!
Asking for a friend… Have you ever been in a situation where developers have wanted to control the narrative in terms of how you are automating tests? What language to use, how to organize it, requesting you follow the same coding conventions and asking you to use typescript? While I can certainly appreciate the desire to be involved, I am anxious we’ll end up with a test suite that is difficult for the testing team to maintain without a whole lot of help. Suggestions on how to approach this?
I was working on an automation team and team where the SW platform architect was trying to make us change our primary scripting language and infrastructure, to the point where he tried strong-arming our manager into making those decisions.
But then I’ve also been told to do it all myself, even when there was no time, or budget, or buy-in from any of the teams.
In reality, it needs to be a collaborative effort, we all can bring different things to the table to bring an automation narrative to the fore.
For me, it’s important to decide what your automation requirements are (including what you want to automate and why) in as agnostic a way as you can, before making decisions about tooling and language. It shouldn’t be a solely test team or dev team (if those are separate teams) but one that we all own, sure there might be some who work on it more than others, but its purpose is to benefit everyone, so we should all be invested in it.
It can be the case that there needs to be a point of contact of decision maker, or champion or whatever.
This is a very interesting question which highlights one of the main differences between developers and (automation) testers in my opinion. Based on the title of the thread my simple answer would be: the team. It’s a joint effort and if we want the whole team to care about quality then we should also welcome their input on the subject of automation.
Having said that, there are some very compelling reasons why you want to organise things a certain way. It all comes down to what the purpose of your code is. A developer wants to build things. Their code is one of the most important things of output and as such they take great care in writing good code. They use all kinds of best practices (DRY, type safety, other coding conventions, etc) to come up with great code. These conventions greatly help in keeping the code maintainable and manageable from a technical point of view.
And that’s where we might encounter a discrepancy between developers and testers. If the focus of your code (and tests) is geared towards the technical side of things than it makes sense to adhere to the coding conventions because they are adding value. However, this is not always the case. As we move up the testing pyramid, and our tests become more functional, we see this added value becoming less relevant.
Now, where and when this point exactly lies is hard to predict, but let me put it this way: if you’re automating some E2E UI tests and you run into issues that you can mitigate by using type safety than you’re probably on the wrong track.
It basically comes down to the purpose of your code. Developers are used to building something once, and then it should run forever as long as you don’t change anything. If I automate a test I’m sure of one thing: at some point in the future I need to come back to this code because of a failed test and I need to know why it failed. This makes that other things might be more important than DRY principles or something. If it makes my tests easier to debug and more readable than I’m sure as heck gonna repeat myself.
Bottom line, realise that there are differences in mindset between developers and testers and as such also in the purpose of the code that is written. Acknowledging this given is probably the first step. After that you can have a chat about why you want to implement something. If there’s a compelling reason why you want to comply with certain standards then go for it. But just using conventions for conventions sake is probably not going to benefit you.
This part especially really speaks to me. Thank you both for your thoughtful responses! This is really helping change my mindset around this a bit, which I needed.
If developers ask to make tests, then they are also willing to help. This is a plus. They trust your skills and experiences in testing.
My favourite way for learning is pair programming.
In one team I only observed the developer the first session. This way I got a feeling about the tools and the programming language. Of course I asked some questions about steps being taken.
Then I started programming, while the developer gave some hints. “What are your thoughts right now?” Then I spoke aloud what I was thinking and what I was planning to do. If I was stuck, then he gave me specific instructions.
The lesson learned for me was that I had to determine the time for the feedback. A code review is feedback, but in the beginning it takes too long. Feedback is needed for confidence.