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!)

Let’s Write an Automated Test Framework

I am a huge one-time fan of HP’s BPT framework.  Test execution may be slow, but it is the best tool I have found for a growing test team to use in a whole-team test automation environment.  BPT has powerful abstraction of test scripts to make it easy for business-focused people and new test team members to build tests.  It enables automators to build tests using simple keyword-driven techniques and more powerful and sophisticated test scripts when the situation demands it.  As soon as I learned to ignore the misguided documentation from HP on how to use BPT, it became a very powerful tool.

Over the past year, I have been struggling with the new (and supposedly improved) version of QC/BPT.  The past year has been a mess.  What was a promising enterprise solution for long-term use has, in my mind, crumbled into a pile of what-could-have-been.  As it looks now, it is time to write an open-source automated test framework.

There are many others who have gone down this path.  Most have mixed results (we have looked for other frameworks that meet our needs and haven’t been satisfied with anything yet).  I am still convinced that BPT (as we implemented it) is the best test automation framework out there.  And since so few other people have found BPT (or found it to be a suitable solution for them), I think my team is uniquely (I am sure we are not alone) suited to drive the development of this project.  We have seen what works well.  We have solved the key problems of automation Fire Swamp -- Remember the movie the Princess Bride (1987) when Westley and Buttercup escaped from the Lightning Quicksand?

Westley: No, no. We have already succeeded. I mean, what are the three terrors of the Fire Swamp? One, the flame spurt - no problem. There's a popping sound preceding each; we can avoid that. Two, the lightning sand, which you were clever enough to discover what that looks like, so in the future we can avoid that too.

Of course, in the next moment, he learns about the Rodents of Unusual Size (ROUS) -- the third of the problems.

In the case of test automation, the three terrors are lack of readability, lack of maintainability, and lack of flexibility.  By using our implementation of BPT, we know what problems to avoid.

Look out HP, I think we might write a framework.