No More Automated Test Engineers

As I reviewed several candidates’ resumes recently, something bothered me.  The open position is for an Automated Test Engineer for Agile Teams.  I am looking for an automated test engineer, but I find that I am bothered by the automated test engineer role.  After I thought about this for a while, I realized that I am still thinking about the “Whole-team” Test Automation post.  If everyone is an automator, then there is no need for an automator.

The common thing about the automation engineers I have met with and interviewed is that their current career path depends on the ignorance of their testing colleagues.

Even though it may seem to be disingenuous (I grew my career as an automation engineer), but I see no place for it anymore.  The presence of an automation engineer at a company is a sign of a problem.  In all likelihood, it means that a two-tiered system exists in the company’s test team.  In a proper agile test team, all members of the team have the skills of automated test engineers and are ready to use them whenever they are needed.

BTW:  I recruit for automation engineers because the industry has not caught up with us yet. I look forward to a day when the base expectations of a software tester include high levels of technical proficiency and mad testing skills.

Regular Expressions: A Tester’s Best Friend

Okay, I feel I am entitled to a bit of hyperbole, but I think regular expressions are great.  I like them for two reasons.  One is they are a programming language, and many programmers do not know regular expressions very well.  It is always great when the testing team has a technical advantage over the application developers.

The first reason is a bit lame.  The real reason I like regular expressions is that they enable you to have some much power in your automated tests while keeping the test framework very simple.

For those unfamiliar with regular expressions, regular expressions enable you to match patterns in strings of text using a simple syntax of reserved characters and patterns.  Regular expressions range from something simple like “Bob.*Jones” where “.*” is essentially a wildcard where matches include “Bob the wildman Jones” and “Bob Jones”  You can also make regular expressions to make sure that a value matches a date format or social security format or use a regular expression match an application validation message where the message changes in some predictable way when a test runs.

In our test framework, we use regular expressions for all automation components involved with verification.  For example, we use many “verify data” components.  In these components, you enter the expected value for a field in the application under test.  All our fields are regEx enabled, and typically this means that you enter an exact string value or a regular expression pattern to match in the test.  This means you have a very simple test with a lot of power.

Implementation note:  There was a point of the development of our automation framework, we had to make decisions about whether to use regular expressions and how to use them.  As much as it pains me to say, the biggest factor was whether the use of regular expressions would be too hard for testers.  Fortunately, we decided that testers are smart enough to handle regular expressions (and of course, they are!)