distributedlife

As a service tester I am constantly flabbergasted by what passes as design by developers. Most of the time my flabbergast is directed at their continuing refusal to learn from their mistakes. Just recently though I had the pleasuring of growing myself.

Service tests where I work are written in Vanilla C. We’re talking 80’s C with the big hair, neon and everything. One of the things Vanilla C doesn’t have is the concept of a Boolean. Integers are used.

When we execute tests we leave cross cutting concern validation off when testing functionality and then enable it when are specifically testing that particular cross cutting concern. An example is ‘Exception Reporting’. We do this to reduce the time it takes to execute the tests and to stop Exception Reporting failures from failing the functional tests. Restricting the focus of testing is very important to me.

So we would have code that looks like this:

EnableCheckForExceptions (0) ;

I was explaining this to my junior service tester and she asked why it couldn’t just be a Yes or a No.

I didn’t have a good answer especially because I knew it was entirely possible to have just a yes or a no; in a newer language I would have coded something like this:

ExceptionValidation.Enable () ;

But in C we don’t get such extravagances as classes. Luxury!

What I did and what I will do in future is define an enumeration like so:

enum EnabledOptions {No, Yes} ;

and then changed the signature to this:

void EnableCheckForExceptions (enum EnabledOptions ExceptionValidationEnabled)
{
     //...
}

This isn’t mind blowing software architecture but anything that increases friction or is a barrier to learning makes it more difficult to learn. Right now my primary job is establishing an autonomous service testing team from people who are not software developers. This is a combination of teaching them various programming languages and writing an API layer that encapsulates the existing HP Service Test functions and gives it a more realistic testing terminology and structure. This enables the testers to use their language to write service tests.

To me this is where HP’s Service Test fails most of its users. It’s designed for the people who wrote Load Runner and not those who are service testers or those that lack in depth programming knowledge.

I fell into the same boat but thankfully I was saved by taking my implementation to the users and asked if made sense. User acceptance testing for APIs!