Unit Testing

Unit testing of internal and external objects in the patch set or application release is conducted in the development environment by the application developers.  Unit testing ensures that the object will execute and desired outputs are produced.  Debugging and verification of output results are performed by the developer.  When unit testing has completed, the patch set can migrate to test.

System Testing

System testing is performed by functional users and key functional users in the test environment.  System testing includes testing of complete processes including upstream and downstream processes as applicable.  System testing may also include integration testing between two or more applications and load testing to verify that the hardware and network infrastructure can support the changes being made.

Software Quality Assurance (SQA) application development life cycle is illustrated in the following diagram:

This process is managed by a product from Quest called STAT.   All Change Service Requests (CSR) are routed through STAT.  STAT is self-documenting.  It will record change requests, track the change service request (CSR) as it moved through the stages, and provides necessary approvals from functional and technical managers before final migration to production.  STAT also provides version control for PeopleSoft internal objects such as pages, components, records, etc. and external objects such as SQRs, COBOL, etc.

Application Review
Application Review, Design Review, and Walkthrough are quality assurance tools.

The Application Review procedure is adapted from an industry accepted structured walkthrough technique described below:

“A structured walk-through is a generic name given to review or “paper tests” conducted with peers, supervisors, etc., to analyze the functional design, detect logic errors, develop test strategy, cross-educate team members, and motivate full team cooperation. The verification is meant to be a non-malicious collaborative procedure for probing and problem detection.  Errors found at this level can easily be an order of magnitude cheaper to fix than at later times in the development.”

An Application Review is conducted during application development. A Design Review is conducted before application development begins.

Design Review

A Design Review is a formal review of the specs and design to ensure that the request will not compromise application or database integrity. A Design Review considers integration processes, process flow, data flow, efficiency, performance, etc.

A Design Review should be conducted whenever complex processes are significantly modified or new functionality is introduced.

Review Procedures
When a newly approved application is defined, or significant modifications to an application are planned, the developer must notify his supervisor to arrange an application review.  Developers should not wait until the entire application is written.  Review schedules should be determined in advance (what will be reviewed and when).  The purpose of these reviews is to raise issues–not to resolve them.

Successful reviews are based on the full preparation and participation of all invited.  It is mandatory that reviewers prepare, attend, and participate when chosen for a review team.  Managers should expect developers to charge time to walkthroughs and walkthrough preparation.  Project schedules must allow for this quality assurance practice.

The typical subset of the modules which make up an application should be included in the review process described in these pages.  Although all application code does not have to be formally reviewed, a second party who is familiar with the files should examine all code that updates the database.

An experienced developer or the Technical Manager should serve as the Review Leader. The Review Leader selects the other team members to serve as the reviewers. The team should include at least one developer with in-depth application-specific and file-specific knowledge.

Walkthrough Procedures for Developers
The developer whose code is being reviewed has the following responsibilities:

1. Select the code to be reviewed (no more than ten programs for a single review) using the following guidelines:

· For small applications, the entire application or module may be selected for review.
· For large applications avoid selecting menus.  Menus are routinely found to be standard.
· Select a subset of the application to be reviewed for a particular walkthrough session.
· Include batch and online processes for review.

1. Schedule the walkthrough.
2. Print out the source code and pages and report samples, and distribute to the Review Team.
3. Secure the reviewers to the application in development.
4. Bring a copy of the Application Development Standards manual to all meetings.
5. Ensure that the meeting room is available and adequately equipped.
6. Notify all participants should meetings be canceled or rescheduled.
7. Review with your manager any additional development work required as a result of the application’s walkthrough.
   • Your Application May Not Be Moved To Test Or Production Without The Consent Of Your Reviewers.
8. The reviewers may require a follow-up walkthrough.  The reviewers shall limit requests for changes to program “bugs” and to violations of the Standards. Issues of design or performance trade-offs shall not be dictated by the reviewers when such issues are otherwise compliant with the Standards, however, the developer should take noted issues into consideration. Reviewers having strong feelings about such issues should work to get the Standards changed.
9. Discuss any suggested changes to Standards with the Chairman of the Application Development Standards Committee.
10. Once all suggested changes have been made to the programs, have the reviewers sign and date the modification form prepared by the Recorder. The form will go to your manager. If reviewers choose to record comments in the “Reasons” section of the form, they must be very specific.  Simple general comments li
    ke “as discussed in the meeting” are not acceptable.

Review Leaders
While the success of the review is the responsibility of each team member, the Review Leader has these additional responsibilities:

1. Guide the tone and pace of the review meetings;
2. Ensure that everyone has an opportunity to contribute;
3. Poll for consensus;
4. Terminate a meeting in case of lack of preparation by or absence of reviewer, length of meeting, tone of the review, etc.

Review Recorder
The Recorder also has obligations beyond being prepared, attending and participating in the review.  These include:

1. Record the findings of the walkthrough committee on the appropriate form;
2. Ensure that the group has reached a definite conclusion by reviewing the issues as recorded;
3. Be able to write notes in “real” time as this may influence the pace of the review;
4. Retain review notes until the application and/or the programs under review have been approved for transfer to Production.

Review Participants
The following list of rules and guidelines applies to all review participants:

1. Be prepared (review materials in advance, bring them to the review with a copy of standards);
2. Be willing to associate;
3. Watch your language;
4. Raise issues and make suggestions;
5. Avoid sidebar discussions;
6. Stick to standards — or get the standard changed;
7. Record all issues in public;
8. Stick to technical issues;
9. Remember education (this is the major long-term benefit of reviews);
10. Do not evaluate the developer;
11. Distribute the report as soon as possible;
12. Let the developer determine when the application is ready for review;
13. Failure to attend or lack of preparation for the review is causes for the review leader to cancel the review meeting.

The review process is a review among peers.
From a Supervisory point of view the objective of these reviews is to:

1. Move quality-control responsibilities to the program developers doing the work;
2. Cross-educate developers so that development activities and progress are observed and understood by all team members;
3. Focus individual creative energies upon the users’ unique application needs rather than upon issues common among users and already addressed by the Standards;
4. Develop a highly-motivated community of application development professionals supporting one another to build integrated yet diverse applications within one consistent environment;
5. Determine whether a newly developed application meets Standards for transfer to production.
   • An Application May Not Be Moved To Training Or Production Without The Consent Of Reviewers.
6. A standards compliance certification form must be signed by reviewers and kept on file with Technical Services.

https://www.bestitdocuments.com/Samples