Looking for professional advice

[sabavno]

Hi

I am getting to the end of my Access application development (my first application ever)
So what I am looking for is the advice on how to test the application, where to emphazise my testing, what not to overlook. Please help me with your professional tips.

Thanks a lot

 

[AutumnBlues]

Hi there,

From experience (from which I've since moved on)...

The first thing you've got to accept is that there are going to be things that need fixing - maybe lots of things. Proper testing of your dB depends upon your ability to manage the process fault finding and subsequent fault fixing.

Have a 'test dB' for users to 'play with'. Note: I say 'play with' intentionally as you may encounter resistance to your new technology brought about by fear. Introducing a sense of fun will help overcome that. The Test dB should work in the exact same way as the real one, except it should write to completely seperate test tables. If you get really good at this type of thing, you can build a function that swtiches your forms between test tables and live tables, but don't worry about being too clever for now.

Have the people who are eventually going to use your dB test it. Ask them to produce lists detailing what they find; ask them to note good points as well as errors, as this will be good for your own future projects. Again, a good reason for having the eventual users do the testing is that they'll feel more involved and consequently be more likely to use the dB properly. They'll feel a sense of ownership that'll go some way to overcoming their resistance to change.

Have them test the dB in short bursts: fifteen minutes or so; any longer and you may find yourself inundated with 'issues'. After a while, once you've fixed the big problems you can allow longer testing periods. Also, try to identify (maybe from your lists) the people who are more minded to this kind of testing and give good feedback. You can use these people to investigate particular components that you feel need special attention.

From the lists, group together the problems and start tackling ones identified most frequently, working down to the less frequent ones.

You also need to get the message over to whoever your boss is that finding errors is a good thing, an essential piece of building such a system, otherwise he/she might think the errors are due to incompetence (You need to learn to manage expectations).

(You'll need to look at the newly populated tables yourself to check that data is recorded correctly. Users will probably identify these issues for you as forms often look at tables anyway, but just to be on the safe side...)

Finally, don't get depressed if it seems like the whole thing is falling apart. Just keep your head down and work your way through the lists, trying not to concentrate on the 'big picture' (otherwise you'll just feel daunted). Once you've fixed the stuff on the lists, get the users to re-test and make up new lists. Keep repeating the process until the lists are no more (You may get one or two users who want the Earth, take note but don't get too involved with them).

Hope this helps,
I'm sure others here will be able to give more tips,
Let us know how you got on.

AutumnBlues

 

[MichaelRed]

Long before you turn a new app over to anyone (including yourself) for testing, generate some guidelines. What is it (the app) supposed to do. Next, generate (a list of) the limits of the app. Next, generate a test set of data which covers these 'limits'.

THEN, do your own set of tests (Pre-Alpha testing). Only after YOU CANNOT 'break' it, resort to AutumBlues' suggestions.

Independent Users will almost certainly find many innovative approaches to using your app, so (as Alfred E. Neuman mighr say), 'not to worry' about their finding things which will 'break' your app.

Finally, do not necessarily 'fix' what thsy find -at least in terms of making it do what THEY want. You designed the app with goals and guidelines. When the 'complaint' does not fall within these 'scope' documents, decide which is really more appropiate:

Fix it (within the scope)

Prevent it (err trapping / validation)

Change the Scope (and return to the decision process)

Not all complaints are VALID!


I usually would include a small form (and table) for users to submit issues to me from directly within the app, at least up through Beta tests. My experience has been that this approach makes it easier for noth the user cmmunity and the development group to collect and organize the issues raised during testing.

MichaelRed
m.red@att.net

There is never time to do it right but there is always time to do it over