Automated Testing of an application

[Guus2005]

Hi,

Do you have experience with automated testing of an Access (or Excel) application?
And if yes, how do you accomplisch that?

Thanks for your time!

 

[MajP]

There was a recent question here, but few replies

Auto testing tools

Hi, It's me again:) I have now just about completed my database and was think there must be an easier way of testing forms. My thinking possibly be a key stroke recorder that I can run on each form to check if the form functions correctly. I had one years ago (on main frame) that you could have...

www.access-programmers.co.uk

 

[Guus2005]

Thanks. I searched for that question but couldn't find it so i posted this one.
Thanks for the link

 

[NauticalGent]

My guess would be that you would have to be intimately familiar with the application and then write code that would simulate a user's activity such as data entry and what not.

You would also have to intentionally input "bad" data to see if your error handling and validation worked.

If there was a way to have one program that could evaluate ANY MS Office app and put it through its paces, that would be a valuable tool.

A worthwhile project to take one and definitely beyond my skill level.

 

[Guus2005]

I found Mini Mouse Recorder and AutoHotKey. For the latter one could write a script to react on texts and/or images.
For me it is important that the tools are portable. Meaning, i don't have to install them since that is not allowed on this computer.

Thanks for your time!

 

[gemma-the-husky]

Depending on the app, I imagine you need a test pack of data with anticipated outcomes, as well as general user acceptance tests

 

[The_Doc_Man]

The U.S. Navy worked with various Windows-based and UNIX-based automated testers for a long time. They involved various scripting tools to do the equivalent of "Send Keys" and some other command methods including programmed interaction with the UI. The basic guideline is that when designing your app, you ALSO have to design tests to verify operation. Specifically, you must design the tests SIMULTANEOUSLY with the function. If this testing-as-part-of-design aspect isn't embraced during original design - and particularly if it isn't embraced with the original design specs in mind, you can't even devise a good series of tests.

At one place where I worked before my Navy job, the quality tests failed because we lacked imagination. We had a huge app with maybe several hundred thousand lines of code in play spread among six major and several minor modules. We thought we had it honed to razor sharpness. But then during a customer visit we found out we were wrong. We had specialized keyboards with custom key caps, which were due to the nature of our particular beast. So the customer put one of the keyboards near the edge of the table and leaned on it. He "butt-typed" a string of characters, didn't matter which ones. Crashed our beautiful system in 20 seconds flat due to buffer overruns. We didn't think outside the box.

Any automated tools you find will probably emphasize to you that you can only test with intimate knowledge of the design goals and internal methods of your system. Any tool that FAILS to warn you of that fact is perhaps not such a good tool.

Sadly, I have dropped out of touch with my Navy contacts so have no easy way to identify product names at this time.