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 🙂

On quitting Twitter and looking forward

Many of you probably have not noticed, but last weekend I deactivated my Twitter account. Here’s why.

I’ve been active on Twitter for around four years. In that time, it has proven to be a valuable tool for keeping up with industry trends, staying in touch with people I know from conferences or other events, as well as a few non-testing and IT related sources of information (mainly related to running or music).

My 'I'm leaving Twitter' announcement

Over time, though, the value I got from Twitter was slowly getting undone by two things in particular:

  1. The urge to check my feed and notifications far too often.
  2. The amount of negativity and bickering going on.

I started to notice that because of these two reasons, I became ever more restless, distracted and downright anxious, and while Twitter may not have been the only reason for that, it was definitely a large contributor.

I couldn’t write, code or create courseware for more than 10 minutes without checking my feed. My brain was often too fried in the evening to undertake anything apart from mindless TV watching, playing the odd mobile game or even more social media consumption. Not a state I want to be in, and definitely not an example I want to set for my children.

So, at first, I decided to take a Twitter break. I removed the app from my phone, I blocked access to the site on my laptop and activated Screen Time on my phone to make accessing the mobile Twitter site more of a hassle. And it worked. Up to a point.

My mind became more clear, I became less anxious. But it still felt like it wasn’t enough. There was still the anxiety, and I still kept taking the extra steps needed to check my Twitter feed on my phone. And that’s when I thought long and hard about what value I was getting from being on Twitter in the first place. After a while, I came to the realization that it simply was too little to warrant the restlessness, and that the only reasonable thing to do was to pull the plug on my account.

So that’s what I did. And it feels great.

I’m sure I’ll still stay in touch with most people in the field. Business-wise, LinkedIn was and is a much more important source of leads and gigs anyway. There are myriad other ways to keep in touch with new developments in test automation (blogs, podcasts, …). And yes, I may hear about some things a little later than I would have through Twitter. And I even may not hear about some of them altogether. But still, leaving Twitter so far turns out to be a major net positive.

I’ve got some big projects coming up in the next year or so, and I’m sure I’ll be able to do more and better work without the constant distraction and anxiety that Twitter gave me in recent times.

So, what’s up in the future? Lots! First of all, more training: this month is my first ever month when I hit my revenue target purely through in company training, and I hope there are many more to come. I’ve got a couple of conference gigs coming up as well, most notably at this point my keynote and workshop at the Agile & Automation Days in Gdańsk, Poland, as well as a couple of local speaking and workshop gigs. And I’m negotiating another big project as well, one that I hope to share more information about in a couple of months time.

Oh, and since I’m not getting any younger, I’ve set myself a mildly ambitious running-related goal as well, and I’m sure that the added headspace will contribute to me keeping focused and determined to achieve it. I’ll gladly take not being able to brag about it on Twitter in case I make it.

One immediate benefit of me not being on Twitter anymore is the fact that I seem to be able to read more. Just yesterday, I finished ‘Digital Minimalism‘ by Cal Newport, and while this book hasn’t been the reason for my account deactivation, it surely was the right read at the right moment!

On choosing both/and, not either/or

Choices. We all make them tens of times each day. Peanut butter or cheese (cheese for me, most of the time). Jeans or slacks (jeans, definitely). Coffee or tea (decent coffee with a glass of water on the side please). And when you’re working on or learning about automation, there’s a multitude of choices you also can (and sometimes have to) make. A lot of these choices, as I see people discussing and making them, are flawed in my opinion, though. Some of them are even false dichotomies. Let’s take a look at the choices people think they need to make, and how there are other options available. Options that might lead to better results, and to being better at your job.

Do I need to learn Java or .NET? Selenium or UFT?
Creating automation often involves writing code. So, the ability to write code is definitely a valuable one. However, getting hung up on a specific programming language might limit your options as you’re trying to get ahead.

I still see many people asking what programming language they need to learn when they’re starting out or advancing in their career. If you’d ask me, the answer is ‘it doesn’t really matter’. With the abundance in tools, languages, libraries and frameworks that are available to software development teams nowadays, chances are high that your next gig will require using a different language than your current one.

As an example, I recently started a new project. So far, in most of my projects I’ve written automation in either Java or .NET. Not in this one, though. In the couple of weeks I’ve been here, I’ve created automation using PHP, Go and JavaScript. And you know what? It wasn’t that hard. Why? Because I’ve made a habit of learning how to program and of studying principles of object oriented programming instead of learning the ins and outs of a specific programming language. Those specifics can be found everywhere on Google and StackOverflow.

The same goes for automation tools. I started writing UI-level automation using TestPartner. Then QuickTest Pro (now UFT). I’ve used Selenium in a few projects. I’ve dabbled with Cypress. Now, I’m using Codecept. It doesn’t matter. The principles behind these tools are much the same: you identify objects on a screen, then you interact with them. You need to take care of waiting strategies. If you become proficient in these strategies, which tool you’re using doesn’t matter that much anymore. I’ve stopped chasing the ‘tool du jour’, because there will always be a new one to learn. The principles have been the same for decades, though. What do you think would be a better strategy to improve yourself?

Identify and learn to apply common principles and patterns, don’t get hung up on a single tool or language. Choose both/and, not either/or.

Do I stay a manual tester or become an automation engineer?
Another one of the choices I see people struggling with often is the one between staying a ‘manual tester’ (a term that I prefer not to use for all the reasons Michael Bolton gives in this blog post of his and becoming an automation engineer. If you’d ask me, this is a perfect example of a flawed choice in the testing field. It’s not a matter of either/or. It’s a matter of both/and.

Automation supports software testing, it does not replace it. If you want to become more proficient in automation, you need to become more proficient in testing, too. I’ve only fairly recently realized this myself, by the way. For years, all I did was automation, automation, automation, without thinking whether my efforts actually supported the testing that was being done. I’ve learned since that if you don’t know what testing looks like (hint: it’s much more than clicking buttons and following scripts), then you’ll have a pretty hard time effectively supporting those activities with automation.

Don’t abandon one type of role for the other one, especially when there’s so much overlap between them. Choose both/and, not either/or.

Do I learn to write tests against the user interface, or can I better focus on APIs?
So, I’ve been writing a lot about the benefits of writing tests at the API level, not only on this blog, but also in numerous talks and training courses. When I do so, I am often quite critical about the way too many people apply user interface-driven automation. And there IS a lot of room for improvement there, definitely. That does not mean that I’m saying you should abandon this type of automation at all, just that you should be very careful when deciding where to apply it.

Like in the previous examples, it is not a matter of either/or. For example, consider something as simple and ubiquitous as a login screen (or any other type of form in an application). When deciding on the approach for writing tests for it, it’s not a simple choice between tests at the UI level or tests at the API level; rather it depends on what you’re testing. writing a test that checks whether an end user sees the login form and all associated in their browser? Whether the user can interact with the form? Whether the data entered by the user is sent to the associated API correctly? Or whether the form looks like it’s supposed to? Those are tests that should be carried out at the UI level. Checking whether the data provided by the user is processed correctly? Whether incorrectly formatted data is handled in the appropriate manner? Whether the right level of access grants is given to the user upon enter a specific combination of username and password? Those tests might target a level below the UI. Many thanks, by the way, to Richard Bradshaw for mentioning this example somewhere on Slack. I owe you one more beer.

Being able to make the right decision on the level and scope to write the test on required knowing what the benefits and drawbacks and the possibilities of the alternatives are. It also requires the ability to recognize and apply principles and patterns to make the best possible decision.

Again, identify and learn to apply common principles and patterns, don’t get hung up on a single tool or language. Choose both/and, not either/or.

The point I’ve been trying to make with the examples above is that, like with so many things in life, being the best possible automation engineer isn’t a matter of choosing A over B. Of being able to do X or Y. What, in my opinion, will make you much better in your role is being able to do, or at least understand, A and B, X and Y. Then, extract their commonalities (these will often take the form of the previously mentioned principles and practices) and learn how to apply them. Study them. Learn more about them. Fail at applying them, and then learn from that.

I’m convinced that this is a much better approach to sustainable career development than running after the latest tool or hype and becoming a self-proclaimed expert at it, only to have to make a radical shift every couple of years (or even months, sometimes).

Don’t become a one trick pony. Choose both/and, not either/or.