IT Employment

General discussion


Application Acceptance Testing Process

By jonah.simpson ·
Hello All!

I'm working for a large government organization with a number of custom built applications that are used domain wide. A lot of these applications are old and very sensitive to any changes in the environment. As well, we have a number 10+ different "standard" images we use (based on job role) * 4 different pc architectures = 40 overall images with some combination of different apps or drivers.

Because of the sheer number of variables, we have a testing department in order to make sure any additional applications or updates do not break any of the other apps. The problem we're having is that we have no explicit guide or procedures to do the testing, so our testing department ends up missing things that they should have easily caught. This negates the usefulness of the testing department, which isn't acceptable.

Can anyone help me with this problem? Specifically we're looking for some kind of process for designing and implementing effective test procedures, but we're interested in any related information as well.


This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Collapse -

Testing is 90% Process and 10% technology

by SkipperUSN In reply to Application Acceptance Te ...

Testing is 90% process/procedure with 10% technology..

You need to establish a process and procedures that must be inforced by management - such someone creates a series of test scripts to prove that things still work (this could be a couple hundred scripts) each must run - the technology would be a way to record these scripts.

So you need to establish a process - and procedures...

Collapse -

Tough part...

by jonah.simpson In reply to Testing is 90% Process an ...

I'm not really looking for a technology to do this automatically, like I said, we have a whole department of people to do this kind of testing...where we're struggling is in their inconsistency.

What I was hoping for is someone that's implemented some of these testing processes and procedures to give me some insight on some key points that they should cover.

Currently our testers (who aren't very technical) are using checklists (ie. Application X opens-check, Email works-check), but their methods for testing this Application Acceptance are pretty weak and don't even cover a fraction of the paths a user could use. So any ideas on how to make that better too would be wonderful.

Collapse -

If you're government did you look at 40CFR

by SkipperUSN In reply to Tough part...

If you are Government did you look at the 40CFR guidelines on establishing testing granted its for the EPA and water - but can be extraplated to Applications (it may help) -

Lets see - Pointe Technology has some very interesting whitepapers on Testing and establishing the procedures.

Remember - Key testing Phases include:
- Package validation testing (when commercial business applications are being used do they integrate with existing systems)

- Unit testing (best accomplished during the development process by developers to validate program logic and to verify that the code is working according to specifications)

- Integration testing (for testing the combinations of individually unit-tested pieces of code as they are linked)

- System testing (consisting of the project team's final test of the system's functionality, performance, and appropriateness and demonstrating that the system meets the original objectives and requirements and that it works within the defined constraints)

- Systems integration testing (addressing integration with existing applications - purchased packages and legacy, internally developed software - as well as effective security, infrastructure, and network support/optimization)

- User acceptance testing (demonstrating that the application meets the original business objectives and satisfies the user and IT environment requirements; must involve end users)

As the development project moves through these events, the approach and focus of testing change. Items may be retested iteratively and multiple times through the approval process. The QA/QC team will utilize a review and sign-off approach at major points in the life cycle. These points include movement of code between development/unit testing into integration testing. When groups of code appear ready to graduate from the integration test into the system test, and then from the system test to user acceptance testing, users alone will not be solely responsible for sign-off. Business users, functional teams, and project management will be involved in the approval at integration test, system test, and user acceptance test completion

Maybe a definition of what we seen as each testing phase was and do:

1. Package validation testing: When commercial applications are in use. The package is evaluated to determine whether a) it is properly configured - b)performs correctly - c) identify any incompatibilities between the software package and the environment in which it will operate.

Results: Completion of this testing event indicates the package operates acceptably in the target environment. This testing is standard practice among organizations that have set up successful testing environments.

2. Unit testing: It has two major objectives: a) to verify that the application software component's code works according to its specifications - b) to validate program logic.

Results: Pinpoints discrepancies between what an application software component does and what it is expected to do.

3. Integration testing: Individually unit-tested pieces of code are tested as they are merged together.

Results: Uncovers errors that cannot be found during unit testing due to the errors occurring in the interactions and interfaces between units.

4. System testing: Independent system's functionality, performance, and appropriateness.
Results: It shows that the system meets the original objectives and requirements and that it works within the defined constraints.

5. System integration testing:Addresses integration of the system as a whole with existing applications, as well as effective security, infrastructure, and network support/optimization.

6. User acceptance testing: Application meets the original business objectives and satisfies user and IT environment requirements.

Results: This test should validate that the system fits into the real-world business environment in which it will be used.

Can really tell you how to do it - but its mostly the establishment of processes - and procedures - What they will be testing for - why they are performing the Integration test - what should be tested - test reviews - test success criteria -

We are just starting to develop one - its going to be interesting ... selling it ... to the developers and business folks ...

Collapse -

Getting closer...

by jonah.simpson In reply to If you're government did ...

Thanks for the reply SkipperUSN!

We're getting closer to what I'm looking for.

I guess out of the methodologies you listed, we're most interested in effectively implementing a combination of System integrations testing and User acceptance testing.

One of the main focuses of our testing is to figure out a non-rigorous but still effective means of testing whether a single desktop image has all the software it needs, that all the software works properly, and that it will play nice with everyone else on the network.

We do a lot of testing but I think this is where we fall down.

Do you (or anybody else) know any effective methods of implementing this kind of testing? The simple checklists we're doing (ie. can send an email, can open a word doc, etc) seem to only be as good as the people checking them, and don't necessarily even cover all the installed applications/configurations...anything we can use to supplement or replace this method which will result in better performance is greatly desired.

Thanks again!

Related Discussions

Related Forums