Standard Development Life Cycle
Standard Procedures
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
| |
 |
Search with Stan
Testing Phase
This is the phase where all the modules relating to each other, will be tested. Full integration
testing. Output from one module will be input to the next. A complete cycle test needs to be
done without failure. That is the goal. All this testing is necessary. Find the problems now,
BEFORE they are found in production.
Save yourself and others the time of having to re-check-out the source and find an available
user for your change to be tested at a future date. The Users are allocated for the project at
this time not in the future.
Along with this goal, other types of testing need to be done.
Scenario Base Testing--try to come up with possible scenarios that will cause problems for the
system, write a script that specifies possible weaknesses and see if system can handle it.
The script used here has, basic information. Scenario, Test data needed, expected results,
actual results, Pass/Fail statement.
This script should be passed on to the users of the system. It should be filled out for each task
found in the AS IS process.
Limits Testing-- put in values and see if they are acceptable in the program, identify
acceptable items and unacceptable items for the program. Things that border on the limits of
acceptable items. Dates, Names, Jan 32 Not acceptable, leap years, 11/30/98, could be
30/11/98 European, see if system catches these possibilities, Checks all of the data values in
the data base.
Once the new system passes all types of scenarios and limits testing, it will be time to
complete the testing with the business users.
Benchmark Values, Have expected results and make sure the expectations are met.
Task based, User testing.
Let the business users execute the process and determine if it does fit their needs. It should be
close to what was discovered in the "AS IS" findings.
Free Play Testing-- Let somebody walk through the test plan. User based testing should be
done by somebody that has little knowledge of how the system works. See if the data entry is
intuitive. Take note of what struggles he or she my have. Does there need to be a change in
that design? This is the time to make it. Not after it is in production.
Sampling-- Use statistics to examine the samples that we have chosen. Does the majority of
our sample work?
Software--Use a program to run scripts, generate simulated transactions that will test
numerous possibilities very quickly without manually having to type in or scan the information.
Build in the testing program to the original software, build the program to have built in testing
(debugging and tracing)
Hardware--Loading the hardware to its limits, test with all users. Can the system handle 5 or
more people at the same time? Make sure the application can handle same processes executing
at the same time
Test Data Base-- used to test the system, how to handle the information, Odd Cases that maybe
a potential error if it occurs in the real world. If errors were found run the same test data
through process again and make sure that enhancement have fixed the problem and also verify
it has not caused another problem. Sarbanes-Oxley also requires saving of test data.
When the testing is complete, the next step is the Implementation Phase.
Benefits of the Testing Phase.
testing. Output from one module will be input to the next. A complete cycle test needs to be
done without failure. That is the goal. All this testing is necessary. Find the problems now,
BEFORE they are found in production.
Save yourself and others the time of having to re-check-out the source and find an available
user for your change to be tested at a future date. The Users are allocated for the project at
this time not in the future.
Along with this goal, other types of testing need to be done.
Scenario Base Testing--try to come up with possible scenarios that will cause problems for the
system, write a script that specifies possible weaknesses and see if system can handle it.
The script used here has, basic information. Scenario, Test data needed, expected results,
actual results, Pass/Fail statement.
This script should be passed on to the users of the system. It should be filled out for each task
found in the AS IS process.
Limits Testing-- put in values and see if they are acceptable in the program, identify
acceptable items and unacceptable items for the program. Things that border on the limits of
acceptable items. Dates, Names, Jan 32 Not acceptable, leap years, 11/30/98, could be
30/11/98 European, see if system catches these possibilities, Checks all of the data values in
the data base.
Once the new system passes all types of scenarios and limits testing, it will be time to
complete the testing with the business users.
Benchmark Values, Have expected results and make sure the expectations are met.
Task based, User testing.
Let the business users execute the process and determine if it does fit their needs. It should be
close to what was discovered in the "AS IS" findings.
Free Play Testing-- Let somebody walk through the test plan. User based testing should be
done by somebody that has little knowledge of how the system works. See if the data entry is
intuitive. Take note of what struggles he or she my have. Does there need to be a change in
that design? This is the time to make it. Not after it is in production.
Sampling-- Use statistics to examine the samples that we have chosen. Does the majority of
our sample work?
Software--Use a program to run scripts, generate simulated transactions that will test
numerous possibilities very quickly without manually having to type in or scan the information.
Build in the testing program to the original software, build the program to have built in testing
(debugging and tracing)
Hardware--Loading the hardware to its limits, test with all users. Can the system handle 5 or
more people at the same time? Make sure the application can handle same processes executing
at the same time
Test Data Base-- used to test the system, how to handle the information, Odd Cases that maybe
a potential error if it occurs in the real world. If errors were found run the same test data
through process again and make sure that enhancement have fixed the problem and also verify
it has not caused another problem. Sarbanes-Oxley also requires saving of test data.
When the testing is complete, the next step is the Implementation Phase.
Benefits of the Testing Phase.
- Validation of developed processes
- Proof of all modules working together
- Involvement of the user community
- Audit trail for auditors
- Builds confidence in the users
- Generates scripts for training