Automated application testing tools

Question

Does anyone have recommendations for tools which can be used to automate testing of Access UI's?  I've never used such tools but have been asked to investigate their use for our various Access applications.  We're looking for tools that would allow us to script various data entry/editing scenarios in user developed forms and evaluate the results, catch bugs, etc.  The one open source tool I've heard of is Sikuli (http://www.sikuli.org/) but if there are good proprietary tools I'd be interested in hearing of those as well.  Thanks!

-Bruce

Answer 1

Hi Bruce. Looks like some of these tools can be very expensive. Like this one: Test Complete

Good luck!

Answer 2

Thanks DBGuy, 

Do you have experience with this tool?  If so what are your impressions?

-Bruce

Answer 3

Hi Bruce. Unfortunately, I have no experience with any of them because I haven't had any opportunity to justify learning another scripting language to create the test sets. Manually testing the UI seems to be a bit faster at the moment. Cheers!

Answer 4

Hi Bruce Hulsey,

According to your description, you could refer to this helpful link:

http://stackoverflow.com/questions/47400/best-way-to-test-a-ms-access-application

If you have any feedback for Access, please feel free to submit them to User Voice:

https://access.uservoice.com/

Thanks for your understanding. 

Disclaimer: This response contains a reference to a third party World Wide Web site. Microsoft is providing this information as a convenience to you. Microsoft does not control these sites and has not tested any software or information found on these sites; therefore, Microsoft cannot make any representations regarding the quality, safety, or suitability of any software or information found there. There are inherent dangers in the use of any software found on the Internet, and Microsoft cautions you to make sure that you completely understand the risk before retrieving any software from the Internet.

Answer 5

Does anyone have recommendations for tools which can be used to automate testing of Access UI's?

Hi Bruce,

I hesitated a long time before stepping in this thread.

No, I have no recommendation on automated test applications. And in fact, personally I do not need them.

I took a complete different approach. I use generalized forms, that – therefore – do not know anything itself on what has to be displayed. So no testing needed.

All work is done in generalized routines, that apply to all forms in all applications. The “intelligence” or “knowledge” is added through these generalized routines by structuring the logic, supported by meta data tables.

In an application a user never need to do any form development, because all needed flexibility is already built in. If not, then the generalised routines can be extended/improved with respect to the particular problem.

As part of the generalized structure, there are very thorough but versatile checks on data entry in the different controls, and one cannot leave a control when the conditions are not fulfilled.

I can not give a “piece of code” to implement, because this approach means a different way of working with respect to Access. But it could give you a hint in a different direction. It is my pleasure to continue a discussion on this topic.

Imb.

Answer 6

"No testing needed" is a bit of a stretch for most applications :)  

Frankly I am skeptical of the usefulness of automated tools for testing Access applications in general but I needed to perform some due diligence to see what was out there, if anything, that developers found useful.  If anything, very generalized scripts of a few complex data entry tasks to be stepped through before dumping interface changes on the end user are probably all that we really need.

I appreciate your input!

-Bruce

Answer 7

"No testing needed" is a bit of a stretch for most applications :)  

Hi Bruce,

I agree that my statement:

I took a complete different approach. I use generalized forms, that – therefore – do not know anything itself on what has to be displayed. So no testing needed.

sounds like an understatement. All entities (tables) in an application use the same form, that has proven to be robust. So adding a new entity to an application, or changing names of entities or fields, do not need further testing. Of course new functionality must be tested thoroughly.

Furthermore, dynamically generated forms or menu's are build from standarized building blocks. This almost means that when the compiler does not complain, the code is ok.

Imb.

Answer 8

That it’s necessary to jury-rig some kind of solution in VBA, is just too much work. And then, when the  project is done and the devs have moved on, someone has to maintain the app. They have to learn the app and whatever the hack was to get auto-testing to work. From the looks of some of the solutions, there’s more code in the auto-testing than there is in most apps.

Easy enough to write

Private Sub XSomeCode()
    SomeCode
End Sub

Public Sub SomeCode()
    Debug.Print "in somecode"
End Sub

On the other hand, it’s wise to incorporate some self-defense, so my SomeCode at a minimum would look more like this:

'
Public Sub SomeCode()
'   Purpose: SomeCode - Demonstrate self-protection
    On Error GoTo errorexit
    Enter "SomeCode"    '   Tracing
    '================================


    '================================
exitprocessing:
    Leave "SomeCode"
    Exit Sub

errorexit:
    ErrorHandler "SomeCode"
    Resume exitprocessing
    Resume
End Sub

Which is generated by a code-writer. The Enter and Leave routines use a stack to record program trace.

That’s usually more than enough to find any errors.

---

peter n roth - http://PNR1.com, Maybe some useful stuff

Answer 9

On the other hand, it’s wise to incorporate some self-defense, so my SomeCode at a minimum would look more like this:

...

That’s usually more than enough to find any errors.

Hi Peter,

In my applications I use an application specific FE, with a reference to a library database, that contains all the generalized code shared by all applications.

This FE - which includes the specific reporting about the application - does not contain any error handling anymore. All (general) error handling is done by the shared code.

Any errors that occur are in fact programming errors or errors because of wrong logic, and have to be removed on forehand before using the application.

Imb.