On my first software development project

For those of you who are connected to or following me on LinkedIn, you might have noticed that recently, I’ve shared and reacted on quite a few updates related to TestProject and their new and open source SDKs, especially the brand new Python SDK. Why? Because I built that Python SDK, and because I’m pretty damn proud of the end result.

I’m not going to talk about how the SDK works in this post, I’ve written a series of tutorials available on the TestProject website that do exactly that. If you want to find out more about the SDK, what it does and how to get started, please read this tutorial. This post, instead, is more of a reflection on the process and what I’ve learned from working in a software development role for the first time in my career.

How did this project get started?
I’ve known and worked with the team at TestProject for a while now, ever since my first blog post was published on their website back in October of 2018. I’ve always enjoyed working with them, and together we’ve published some 10 articles on blog.testproject.io, not including the SDK tutorials. Then, late December of last year, they got in touch to see if I was interested in collaborating with them on a to-be-developed Python SDK for their test automation platform that would supplement their existing Java and C# SDKs.

Initially, I declined. Having no real experience as a software developer, plus having a training business that was growing pretty rapidly, I thought it wasn’t the right fit at that moment. However, the opportunity of experiencing first-hand what it would be like to be a developer, and moreso, a developer for a free and open source project that would benefit the software testing community, kept flying around in my head, until I was sure that saying ‘yes’ was the only right thing to do. Lucky for me, the job was still open, so I accepted, we worked out the terms and conditions, and that’s when the project could actually get started.

What did I learn in the process?
To be honest, I don’t think there’s been a single project in my career where I’ve learned (had to learn!) as many things in such a short time as with this project. Granted, I knew a thing or two about writing code, about Python and definitely about test automation, but going from there to actually creating a software product and making it available to the outside world was definitely a step (or two, or three …) up from that. Take these things, for example:

  • Writing code that is well-structured enough to allow easy unit testing
  • Packaging and publishing code to a public repository
  • Effectively applying code linting and formatting tools
  • The intricacies of Git – branching, rebase with autosquash, fixup commits, dealing with merge conflicts, … (I’m sorry for all the frustration I caused, Marat and Vitaly!)

And that’s only the general software development skills.. I’ve learned so much about Python, the way it works and what you can do with it, too, the list would just be too long to include here.

Any other lessons learned?
Oh, lots of them! The biggest lesson, probably, would be to not underestimate again the time and effort it takes to create and release a quality product. I knew this, of course, having worked in software development teams for years, but it has never been as tangible and as first-hand an experience as with this project.

Another lesson is that yes, developers do make mistakes 🙂 At least I did… Lots of them! I’m lucky to have had the opportunity to work with a couple of great testers in this project, who came up with excellent ways in which the thing I built did not work as expected, even though I thought I covered them all.

Even though I’ve been on the other side of these discussions a lot in the past (being a tester, pointing out what I thought was a bug to a developer), seeing and experiencing this from a developer perspective has been a really valuable experience. Thank you so much for that, Ran and Gil!

Would I do it again?
Without a doubt: yes! Even though test automation is where my heart -and my experience- is, I loved the experience of actually creating something, seeing it go live and reading about others using and appreciating it.

I don’t think I’ll ever turn into a full time developer (never say never, though), if only because I like delivering training just as much, but I do think it’s a great way to spend part of my working hours. In fact, the next development project is already in the works, and I hope to be able to do this even more often in the future.

The end result
If you want to have a look at the end result of this project, it’s available on GitHub here. Why not give it a spin and let me (and the TestProject team) know what you think? Feel free to leave a review, file an issue if you think something’s not right or missing, or even better, submit a pull request.

A big, big thank you once again to the entire team at TestProject for making this an amazing experience. I won’t name all of you individually for fear of accidentally leaving someone out, but you know who you all are 🙂

Should test automation be left to developers?

I am not a developer. I have a background in Computer Science, I know a thing or two about writing code, but I am definitely not a developer. This is similar to me knowing how to prepare food, but not being a cook. People that have met me in person probably remember and will possible be bored to death by me using this analogy (sorry!).

On the other hand, I also try to repeat as often as possible that test automation is software development, and that it should be treated as such. So, you might ask, how come I am working in test automation, yet I don’t call myself a developer? And more importantly, shouldn’t test automation be left to developers, if it really IS software development? Recent blog posts I’ve read and presentations I’ve heard have made me think a lot about this.

So, to start with the second and most important question: should test automation be left to developers? My answer would be yes.

And no.

Test automation should be left to developers, because
writing automated tests involves writing code. Personally, I don’t believe in codeless solutions that advertise that ‘anybody’ can create automated tests. So, since code writing is involved, and since nobody knows writing code better than a developer, I think that writing automated tests can best be done by a developer.

I’m going to use myself as an example here. Since writing code isn’t in my DNA, I find it takes me three times as long – at the minimum – to write automated tests compared to your average developer. And with high-pressure projects, short release cycles and the trend of having less and less testers for every developer in development teams, I just couldn’t keep up.

To make matters worse, new automation tools are being released what seems like every day. Especially within the Java and JavaScript worlds, although it might be just as good (or bad?) in other ecosystems, just less visible to me personally. I don’t know. For a while, as a non-developer, I’ve tried to keep up with all of these tools, but I just couldn’t manage. So, instead of frantically trying to keep up, I’ve made a career shift. This came naturally after I realized that

Test automation should not be left to developers, because
nobody knows testing better than testers. As I said, I (and possibly many people involved in test automation along with me) am not skilled enough to compete with the best on how to create automated tests. However, I think I (and a lot of others) can teach a lot of people a thing or two about the equally, if not more important questions of why you should (not) do test automation, and what tests should and should not be automated.

A lot of developers I have met don’t have a testing mindset (yet!) and tend to think solely along the happy path. ‘Let’s see if this works…’, rather than ‘let’s see what happens if I do this…’, so to say. When writing automated tests, just as with creating specs for the software that needs to be built, it requires a tester’s mindset to think beyond the obvious happy flow. This is why I think it isn’t wise to see test automation as a task purely for developers.

It also helps if people other than developers feel some sort of responsibility for creating automated tests. Given that most developers are busy people, they need to choose between writing tests and writing production code on a regular basis. Almost always, that decision will be made in favor of production code. This does make sense from a deadline perspective, but not always as much when you look at it from a quality and process point of view. Having people in other roles (testing, for example) stressing the need for a mature and stable automated testing suite will definitely improve the likelyhood of such a suite actually being created and maintained. Which might just benefit the people continuously fretting about those deadlines in the long end..

So, to answer the first question I posed at the beginning of this post: Why am I still working in test automation despite not being a developer? Because nowadays I mainly focus on helping people answer the why and the what of test automation. I do some stuff related to the how question as well, especially for smaller clients that are at the beginning of their test automation journey or that don’t have a lot of experienced developers in house, but not as much as before. I love to tinker with tools every now and then, if only just to keep up and remain relevant and hireable. I’m not as much involved in the day to day work of writing automated tests anymore, though. Which is fine with me, because it plays to my strengths. And I think that’ll benefit everybody, in the long end.

I think the test automation community could use a lot more highly skilled people that are (not) developers.