Accelerating your SDET career.
Since changing from teaching into software development on my 45th birthday exactly three years ago today, I fell into test automation entirely by accident. It is something however that I really enjoy and apparently it is a great path for the ambitious software development professional. In just those three short years I am already earning more than I ever achieved in 20 years as a school teacher, and almost certainly more than I would be able to command had I gone down the regular software developer route.
In case you are coming straight to this post, I should explain that an SDET is a Software Development Engineer in Test, sometimes called a Developer in Test or Test Automation Engineer. Whatever the title our job is to test new software and write automated tests to run everytime a developer adds new code. Hopefully the tests validate that they didn’t break anything that was working before. When people ask I say that I write programs that test other people’s programs.
A few reasons why I love my job:
- I get paid to deliberately try to break stuff.
- I write my own code, and sometimes get to wrestle with some really challenging problems.
- I get to design and build frameworks from scratch.
- I get far greater input into the design phase of a project than any developer with the same level of experience.
- I have the biggest input on whether something is going to be ready to ship.
- If I am not happy and release date is approaching, anyone from the most junior junior to the most senior architect may be asked to drop what they are doing to fix the problems.
Skilled SDETs are highly sought after. Whilst not quite as rare as hens teeth, I have yet to meet a company that doesn’t find SDET positions far harder to fill than developers. This is a ‘good thing’ for those willing to follow the less trodden path. So how can you make yourself stand out and get on that path?
Here are my top tips:
Top tip #1: Learn a modern object oriented language
If you are coming from a classic Computing degree this is the easy one for you. It doesn’t matter how recently, or what language but you need at least a solid understanding of basic object oriented programming. I was very fortunate that some 10 years before my career change I had taken a year out and spent a year basically studying Computer Science (at Masters level) at the IT University of Copenhagen. I never completed the degree, but with object oriented programming; algorithms; the software development lifecycle; networking and databases all covered in the year I was well placed to make the switch when the time came. Don’t get me wrong, I have learnt far more in the two years and a bit years writing tests than I did at university, but the theoretical grounding is so useful. If I am honest, probably the biggest advantage it gives is in the dreaded coding interview. If you want to be paid the same as a regular developer, you had better be able to impress as well as one in the whiteboard test!
If you are looking to start out, or move into test automation from a more manual role, this is quite daunting and I wish I could point you at a great resource to do so. If you are already in testing, push your employer to get you on courses and/or mentoring from a senior developer if not SDET. If they are investing in you, and helping you to build your skills, they are worth sticking with even if the pay looks better elsewhere.
Top tip #2: Find a job at a company you can learn from
Starting out you may not have so much choice here, especially it you don’t have a CompSci background. Ideally you want a company that you can start off as a manual tester but get help to learn to code if you show potential. I was lucky that my first two companies were happy to let me learn as I went. Better than that, at Experian Data Quality I was fortunate to have a mentor in Ross Ackland who was both incredibly experienced and very thorough in code reviews. I may have worked very hard to get where I am today, but it simply would not have happened anything like so fast without his diligent code reviews and patient explanation of my mistakes.
A job with a good mentor who you are learning fast from is worth a lot more than a slightly higher paid job repeating what you have done before.
Most importantly however, don’t let yourself get stuck somewhere that doesn’t challenge you to learn. Identify what you have learnt from them so that you can discuss it in your next round of interviews and get applying.
Top tip #3: Learn to write automated tests
If you are in an sdet role already this will be an easy one for you. It doesn’t matter whether this is an API testing or UI testing. The technology doesn’t matter either. If you are being paid to learn it great! If not, I suggest that you use one of the myriad of resources out there to learn how to use Selenium for browser based UI testing.
The great thing about Web Testing instead of API testing is that you can really see what you are trying to achieve and what goes wrong when a test fails. Start simple and start with tests. I think it the height of madness that so many introductions to Selenium start with firing up in an application. My second post on this blog explained how to start out in Java with Junit and I hope to do something similar in C# / .net very shortly.
public void WebDriverSessionCanBeLaunched()
{
...
}
The Selenium coders ‘Hello World’
Remember, you are there to speak for the user and the product owner when they are not there. You are paid to to say when you don’t think it is good enough!
Top tip #4: Be outspoken about quality at work
- Remember, you are there to speak for the user and the product owner when they are not there. You are paid to to say when you don’t think it is good enough! When you think something is unusable be prepared to explain and show why. Sometimes you will be overruled but you are still doing your primary role. It then becomes the developers job to fix it or persuade you that you are wrong.
- Challenge poor code. Review other’s code if you can. Spend time exploring the repository and be prepared to feedback on the good, the bad and the downright ugly.
- Cultivate Quality Allies. Shine a light on quality work from your colleagues. Mention those awesome unit tests someone added, or highlight the excellent code reviews that they give. Share the good practice in your office with everyone and especially the person involved and their manager. Don’t let someone with good training get sloppy.
- Raise bugs as soon as you are sure you can reproduce it. Include version number and OS, time and date, full reproduction details and acceptance criteria on a fix. If its really serious make sure that the powers that be know to Triage it. (You usually know when something needs to be fixed now)
- If its not there yet, keep pushing to get static code analysis embedded as soon as you can. There is no better way to leave a legacy of quality after you have gone.
Top tip #5: Study for the ISTQB Certified Tester Foundation Level
This is where the tables are turned. If you are already in test you will not find this difficult. Mostly it is just putting a firm theoretical basis on things that will already be mostly obvious to you. Personally I trained myself for this exam after 6 months as a tester as I could see unemployment coming at me fast. I could afford to put down the £180 for the exam and I have to say that it paid for itself immediately when the inevitable redundancy came a few weeks later. ISTQB CTFL plus self taught Selenium testing experience got me two job offers within a week at a 75% pay rise!
There are ample free resources to teach yourself. If you really cannot afford the exam, it won’t do any harm to ‘be preparing for the ISTQB CTFL exam’ on your CV / covering letter as long as you can back it up with the knowledge. A good employer might even offer to pay for it.
If you are coming from a CompSci background or currently working as a developer don’t skip this step. It will make you look at Software Development from a different angle and put the whole ‘shifting left’ mantra in context. I would thoroughly recommend taking the exam if you can afford it. This is your way to show the recruiters / development managers that you are serious about test, not just applying to SDET positions to shore up a struggling development career.
The ISTQB Exam is offered by many different organisations around the world and in many languages such as the BCS in the UK, and the ASTQB in the USA.
Top tip #6: Keep your CV and LinkedIn profile up to date with relevant new skills and achievements
This is an insurance as much as anything. You never know when your team might be shut down or an amazing opportunity opens itself up to you. If you have been in your job six months there are hopefully already a number of achievements that will enhance your CV. I bet you won’t remember them when you have to write a CV overnight. Get in the habit of updating it regularly – quarterly or annual reviews at work provide the chance for you to discuss with your manager what has gone well, and get an idea on what you want to work on for the next update.
If you sit down after a review and honestly cannot say that you have progressed, that should be a big red flag. You either need to buckle down or move on.
Top tip #7: Build your own test framework at home and blog about your progress.
Note: Employment law and contracts vary wildly.
The easiest and safest way to ensure that blogging does not get you into trouble is to have explicit written permission from your employer. As long as you focus on generic test automation it is in their interest to allow you to improve your skills and research future technologies at home.
In any sensible world, you would probably not be building a framework from scratch for at least a couple of years. In fact, I am pretty sure that had I realised that I was going to be doing so in my first official test role, I probably would have run a mile. However, sometimes a company or division just doesn’t have a framework, but does have a willing victim, oops I mean Junior SDET and someone with the skills to mentor and support them through it. Lucky you!
If not, you will, I hope be writing tests using someone elses framework and implementing it on many projects. This should be enough to get a decent idea of the basics you need to achieve for this step: At work, especially if you are using a prebuilt framework, you will almost certainly be using mature technologies. My idea in blogging was always to imagine how I would go about building a new frameork with the most up to date technologies. In the case of my Java framework this was using JUnit 5 as it was first released. Not only will you reinforce your knowledge, you also end up putting some of the first content online about using the technologies you are working with.
Super important caveat:
Anything that you write at work is the property of your company and may not be blogged about or shared without explicit permission. Set yourself the task of doing something generic using different technologies at home and NEVER cut and paste from your work repo: Don’t even have it open! If you are having problems, search for public domain solutions and credit the authors. The issues you had should be tagged for SEO as that is exactly when others will want to find your post.
Many of the posts in this blog are my attempt at doing this. My blog project tests my blog site. Perfect!
- Repetition is the best way to remember something that you did. You will have a much better chance of remembering how when you start your next job at a company with nothing!
- If you did a decent job in blogging, you can always refer to your earlier notes.
- It is your own time so you can choose to waste it on ‘that dumb idea’ instead of a business focus on getting more tests written.
- You can dive deep into how the (open source) projects that you are building with work.
- Others WILL hit the same problems and your blog posts will soon start appearing in searches.
- Your brand is being built: It will impress employers and recruiters will notice you, especially if you are sharing on Twitter and LinkedIn.
I chose to pay for a WordPress site and domain name, but there is nothing to stop you going with a free blog site or sharing your insights on Medium or similar sites. Maybe your employer willl ask you to write posts for the company website. Each approach has its advantages.
To protect yourself from IP theft claims:
- Cite your sources or inspirations if trying something different.
- If you want to write about something you did at work, always get approval from the company first.
- If you think that something you have done at home could be useful at work ALWAYS get your post published before letting the code anywhere near the office. (Ideally let your boss / mentor suggest that you ‘Do that thing you blogged about last week.’)
In Summary….
You don’t have to do any or all of the above to progress quite successfully in a specialism that so few chose to follow, but especially if you have ‘soft skills’ from your work and experience in different industries, the potential to progress quickly is there: Show your ability to learn and apply the twin skills of testing and coding and you will not be short of job offers.
Maybe it is time to finally put all those hours entering basic programs on your ZX Spectrum in your teenage bedroom to use and make that career change into tech that you always wondered about. My DMs are open on twitter if you want advice on making the switch. It was easier than I thought.