One of the things that really bugs me is when I hear anyone talk or write about writing test automation scripts. You see it on Twitter, in blogs and even on CVs and it always makes me twitch.

The problem for me is that there is an implicit ‘only’ in there that downplays the importance of writing test automation code. It is a complex enough task in itself to plan reasonable coverage in a minimum number of tests, but then turning that into reliable and maintainable code is a challenging task.

Poorly written tests can be as costly in ongoing maintenance and investigation, so quality in your tests is as important to your business as anyone elses.

You write Software – Yay!

The first point is that you are a developer like anyone else. You may well be quite junior (inexperienced) at coding, but a developer none the less. Expect to be treated the same:

• Equivalent pay (OK this is an ongoing challenge)
• Equivalent access to software development tools that you need
• Your code reviewed by more senior developers
• Access to appropriate training / mentoring
• Assistance when you are having problems

You write software – Boo!

If course, like anything else, with respect comes responsibility:

• A desire to learn
• Toughness to listen to criticism and learn from it
• Questioning WHY you are asked to change something
• Trying new ways, but always keeping in mind that working code is what really matters

So what’s my point?

I was incredibly fortunate that in my first SDET job I was given a mentor who was serious about writing the best test code. Every pull request taught me new things as he pointed out my many rookie errors.

Now I am the mentor trying to teach and it is is scary for me now as it was trying to learn. I am far from the experienced developer who has been there and done everything so I try to focus on best practice.

• SOLID principles
• Don’t Repeat Yourself

It is almost impossible to get everything right first time, and you shouldn’t try. Seeking perfection is the enemy of delivering quality.

• Plan small classes and short methods.
• Pull out repeated code into private methods, base classes, extension methods or utility classes.
• Make your interfaces logically separated

TLDR:

• If you are writing test automation code, you are a developer. Don’t let anyone tell you otherwise.
• Ensure that you have support and help to improve.
• Someone to review your code should be a given.
• If your current employer cannot do that for you, ensure your CV / résumé represents what you have managed to teach yourself. Others will

A reminder:

If you want to ask me a question, Twitter is undoubtedly the fastest place to get a response: My Username is @AlexanderOnTest so I am easy to find. My DMs are always open for questions, and I publicise my new blog posts there too.

Series Navigation

Accelerating your SDET career. >>