Tip – Take Pride in What You Do

Normally, these articles in the ‘Tip’ series are technical in nature and give you useful tips to help you in your tests or frameworks. However, occasionally I like to try and give tips or advice in areas that are not technical, but still aim to help you become a better automation tester through an improved approach or mindset.

Today’s article is about taking pride in your work, taking pride in your work should apply to everything you do but for the sake of this argument, and so not to end up writing a novel on self improvement, I’ll keep it to the context of test automation.

So, why am I choosing to write this article? Well in recent months, I’ve seen a few posts on social media, LinkedIn and Twitter specifically, talking about how someone is “only doing automation half the time”, “only using x language”, “maintaining pointless tests” and the best one “only writing test scripts”. It’s easy to fall in to this trap when working on tasks that feel insignificant or that you feel are below you and your ability. I too am guilty in the past of feeling like certain, less glamorous code is any less important. Allow me to post a quick story that might set the scene for what I’m about to write:

”Once there were 3 bricklayers. Each one of them was asked what they were doing.
The first man answered gruffly, ‘I’m laying bricks.’
The second man replied, ‘I’m putting up a wall.’
But the third man said enthusiastically and with pride, ‘I’m building a cathedral”

The above sets up perfectly what I want to talk about, and that is to discuss two key areas when it comes to taking pride in your work and why it matters.

The first is attitude. Your attitude towards your work will show in what you do. If you take the attitude that you are “just writing test scripts” then the code written for those scripts will reflect the lack of enthusiasm and care for work being done. If you’re aiming for bigger things and want to be writing the more technical framework code, then that is absolutely fine, and it’s no bad thing to be ambitious, it should be encouraged. But understand that what you’re doing is just as important, if not more so, than the framework. A framework can be the most technical and complex out there, but if the tests it is driving are rubbish, then all that code is for nothing. A brilliantly designed and coded framework powering poor or inefficient tests will provide no benefit over even the most simplistic framework.

Take pride in the fact that those tests you write are key in the ensuring quality in the project you are working on, and in turn, will allow you to release the best product you possibly can. Which leads me on to the second thing to mention, which is being able to see the bigger picture.

While it may feel like you’re writing just another test script, and that you’re doing the same old thing, but like the third brick layer in the story, learn to see and appreciate the bigger picture. Imagine a visitor came to your office and asked you what you were doing. You could answer with “I’m writing a test” or, you could proudly say “I’m helping to put the best product possible out to our customers”

While that may seem incredibly an cheesy thing to say, notice how it tells the real story of what you’re doing. Don’t sell yourself short, you are playing a huge part in the process of creating a product to release to your customers. Without that test, a blocking bug may get released that ruins your product, or worse your companies reputation. Being connected to the company that you work for and their mission will help you to understand the importance of what you do, and enable you to feel like what you’re doing is making a difference, no matter how small the task may feel in the grand scheme of things.

Treat that test (I keep using test writing as an example but as I said earlier, it applies to everything in your job) like it is the most important task you could possibly do. That without it, the project just will not be able to continue. This will show when the code is being written and the quality of your test will be far higher.

Importance aside, see it as an opportunity. If the code you are writing feels very repetitive, look at areas that can be improved. Are your page actions using implicit waits that are adding unnecessary time to your test suite? Maybe there’s a lot of tests that are using the same code and they can be merged and parametrised to be more efficient? There is always scope to learn when it comes to coding. That goal of getting to be a automation architect, or a consultant, will only be sped up by getting better at understanding what makes a good test and how to make them as efficient and robust as they can be.

While there will no doubt be times where you are doing tedious or frustrating work that isn’t what appeals to you or what you enjoy, but it’s important where possible to use it as an opportunity to learn and improve, but most importantly, whatever the task, take pride in what you do and ensure that it’s reflected in the end result.