How to test program before releasing new version?

[Josef P.]

[OT]

... to compare your new version against Prod. And then go thru the difference reports line by line to make sure there is no odd code in your changes, ...

This functionality is also given if you use a version control system like Git or similar.
However, I believe that only a few Access developers use a VCS and/or automated testing. I just don't understand the reason, because it's not particularly complicated.

 

[amorosik]

All great ideas for testing. As a former release manager, I note that the OP mentioned 'the moment of release', and confined the question to functional verification.
So if I may, I'd add the following: consider running something like Access Detective to compare your new version against Prod. And then go thru the difference reports line by line to make sure there is no odd code in your changes, and that all expected changes are there. There are many reasons why this can inadvertently happen, most particularly if you have a team of Access developers all working multiple change requests for a single release.
Jack

This check is simple to perform
Just export the entire Access procedure to text file format (see Vcs-Access)
Then compare the new version with the old one simply using one of the many programs for comparing text files
I use WinMerge but many others are available

 

[amorosik]

Which implies carefully keeping older versions,

???
Are you saying that's not common practice?
Personally, I always keep all copies of previous versions, with descriptions of the changes made
But I must say that in reality I have never needed them
I keep them anyway because I think that security is never enough

 

[amorosik]

I add these links because they contain information related to the topic of this 3d

accessUnitFork - Unit Test Framework/Utility for Access-VBA​

Automatic Testing in VBA and Access - NADD 2019 - Philipp Stiefel​

Modern Software Quality with VBA and Access - Live at AccessDevCon 2019​

 

[Pat Hartman]

Are you saying that's not common practice?

Not for the newbees. They need to get burned a few times before they understand the importance of version control whether you do it with a formal app or roll your own.

 

[The_Doc_Man]

Are you saying that's not common practice?

It should be - but sadly, often it is not. And is therefore yet one more contributor to reasons why big projects sometimes fall down.

People mistake the pressure of a managerially-imposed deadline with having anything to do with the correct handling of a project. So what they do is say, "Do you really need to keep records like that?" "You know that every complete backup takes two hours to complete." "Why are you writing in this document when you should be writing code?" Business managers are useful when dealing with logistics of procurement and such, but there are times when they are a true pain in the toches.

Whoever sets the deadlines and makes other noise needs to be told distinctly and clearly: "I can sit here and talk with you about deadlines or I can get back to work finding and fixing problems in this thing that you are currently distracting me from doing." I've had to use that line more than once. But because of that kind of pressure, it is sadly NOT common practice in some environments.

 

[kentgorrell]

When a new procedure is created or even simply when functionality is added to an existing procedure, the moment of release to the end user is always a critical phase
Will I have thoroughly tested the new features?
Will I have introduced anomalies on functions that worked correctly before?
And so on
And so the question is: how do you effectively test a new procedure or a procedure already released and updated on new features?

The simple solution is to share responsibility for testing with your client or the project manager. With the client having responsibilty for the final testing. I don't release a new version, they do. They must have a critical process test plan that they go through to ensure that there will not be a show stopper on release.

Typically the person (project manager, business owner...) who requested the work is responsible for the final testing and release.

While it may be unreasonable to test everything, a formal test plan for critical use cases is a must. Issues that don't stop the show can be handled on a prioritised agile basis.

 

[ebs17]

how do you effectively test a new procedure or a procedure already released and updated on new features?

It has already been said above: Divide and conquer.
You also need organization and programming style.

If you understand your new / changed procedure as a class that fulfills a certain defined task and where there are defined places for data input and output, it is quite clear.

The procedure itself must process everything cleanly and error-free, what arrives as input and what you allow as input. You can imagine and test different inputs: normal values, borderline values, impossible values (text where a number is required), NULL, empty strings, no values at all (forgot to pass parameters).

It helps a lot if the procedure (or form) is self-contained and has no mutual dependencies on other procedures and objects or variables, because you will no longer be able to imitate and test such a "pinball machine".

 

[Pat Hartman]

borderline values

Don't underestimate this type of testing. This is how I accidentally discovered in 1972 that there would be a Y2K crisis in 2000 because
1. most date routines didn't apply all the leap year rules correctly. They didn't go to the "except for divisible by 400" rule so they would determine that 2000 was NOT a leap year when in fact it was a leap year even though 1900 was not a leap year.
2. due to the high cost of disk storage, most dates were stored as two digits and in 2000, 00 would be less than 99 so sorts and compares would break.
Therefore, I NEVER, EVER created an application with a Y2K problem even though I never knew if any of my apps would ever live that long including the one I was designing which was writing mortgages with a 30 year horizon.

 

[DickyP]

I've read the thread with great interest and generally all the advice is good.

However, I would point out the steps you need, all desribed in one way or another above are:

There must be fully described specification of what the changes are supposed to do (an what the must not do)!

There must then be a test plan that checks every aspect of the specification.

This test plan must then be executed in full. (And errors fixed and retested).

If there are users separate from the development environment a full test by selected users must follow.

All steps above must be subject to review and appropriate revision,

It is all a a matter of iteration until complete.

These steps apply whether it is a full radical release or revision,or just two lines of code, and whatever level of automation is involved.

After a career of writing software that was used in commercial and military applications, I still follow all these steps even in access databases that are for my use only. Mind you it now just hand written process in an A5 notebook.

And I still get errors!