I love test automation. In fact, I’ve made a career out of focusing exclusively on automation. It may seem strange, then, to hear me say that test automation skills alone are not enough if you want to pursue a career focused in software testing as a test automation engineer.
This has been a revelation for me; especially when it comes to interviewing candidates for open testing positions at my company. Many candidates who have automation skills listed on their resumes are still not qualified, because they lack the general testing and development knowledge that's essential for any successful testing project.
So what other skills do you need to know to land a position as a software testing engineer? From what I’ve gleaned from the Test Talks interviews I’ve conducted, discussions with speakers at the upcoming Automation Guild conference, and my own personal experience, here are the main areas where job candidates are most often lacking.
Automation is not testing
There is a growing debate in the testing community as to whether automation is actually even testing. For example, in on Test Talks episode, Richard Bradshaw, AKA the Friendly Tester, emphasized that automation is the efficient use of something repetitive or time consuming, so it could very well be that you are automating the execution of test cases, but it is not testing.
Richard went on to explain that automation can more accurately be described as checking. This is important, because lots of folks tend to view automation as only the automation of test cases. This mindset does automation a disservice.
Expanding the definition of automation to mean more than just the automation of regression tests will prove critical as more teams begin to shift-right in their development processes towards continuous integration and continuous deployment.
Interpreting the concept of automation as testing only limits the amount of value you can potentially provide to your team and company.
If you can automate any task—whether a test or not—to save time, that’s when you should use automation. Whether it’s helping to automate the deployment of your software, or creating automation scripts that do some sort of screen scraping or data population to assist someone in their testing efforts, this mindset is one of the main skills a software automation engineer should have.
But as more activities become automated, the tester responsible for that automation must possess a high level of development acumen in order to succeed.
Automation is development
Test automation is all about writing code to test code. That means that you must architect and design the code with the same standards and good practices that developers use with any other software development project.
Automation is software development, pure and simple, and should follow the same standards. That means you must design your code for maintainability and reliability, and follow design principles such as don’t repeat yourself, (DRY) and descriptive and meaningful phrases (DAMP).
When I interview a job candidate who has listed automation expertise on his resume, it often turns out that his experience has been limited to using the Selenium IDE to record and play back a script, or to modify a script. They have no concept of such things as development best practices or having an automation framework in place.
When I ask potential new hires if they can name any best practices for making automation more maintainable and reliable, many of them can’t answer.
I agree with John Sonmez, the founder of Simple Programmer, who believes that many people still don't understand that they need a framework. What they do instead is write complicated tests that directly manipulate the browser and that are directly tied to HTML.
Even though they're being a bit more clever than simply doing a record and playback, they're still making their tests brittle, and they're still tying them directly to the HTML. This mistake is quite similar to the record and playback fallacy, but the situation has morphed a bit. Before it was the recording tools; now it's manually coding with the same problems.
Testers interested in expanding their role to include automation need to learn development best practices such as creating an abstraction level, and they must follow principles such as DRY and DAMP.
Know when to automate
In addition to knowing how to create developer-grade automated tests, it’s important that test engineers have domain knowledge for the applications under test.
Only when you know how a real user of your application is going to be using it will you be able to create an effective test, whether automated or not.
That’s one reason why I’m such a huge proponent of behavior-driven development (BDD). BDD focuses on the user of the application by fostering conversations between all members of the team. It helps to clear up any requirements ambiguity before you write any application code or create any automated tests.
It also helps the tester think about which cases should or should not be automated. Just because something can be automated doesn’t mean it should be.
To be able to decide what tests are good candidates for automation, testers must be able to see the big picture, and be good system thinkers.
Become a system thinker
Alan Page, a tester at Microsoft, brought up a good point when he mentioned to me that testers who are system thinkers are testers who are able to investigate software and have the ability to find holes in the larger system.
They see the system as a whole; they can figure out how piece A should integrate with piece B, and what that should look like. They also can tell when it's working and when it's not, and they have some specialties in nonfunctional areas as well. They can see that automating a certain test may not be reliable in the long run because of how the whole system will be put together.
This is where that tester mindset comes into play: You must be able to see the bigger picture, and how the system fits together.
But quite often, people who don't have the tester mindset are thinking, “Okay. Here's a great tool we can use to automate,” but fail in their determination as to whether or not the return on investment from automating is high enough to make it worth the effort.
Automation not automagic
As automation and performance testing consultant Jim Hazen likes to say, automation is not automagic. Use the computer between your ears before blindly automating something. Use your brain and work on your testing, development and system thinking skills if you really want to nail your next testing interview.
For more on the skills you need to advance in testing, and lots of practical, hands-on advice from testing pros, listen to the podcasts on Test Talks. And don't miss the Automation Guild test automation conference, an online event that runs from January 9-13, 2017.
Image source: Flickr
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
