Testing Automation for MS Access

[chriss]

I have a client who have created a MS Access 2003 application that
replaces the UI for their black and green (b&g) system. The Access app
was largely generated from the layouts of the b&g screens and has over
1500 forms.Each form has basic generic editing and when that editing
is passed, the form controls contents are strung into a tab delimited
string and sent to a mainframe for processing. Once the mainframe has
processed the form contents, it responds with the next MS Access form
to load and a tab delimited list of the values to be put into the
form.

So far so good.

My problem is that they test this application by hand!!!! A full
regression test takes six testers the best part of six weeks!!! (And
thats a good regression test!)

So how can this be automated?

Does MS have tools to do this? Can you use MS Access macros? Is MS
Access 2003 supported by VS2005 Team Edition for SoftwareTesters?

Just how does the MS Access community of software developers run
regression tests?

 

[Guest]

I put the tests into a table. The table has function name
form name, parameters, sequence/parent information,
return value, data state test function etc.

I have to write a function to enter the data into the form
fields (easy automation task), and a function to test the
data state after the action.

So the test plan looks like
sequence
state machine
setup
button click event
test result
check test result
state machine
sequence

except that I also have calculation functions I need to test, so there are
also simple calculation tests, and a lot of tests that test queries
directly.

You can use eval or run or whatever to run the functions out of the table.
I also recognise some key words, so I can do simple tests on recordsets
(we have a lot of places where the must be exactly one matching record)

Note: my code has line numbers. Line Numbers are the primary key
of automated test and bug report systems. Some languages use implicit
natural keys, which are unstable and variable. VBA allows you to
use an explicit artificial key, under explicit control. The current version
of VBA has a restricted numerical range for explicit line numbers, so
you need to use a multi-field primary key, including module name. It's
still better than using implicit line numbers.

Since my error reporting framework captures forms by enumerating
fields, I could modify that to build my test cases, but I never needed
to, since all the test cases were added one form at a time.

(david)

 

[Tony Toews [MVP]]

Thanks for your detailed explanation. Some useful and interesting
ideas there.

Line Numbers are the primary key
of automated test and bug report systems.

I would argue that using line numbers are seldom required in most
Access systems given how much of a pain I suspect they are to work
with.

1) VBA code in functions and subroutines tends to be relatively short.
Generally within 10 or 30 lines.

2) I would think that knowing that a given test failed and what module
failed would be sufficient. Then you can just rerun the test
yourself manually and fix things up.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[Guest]

Yes, I just threw that note in as a bonus extra.

It's also the case that, in practice, the call stack is a
lot less useful then you expect it to be. Our error
framework captures the line number, the call stack
and the active form data. Of the three, the line number
is certainly the most useful.

Firstly, it really does help to be able to go directly to
the actual line that faulted, like you can do that when
running interactivity.

Recording the line numbers allows you to do that when
you are just looking a test result or a crash report.

Secondly, we do have complex transactions and calculations.
For us, sometimes the line numbers are really necessary.

But you are right about of the complexity and lack of
support, there are big sections of our code with only minimal
line numbering. Typically the big complex sections are first
written with only paragraph numbering - 17110, 18110
etc. That allows you to easily find the error paragraph, which
you can examine, rewrite, instrument, and number if there
is a problem. The primary key analogy is important here,
if you have hundreds of line 100, one in each sub, it hasn't
helped nearly as much.

(david)

 

[Tony Toews [MVP]]

I would argue that using line numbers are seldom required in most
Access systems given how much of a pain I suspect they are to work
with.

Hah. I just found two buttons within MZ Tools that create and remove
the line numbers. So no pain there.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/