Question Does anyone know of a good test tool for access?

[Gareth]

I have searched high and low and cannot find a tool which will help me test a very large access database. What I am after is something which will press every button on every form and fill each field with data. I may not be able to find something to do all that but at very least click every button.

I have created an add-in that launches every query, report and form but this is only half way to what I am after.

Any sugestions?

 

[Banana]

Just exactly what do you want to test?

I would think clicking buttons won't really mean that much as this is executed locally and would be just fast as anything else running on the client's machine. Rather, I'd be much more concerned with the network performance, whether I can retrieve large amount of data in a reasonable frame of time.

 

[Atomic Shrimp]

I'm going to say "can't be done" - not because of technical complexity...

I think it would be quite possible to create a little form object that would do some of this, for example, the button click thing could be done by:
Looping through each of the forms
Looping through all the controls on each form
If the control is a button, and is enabled, set the focus and use SendKeys to send a space character

BUT...

I would expect an automated process like this to fail quite horribly for any access application of any significant size or complexity, because:
- It's not enough just to want it to push data into a text box - it very probably needs to be the right kind of data
- It's not enough to just click every button in turn - some of them might not be enabled until other processes have been invoked
- If there's a 'quit' button on the form, clicking it will abort or crash the whole process prematurely.
- Opening each form programmatically and clicking the buttons on them might create situations that could not happen within the normal flow of work - for example, clicking a 'yes' button on a custom question dialog when the situation normally invoking the question is not in evidence.

(those scenarios are just examples for starters - there are a whole bunch of similar ways in which it could - probably will - go wrong)

What could you possibly hope to achieve from an automated test like this? What confidence could you ever have in the results it produces? It's possible to test the facts and figures of a database app, but without understanding their meaning, the test would be pointless at best.

Hire a temp and give them a testing plan.

 

[The_Doc_Man]

Hire a temp and give them a testing plan.

Good advice. It helps if this temp ISN'T that savvy regarding Access. I have always found that less-than-perfectly-astute users are the BEST methods of testing any new software. Users in that category make the perfect mistakes to give you really good tests of your new application.

In fact, once upon a time at least 25 or 30 years and at least 6 employers ago, we were about to hire a software tester and were trying to put together a job description. It had been a long day, it was late in the afternoon, and we were all really tired. So the discussion went...

"OK, let's run the ad 'Wanted - a fool to test foolproof programs' and see what we get."

To which one of my assistants, absolutely deadpan, said, "What fool would apply for such a job?"

Without missing a beat, another staffer said, "And if we found one, what fool would hire him?"

The third staffer replied, "If we can find an answer THAT question, we could simply hire from within. And as far as I can tell, the bosses with hiring authority probably would ALL qualify equally well."

With that comment, we lost it completely. When we stopped the activity now known as ROTFLMAO, we turned out the lights, closed the door, and went down the street to the nearest bar and grill. We'd had enough for that day.

 

[Gareth]

Thank you all for your comments. I would love to hire a temp to do the testing except I work for a non for profit. Maybe I can just grab someone from the canteen and give them a few quid.

I was already thinking about putting together a test plan for regression testing but this will take me a long time and its just me doing the db support work. Ho Hum.

 

[Galaxiom]

There is no such thing as foolproof because fools are too ingenious.

 

[Banana]

The trouble with regression testing is that you have to program what it should expect for in testing, and I'd bet that you'd end up putting lot of time telling the tool what to do and what it should be expecting and double-checking that the test itself actually is valid that you've ended up investing 10x more times than if you just had an idiot off the street sit down and randomly hit the keyboard with his head.


Okay, that last sentence was a slight... erm, gross exaggeration, but in this context, I do not think it's really worth the time and effort looking for and/or designing such test when you can just do it yourself.


I'd also heed Galaxiom's advice. One MVP has it in his signature: "I didn't know there'd be so many fools when they told me to build a foolproof program."

and another quip:
"Everytime we invent a foolproof program, they build a better idiot."

 

[Mike375]

It helps if this temp ISN'T that savvy regarding Access. I have always found that less-than-perfectly-astute users are the BEST methods of testing any new software. Users in that category make the perfect mistakes to give you really good tests of your new application.

Agree 110%.

Those people will "click" on the wrong things etc.

 

[Atomic Shrimp]

Thank you all for your comments. I would love to hire a temp to do the testing except I work for a non for profit. Maybe I can just grab someone from the canteen and give them a few quid.

I was already thinking about putting together a test plan for regression testing but this will take me a long time and its just me doing the db support work. Ho Hum.

Presumably the system will be released to a group of users at some point? Why not recruit some volunteers there?

That's what I'm doing at the moment with an application to deal with company credit card expense forms - it will eventually be administered by half a dozen people in finance, accounts and management, and communicating with several hundred cardholders - but for now, it's released to one person in finance and only a dozen of the cardholder accounts are switched live.
As long as everyone understands that it's in a testing/pre-release phase and will go wrong, it's fine. Users are encouraged to break it, because at the moment, it's running on live data, but alongside the existing paper system - if it all goes wrong, we haven't lost anything critical.

It's also a good way of working out all the non-fatal usability quirks (for example filter and search functions that nobody thought to ask for at the beginning, but are essential in dealing with big lists), but watch out for 'feature creep' (i.e. failure to ever reach full release status because of a steady stream of new feature requests).

As and when the system goes fully live, there will already be a small team of people experienced in using it - and some of the training can be delegated to them.

 

[Galaxiom]

One of the really common problem experienced by naive users is double-clicking when a single click is required. Some developers tie the On Double Click event to the Click event to circumvent this behaviour.

And a quip. When I was growing up a "tool" meant a foolish person which is exactly the kind of "tool" suggested. Don't know if the term is still used.

 

[Banana]

Ha, ha, you're such a tool.


(Does that answer your question? )


I would be guilty of tying the double-click to the click for some controls; it's not strictly necessary, but in that context double-clicking wasn't expected to do something different and would have had been confusing if it did.