Ways and Means

I recently learned that New Jersey and Pennsylvania are putting in new toll benefits for seniors. Good, you think? Well, these benefits are changing form. The benefits will now be tied to EasyPass, which not all seniors use.

This reminds me, for some reason, of when Digital Equipment Corporation was trying to get people to stop using the PDP-11. Try as they might, people really liked the workhorse, and didn't want to change. Of course, this meant that DEC was selling less hardware than they would have liked, and spending a fair amount of their customer service resources supporting 'old technology'.

There are ways and means of motivating people to move to a new system. Usually, the young among us is more open to these changes. They haven't gotten used to the old ways. We move to new things, too, when they seem significantly easier than our old ways.

For the tolls in these mid-Atlantic states, the means to move the seniors to this new program seems cumbersome. Even if they already have EasyPass, they can't simply add a senior option. If they have been using coupons, they are forced to apply for EasyPass, even if they are skeptical of using electronic systems for tolls. It would be like telling people we no longer accepts checks.

When times comes to ask users to make a change, always consider the two most successful paths: new users and the new system being easier than the old. Otherwise, you'll find yourself in the situation that DEC did - new product, loyal customers, but not enough profit on the new product.

Flexibility in Data Definition

I was reading a book recently called "The Art of SQL" that I highly recommend. The authors warn against what they call the dangers of excess flexibility. It got me to thinking about automated test designers who promote 'data driven design'. In fact, if you say that you use data driven design, you're sure to be considered a serious Quality Automation Professional. But what does that mean?

Well, I have discovered a disturbing trend. The trend is to create a table of attributes, and corresponding values. The automated designer creates his or her engine, and all the users of that engine have to do is populate the table. That was the part that always got me. These professionals don't have to actually understand the product that was going to be tested, but they get paid for 'creating the engine'. It seemed that there was still an awful lot of work to do to populate these tables, but until I read the clear and concise description of excess flexibility, I couldn't seem to put my finger on just why it sounded so wrong.



Now, I do create data driven automated tests. These are created after I have analyzed how the product is meant to work. To use "The Art of SQL"'s term, I atomize the data. "The Art of SQL" defines atomized data as what is unique. By extending the principles of creating maintainable databases to creating maintainable data driven automated tests, you can create an automated suite that will actually survive past one Quality Assurance Test Engineer. I know. Several of the test suites I have created over the years are still in use long after I've left.



I used to try to figure out why the way I create data driven testing wasn't the way that they do it. Why do they 'get paid the big bucks', and how do I explain that my way is better?

Well, I don't have to anymore. I can just point you to "The Art of SQL". After all, SQL is all about managing data, and if you are going to create automated tests that are 'data driven', you should effectively manage the data.