Part 2. Information Technology

Chapter 6. Product Assurance

Section 1. Test, Assurance & Documentation (TAD) Standards and Procedures (Cont. 1)

2.6.1  Test, Assurance & Documentation (TAD) Standards and Procedures (Cont. 1)

2.6.1.6 
Final Integration Test (FIT)

2.6.1.6.3  (03-01-2010)
Managing FIT

  1. Plan and monitor FIT using project plans, budgets, schedules, and resources to report status. Also, as changes occur, modifications to the Development, Integration and Test Environment (DITE) Service Level Agreement (SLA) Package and/or the Enterprise Operations Organizations Level Agreement (OLA) Package may be necessary.

  2. Obtain commitments for internal and external (vendors and contractors) staffing and resources, hardware and software, infrastructure, and program support.

  3. Track resources and report progress on a number of topics, issues, action items, risks, problems, test completion status, etc.

  4. Track issues and create action items for open issues until they have been resolved and the action items closed. Assign action items to specific individuals or organizations to perform tasks necessary to resolve the issues. The automated system used to track FIT issues and action items is available on the FIT web-site by using the following URL: http://tad.web.irs.gov/systbr/fit/index.asp .

2.6.1.6.4  (03-01-2010)
FIT Common Processes

  1. FIT is to be conducted in accordance with the processes outlined in the appropriate life cycle methodology and in all related IRS handbooks.

  2. This section outlines common processes to be incorporated into each FIT project as well as ongoing activities. The specific implementation of these processes are to be reflected in a FIT Plan for each project.

2.6.1.6.4.1  (03-01-2010)
FIT Data Management

  1. FIT requires a production-like environment where data is synchronized across all of the system/platforms.

  2. The use of files copied from production systems, which reflect true taxpayer account data, is often a necessity to accomplish the goals of FIT. The constraints which create this condition are as follows:

    • The design of the current production environment is such that data is persistently stored in many of the application systems. Additionally, information that can identify a taxpayer is deeply embedded into each of these systems

    • Release and Configuration Management (CM) is structured in a way that developers can release updated software to the production environment each business day. Any piece of code released to the production environment may permanently affect the condition of data, including negative effects. In some cases, programs are transmitted that update data elements to inappropriate values. When this situation occurs, utility programs are used to correct the situation

  3. When it is necessary to use copies of production data as the baseline for a FIT environment the following occurs:

    • Apply for appropriate security approval

    • Create and maintain a Security Plan documenting all of the special safeguards used to protect the sensitive data

    • Prepare a high level data capture plan that includes a detailed list of exact files to be captured

    • Coordinate with production sites early

      Note:

      Refer to IRM 10.8.1 Information Technology (IT) Security, Policy and Guidance and IRM 10.8.8 Information Technology (IT) Security, Live Data (LD) Protection, for procedures on the use and approval process for the use of live data.

2.6.1.6.4.2  (03-01-2010)
Validate Test Data

  1. Validate that the test data produces the expected results for running the planned FIT.

    Note:

    This activity could take place in conjunction with, or immediately following, the Assess and Verify Test Environment activity.

  2. Replicate production processing. With help of operations support personnel, ensure the test environment replicates production processing to the extent needed for validating the data.

  3. Load the FIT environment platforms with test data. The test data would normally include one full weekend update followed by one day of daily processing.

  4. Perform the validation test, which consists of a partial run simulating the production cycle. The successful execution of processing indicates the required test data was loaded properly on the FIT platforms and meets test case execution requirements.

2.6.1.6.4.3  (03-01-2010)
Assess and Verify Test Environment

  1. Use a set of verification tests to ensure the FIT environment hardware, database management systems, other system-level software, and intra-suite and inter-suite communications are present and functioning. Together, the verification tests demonstrate each of the systems within a test suite permits the application software to run and that data can be exchanged between and within the test suites.

  2. Review the FIT Plan, FIT Environment Requirements, DITE SLA, EOps OLA, and Support requirements. Ensure the test environment can support integration testing of each test item. Review the DITE SLA and EOps OLA to ensure service levels are met and products and services are obtained. Audit the test environment to make sure it contains what is needed. This includes assessing the readiness of the equipment (e.g., sufficient tapes and disk space), making sure the latest versions of system software have been installed, and ensuring operational staff has been identified and is in place.

  3. Perform verification runs that include acceptance testing of any test tools. Changes to a test tool after it has been used will require review of previous test results obtained through use of that tool and may require retesting.

  4. Identify and correct, if possible, any discrepancies between what is actually loaded into the test environment versus the project/system documentation received from the software supplier.

2.6.1.6.4.4  (03-01-2010)
FIT Test Readiness Review

  1. Conduct a formal Test Readiness Review (TRR) to determine whether to proceed to the Test Execution Phase of FIT.

  2. See IRM 2.6.1.4.1.6., Test Readiness Review (TRR) for more information.

2.6.1.6.4.5  (03-01-2010)
Monitor Test Performance

  1. Monitor test performance using appropriate FIT planning and results data and collect information to support test metrics.

  2. Analyze the test planning and test results data. Use the test organization's Quality Management Plan, if available, to provide guidelines for monitoring the following:

    • Test Resources - Ensure analyst, equipment, data, training, field support and vendor support are available when needed. Verify training plans to ensure testers will be trained

    • Test Schedule - Monitor, maintain, and optimize the test schedule. Monitor the project's status to ensure, for example, the turnover of test items from a SAT sub-phase (or from the software suppliers) to FIT is on schedule

    • Test Environment - Monitor the DITE and EOps for supporting the FIT

    • Test Results - After each FIT is completed, hold an informal meeting with the project managers and software suppliers to review problems and unusual events encountered by the test team. This meeting allows feedback to supplier's engineering and development personnel for correcting any problems encountered. If the test reveals problems that are unlikely to be resolved in a timely manner, it may be necessary to document the project's or system's deviation from requirements and obtain a waiver. Also, some issues revealed during the FIT may be added and tracked in the FIT Action Items depository for future FIT testing

2.6.1.6.4.6  (03-01-2010)
FIT Problem Reporting

  1. Problem reporting procedures provide the functionality to ensure that a problem is properly identified, documented, prioritized, corrected, and tracked from occurrence to resolution.

    • As testers identify problems with applications, systems documentation, hardware, system software, and telecommunications or other infrastructure, these problems are reported and monitored for resolution

    • Use the Information Technology Asset Management System (ITAMS) web-site to open, update, and monitor problem tickets

2.6.1.6.4.7  (03-01-2010)
Collect Lessons Learned

  1. Collect and record the information on lessons learned to be used in improving FIT processes. This activity is on-going and the information can be accessed via the FIT web-site by using the following URL: http://tad.web.irs.gov/fit/index.asp .

2.6.1.6.5  (03-01-2010)
Plan and Prepare for FIT

  1. Perform test planning and document the plan in a detailed FIT Plan for the release to be tested. A FIT Plan describes the following:

    • Release to be tested

    • Scope of the test

    • Resources required to perform the test

    • Test phases and test activities to be performed

    A FIT Plan also describes the roles and responsibilities assigned to each of the groups participating in the test.

  2. Produce a FIT schedule consistent with the detailed planning performed during FIT. Use the current IRS standard software application for project planning to prepare the Work Breakdown Schedule (WBS).

2.6.1.6.5.1  (03-01-2010)
Determine FIT Requirements

  1. Verify the present state of the application software to be tested and perform necessary test planning and preparation activities.

  2. Review UWR's and other project documents that define the user and operational requirements for the application (within the projects/systems) to be tested during FIT.

  3. Review design documentation from the software suppliers (or others) that describes the new application to be tested or the software changes that require FIT.

  4. Perform test planning and document it in a detailed FIT Plan.

  5. Generate the end-to-end test threads and scenarios for the planned FIT.

  6. Construct the specific test cases for conducting FIT.

  7. Identify, generate and capture the test data for conducting FIT and establish the necessary test data files for inclusion in the FIT test data repository.

  8. Validate the data capture from production processing produces the expected results for running the planned FIT.

  9. Assess and verify that the test environment is sufficient to support FIT.

  10. Assess the risks associated with the readiness of the applications (within the projects/systems) to be tested, the test environment, and the test teams.

  11. Verify the content of the software programs transmitted to FIT. Create a formal test baseline to be used in conducting FIT.

  12. Conduct a formal TRR to assess the readiness of the test team to begin FIT. A Go/No-Go decision whether to proceed to the Test Execution Phase of FIT is made based on the results of the TRR.

2.6.1.6.5.2  (03-01-2010)
Developing a FIT Plan

  1. Summarize the projects/systems to be tested. This includes the following information:

    • Nature of each project/system (and associated applications)

    • Software change to be included in the test

    • Supplier organization

    • User organization

    • Associated hardware and software documentation

    • A description of the overall release to be tested during FIT

    • Other appropriate introductory material for inclusion into a FIT Plan

  2. Define the scope of the FIT. This includes the following:

    • Test standards

    • Requirements traceability

    • Products to be tested

    • Test interfaces

    • Test constraints

    • General acceptance criteria

  3. Specify the required test resources. This includes personnel, infrastructure, and any special test support items (stimulators/load generators, automated and manual data collection systems, interfaces to production systems and other equipment and software).

  4. Review the planned FIT environment and test tools. This includes the creation or update of a DITE SLA or EOps OLA. These agreements enables the DITE and EOps to build the appropriate test environment:

    • Verify the readiness of the planned configuration for DITE and EOps to support the required FIT

    • Review test tools, plans for simulators, and plans for production equipment

    • Review the automation test tools for their applicability to the current level of FIT

    • Note any discrepancies concerning equipment, communications, tools, procedures, and/or other test environment components in DITE and EOps suitability notes

  5. Define the detailed FIT activities. This includes the test team responsibilities and other support requirements needed to successfully conduct FIT.

  6. Define the schedule of the FIT phases. This schedule details the time-line for the specific test activities occurring during each phase. Organize this information into a detailed schedule of FIT activities showing start times, duration, milestones, dependencies, etc. Update the FIT schedule to include this detailed testing information.

  7. Identify the procedures to be used for reporting problems during each phase of FIT. Use the standard IRS problem reporting tool/system, which is ITAMS. Describe the procedures for the standard IRS tool/system to be used for problem reporting in the FIT Plan.

  8. Develop FIT Environment Requirements. The FIT Environment Requirements defines the following information:

    • FIT environment and its components

    • Activities and tasks to implement in the DITE and EOps

    • Required conditions of the equipment and system software

    The FIT Environment Requirements may be a separate document or incorporated as an attachment to a FIT Plan.

  9. Optimize the test schedule. To optimize the FIT schedule, identify critical schedule dependencies, for example, the availability of external interfaces needed for testing.

  10. Prepare cover memorandum for transmitting a FIT Plan and the FIT Environment Requirements. Include an appropriate sign-off by FIT management.

2.6.1.6.5.3  (03-01-2010)
Generate and Maintain Threads and Scenarios

  1. Develop or update the thread portion of the FIT Test Case Database. Link threads, scenarios, and test cases in the database. Use sequential tracking numbers to identify threads in the database. Use a number and title to identify each test scenario associated with a thread.

  2. Review design documentation from the software suppliers (or others) that describes the new applications to be tested or the software changes that require FIT. Assess the adequacy of the documents for supporting FIT.

  3. The primary documents to be reviewed are:

    • Functional Specification Packages (FSPs), or equivalent functional design documents, for software supplied by IRS modernization projects

    • Programming Requirements Packages (PRPs), or equivalent requirement documents, for software supplied by IRS modernization projects

    • Computer Program Books (CPBs) to include Computer Operator Handbooks (COHs), or equivalent computer operations documents, defining the Job Control Language (JCL), Executive Control Language (ECL), record layouts, etc.

  4. Perform the review of the software documentation at a much higher level than the corresponding review conducted during SAT as follows:

    • Review infrastructure requirements and related documents to understand how these will affect FIT

    • Use these review to understand how the new system or change impacts the end-to-end thread definition

    • Use the knowledge gained during this documentation review to prepare for the remaining FIT planning and preparation activities

2.6.1.6.5.3.1  (03-01-2010)
Thread Development

  1. Write test threads which reflect the data flow through the IRS production enterprise. Construct each thread to enable the result of the production system to be traced back to its originating event using the following steps:

    • Identifying each Ending Point for a system

    • Review the system schematics to identify each unique Starting Point for each identified Ending Point

    Whenever the path varies between the Ending Point and the Starting Point, the path is a thread.

  2. Identify the expected result as the Ending Point of the thread using the following list:

    • Taxpayer (TP) Account Updated

    • Data to Regional Finance Center

    • Refund

    • Notice

    • Letter

    • Data to Social Security Administration (SSA)

    • Data to Census Bureau

    • Audit Information Management System (AIMS) Opening

    • Label

    • Transcript

    • Information to Taxpayer

    • Information to IRS Employees

    • Information to Authorized Third Party

    • IRS Trading Partners

  3. Identify the test trigger as the Starting Point of the thread using the following list:

    • Individual Master File (IMF) Tax Return/Form

    • IMF Payment

    • Business Master File (BMF) Tax Return/Form

    • BMF Payment

    • TP Request

    • TP Inquiry (Web)

    • TP Inquiry (Telephone)

    • IRS Employees

      Note:

      Below are three examples of taxpayer address changes on the National Account Profile (NAP) database. Even though the result is the same, there are three threads because of the different way the IRS receives the initial data:

    • IMF Tax Form-ISRP-GMF-Mission Support-CADE-IMF-NAP-TP Account Updated

    • IMF Tax Form-EMS-ELF-GMF-Mission Support-CADE-MIF-NAP-TP Account Updated

    • TP Request (Address Change)- IDRS-EOD-GMF-Mission Support-CADE-IMF-NAP-TP Account Updated

  4. Any path through a single system is part of the systems design. Therefore, no FIT threads consists of only one IRS system.

  5. Develop threads with consistent Starting Points.

    Note:

    If a taxpayer files an IMF tax return through ISRP, the starting point is the IMF tax return, not the taxpayer or ISRP. Use professional language to develop threads.

  6. Develop threads with consistent Ending Points. Thread Ending Points such as Master File, MCC and TP Account Update are available as options in the Test Case Database (TCDB). However TP Accounts Update is the correct value in this case. The TIF (ITIF or BTIF) is a valid Ending Point only if it truly represents a business process. Threads ending at Files are valid only if the thread represents a business process. However, there are exceptions to this and the exceptions are determined on a case-by-case basis.

    Note:

    Some exceptions include files to SSA and the Census Bureau.

  7. Use appropriate IBM file notations. Some existing threads have file names as 460–02–11, while other have fully qualified file names such as the file name notation PDIPW.i46002##F011.TCCCCCC. Use file names notations as 460–02–11 for all new threads and for any existing threads that are changing. Use a fully qualified file name as PDIPW.I46002##F011##.TCCCCCC in the test case results.

  8. Indicate each FTP, EFTU, NDM and RI Copy in the threads. Identify the System Name as File TRANSFER and the Run ID as the transfer type. (Example: FTP, NDM, AFT/FTP, etc.).

  9. Identify the UNISYS system in a thread as UNISYS only. It is not necessary to indicate the UNISYS system type. (Example: UNISYS 6800 or UNISYS 7802). Remove the UNISYS system type from existing threads using that identifier.

  10. Examples of other valid system names include Mission support, IMF Inputs and IMF Account Settlement. Generalize system names are also acceptable.

  11. Refer to Test Guide documents or analyst notes for more information about each thread. These documents should explain run IDs as ECC on EMS and pre-ECL for File Transfer Protocol (FTP).

2.6.1.6.5.3.2  (03-01-2010)
Scenario Development

  1. Write the test scenarios and load them into the FIT Test Case database linking them to the corresponding thread. Scenario titles logically associate the scenario with its objectives and typically identify both the test input and the test output.

  2. Make scenarios narrative descriptions of the thread. Clearly state the following information in the scenario purpose:

    • Specific trigger

    • Input System

    • Specific result (and location)

    • Preconditions

    • Verification method.

  3. Input the verification method in the scenario purpose when there is only one way to perform the verification. For example, if using command code BMFOLT as the only way to verify a particular scenario, then include that information in the scenario purpose.

  4. Listed below are some scenario examples:

    • Incomplete: the NAP SSN VSAM file is updated with a more current address for a taxpayer

    • Complete: Update the entity data (address) on the NAP SSN VSAM file with an address change from the IMF 1040 tax form, via ISRP. Verify the address changes using CC INOLET

  5. All scenarios should answer the following four questions:

    1. What is the specific trigger or where does this business process start?

    2. What is the input system?

    3. What is the specific result?

    4. What are the preconditions, if any?

  6. Make the Starting and Ending Points of the scenario more specific forms of the thread Starting and Ending Points. For example, if BMF tax form is the thread starting point, then make the scenario starting point more specific (i.e., Form 941).

  7. Use the estimated duration field for all scenarios. Set this field equal to a best estimate of the number of days it will take to complete execution of the scenario from the trigger initiation day to the day output verification is possible. For example, it is possible to test electronic submission acknowledgements in one day, but the credit transfer process requires three full cycles to complete.

    Note:

    This is an estimate.

  8. Create one scenario per form for a thread that involves a test where each return type uses a different record layout. If the record layout is the same for all form types, one scenario can cover that thread.

  9. Use the convention Form XXX, not XXX when referencing a form in the scenario Starting Point, scenario Ending Point and scenario Title/Purpose. For example, use Form 1040EZ not 1040EZ.

2.6.1.6.5.4  (03-01-2010)
Construct FIT Test Case

  1. Construct the specific test cases for FIT. A test case identifies the detailed data that satisfies the conditions of a specific test definition/scenario.

  2. Each FIT case consists of the following information:

    • Test definition information

    • Thread information

    • Data necessary for the test

    • Execution results

    • Review information

  3. Test cases are maintained in the Test Case Database. The FIT test cases will contain some or all of the following information:

    • Name or projects/systems (and associated applications) or software changes applicable to the test case

    • Title of test and test case identifier, together with any other appropriate test identification information (e.g., associated UWR number, FSP process number, etc.)

    • Test Description

    • Type and location of test input data (e.g., file, report, screen, command code, etc.)

    • Specification of the test procedure

    • Tax processing definition data (e.g., Tax Identification Numbers (TINs), Tax Period, Master File Tax (MFT) code, and Name Control (NCTRL:) identifiers);

    • Description of test case results

    • Identification of the test acceptance (for completion) criteria by which the test team will measure the acceptance of the test, (e.g., when the runs included in a thread process successfully and terminate normally)

2.6.1.6.5.5  (03-01-2010)
Identify and Create FIT Data

  1. Create test data for executing each test case.

  2. Record the location of the test data for the respective test cases in the FIT Test Case Database.

2.6.1.6.6  (03-01-2010)
Perform Planned FIT

  1. Conduct FIT in the test environment/facilities specified in the FIT Plan. After each test session, collect the test materials and proof of results.

  2. Document and control access to the test environment. Control test documentation and data. Maintain a master set of the red-lined test documentation and data. Respond to unplanned events that involve changes to the test environment in accordance with the CM procedures for the FIT environment. Make changes to the test item outside the test environment in accordance with CM.

  3. Execute each test according to the test procedures within each test case. Include the following information in the test procedures:

    • Descriptions of how to set up the test

    • Sequence of tests

    • Descriptions of what is to be tested

    • Conditions needed for a specific test

    • Expected results of the test

  4. Ensure the test procedures are executed properly.

  5. Be prepared to respond to unplanned events, work-arounds, other memorandum program changes, or deviations from the published or red-lined test procedures. Document any of these deviations.

  6. Determine the success of each test by comparing the test case to the actual results. Review the test results against the FIT Plan and the acceptance criteria defined in the test cases to ensure the test activities were completed successfully. Document discrepancies and create Problem Ticket Reports. The test team uses the results of this process to prepare the End of Test Status Report (EOTSR).

  7. A FIT team will review test results data and determine what data to retain and what data to eliminate based on the requirements defined in the FIT Plan.

  8. Schedule test reruns, when necessary. This is performed whenever there is any doubt that proper conditions were not established or test procedures were improperly executed. Also, rerun tests for resolved defects.

  9. Create a test log to document deficiencies found in test cases and test data, unplanned events, and results. Issue a Problem Ticket as applicable.

  10. Use the test log to build a performance history for each test and to record questions or action items. Document the following information in the test log:

    • Instances in which the test conditions, assumptions, or test environment are not specified

    • Hardware, software, or network changes that may occur

    • Any other test deficiencies

    • Unplanned events

    • Deviations from the written test cases

    Track the execution of all tests in a test log for each test run. For example, if a test is run four times before the correct results are achieved, there will be four entries in the test log for the test. Use the test log to help reconstruct events accurately during post-test analysis. As problems are found and corrected, use the Change Request (CR)/Problem Report Log and the test log to provide testing statistics.

2.6.1.6.7  (03-01-2010)
FIT Test completion and Closeout Activities

  1. Perform the following closeout activities at the end of a FIT project:

    • Conduct FIT closeout meeting

    • Prepare EOTSR

2.6.1.6.7.1  (03-01-2010)
Conduct FIT Post-Implementation Review (PIR)

  1. Conduct a FIT Post-Implementation Review (PIR) meeting to assess the test completion status and success factors. This meeting also helps to facilitate the flow of information to be included in the EOTSR.

  2. Develop an agenda and checklist for the planned FIT PIR meeting. The checklist identifies the items to be reviewed during the meeting.

  3. Perform the following PIR preparation activities:

    • Distribute test results, test logs, and other materials for review by the meeting participants

    • Assign responsibilities for presenting testing materials at the meeting

    • Assign responsibilities for collecting meeting results

    • Perform other preparation activities as necessary to enable efficient conduct of the FIT PIR meeting

  4. Conduct the a FIT PIR meeting in accordance with the agenda/checklist developed prior to the meeting. Indicate which requirements were verified based on the requirements traceability matrices within each test case. During the meeting, any problems encountered by a FIT team are reviewed for the purpose of identifying problems/changes missed during test execution. Other problems are collected and documented as lessons leaned for future FIT.

  5. The following FIT closeout activities are also performed:

    • Verifying the contents of the project folder for completeness and accuracy

    • Ensuring obsolete test data and other test materials are disposed of in accordance with procedures

    • Ensuring all final outputs are marked for retention and stored in accordance with current procedures

2.6.1.6.7.2  (03-01-2010)
Prepare FIT EOTSR

  1. The FIT team collaborates to write a FIT EOTSR, which is then distributed for review.

  2. The FIT team collects and reviews the following data used as input to the EOTSR:

    • Test results

    • Test logs

    • Change request logs

    • Results from the FIT closeout meeting

    • Lessons learned information

  3. Prepare a cover memorandum for transmitting the EOTSR with the appropriate sign-off by FIT management (i.e., Program/Project Manager).

  4. Issue the EOTSR after the analysis of the test results is complete for the production enterprise undergoing FIT. If there is a need to summarize the results before the conclusion of FIT, an Executive Summary will be prepared as the initial version and then an EOTSR will be prepared after the completion of FIT.

  5. Include the following information in the EOTSR:

    • Summary of the over all test effort

    • Tests performed

    • Test results

    • Problems encountered

    • Problem severity

    • Solutions applied to resolve problems

    Clearly distinguish between observations and inferences in the EOTSR.

2.6.1.7  (03-01-2010)
TAD Interface Database

  1. The TAD Interface Database assists in tracking the transfer and coordination of the following:

    • Data required to perform interface testing

    • Interface media by creating formal agreements within and between the TAD branches

    .

  2. This web-based application is a menu-driven system. Access to the database is restricted to only TAD employees.

  3. The database and users manual may be accessed via the TAD web-site using the following link http://tad.web.irs.gov/InterfaceDB60/inMain.asp .

  4. The baseline of an Interface Database Agreement occurs once the sender and receiver have entered all necessary information in the TAD Interface Database.

  5. The interface files are used to conduct functional (black box) testing.

2.6.1.7.1  (03-01-2010)
Guidelines

  1. All interfaces within and between testing branches are documented using the TAD Interface Database. All files listed in the SAT Plan as an interface are included in the Interface Database. Files transferred during Systemic Processing are exempt.

    • An Interface Database Agreement between the receiver and sender is needed before any entries are made to the database. The agreement may be verbal and can be reached via phone, E-mail, or in a meeting

    • The receiver is the person receiving the file(s) or making a file(s) request, and initiates the Interface Database Agreement

    • The sender is the person providing the file(s) requested, and responds to the agreement

    • A determination is made as to what type(s) of data is needed, including:

      • When it is required

      • Degree or complexity of the data

      • What data can be provided

      • Any special work that might need to be accomplished.

    • Interface Database Agreement(s) are updated as needed and closed at the completion of the interface run

2.6.1.8  (03-01-2010)
TAD Test Automation Procedures

  1. The Test Automation Section is available to assist testers in developing a strategy for integration of software automation tools into their test plans and to provide TAD specific software training. Customized software can then be developed and implemented to:

    • Create new test data

    • Manipulate or reformat existing test data, including sanitization of live data

    • Automate the verification of output data

    • Enhance manual output review processes

    • Document test cases

    • Create reports, graphs, and spreadsheets for status reporting purposes

    • Store, backup, and archive valuable information in databases

  2. The use of automation software can lead to:

    • Cost and time savings

    • Improved use of resources

    • More productive and effective testing

    • Faster response to last-minute changes in data or requirements

2.6.1.8.1  (03-01-2010)
Determining Applicable Uses of Automation Software

  1. All TAD employees are encouraged to:

    • Review their manual processes and identify repetitive, redundant, and/or time-consuming activities

    • View the automation presentation on DocIT at http://docit.web.irs.gov/docit/drl/objectId/0900756280136400

    • Review the lists of existing utilities that have already been developed for the IBM, UNISYS mainframes and Tier II and Tier III platforms. These lists may provide ideas for new applications, and are available at http://tad.web.irs.gov/inmabr/sasc/documentation/desc_files.htm

    • Contact the Test Automation Section to entertain automation for their area

    • Submit a formal request for the automation software, if needed

2.6.1.8.2  (03-01-2010)
Request for Computer Services (RCS)

  1. A Request for Computer Services (RCS) is the vehicle by which automation software and software training is formally requested. Currently a memorandum is required, and may be submitted in either printed or electronic format.

  2. The requesting analyst gathers all record, file, and processing specifications that are needed for the development of an appropriate automation program.

  3. The analyst contacts the Test Automation Section to assist in the submission of the request.

  4. The following steps below are implemented once the request has been coordinated with the Test Automation Section.

    • Prepare the RCS memorandum and deliver it to his/her manger for approval

    • The requestor's manager submits the memo to the Chief, SAT Automation Section

    • A developer on the appropriate team (IBM, PC, or UNISYS) is assigned to work the request

  5. For a template of the RCS memorandum and basic instruction on completing the request, go to http://tad.web.irs.gov/inmabr/sasc/documentation/sasc_docs.htm .

  6. A printable tri-fold desk guide is also available in DocIT at http://docit.web.irs.gov/docit/drl/objectId/090075628013695b . This guide includes a current list of the SAT Automation staff.

2.6.1.8.3  (03-01-2010)
TAD Status Reporting System (TSRS)

  1. The TAD Status Reporting System is a web site developed to aggregate all project status reports filed within the Test Assurance & Documentation Division.

  2. Status reports for all TAD projects should be submitted through this web site, which captures data on test cases such as the number of test cases completed, waived, or failed.

  3. The Status Reporting System web site may be accessed at http://tad.web.irs.gov/TSRS.

  4. No 5081 is required to gain access to the site; Section Chiefs within TAD can grant access to their section members directly by visiting the Section Management page at http://tad.web.irs.gov/TSRS/ManageSection.aspx .

  5. The site has identified two primary roles for users, that of Analyst and Section Chief. The Analyst workflow involves the tracking of individual projects and test cases while the Section Chief role consists of managing the section’s projects through reports and managing section members and assignments.

  6. A user manual is available online within the TSRS web site at http://tad.web.irs.gov/TSRS/tsrs%20user%20guide.pdf. .

  7. The TSRS web site takes advantage of some of the latest technologies to provide modern automation services to TAD through Microsoft Visual Basic 2005 and .NET 2.0, while the data is stored in a Microsoft SQL Server database.

  8. In keeping with the Modernization effort, focus was placed on developing a secure web site that can meet the present and future needs of the IRS. To this end the site makes full use of Windows Integrated Authentication and does not require any User IDs or Passwords, as the user’s Windows login is used to enable a single sign-on environment.

2.6.1.9  (03-01-2010)
Enterprise File Transfer Utility (EFTU)

  1. The Enterprise File Transfer Utility (EFTU) is a modernized replacement for the Enterprise File Network Server (EFNS). The initial development was a joint task between the IRS and Prime Systems Integration Contractor (PRIME). Currently, the DITE is responsible for administering the EFTU Control Servers and the IRS is responsible for the continual development of the utility/application.

  2. EFTU is a utility that moves data in a controlled, structured, and secured environment through the organization.

  3. EFTU expands functionality that was initially provided in its predecessor system (EFNS) which includes:

    • Improved authentication and authorization

    • Centralized control and logging of transfer activities;

    • Greater automation for routine transfers

    • Increased monitoring and recover features

    • Increased security features

    • Detailed audit trails for log files of all transfer attempts, within the IRS internal network

2.6.1.9.1  (03-01-2010)
Scope

  1. The purpose of EFTU in the Test Environment is to manage and coordinate the transfer of data in the TAD Division for SAT and FIT. EFTU transfers data files for TAD approved projects on any IRS internal server (e.g., UNIX, Windows, IBM mainframe and UNISYS mainframe). For the majority of data transfers, the EFTU test environment mirrors the production environment.

2.6.1.9.1.1  (03-01-2010)
Basis

  1. With increased security and the disabling of FTP on many servers, projects are advised to use EFTU because EFTU is the viable option to FTP. It automates the transfer process in a secured environment by keeping an audit log and audit trail of every file transfer.

  2. For an overview of the EFTU process, go to the TAD Web Site http://tad.web.irs.gov/, then select the EFTU link http://tad.web.irs.gov/eftu/Default.htm , where the resources for EFTU are located.

2.6.1.9.1.2  (03-01-2010)
Process

  1. The EFTU Overview can be found on the TAD web-site referenced above. Projects need to view this presentation to determine if they are a candidate for EFTU.

  2. Projects need to indicate within their test plans if they will be using EFTU.

  3. If projects plan to use EFTU, provide the following in the test plan:

    • Estimated number of files to be transferred

    • Number of files on the mainframe

    • Number of files on UNIX/Windows

    • Type of FTP software used to transfer the data (e.g., FTP, SSH, Tectia, etc.)

    • Projected start dates of transfers

    • Projected test end date

    • Project Point of Contact (POC)

  4. If a project does not indicate they will be using EFTU in their test plan and submits the EFTU forms at a later date, priorities will be determined by the Section Chief/Project Manager.

2.6.1.9.1.3  (03-01-2010)
EFTU Forms

  1. There are three EFTU forms that need to be submitted when requesting file transfers (Form 13605, Form 12038, and Form 12038-A).

    • Form 13605 – This form is required when a project needs a server registered with EFTU. If the project is using a mainframe, the form must be submitted 30 days prior to the transfer start date. If the project is using a UNIX or Windows server, the form must be submitted 14 days prior to transfer start date. (For an example of Form 13605 See Exhibit 2.6.1-19.)

    • Form 12038/12038A - Both forms must be submitted 14 days prior (for 20 files or less. Additional time will be needed for large group of files.) to transfer start date. The Date Required field must be as accurate as possible. A draft copy should be submitted to the EFTU team to ensure accuracy of the information before the form is signed. (For an example of forms See Exhibit 2.6.1-20. and See Exhibit 2.6.1-21.)

  2. All forms must be submitted electronically. Forms 13605 and 12038 must include a digital signature.

  3. For a copy of the forms go to the TAD Web Site http://tad.web.irs.gov/, perform the following steps:

    • Select the EFTU link http://tad.web.irs.gov/eftu/Default.htm , where the resources for EFTU are located

    • Select the EFTU Documents link

    • Select the Guides and Forms link

  4. To ensure all delivery rules and tasks are setup properly for the transfer, EFTU may need to validate the setup by performing a test/validation transfer. This test/validation transfer is highly recommended and is normally done 2-3 days prior to the actual transfer start date.

  5. Within five business days following receipt of all signed forms, a workload decision will be provided identifying whether the project dates can be met.

2.6.1.10  (11-05-2010)
TAD Systemic Processing

  1. Systemic Processing (SP) is a cycle driven testing environment originally designed to assist with Integrated Data Retrieval System (IDRS) testing. Numerous TAD test teams participate in Systemic Processing. Any project that accesses the Taxpayer Information File (TIF) or Corporate Files On-Line (CFOL) may benefit by participating in Systemic Processing. Since many test teams use SP test data, each participating team/project is assigned one or more TIN ranges from the Systemic Processing TIN Assignment List, managed by the SP team, to prevent multiple tests on the same test accounts by more than one team/project.

  2. Systemic Processing attempts to mirror production processing as much as possible. Therefore, test cases/data are processed through one or more "cycles" , with data flowing from input systems such as ISRP and GMF, IDRS command codes, or test datasets created as inputs for Master file processing. There is a dedicated SP Master File, and while the Master File programs aren't truly tested as part of SP, the programs are executed to process the SP transactions through the necessary Master File runs. Master File output is then used to update the various databases (TIF, AIMS, ACS, etc.).

  3. A Systemic Processing schedule is used to keep all participants aware of due dates for test data, availability of IDRS command code input, and expected program processing dates. For more information on Systemic Processing, refer to the Systemic Processing link on the TAD web page http://tad.web.irs.gov/itcc0798/SYS_PROC/sp_home.htm .

2.6.1.11  (03-01-2010)
Source Code and Documentation Control (SCDC) Branch

  1. Source Code and Documentation Control (SCDC) Branch provides independent source code and documentation control of the IRS's critical tax and administrative systems. This is accomplished by:

    • Using established configuration control procedures to ensure that only approved source code and documentation baselines are promoted to the test and production environments

    • Building and promoting transmittals to the test and production environments.

    • Providing configuration control tools with applicable training to the development and test communities

2.6.1.11.1  (03-01-2010)
Software Quality Assurance Automated Configuration Management Tool - UNISYS Platform

  1. The SCDC Branch serves as an independent version control entity for all of the source code running on the UNISYS platform. SCDC serves as a control center for the movement of transmittals from the development environment to the SAT, FIT, Martinsburg Application Development Systems (MADS) production files, and the Submission Processing Center (SPC) for production processing.

  2. The use of the Software Quality Assurance (SQuA) Automated Configuration Management (ACM) tool ensures that controlled production libraries contain the official version, or baseline, of all existing IRS UNISYS application source code. SQuA facilitates easy access to the baseline version of the source code as a starting point for the development activity. It significantly reduces the effort required to transmit software to the production sites after development and testing. It also ensures that modified source elements do not move into production libraries until the appropriate implementation date.

  3. The implementation of the SQuA tool closely aligns the IRS with industry standards and CM procedures. It also meets some of the Capability Maturity Model (CMM) Level II requirements for the CM Key Process Area.

  4. SQuA ACM tool provides the following capabilities:

    • Ensures that official software and related components are stored in a secure environment

    • Restriction and control mechanisms are built in to assure that only official and production based source code is checked out for modification.

    • Establishes ownership of source code components to a responsible section and employee

    • Standardizes the compilation, linking, and collection process of elements

    • Compiles statistical information related to transmittal activities in a report format; the report is used by SCDC technicians and management

  5. The SQuA Task Processing:

    • SCDC personnel monitors the SQuA system daily for transmittals authorized by development managers. When authorized tasks are identified, SCDC technicians perform manual checks to verify that tasks are assembled correctly and completely. Many of these may be sent to TAD, SAT, FIT, MADS production files or sent to SPCs for production processing

    • Tasks that are classified as ready for production are submitted to the SCDC management for final authorization and transmission to SPCs and to the MADS production environment

      Note:

      Procedures for using SQuA (User's Guide), can be found on the TAD web-site by using the following URL: http://tad.web.irs.gov/scdcbr/t1sc/SQuA.htm .

2.6.1.11.1.1  (03-01-2010)
Roles and Responsibilities

  1. Developer roles and responsibilities:

    • Create a new task

    • Add or update modified elements

    • Add or update production schedule

    • Add or update transmittal memorandum

  2. Development Manager roles and responsibilities:

    • Review and authorize task to be promoted to SAT or production

  3. SCDC personnel roles and responsibilities:

    • Accept task for review

    • Review the transmittal memo for reason/authority, project and run number, operational impact, implementation dates

    • Promote to SAT and FIT environments

    • Promote to the Common Used Non-Production Libraries (CUNPL)

    • Prepare task for production

  4. SCDC Manager roles and responsibilities:

    • Review the task status, transmittal memorandum and implementation schedule

    • Approve task for Production implementation

2.6.1.11.1.2  (07-24-2006)
SQuA Sensitive Package Processing

  1. Sensitive code is transmitted in packages that have restricted access.

  2. Sensitive packages are processed the same as regular SQuA packages except access is restricted to specific persons within TAD.

2.6.1.11.2  (11-05-2010)
ENDEVOR Automated Configuration Management Tool - IBM

  1. The ENDEVOR ACM tool provides a robust and controlled environment for test, development, and storage of software elements and documentation. It controls systems that have developers simultaneously working on multiple versions of the same source code element. Control is exercised by designating code that is in production libraries as the official version and level.

  2. ENDEVOR ACM tool provides consistent procedures for CM and migration control of software on IBM platforms. The ENDEVOR implementation has been designed with sufficient flexibility to support the different development environments found on the following platforms:

    • Enterprise Computing Center - Martinsburg (ECC-MTB) Master File (MF) processing

    • Integrated Collection System/Automated Collection System (ICS/ACS)

    • Printer Replacement to Integrate New Tools (PRINT)

  3. ENDEVOR ACM tool provides the following capabilities:

    • Manages source, object and load libraries that are created by ENDEVOR

    • Automatically compares and tracks source code changes against the version in production

    • Ensures the versions of source and executable modules correspond

    • Allows viewing or retrieval of prior levels of elements

  4. ENDEVOR Package Processing:

    • SCDC personnel approves transmittal packages daily. Many of these transmittal packages may be sent to TAD for testing or sent to the final production environment. SCDC personnel are required to process a transmittal package within an hour of receipt from the development project

    • ECC-MTB System Control Point (SCP) provides the final approval of transmittal packages

    • The IBM Scheduling Section (ISS) promotes the batch modules to production

    • The ECC-MTB Data Base Administrators (DBAs) promotes the Data Base Management (DB2) modules

    • The Information Systems Support Branch (ISSB) promotes the Customer Information Control System (CICS) modules

    Note:

    The detailed procedures can be found on the TAD web-site by using the following URL: http://adweb.irs.gov/domainareas/testassurancedocumentation/default.aspx.

2.6.1.11.2.1  (03-01-2010)
ENDEVOR Roles and Responsibilities

  1. Developer roles and responsibilities:

    • Create or update transmittal packages in development stage

    • Cast transmittal packages in development stage

  2. Development Manager roles and responsibilities:

    • Review version levels and unit testing check list

    • Approve/deny transmittal packages in development stage

  3. SCDC personnel roles and responsibilities:

    • Review transmittal packages for IRS Standards

    • Approve/deny transmittal packages in Quality Assurance (QA) stage

    • Execute QA transmittal packages

    • Build and cast production transmittal packages in QA stage

  4. SCDC Manager roles and responsibilities:

    • Review memo and check JCL levels for production transmittal packages

    • Approve/deny production transmittal packages

    • Execute ACS/ICS and PRINT production transmittal packages moving elements to production libraries

  5. SCP & ISS roles and responsibilities:

    • Perform initial review for IRS standards

    • Approve/deny production transmittal packages (SCP)

    • Execute production batch transmittal packages (ISS)

2.6.1.11.2.2  (08-01-2007)
ENDEVOR Sensitive Package Processing

  1. Sensitive code is transmitted in transmittal packages that have restricted access.

  2. Sensitive transmittal packages are processed the same as regular ENDEVOR transmittal packages except access is restricted to specific persons.

2.6.1.11.3  (11-05-2010)
ClearCase Automated Configuration Management Tool - UNIX and Windows

  1. The Tier 2 & 3 Configuration Management Section of the SCDC Branch provides independent control for all software developed on the Tier II and Tier III platforms. The ACM tool for software version control on the UNIX and Windows platform is IBM/Rational ClearCase. ClearCase is a version control tool used by the IRS to track developers modification to Application source code.

  2. The Tier 2 & 3 Configuration Management Section maintains source code in a secure repository location where the original replica database is located in the New Carrollton Federal Building (NCFB). The section supports SAT environments, projects that transition from Modernization to the IRS, and provides a Gatekeeper function for all production releases. The Tier 2 & 3 Configuration Management Section stages the bundle (executable, zip, etc.) and Software Deployment (SD) Organization deploys the bundle to the appropriate location.

2.6.1.11.3.1  (11-05-2010)
SCDC ClearCase Procedures

  1. The Tier 2 & 3 Section of the SCDC Branch provides independent control for all software developed on the Tier II & III platforms.

  2. There is a 3-phase approach towards implementing ClearCase in the IRS.

    • Phase 1 - Developers are trained to use ClearCase and a ClearCase environment is set up for project use

    • Phase 2 - Tier 2 & 3 Section begins building the SAT and Production baselines

    • Phase 3 - Tier 2 & 3 stages the bundle (exe, zip, etc.) so the EOps Software Deployment (SD) Organization can deploy to Production

  3. The Tier 2 & 3 Section maintains source code in a secure repository location where the original replica database is located in the New Carrollton Federal Building (NCFB). The section supports SAT environments, projects that are transitioning from Modernization to the IRS, and provides Gatekeeper function for all production releases. The Tier 2 & 3 Section stages the bundle (executable, zip, etc.) and Software Deployment (SD) Organization deploys the bundle to the appropriate location.

  4. The ClearCase tool provides the following capabilities:

    • Parallel development which isolates the work of one developer from others on a small team or developing multiple releases in parallel using different teams

    • ClearCase MultiSite which extends ClearCase by supporting parallel software development across geographically distributed project teams

    • Identify and store artifacts in a secured centralized repository

    • Control and audit changes to artifacts

    • Supports concurrent changes to artifacts and components

    • Ensures reproducibility of software builds

      Note:

      The SCDC Tiers 2/3 Version Control document; Attachments I, II, and III; SCDC Tiers 2 Modernization Projects Transition to IRS Support Guide are available at TAD web-site by using the following URL: http://adweb.irs.gov/DomainAreas/TestAssuranceDocumentation/SourceCodeandDocControlBranch/SourceCodeDocuments/default.aspx.

2.6.1.11.3.2  (11-05-2010)
Roles and Responsibilities

  1. SCDC roles and responsibilities:

    • Obtain Project System Configuration Requirements

    • Setup an original replica of the Version Object Base (VOB) on the SCDC ClearCase servers and create developer’s copy of replica for their access and development

    • Provide training and access to the ClearCase tool

    • Conduct SCDC Startup and Version Description Document (VDD) Overview

    • Continue day to day ClearCase support (for merges to main etc.)

  2. Development Manager roles and responsibilities:

    • Review VDD for accuracy

    • Approve VDD by signing and forwarding to SCDC

  3. Developers roles and responsibilities:

    • Provide SCDC with Project System Configuration Requirements

    • Submit OL5081(s) for access to ClearCase servers

    • Submit testing and production schedules

    • Prepare VDD for SAT, FIT and production transmittals

2.6.1.11.4  (03-01-2010)
Document Management for Information Technology (DocIT)

  1. A document management system is a business-critical application for managing and controlling the organization's information and making it secure and easily accessible to end-users. The chosen document management system at the IRS is Documentum. Documentum is currently being used by several organizations, among them are Tax Exempt and Government Entities (TE/GE), Applications Development (AD) and TAD.

  2. Documentum within TAD is named "DocIT" (Document Management for IT projects), and is a web-based application. DocIT integrates with existing desktop applications such as Microsoft Word, Excel, and Visio, and Adobe Acrobat. Most applications access via DocIT work with Jobs Access with Speech (JAWS) screen reader program for the visually impaired.

  3. DocIT is used at the IRS to organize, manage, distribute, and oversee the flow of volumes of documents. The system in place includes one centrally controlled repository for documents, organized by IRS domains, and provides:

    • Version control

    • An audit trail for changes

    • Document check-in notification capability

    • Storage management capabilities

    • Off-site storage for disaster recovery

    • Full text searching

    • Security

    • Document routing and workflow capabilities

  4. TAD's primary users of DocIT are the end-user who retrieves documents created by others to support program testing and the developer who creates and edits documents. DocIT is further defined as follows:

    • Some documents retrieved and viewed by end users in TAD are created by the Development organization. The documents (e.g., COH, FSPs, Schematics, CRLs, Unit Test Plans) are required for testing. Developers create documents in project folders, stored in cabinets that reflect their domains within the IRS. The versions of the documents follow three lifecycle states which includes Draft, Review (SAT review), and Final (Production). Documents are promoted to the Review state when approved. TAD mainly retrieves and reviews documents in the Review state. Non-development users use DocIT for the storage of spreadsheets, handbooks, procedure manuals, and other documents that need to be placed in a secure environment. When the document production date is reached for an approved document it is automatically promoted to the Final state

    • Each folder and document has specific access permissions. The project folders are created by the DocIT system administrators. The standard project folder and sub-folder structure is the logical organization of all internal TAD documents that are considered critical internal work products for testing

  5. Help for using DocIT is provided through on-line help and the DocIT home page at http://tad.web.irs.gov/docIT/docIT.htm .

2.6.1.11.5  (03-01-2010)
TAD Lab Access Control Policy

  1. The TAD labs are safeguarded by protective actions taken by managers, the Lab Access Coordinator (LAC), and system users. The decision to grant a person access to a lab is based on that person's need to access per their official duties/responsibilities. A user can request temporary or extended access. Management verifies and approves the appropriate type of access to its computer labs.

    • All requests for access are documented on a Request for Lab Access Form ( See Exhibit 2.6.1-22.)

    • All requests for access are submitted to the Lab Access Coordinator (LAC)

    • All access to the controlled computer rooms are approved by the Systems Services Branch in EOps via the Tier 2 & 3 Project Implementation Section

    • All requests require at least two workdays to process

    • All access is active until the end date requested or the annual re-certification in March of the following year. At that time users are required to reactivate their access

    • No user already in the lab(s) shall grant access to visitors trying to enter the lab

    • All visitors are required to have ProxCard access or have an escort

    • Users requesting temporary access must be escorted by a user that has authorized access to the lab

    • Escorted users are required to complete the Restricted Area Register (Form 5421) located at the entrance of each lab

    • Users are required to use their ProxCard each time they enter the lab

  2. The Tier 2 & 3 Project Implementation Section , within the SCDC Branch, is responsible for ensuring that entry to the secured area is controlled, and access is limited to those individuals who have a demonstrated need to enter. All employees are required to comply with the established policies and procedures. Violation of these policies and procedures could result in revocation of lab access.

2.6.1.11.5.1  (03-01-2010)
Determining Appropriate Access

  1. Extended access is allowed for people needing access to the lab(s) for 31 days or more.

  2. Temporary access is allowed when the person:

    • Needs access to the lab(s) for 30 calendar days or less

    • Needs access to the lab(s) for training

    • Does not have a ProxCard issued by NCFB Safety and Security Office

  3. When the requested access is for training, the Section Chief/Contracting Officer Technical Representative (COTR) responsible for conducting the training submits a Request for Lab Access form and indicates in the "Special Instructions" block the names and phone numbers of training attendees.

2.6.1.11.5.2  (03-01-2010)
TAD Lab Names and Locations

  1. The TAD labs are located as follows:

    Lab Name Lab Location
    Lab A NCFB B2–303
    Lab B NCFB B2–304
    Lab C NCFB B2–403
    Source Control Room NCFB B2–302
    SCRIPS NCFB B2–300

2.6.1.11.5.3  (03-01-2010)
Requesting Access

  1. This section covers the access-control responsibilities and serves as the instructions for individual roles.

  2. TAD Management and the SCDC Branch are responsible for the overall security within the TAD labs.

2.6.1.11.5.4  (03-01-2010)
Requester Information

  1. The individual requesting access to the TAD lab(s) determines the type of access. The access is either extended or temporary.

  2. The requestor completes the Lab Access Form and forwards it to their Section Chief/COTR for concurrence and signature.

2.6.1.11.5.5  (03-01-2010)
Section Chief

  1. The requester's Section Chief/COTR verifies the need and type of access requested for the TAD lab(s).

  2. Once the Lab Access Form has been signed, it can be delivered to SCDC LAC as follows:

    Placing the document in the Lab Access box at NCFB B6-275 or
    The form may be faxed to the LAC but the original must be provided to the LAC within five business days. The fax number is (202) 283–5153 or
    Mailing it to:
    SCDC Lab Access Coordinator
    Internal Revenue Service
    1111 Constitution Avenue NW, NCFB B6-275
    Washington, DC 20224

2.6.1.11.5.5.1  (03-01-2010)
Lab Access Coordinator (LAC)

  1. Ensure the Request for Lab Access has been properly completed and has the appropriate Section Chief's/COTR's signature.

  2. Enter the request into a database.

  3. Forward the form to Systems Services Branch in Enterprise Operations, and track its approval process.

  4. Once the Systems Services Branch has approved the request, sign the form.

  5. If the request is approved for extended access, forward the form to the NCFB Safety and Security Office.

  6. Maintain a file of all approved request forms.

  7. Notify the requester of access approval or denial.

  8. Verify the ProxCard information for the requester.

  9. Activate/deactivate the ProxCard for TAD lab(s) access.

2.6.1.12  (03-01-2010)
UNISYS and IBM Naming Standards

  1. This section applies to the naming of UNISYS data files and IBM datasets that are used, retained, and/or provided to other organizations by TAD. It is required that datasets sent to TAD from external sources also conform to these data naming standards as identified in IRM 2.5.7 , Data Name Standards.

2.6.1.12.1  (03-01-2010)
Purpose

  1. This section provides a standard for naming TAD UNISYS data files and IBM datasets. Standardization of data naming conventions facilitates data sharing, data consistency, and communication between organizational areas in the IRS. Adherence to this standard helps to eliminate data redundancies, simulate production naming, and allows a greater degree of control over data usage, while enhancing data security.

  2. TAD analysts using these naming standards are also required to comply with the naming conventions as outlined in the UNISYS Programmer's Handbook and IBM Dataset Naming Standards.

2.6.1.12.2  (03-01-2010)
References

  1. For further information pertaining to UNISYS data file naming standards refer to the following sources. Some of these sources are available on the Intranet as indicated by the corresponding URL in paragraph (3).

    • UNISYS Programmer's Handbook, Production Standards, URL http://unisoft.web.irs.gov/unisys/

    • SAT Analyst Training Orientation and Overview: File Formats, May 2000

    • UNISYS Programmer's Handbook, Program Development and Maintenance, URL http://unisoft.web.irs.gov/unisys/

    • UNISYS Reference Manual, ECL and FURPUR, URL http://unisoft.web.irs.gov/unisys/

    • Data Name Standards, IRM 2.5.7, April 2005

    • Naming Standards, Document 7986, September 1995.

  2. For further information pertaining to IBM Dataset Naming Standards, refer to the following:

    • ECC-MTB Systems Information Bulletins

    • I1537 Production Dataset Naming Changes for Preparation for Y2K, April 2, 1997

    • I1537 Attachment (refer to Book Manager on the IBM Mainframe), April 2, 1997

    • ECC-MTB Corporate Systems Standards Library (ACORPSYS on Book Manager) Book: PRODSN, June 12, 1995.

    • ECC-MTB Corporate Systems Standards Library (ACORPSYS on Book Manager) Book: PRODSN2K, May 1, 1997

    • Production Dataset Naming Standards Update 1, March 19, 1997

  3. Further information pertaining to Data File Naming Standards is available at the following web-sites by using the following URLs:

    • UNISYS Programmer's Handbook, Production Standards, http://unisoft.web.irs.gov/unisys/

    • UNISYS Programmer's Handbook, Executive Control Language and FURPUR, http://unisoft.web.irs.gov/unisys/

    • UNISYS Programmer's Handbook, Program Development and Maintenance, http://unisoft.web.irs.gov/unisys/

    • UNISYS Programmer's Handbook, Transaction Processing, http://unisoft.web.irs.gov/unisys/

    • UNISYS Programmer's Handbook, Data Management System, http://unisoft.web.irs.gov/unisys/

    • UNISYS OS 2200 Programming Reference Manual, Data Structures, http://unisoft.web.irs.gov/unisys/

    • UNISYS OS 2200 Administrative and Programming Reference Manual, Processor Common Input/Output System (PCIOS), http://unisoft.web.irs.gov/unisys/

    • UNISYS OS 2200 Reference Manual, Executive Control Language and FURPUR, http://unisoft.web.irs.gov/unisys/

    • ASCII COBOL PROGRAMMING Reference Manual, August 1998, http://unisoft.web.irs.gov/unisys/manuals.htm

2.6.1.12.3  (03-01-2010)
UNISYS File Types and Syntax

  1. There are three distinct file types on the UNISYS system:

    • Data - Contents are acted on as a single unit - each record or "image" is processed sequentially. These files generally contain data records or transactions

    • Database - A central repository of data that can be accessed either by individual end-users via IDRS command codes on an individual basis or by batch programs as a composite unit producing a data file

    • Program - Contents consist of independent pieces called "elements" , each of which can be acted upon separately (similar to a directory on a personal computer). Elements will generally contain ECL or programs; however, they may also contain records

  2. The syntax of a typical UNISYS data file includes the qualifier, filename, F-cycle, and period. At a minimum, "Filename" is required. Data files displayed on UNISYS will also include the Access Locator Number (ALN) preceding the qualifier.

    UNISYS Data File
    Qualifier*Filename (F-cycle) Exempt Qualifier - applies to system files.
    (ALN)Qualifier*Filename (F-cycle) Non-exempt files.
    00Qualifier*Filename (F-cycle) Exempt Qualifier for user files

    1. ALN - (optional). The ALN represents the File Location Code (FLC) of the Campus being accessed on the UNISYS mainframe. The ALN areas are 17, 18, 19, 28, 29 and 49. An additional ALN of "00" represents the exempt qualifier. Within a specified ALN area, the ALN preceding the qualifier is implied by the UNISYS system and the ALN is not typed as part of the full file name. The exception is the user-exempt file ALN of "00 " . For each file to which "00" is attached, the entire qualifier must be included as part of the full filename.

    2. Qualifier - (optional). 1 to 12 characters (alphabetic, numeric, hyphen, dollar sign ($)). The qualifier is part of the full filename and distinguishes files with the same base filename. For example, VD123*FileA is distinguishable from VD456*FileA. User IDs and Project IDs are commonly used. Examples of qualifiers are VD123*, PSC*, MGB*, and CSC*. If not specified, the Project-ID from the run card is used. Use of dollar signs ($) is discouraged, as it typically implies a system-level file.

    3. Filename - (required). 1 to 12 characters (alphabetic, numeric, hyphen, dollar sign ($)). Dollar signs are generally used to represent system files, and are not included for user files. Hyphens are generally used in database areas and can be used in data files. The "AREA-NAME" of a database area will be the filename (refer to example on Data Management System (DMS) filenames in "e." below). A filename must be clear and accurate to reflect a condensed version of the data description.

    4. F-cycle - (optional). Iteration of a file. Identifies a file in a set of files that have the same qualifier and file name. Normally the F-cycle is not included with the file name. If the F-cycle is not provided, the highest catalogued file cycle in the set is shown. A maximum of 32 "F-cycles" may exist at one time. There are absolute (ABS) and Relative (REL) cycles, each with unique requirements:

      ABS & REL Cycles
      ABS A sequential number assigned to each file in the physical sequence it was created. 1, 2, 3, 4 etc. (1 through 999).
      REL A signed integer representing the position of a given file within the series of files with that name, useful when a new cycle of a given file is constantly being created. A negative number (-) indicates a previous cycle and a positive number (+) indicates the current cycle plus one.

    5. Period - (required). With few exceptions, every filename must end with a period.

      Examples of Data File Names
      VD123*NOR0111(-1). Data file
      DMS*NRPS-AREA. Database file
      PSC*DMS5001. NRPS area unload file from utility program DMS50.
      00*EOD0164(+1). If used, exempt qualifier must be included as part of filename, input data file for TIF-EDIT utility

2.6.1.12.3.1  (03-01-2010)
UNISYS Data File Naming Standards

  1. UNISYS data files - The standard applies to any pre-processing @DATA and @FILE files and any post-processing print files. This format is specified in IRM 2.5.7, Data Name Standards. Non-database files must meet the standards for data file naming convention in the form of " nnscab*sssrrff. " scab = Campus ID (i.e. PC, AUC, etc.).

    1. nn - ALN values are as follows for testing on the UNISYS 7800:

      ALN Values
      17 Cincinnati Campus (CC)
      18 Austin Campus Center (AUC)
      19 Brookhaven Campus (BC)
      28 Philadelphia Campus (PC)
      29 Ogden Campus (OC)
      49 Memphis Campus (MC)
      00 exempt qualifier (available within all ALNs)

    2. SATF/SATC - A unique qualifier is attached. SP utilizes the following format for the SAT library:

      SATF/SATC
      SATC indicates the current library utilized by the production environment.
      SATF indicates the library in use by a SAT before programs are released to the field. In order to avoid conflicts with files created during systemic test processing, use the SATF qualifier when executing individual test programs.

    3. sss - System ID

    4. rr - Run number within system

    5. ff - File number within run:

      01 - 19 Reserved for non-print magnetic media files
      20 - 29 Reserved for non-print disk files
      40 - 49 Reserved for print files (magnetic media and disk files)
      99 Reserved for checkpoint files

      Note:

      While the qualifiers that are attached to files will vary between users, the base filename must match exactly to the filename as it is used in production. For example:

      SCAB*NOR0110. RIR tape file
      SCAB*EOD0621. EOD disk file
      SCAB*NOR0143. RIR print file

  2. UNISYS TIF unload data files -TIF unload data files are exact copies of the TIF database areas ITIF00-99, BTIF00-99, and ZTIF01. SP creates these files from the DMS*0201 file as a job aid for end-users to easily search from the TIF unloads. As a consequence these files follow a special naming convention to enable the user to access these files under any ALN environment where the user is currently accessing the unload file.

  3. All TIF unload files following data file naming standard: "00DMS*CYyyyyccxnn" .

    1. CY - Represents the literal of the IDRS cycle.

    2. yyyy - Represent the calendar year.

    3. cc - Represents the numeric of the IDRS cycle.

    4. x - Represents the particular TIF area being accessed:

      B - BTIF area Contains BMF data
      I - ITIF area Contains IMF data
      Z - ZTIF area Contains EPMF, and NMF data

    5. nn - Numeric digits representing the particular TIF area accessed. There are 100 different TIF areas, "00" through "99" , in the BTIF and ITIF areas. The ZTIF has only one area, "01" . For example:

      00DMS*CY200430B00. BMF area 00 TIF for IDRS cycle 200430
      00DMS*CY200447I29. IMF area 29 TIF for IDRS cycle 200447
      00DMS*CY200452Z01. IRAF/EPMF/NMF area 01 TIF unload for IDRS cycle 200452

  4. UNISYS database files - UNISYS database files use the qualifier DMS on the UNISYS mainframe. The database file naming standard will follow the format " DMS*xxxxxxx-AREA. " and the file syntax is:

    • DMS - The qualifier representing the literal for DMS files

    • xxxxxxx-AREA - The unique database area name, which can have up to twelve characters (alphabetic, numeric, hyphen and literal "AREA" ). For example:

    DMS*NRPS-AREA NRPS database area
    DMS*IRIR-AREA IMF RIR database area
    DMS*ITIF00-AREA IMF TIF-00 database area
    DMS*ITIF00-1-IDX IMF TIF-00 index file

2.6.1.12.4  (03-01-2010)
IBM Dataset Naming Standards

  1. TAD IBM Datasets must be named according to prescribed standards in the Production Dataset Naming Standards. The standards are published in the ECC-MTB Corporate Systems Standards Library and the ECC-MTB System Information Bulletins (SIBs).

  2. The maximum number of alphanumeric characters allowed in an IBM Dataset name is 44, excluding periods. The IBM Dataset syntax is as follows: "VxQualifier1.Qualifier2.Qualifier3.Qualifier4.Qualifier5.Qualifier6 "

    1. Vx = Prefix (required). The "V" is constant, signifying the dataset belongs to TA, while the "x" is an alphanumeric character representing the section which created the dataset (VA, VT, V3, V5, etc.)

    2. Qualifier1 = Project (required). This is the project designation or programmer ID number. It is a three-character field. The project, prefixed by Vx, is the first qualifier of the name. If the data is not being processed by ECC-MTB schedulers, the programmer ID number may be substituted for the project designation. Below are some examples of the high level qualifiers that must be used for the corresponding tests

      Project High Level Qualifier
      IMF Master File VBITY
      BMF Master File VABTY
      IDRS IMF Extracts VGIDR
      IDRS BMF Extracts VGBDR
      IDRS EPMF Extracts VGEPY

    3. Qualifier2 = Program Run Identifier (required). This field is the program run identifier as it appears in the accounting section of the jobcard of the run creating the dataset. The valid format for a program run identifier is as follows:

      " ABBBCCDD " , where:
      A = One position alpha equal to the first letter of the project (e.g., B for BPW or I for IAY, etc.).
      BBB = Three position alphanumeric program project identifier (e.g., 140 or 460 or 280, etc.).
      CC = Two position alphanumeric run identifier (e.g., 02, 12, etc.).
      DD = Two position alphanumeric identifying the segment (if multiple segments are processed by the run - some programs do not require use of the "DD" identifier).

      The two position suffixes identify the segments as follows:
      Valid Suffixes Segment Count
      AA-AZ and A0-A9 36
      BA-BZ and B0-B9 36
      CA-CZ and C0-C9 36
      DA-DZ and D0-D9 36
      EA-EZ and E0-E9 36
      FA-FZ and F0-F9 36
      GA-GZ and G0-G9 36
      HA-HZ and H0-H9 36
      IA-IZ and I0-I9 36
      JA-JZ and J0-J9 36
      KA-KZ and K0-K9 36
      LA-LZ and L0-L9 36
      MA-MZ and M0-M9 36
      NA-NZ and N0-N9 36
      Maximum number of segments: 504

    4. Qualifier3 = Filename (required). This field is the same file name corresponding exactly with the DDNAME in the Job Control Language (JCL) used to define the file. The format is as follows:

      " FAAABB " , where:
      F = Represents the literal word "File" , this value is a constant.
      AAA = Three alphanumeric characters uniquely identifying the file within the program run identifier (e.g., 011, 018, etc.).
      BB = Suffix for a multi-thread program run identifier, identical to the "DD" suffix in Qualifier2.

    5. Qualifier4 = Cycle (required). This field defines the cycle in which the program is being executed and follows the format:

      " AYYYYCC " , where:
      A= The letter assigned by the analyst to indicate the pass. It is a single position and usually sequential (e.g., A = Pass A, B = Pass B, C = Pass C, etc.).
      YYYY = The four digit numeric that indicates the year of data processing (e.g., 1999, 2000, 2001, etc.).
      CC = The two digit numeric that represents the weekly cycle of data processing, from cycle 1 (01) through cycle 52 (52).

    6. Qualifier5 = Rerun Indicator (optional). This is a two position alphanumeric value representing the iteration of the program run. The first position is always a literal "R" (this is a constant), followed by a number, starting at "0" , to indicate the sequence of the run (e.g., R0, R1, R2, R3, etc.)

    7. Qualifier6 has no specific definition. It is completely optional at the user's discretion

  3. IBM Dataset Naming Standard examples:

    1. VxBTY.B16012AB.F011AB.A200108.R0 - This illustrates the dataset name for file 11, segment AB, of BMF run 16012 (also segment AB) in cycle 200108, Pass A in project BTY. This is the initial creation of the dataset (R0)

    2. VBITY.I44001AA.F014AA.C200101.R2 - This illustrates the dataset name for file 14, segment AA, of IMF run 44001 (also segment AA) in cycle 200101, pass C in project ITY of section B. This is the third creation of the dataset (R2)

2.6.1.13  (11-05-2010)
National Office Directed Travel (NODT) Letter and Field Support

  1. TAD domain projects sometimes include the use of field participants (FP) from the field to obtain knowledge in the testing areas where final user experience benefits both the system test development and conduct.

  2. TAD domain projects also provide users with advance insights into changes being implemented that could be of value to the field.

  3. After scheduling of field participants has been performed, a National Office Directed Travel (NODT) letter is drafted. See Exhibit 2.6.1-23. for an example.

  4. Copies of NODT letters are provided to the TAD Budget and Contract Administration Section, .

  5. When scheduled changes impact field participation, the NODT letters are updated and copies shared as described in paragraph (4) above.

Exhibit 2.6.1-1 
Testing Life Cycle Activities

This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 2.6.1-2 
Work Breakdown Structure

This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 2.6.1-3 
Work Request Analysis Form

<<Branch Name>>
<<Section Name>>
Work Request Analysis Form
Request Number:   Project:  
Analyst:   Date:  
1. Explain at a high level in your own words the requested change.  
2. Have you discussed the work request with your team leader, developer and customer? List your points of contact.  
3. Identify or list your requirements?  
4. What documentation will be impacted by this work request? (i.e., PRP, FSP, COH, CRL, etc.)

When will document(s) be delivered? 		 
5. What programs or runs are changing per this request?  
6. Type of test data required to test.  
7. Test data concerns or contingencies.  
8. How will test data be created? (i.e., modified, SCRS, tax returns, IMF/BMF.)

When will this data be available for execution? 		 
9. What programs (runstream) will be executed to validate the change?  
10. What is the interface projects/runs (both input and output)?
Identify and list the points of contact?
What agreements have you reached with your interface points of contact? 		 
11. When is your review schedules?
• WRAF
• RTVM (Requirements/Test Conditions)
• Test Case/Test Data 		 

Exhibit 2.6.1-4 
Project Impact Assessment

This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 2.6.1-5 
Project Folder Checklist

Project Folder Checklist
Project: __________
Analyst: __________
Date: ___________
Requirements Document(s) DocIT # Yes No
Unified Work Requests (UWR)      
• Agree to test      
• Staff days calculation worksheet(s) (Project Impact Assessment (PIA))      
• Cost for Contractor(s)      
Statement of Work (SOW) or Work Request      
Cost and Technical Proposals      
Business Systems Concept Report (BSCR)      
Business System Requirements Report (BSRR)      
Business System Architecture Report (BSAR)      
Service Level Agreement (SLA)      
Other      
       
       
Dates/comments:
 
 
Requirements Analysis DocIT # Yes No
Requirements Testability Checklist      
Work Request Analysis Form (WRAF)      
Other:      
       
       
Dates/comments:
 
 
Work Breakdown Structure DocIT # Yes No
Work Breakdown Structure      
Projected/Actual test cases/script preparation schedule      
Projected Actual test execution schedule      
Other:      
       
       
Dates/comments:
 
 
Test Plan DocIT # Yes No
Approved Test Plan(s)      
Approved Revision(s) to Test Plan(s)      
       
       
Version numbers/dates/comments:
 
 
Functional Document(s) DocIT # Yes No
Design Specification Package (DSP)      
Functional Specifications Package (FSP)      
Programming Requirements Package (PRP)      
Interface Control Document (ICD)      
Design Specification Report (DSR)      
Logical Design Description (LDD) Document      
Other:      
       
       
Dates/comments:
 
 
Operational Document(s) DocIT # Yes No
Computer Program Book (CPB)      
Computer Operator Handbook (COH)      
Internal Revenue Manual (IRM)      
Users Manual(s)      
Other:      
       
       
Dates/comments:
 
 
Work Product Reviews DocIT # Yes No
Work Request Analysis Form      
Test Case      
RTVM      
Walkthrough/Coordination      
IRM      
Test Plan      
EOTSR      
Other:      
       
       
Dates/comments:
 
 
Test Cases/Test Scripts DocIT # Yes No
Test Case(s)      
Regression Test Cases      
Test Case Deferral and Waiver Form(s), if applicable      
Other:      
       
       
Dates/comments:
 
 
Requirements Traceability Verification Matrix (RTVM) DocIT # Yes No
RTVM      
Other:      
       
       
Dates/comments:
 
 
Test Readiness Review (TRR) DocIT # Yes No
TRR Agenda      
TRR Checklist      
TRR Memorandum — System is Ready      
TRR Memorandum — System Not Ready      
       
       
Dates/comments:
 
 
Transmittal Log DocIT # Yes No
Software Transmittal Log      
Documentation transmittal Log      
Other:      
       
       
Dates/comments:
 
 
Test Results Output
Identify the location of printouts, magnetic media backups, files, test cases/test scripts (e.g., tapes, computer disk, data files, Mag Media shipment records, etc.). 		DocIT # Yes No
       
       
       
       
Dates/comments:
 
 
Problem Ticket Log DocIT # Yes No
Problem Ticket Log      
       
       
Dates/comments:
 
 
Interface Agreement(s) DocIT # Yes No
SAT Interface Database Agreement(s)      
Files Communication Status Report (FCSR)      
Other      
       
Dates/comments:
 
 
Closeout Activities DocIT # Yes No
Approved EOTSR      
Approved Revision(s) to EOTSR      
Conduct remote site closeout, if applicable      
Conduct Lessons Learned      
PIR Agenda      
PIR Discussion Street      
Finalize RTVM      
Finalize Work Breakdown Structure      
Finalize test cases/test scripts      
Disposition outstanding issues      
Archive test data      
Closeout Project Folder      
Other:      
       
       
Dates/comments:
 
 
Test Log DocIt # Yes No
Documentation receipt dates      
Run dates and results      
Entries of daily activity during software testing and output review      
Reporting/ending dates for field Participants, customer representatives, and other support personnel      
Significant information, commitments or decisions made in meetings, via the phone or electronically (include dates)      
Site visitation dates and notes      
Dates and notes of significant problems encountered (lessons learned)      
Electronic Mail      
National Office Directed Travel (NODT) Letter(s)      
Points of contact (Name, Symbols, Telephone number, and Location and E-mail Address)      
Request for Computer Support (RCS)      
Request for Contractor Support      
Request for Enterprise File Transfer Utility (EFTU)      
Test Environment Checklist      
       
Other      
       
       
Dates/comments:
 
 
Status Reports DocIT # Yes No
TAD Status Reporting System (TSRS)      
Release Readiness Schedule and Status Report      
Exception Report      
ITAMS Problem Reports      
Overage Report      
Other      
       
       
Dates/comments:
 
 
Ad Hoc Testing
List all artifacts below for emergency or ad hoc testing for a program/software already in production 		DocIT# Yes No
Dates/comments:
 
 
Miscellaneous DocIT # Yes No
       
       
       
Dates/comments:
 
 
Verification of Project Folder
   
Reviewer's Signature: _________________ Date: ____________
Analyst's Signature: __________________ Date: ____________

Exhibit 2.6.1-6 
Requirements Traceability Verification Matrix (RTVM)

Requirements Traceability Verification Matrix (SAT)
Version Number and Date:  
Project Name and Release/Production Implementation:  
Requirements Control Number Requirements Item Reference Number Requirement(s) Functional/ Operational Document Name/Item Reference Number Functional/ Operational Document Version/Date Test Case ID Number Test Condition TestDate TestResults Problem Ticket Number Remarks/Constraints
                     
                     
                     
                     
                     
                     
                     
                     
                     
                     
                     

Exhibit 2.6.1-7 
Systems Acceptability Test Plan

This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.
Section 1.0 Introduction
1.1 Purpose
The Systems Acceptability Test (SAT) Plan for <<name of project>> was developed based on the procedures in Internal Revenue Manual (IRM) 2.6.1, Test, Assurance & Documentation Standards and Procedures

The purpose of this SAT Plan is to describe how Test, Assurance & Documentation (TAD) will ensure products to be tested meet customer requirements and specified deliverables conform to approved standards.
1.2 Document Organization
This section serves as a roadmap for the reader to understand how the document is organized. Provide a brief summary of each statement of each section and appendix. If desired, tables may be used in lieu of appendices as applicable within each section of the SAT Plan.

This plan consists of five sections, <<insert number>> appendices, if applicable and a list of acronyms:

Section 1, Introduction – describes the purpose of the SAT Plan. The Introduction also describes the plan’s organization, relationship to other documents, and the document maintenance procedures.
Section 2, Overview - provides an overview of the existing or new project/system, the test approach, and the major system changes being tested.
Section 3, Test Management - describes the scope of the test, standards and procedures, documentation, products to be tested, requirements traceability, interfaces, test environment, test tools, assumptions and constraints, problem reporting and resolution, test data, and test metrics.
Section 4, Test Resource Management - describes the organization and management of the test team and other resources.
Section 5, Systems Acceptability Test Phases – summarizes the four phases of the test. Each phase should identify the scheduled tasks to be performed during that phase
Appendices (Optional)
• Appendix A - Work Breakdown Structure
• Appendix B - Requirements Traceability Verification Matrix (RTVM)
Acronyms - provides a list of acronyms used in this document.
1.3 References and Related Documents
This section specifies project assets and other documents closely related to or referenced by the document.
Some references and related documents may include:
•IRM 2.6.1 Test, Assurance & Documentation Standards and Procedures, dated <<mm/dd/yyyy>>
• IRM 10.8.1 Information Technology (IT) Security, Policy and Guidance, dated <<mm/dd/yyyy>>
• IRM 10.8.8 Information Technology (IT) Security, Live Data (LD) Protection, dated <<mm/dd/yyyy>>
• Document 6209 - Automatic Data Processing (ADP) and Integrated Data Retrieval System (IDRS) Information Handbook, dated <<mm/dd/yyyy>>
•<<Project Name>> System Test Plan, dated <<mm/dd/yyyy>>, if applicable
1.4 Document Maintenance
This section describes how the document will be maintained and the frequency and nature of updates. It also identifies the ownership of the document. For distribution purposes the SAT Plan must be forwarded to the TAD Web Master to be placed on the TAD Web site.

The <<name of project>> SAT Team will perform all updates and modifications to the SAT Plan. Version control will be used to manage the change history of the document. The approved SAT Plan will be located in Document Management for Information Technology (DocIT) and maintained in the TAD Cabinet in <<name of project>> Project Folder, DocIT number << insert DocIT number>>.
Section 2.0 Overview

2.1 System Overview
Briefly describe (one or two paragraphs) what the existing project/system currently does in production or what the new project/system is expected to do. Briefly state the purpose of the system to which this plan applies.

Testing will be conducted at <<location(s) of test>>. The test will begin on <<begin date>>, and is scheduled to conclude on <end date>>. The test will be conducted under the supervision of <<name>>, Chief, <<Section Name>>
.
2.2 Test Approach
This section defines the testing activities that will be applied against the application(s) being tested. The approach should be viewed as a "to do" list, in paragraph language providing details of how execution will verify and/or validate business requirements, that will be fully detailed in the Work Breakdown Structure and/or Test Execution Schedule as defined by the project. The Work Breakdown Structure or Test Execution schedule is to be included will only be a snapshot of the current view the day the SAT Plan is approved.

To ensure prompt detailed testing of specific system changes TAD is conducting a SAT on systems affected by <<name of project>>. Testing will ensure the integration of the changes across the tax processing systems << or change to appropriate system>> from a business perspective.
2.3 Major System Changes
The major system changes included in this test are…

or

The major system changes included in this test can be found in Table …

Example of table below,

Table 2-1 Unified Work Requests

UWR Title
WCS081236OTH Legislative HR 5140 - Perform Rebate Processing (Economic Stimulus Rebate)
WSP081482OTH Legislation - Electronic Filing (ELF) Legislative Economic Stimulus Act of 2008
WSP081483OTH Legislative - Economic Stimulus Act of 2008


or

The major system changes included in this test can be found in Appendix…
Section 3.0 - Test Management
3.1 Scope of the Test
This section describes the limits of the test, identifies the boundaries of what the test will, and will not address. In most cases, the following statement should be included in this section: "Capacity, performance, security, stress, accessibility, usability, string, unit and hardware testing will not be performed as part of this test." If any of the aforementioned tests are performed they should be deleted from the statement.

The <<name of project>> SAT will use requirements that will be derived from the << select any or all that apply such as Unified Work Request(s) (UWR), or Change Request(s) (CR), or Business System Requirements Report (BSRR), or Business System Architecture Report (BSAR), and/or Business System Concept Report (BSCR) ,>> for each affected system to prepare test scenarios, data, and expected results.
3.2 Standards and Procedures
Standards and procedures used to generate this SAT Plan have been obtained from the IRM 2.6.1, Test, Assurance & Documentation Standards and Procedures.

If using live and/or sensitive data, the following statement should be included in this section: The standards and procedures to follow when Live and/or sensitive data will be handled will be in accordance with IRM 10.8.8, Information Technology (IT) Security, Live Data (LD) Protection and IRM 10.8.1, Information Technology (IT) Security, Policy and Guidance.
3.3 Documentation
This section must include a list of all documentation (Requirements, Functional, and Operational) used in planning and executing the test.

The following documentation will be used to perform the test:

or

The documentation used to perform the test can be found in Table…

or

The documentation used to perform the test can be found in Appendix…
3.4 Products to be Tested
If your transmittal date(s) is known use the word "scheduled " . If your transmittal date(s) is not known or tentative use the word "target" .

The following products to be tested and their <<scheduled or target>> transmittal dates to SAT are:

or

The products to be tested and their <<scheduled or target>> transmittal dates to SAT can be found in Table …

or

The products to be tested and their <<schedule or target>> transmittal dates to SAT can be found in Appendix …
3.5 Requirements Traceability
This section must describe the methods used to track requirements to specific test cases. The RTVM that is to be included will only be a snapshot of the current view the day the SAT Plan is approved.

The RTVM documents traceability relationships between requirements, rules, and associated work products, as well as identifying which requirements cannot be tested. The SAT team uses <<Word, Excel, Access, Req Pro, etc.>> to prepare test cases that trace requirements. See Appendix B, Requirements Traceability Verification Matrix.

Continual/ongoing maintenance of the RTVM will facilitate the required update(s), review(s) and approval(s) of the RTVM as the project moves through the testing lifecycle. A RTVM report will be generated and examined as intermittent work product reviews are held to ensure ongoing maintenance of traceability.

If Appendix B is not included as part of the SAT Plan, then the location of where the RTVM can be found, must be included in this section.
3.6 Interfaces
If there is no need to contact another organization for interface testing, then this section would not be applicable. When documenting the interfaces use the TAD Interface Database Agreement or the Files Communication Status Report (FCSR).

Interfaces coordinated with <<branch name(s) and/or other agencies (agencies to be determined by the projects)>> included in this test are…

or

Interfaces included in this test have been coordinated with <<branch name(s) and/or other agencies (agencies to be determined by the projects)>> and can be found in Table…

or

Interfaces included in this test have been coordinated with <<branch name(s) and/or other agencies (agencies to be determined by the projects)>> and can be found in Appendix …
3.7 Test Environment
Describe the test environment at each intended test site. Describe the locations/facilities where testing will be performed, as well as hardware, software, networks, databases, protocols used, etc..
3.8 Test Tools
Provide a description of all test tools required to support testing activities.

Each team will use the appropriate tools necessary for planning, execution, and management of their <<name of project>> test cases.
3.9 Entrance and Completion Criteria
Entrance and completion criteria are guidelines established to ensure organizations are prepared to begin test execution and understand what is required to complete test execution.

Entry criteria is defined prior to test execution to help determine what items need to be in place for test execution to successfully commence.

Exit criteria is defined prior to test execution to document the conditions necessary to complete the testing phase and determine if the application(s) is/are ready to be released into production.

The overall entrance and exit criteria are described below. Detailed criteria will be available at the TRR.
3.9.1 Entrance Criteria
The following list are suggested examples of what can be included as entrance criteria.

Entrance criteria for test execution are as follows:
• Applications are base lined and related documentation updated and distributed
• Version Description Documents (VDDs) for all software/hardware components are complete
• Test tools set up and ready
•Test cases and scripts have been completed.
• Test data is sufficient (not necessarily complete) to begin testing
• All support personnel identified and contact lists available
•ECC, development, and deployment personnel ready to support testing
• EITE is ready to support at NCFB and MCC.
• Requirements Traceability Verification Matrix (RTVM) has been supplied
• All open defects from prior test phases will be identified during the TRR
• A TRR has been conducted, all required issues have been resolved, and approval has been obtained to begin testing
3.9.2 Completion Criteria
The following list are suggested examples of what can be included as completion criteria.

Completion criteria for test execution are as follows:
• All scheduled tests are either executed, waived, or deferred
• All Severity 1 and 2 defects are closed
•All Severity 3 and 4 defects have a resolution status or action plan toward resolution
•IRS customer has agreed to a disposition plan for all Priority 3 problem tickets (defects)
• Waived and deferred test cases have been approved for waiver or deferral
3.10 Assumptions and Constraints
This section must include specific conditions or circumstances (if any) that will limit the scope of the test. In addition, identify any "No SAT" for this current test and/or release.
3.11 Problem Reporting and Resolution
A Problem Ticket describes a problem or discrepancy that is detected during documentation review, test execution, or output review. Problems found during testing will be reported on the Information Technology Asset Management System (ITAMS). The instructions for ITAMS access and input procedures can be found at http://eues.web.irs.gov/ESD/itamsresource.aspx . Once the software, control language, or documentation corrections have been transmitted, TAD analyst will verify the corrections within project time-frames. Problem Tickets will only be closed if the solution corrects the original problem, which is verified by regression testing, or the resolution satisfactorily explains why the problem occurred.

The SAT ID(s) used for problem reporting are…

or

The SAT ID(s) used for problem reporting can be found in Table …

or

The SAT ID(s) used for problem reporting can be found in Appendix…
3.12 Test Data
Provide a description of all data required at each location to perform the test. Include content, source, storage, access, protocols, security, backup, and maintenance. Information, as well as any sanitizing required prior to the data’s use. Reference a live data request or waiver if live date is to be used.

If using live and/or sensitive data, the following statement should be included in this section: Live and/or sensitive data will be handled in accordance with IRM 10.8.8, Information Technology (IT) Security, Live Data (LD) Protection and IRM 10.8.1, Information Technology (IT) Security Policy and Guidance.
3.13 Test Metrics
Describe the reports that will illustrate progress during test execution.

Test status and execution will be reported <<insert frequency e.g., daily, weekly>> using the TAD Status Reporting System (TSRS).
Section 4.0 Test Resource Management
4.1Test Resources
This section describes the SAT team personnel, computer support personnel, computer support requirements, and physical resources needed for conducting the test.
4.1.1 SAT Team Organization and Responsibilities
Identify the SAT team members conducting the test. Include (if known) their name, title, testing responsibilities, organization and/or IRS office symbols, and their testing location. Identify the originating location of field participants and their beginning and ending test dates, as applicable.
4.1.2 Support Team Responsibilities
Identify the personnel needed to support specific portions of the test, (such as support contact at Enterprise Computing Center (ECC) Detroit, MI (ECC-DET), ECC Memphis, TN (ECC-MEM); and ECC Martinsburg, WV (ECC-MTB), etc.). Include the same information for each participant as defined in section 4.1.1.
4.1.3 Computer Support Requirements
The following computer support requirements needed for the test are:

or

The computer support requirements needed for the test can be found in Table …

or

The computer support requirements needed for the test can be found in Appendix …
4.1.4 Physical Resources
The <<name of test>> SAT will be performed using the resources provided at <<name of on-site and/or off-site location(s) of test>> . No additional resources are required.

or

The following list of physical resources was provided to <<name of contact>> on <<mm/dd/yyyy>>.

or

The list of physical resources provided to <<name of contact>> on <<mm/dd/yyyy>> can be found in Table …

or

The list of physical resources provided to <<name of contact>> on <<mm/dd/yyyy>> can be found in Appendix …
Section 5.0 System Acceptability Test Phases

This portion of the document must summarize the four phases of the test. Each phase should identify the scheduled tasks to be performed during that phase.
5.1 Initiation Phase
The Initiation Phase includes the following tasks and schedules

or

The tasks and schedules for the Initiation Phase can be found in Table

or

The tasks and schedules for the Initiation Phase can be found in Appendix …
5.2 Preparation Phase
The Preparation Phase includes the following tasks and schedules

or

The tasks and schedules for the Preparation Phase can be found in Table …

or

The tasks and schedules for the Preparation Phase can be found in Appendix …
5.3 Execution Phase
The Execution Phase includes the following tasks and schedules

or

The tasks and schedules for the Execution Phase can be found in Table …

or

The tasks and schedules for the Execution Phase can be found in Appendix …
5.4 Conclusion Phase
The Conclusion Phase includes the following tasks and schedules

or

The tasks and schedules for the Conclusion Phase can be found in Table …

or

The tasks and schedules for the Conclusion Phase can be found in Appendix …
Appendix A Work Breakdown Structure
The Work Breakdown Structure that is to be included will only be a snapshot of the current view the day the SAT Plan is approved.

The Work Breakdown Structure is used to schedule and track activities performed during SAT. The Work Breakdown Structure for the <<name of project>> SAT is as follows:

or

The Work Breakdown Structure is used to schedule and track activities performed during SAT. A copy of the Work Breakdown Structure is located in the TAD Cabinet in DocIT, <<name of project>> Project Folder, DocIT number <<insert DocIT number>>>
.
Appendix B Requirements Traceability Verification Matrix
The Requirements Traceability Verification Matrix (RTVM) establishes the relationships between the requirements to be tested and the associated test cases. Identify which requirements cannot be tested. The RTVM for the <<name of the project>> SAT is as follows:

or

The Requirements Traceability Verification Matrix (RTVM) establishes the relationships between the requirements to be tested and the associated test cases.Identify which requirements cannot be tested. A copy of the RTVM is located in the TAD Cabinet in DocIT, <<name of project>> Project Folder, DocIT number <<insert DocIT number>>.
Acronyms
List all acronyms used in this document in a table with the acronym then spelled out.
below are examples
SAT Systems Acceptability Test
EOTSR End of Test Status Report

Exhibit 2.6.1-8 
End of Test Status Report

This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.
Executive Summary
The Executive Summary provides the business executives with the information needed to decide whether the system is ready for production.

The summary should identify all risk factors, issues or areas of concern, open Problem Tickets, test constraints. and/or variances from the <<SAT/FIT>> Plan

Format and Content:
When (scheduled to deploy; test window and exceptions/extensions and rationale)
What
★ Features of release
Focus of SAT
Findings of SAT How (did the test go? All test cases verified, some deferred, some problems accepted)

Must be logical, meaningful and concise (no abbreviation/filenames/runs/tables)

Example:

The SAT for <<project name>> scheduled to deploy <<mm/dd/yyyy>> was subject to SAT verification << mm/dd - mm/dd/yyyy>>. This test window was <<met/extended/shortened>> due to .

High profile features in this release included….In addition changes to the …were added. The SAT verified business requirements for the subsystem XXX functions and ensured processing for external input and output systems.

The SAT surfaces issues with the xxx feature/function which required a requirements/design modification. Several delays were encountered due to the instability of the test environment. Seven test cases for xxx functions were waived due to the test bed limitations. All other software corrections required by the business were verified upon conclusion of the SAT. Unresolved issues…will be deferred to a later release. The results observed during the SAT indicate the <<project name>> is functionally consistent with requirements validated in the scope oft his release.

The Executive Summary must only be one page

Section 1. Introduction starts on the next page of the EOTSR
Section 1.0 Introduction
1.1Purpose
The End of Test Status Report (EOTSR) for <<name of project and/or release>> was developed based on the procedures in Internal Revenue Manual (IRM) 2.6.1, Test, Assurance & Documentation Standards and Procedures.

The <<section name>> of the <<branch name>>, <<branch symbols>>, performed a <<Systems Acceptability Test (SAT)/Final Integration Test (FIT)>> of the <<system name>> to determine its capabilities to receive, validate and process <<explain processing>> .....

The test was conducted from <<begin date>> to <<end date>> under the direction of <<Name of Section Chief>>, Chief, <<Section Name>> at <<test location>>. The scheduled production date is <<production date>>.
1.2 Document Organization
This section serves as a roadmap for the reader to understand how the document is organized. Provide a brief summary of each statement of each section and appendix. If desired, tables may be used in lieu of appendices as applicable within each section of the EOTSR.

This plan consists of four sections, <<insert number>> appendices, if applicable and a list of acronyms:
Section 1 Introduction - provides the purpose of the EOTSR. The Introduction also describes the report’s organization, relationship to other documents, and the document maintenance procedures.
Section 2 Overview - provides an overview of EOTSR, defines the scope of the test effort, the test environment, test constraints and system interfaces.
Section 3 Test Results Summary – describes processes that were successful and/or were not successful according to specifications at the conclusion of the test, requirements traceability, and test schedule.
Section 4 Outstanding Issues – describes any unresolved issues (e.g., Problem Tickets) and/or other findings and concerns.
Appendices:
•Appendix A – Documentation Received
•Appendix B – Software Received
• Appendix C – System Interfaces
•Appendix D – Problem Ticket Summary Report
•Appendix E – Requirements Traceability Verification Matrix
•Appendix F – Work Breakdown Structure
• Appendix G – Approved Deferrals and/or Waivers
• Appendix H – Live Data Waiver
Acronyms - lists the abbreviations and acronyms used in this document
Additional appendices may be added as needed.
1.3References and Related Documents
This section specifies project assets and other documents closely related to or referenced by the document.

Some references and related documents may include:
•IRM 2.6.1 Test, Assurance & Documentation Standards and Procedures, dated <<mm/dd/yyyy>>
•<<Project and/or Release Name>> System Acceptability Test (SAT) Plan, dated <<mm/dd/yyyy>>
•<<Project and/or Release Name>> Final Integration Test (FIT) Plan, dated <<mm/dd/yyyy>>
•IRM 10.8.1 Information Technology (IT) Security, Policy and Guidance, dated <<mm/dd/yyyy>>
•IRM 10.8.8 Information Technology (IT) Security, Live Data (LD) Protection, dated <<mm/dd/yyyy>>
• Document 6209 - Automatic Data Processing (ADP) and Integrated Data Retrieval System (IDRS) Information Handbook, dated <<mm/dd/yyyy>>
•MITS Test Case Waiver and Deferral Procedure, dated <<mm/dd/yyyy>>
•<<Project and/or Release Name>> System Test Plan, dated <<mm/dd/yyyy>>, if applicable
1.4 Document Maintenance
This section describes how the document will be maintained and the frequency and nature of updates. It also identifies the ownership of the document. For distribution purposes the EOTSR must be forwarded to the TAD Web Master to be placed on the TAD Web site.

The <<Project and/or Release Name>> SAT Team will perform all updates and modifications to the EOTSR. Version control will be used to manage the change history of the document. The approved EOTSR will be located in Document Management for Information Technology (DocIT) and maintained in the TAD Cabinet in <<Project and/or Release Name>> Project Folder, DocIT number << insert DocIT number>>.
Section 2.0 Overview
2.1 Scope
The <<Project and/or Release Name>><< SAT/FIT>> used requirements derived from the << select any or all that apply such as Unified Work Request(s) (UWR), or Change Request(s) (CR), or Business System Requirements Report (BSRR), or Business System Architecture Report (BSAR), and/or Business System Concept Report (BSCR),>> for each affected system to prepare test scenarios, data, and expected results. No source code was used or referenced to create test conditions or test data. No live data was used during the test. If live data was used, provide an explanation and attach Appendix H – Live Data Waiver.

All problems and inconsistencies identified during the <<SAT/FIT>> were documented as Problem Tickets using the Information Technology Asset Management System (ITAMS). Problem Tickets are listed in Appendix D – Problem Ticket Summary Report.
2.2 Test Environment
The <<Name of Project>> test was conducted on the <<database name>> located at <<machine location>> from <<test team location>>. The <<database/environment name>> was configured to simulate the production environment. Exceptions to hardware and/or software configurations must be specified.

Access to the <<machine system name>> was through <<data communication package, version>> from workstations located at <<test team location>>. Test data was created using <<method of creation>>…and/or…test data files were edited using <<editor name, version>> and file transfers were conducted using <<method of file transfers>>.
2.3 Test Constraints
Capacity, integration, performance, security, stress, string, unit, and hardware testing were outside the scope of this test effort and were not conducted during the <<SAT/FIT>>.

If any of the aforementioned tests are performed they should be deleted from the above statement.

and

Identify additional constraints as appropriate:

• Identify requirements, applicable environmental, test approach, test design, test planning and test execution variances from the original <<SAT/FIT>> plan.
• Refer to deliverables not received in adequate time to meet the testing and production implementation schedules. Include documentation, ECL/JCL, executable programs, output files, reports, and run to run balancing instructions.
• If a UWR was subsequently withdrawn or changed to "No SAT" after the <<SAT/FIT>> Plan was issued, identify the UWR(s) in the Test Constraints section and Appendix A.
•Identify any test cases that were waived or deferred during the test. Include the deferrals and/or waivers form in Appendix G. Approved Deferrals and/or Waivers.
2.4 System Interfaces
Input and output files for <<Project(s) and/or Release Name>> were tested for interface compatibility with the <<Project(s) and/or Release Name>> system(s). The Test, Assurance & Documentation Interface Database system and/or the Files Communication Status Report (FCSR) was used to track the coordination and transfer of data files required for system(s) interface tests. Interface Database and/or Files Communication Status Report (FCSR) are listed in Agreements are listed in Appendix C – System Interfaces.

Additional interfaces included in this test were coordinated with <<other agencies (agencies determined by the project)>> and can be found in Appendix C – System Interfaces.
3.0 Test Results Summary
3.1 Test Results
This section must contain a description of the processes that were successful and/or not successful according to specifications at the conclusion of the test.

The results observed during the test indicate that <<Project and/or Release Name>> is functionally capable of supporting tax administration <<or appropriate type of activities>> activities for individual <<or appropriate taxpayer>> taxpayers within the defined scope of <<release or tax processing year>>.
3.1.1Requirements Tested
Requirements tested were derived from the requirements documentation and functional documentation listed in Appendix A – Documentation Received.
3.1.2Products Tested
The <<SAT/FIT team name>> created test data and test cases for all system processes. A list of transmittals identifying the programs and subprograms utilized during testing can be found in Appendix B – Software Received.

The programs transmitted for testing, listed in Appendix B – Software Received, meet the requirements included in the documentation received, listed in Appendix A – Documentation Received.

or

The programs transmitted for testing, listed in Appendix B – Software Received, do not meet the requirements included in the documentation received, listed in Appendix A – Documentation Received. The major discrepancies between software and requirements document(s) are described in detail in Section 4.0, Outstanding Issues.

Example of table if not in an appendix.

Table 3-1 Unified Work Requests

UWR Title
WCS081236OTH Legislative HR 5140 - Perform Rebate Processing (Economic Stimulus Rebate)
WSP081482OTH Legislation - Electronic Filing (ELF) Legislative Economic Stimulus Act of 2008
WSP081483OTH Legislative - Economic Stimulus Act of 2008
3.2Requirements Traceability
This section must describe the methods used to track requirements to specific test cases.

The <<name of project>> Requirements Traceability Verification Matrix (RTVM) documented traceability relationships between requirements, rules, and associated work products, as well as identifying which requirements could not be tested. The <<SAT/FIT>> team used <<Word, Excel, Access, Req Pro/Test Manager, etc.>> to prepare test cases that traced requirements. See Appendix E - Requirements Traceability Verification Matrix.

If Appendix E is not included as part of the EOTSR, then the location of where the RTVM can be found, must be included in this section.
3.3Test Schedule
A Work Breakdown Structure was used to schedule and track activities performed during the <<SAT/FIT>>. The WBS included in this EOTSR is only a snapshot of the current view the day the EOTSR was approved, listed in Appendix F – Work Breakdown Structure. The WBS will be finalized during the Conclusion Phase of the test.

If Appendix F is not included as part of the EOTSR, then the location of where the WBS can be found, must be included in this section.
Section 4.0 Outstanding Issues
4.1Problem Tickets
No Problem Tickets remain open for this test.

or

There were <<Number of Problem Tickets issued>> Problem Tickets issued of which <<number of Problem tickets>> still remain open. There are <<number of open Problem Tickets>> outstanding Problem Tickets open to <<routing symbols responsible organization>> . The test team expects to receive a transmittal prior to production start up that will address these issues. The test team will close Problem Tickets upon receipt and verification of the correction transmittal(s).

The open Problem Tickets are:

<<Priority>> - <<Problem Ticket number>>, <problem description>>

If a transmittal has been received to correct the problem, but it has not been verified, then...
Transmittal(s) <<transmittal number(s)>> <<was/were>> received on <<date received>> to correct Problem Ticket(s) <<Problem Ticket number(s)>>, however the <<SAT/FIT team name>> has been unable to verify the correction.

A list of all Problem Tickets issued for this test can be found in Appendix D – Problem Ticket Summary Report.
4.2Other Concerns
Specify any other concerns of significance.

Identify any Unauthorized Access (UNAX) or other unusual security incidents. Identify how the incident was handled. Reference IRM 10.8.1, Information Technology (IT) Security Policy and Guidance, or UNAX documentation for proper procedures to follow.

Examples of other concerns:

•Documentation guidelines initially were not clearly defined. The documentation containing the literal definition of transaction codes, transaction code values and sub-condition codes was received after the test began. Due to late receipt of documentation, TAD was unable to test all transaction codes as referenced in Section 2.3 – Test Constraints.
• There were multiple delays throughout the test due to environmental instability resulting from issues with Websphere and AMDAS. In addition, daily transmittal installation was conducted between 6:00 a.m. and 9:00 a.m., resulting in significant loss of availability of the test environment. In an effort to recover schedule, TAD augmented staff with testers from within the domain, and the test completion date was extended to …
• Test environment and resource issues were encountered due to multiple testing efforts (Capacity, performance, security, integration, penetration, infrastructure) taking place concurrently with SAT in the EITE.
This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.
Appendix B Software Received
The <<project and/or release name>> project folder contains a complete listing of all software transmittals. The following is a list of all transmittal(s) received during the test.

Uniquely identify all software (ECL/JCL, executable programs, scripts, etc.) tested.

All machine operating systems are capable of generating standard directory listings that identify the library or directory, transmittal date, module name and version, module type, module size, and date/time of creation or modification. They can be generated and stored to a file to be formatted for the EOTSR.

Tier 1 Systems
Attach IBM library/directory listings Attach UNISYS library/directory listings of the most recent transmittals

Tier 2 Systems
Attach Pyramid, SUN, or other library/directory listings

Tier 3 Systems
Attach MS Windows XP library/directory listings
Appendix C System Interfaces
Attached are the Test, Assurance & Documentation Interface Database Agreements and/or Files Communication Status Report (FCSR) for <<name of project and/or release>> project. The <<name of project and/or release>> project folder contains a complete set of the System Interfaces listed below:

or

Attached are the System Interfaces or artifact(s) for the <<name of project and/or release>> project that were coordinated with <<other agencies (not TAD interfaces, agencies determined by the project)>>. The <<name of project and/or release>> project folder contains a complete set of the System Interfaces that were coordinated with <<other agencies (not TAD interfaces, agencies determined by the project)>> listed below:

Note: Please ensure all interfaces listed in the SAT Plan and subsequent revisions are attached in Appendix C. Any deviations should be explained.
This image is too large to be displayed in the current screen. Please click the link to view the image.
Appendix E. Requirements Traceability Verification Matrix
A Requirements Traceability Verification Matrix (RTVM) established the relationships between the requirements tested and the associated test cases. Identify which requirements could not be tested. The RTVM for the <<name of project and/or release>> is as follows:

or

A Requirements Traceability Verification Matrix (RTVM) established the relationships between the requirements tested and the associated test cases. Identify which requirements could not be tested. A copy of the RTVM is located in the TAD Cabinet in DocIT, <<name of project and/or release>> Project Folder, DocIT number <<insert DocIT number>>...
Appendix F. Work Breakdown Structure
A Work Breakdown Structure was used to schedule and track activities performed during <<SAT/FIT>>. The WBS for the <<name of project and/or release>> <<SAT/FIT>> is as follows:

or

A Work Breakdown Structure was used to schedule and track activities performed during <<SAT/FIT>>. A copy of the WBS is located in the TAD Cabinet in DocIT, <<name of project and/or release>> Project Folder, DocIT number <<insert DocIT number>>.
This image is too large to be displayed in the current screen. Please click the link to view the image.
INSTRUCTIONS
Project/ Release The name of the project and the release.
ID An alphanumeric identifier that specifies the project, release package, test phase and a sequential numeric identifier such as CADE RP4 PSIT-001.
Organization The name of the organization responsible for originating the deferral or waiver request.
Date Date the request was initiated.
Submitted By Name of person responsible for originating the deferral or waiver request.
Purpose Brief description of the purpose of the request.
Number of Deferrals Total number of test cases to be deferred.
Number of Waivers Total number of test cases to be waived.
Test Case Deferrals Itemized list of deferrals requested. The list must specify the following:
•Test Case/Script ID - Affected test case or test script ID
•Requirement ID(s) – Requirements ID associated with the test case or test script
•CR/ITAMS #'s - Change Request (CR) and ITAMS applicable to the test case or test script
•Rationale - Rationale for the deferral request.
Test Case Waivers Itemized list of waivers requested. The list must specify the following:
•Test Case/Script ID - Affected test case or test script ID
•Requirement ID(s) – Requirements ID associated with the test case or test script
•CR/ITAMS #'s - Change Request (CR) and ITAMS applicable to the test case or test script
•Rationale - Rationale for the waiver request.
Approval Signature lines for representatives of approving organizations. (e.g., Business Customer, Application Development, Project Office, Test Team, and TPO)
•Organization/Role - Organization name, position title and symbols
•Name - Name of Approver(s)
•Signature - Signature of individual or authorized approver(s)
•Date - Date of signature
Appendix H. Live Data Waiver
Attach a copy of the Live Data Waiver

or

Identify location of the Live Data Waiver.
Acronyms
List all acronyms used in this document.

below are examples
ITAMS Information Technology Account Management System
SAT Systems Acceptability Test
   
   

Exhibit 2.6.1-9 
Work Product Review Form

This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 2.6.1-10 
Test Environment Checklist

Test Environment Checklist
  Comments
1. Is there an existing SAT / EITE test environment?

0x2713 Yes 0x2713 No 		 
  •What is it located?  
  •What is the current OS and HW/SW available?

• Does it meet the current requirements? 		 
  •Submit requests for upgrades, enhancements and additions to hardware if needed.  
2.Is there a need for establishing a SAT / EITE test environment?

0x2713 Yes 0x2713 No 		 
  •Where will that system be located (ECC or EITE/DITE)?  
  •What are the processing power requirements (same as Production)?  
3.What are the estimated storage requirements for both the initial release and for the next three fiscal years if known?  
  •Location of the storage?  
  •SAN or independent storage?  
  •ATL storage?  
  •Off-site Storage?  
4.What are the platform requirements for both the initial release and for the next three fiscal years?  
5.What software will the project be using? (so as to determine associated SW maintenance costs over the next three fiscal years for O&M)  
  •What is the Operating system?  
  •What is the Database Management System?  
  •Other major COTS products, particularly Infrastructure related (e.g. Business Objects, PeopleSoft, WebMethods, Veritas, WebSphere, Rational)  
6.What are the human resource requirements?  
  •DBA / SA support?  
  •Security support?  
  •CSA support for Incident / Problem Management?  
  •SW customization required for OS / DBMS / other COTS?  
  •Support required for DITE / EITE?  
  •Contractor or Gov’t FTE?  

Exhibit 2.6.1-11 
Test Readiness Review

TRR Agenda for <<Name of Project>>
A. Time, Date, Location
Your attendance is requested at the Test Readiness Review (TRR), which has been scheduled for <<hh:mm - hh:mm>> on <<mm/dd/yyyy>> . The meeting will be held at <<insert meeting location; building, conference room number and Teleconference number and access PIN>>
 
B. Purpose and Scope
This review will cover the test readiness for the following systems and components [list all systems and components].
 
C. Objectives
In order to assess the test readiness of the above system/components, several documents will be discussed and a number of topics will be addressed at the TRR. The topics listed include the following but are not limited to:
 
  1. The Business Customer will discuss the following items:
   
* Procedures for late changes to requirements
* Inventory of documentation delivered
* Delivery schedule for remaining documentation
* Legislative and other potential changes
* Implementation dates for production
* Customer involvement during the test
* Business Customer points of contact
     
  2. The Application Development Team will discuss the following items:
   
* Status of inventory of project/system software to be transmitted
* Information contained in transmittal memorandum
* Inventory of documentation being or previously delivered
* Response(s) to UWR/Change Requests incorporated into the software
* Outstanding problems from developer testing and their impact
* List of software components not tested
* Project/System Software not compatibility tested
* Dependencies (e.g., Stubs and/or drivers used during unit testing and their impact)
* Schedule for future deliveries
* Application Developers points of contact
     
  3. The Test Organization Team will discuss the following items:
   
* Test Plan (SAT/FIT)
* RTVM
* Test Cases
* Test Data
* Dependencies
* Testing constraints
* Schedule
* Interfaces
* Customer involvement
* Problem reporting
* Status reporting
* Test Organization points of contact
     
  4. The Database/Systems Administrator will discuss the following items:
   
* Readiness of the test environment
* Readiness of any/all databases required for the project to be tested
* Procedures for routine and emergency transmittals
     
  5. TRR Findings and Readiness Concerns:
   
* An open forum will be provided to discuss any other issues.
* Collectively the stakeholder will determine the readiness of the system to proceed with testing. The decision to proceed with testing is made based on a successful TRR outcome.
* If the TRR is not successful, follow-up meetings will be conducted to address all outstanding concerns. A new version of the SAT Plan must be issued with revised dates.
* The determination regarding the readiness of the system for testing will be documented in a memorandum to all participants within five work days.
     
  Attachment

TRR Checklist
<<Project and/or Release Name>>
 
Test Readiness Review (TRR) Checklist
 
Test, Assurance & Documentation
<<Systems Acceptability Test (SAT)/Final Integration Test (FIT)>>
Test Readiness Review (TRR) Checklist
For <<Project and/or Release Name>>
 
Welcome and Introduction
Project/System:
Release/Version:
Meeting Information
Category Information
Date  
Time  
Location  
Teleconference Number  
PIN Access Code  
Attendees (roll call and sign-in)
Community Individuals Name
TAD  
<<MITS PMO>>  
<<Business Customer>>  
<<Application Development>>  
   
   
1. Business Customer Briefing
  Comments
1. Have procedures for late changes to requirements been established?

0x2713 Yes 0x2713 No
  
2. Have procedures been established for delivery of documentation (e.g., E-mail, DocIT, hard copy, etc.)?

0x2713 Yes 0x2713 No
  
3. Has inventory of documentation been delivered to the test team (e.g., IRMs, User Guides, Forms, etc.)?

0x2713 Yes 0x2713 No

If No, list documentation not included in the inventory delivered in "Comments" .
  
4. Has the delivery schedule for remaining documentation been determined?

0x2713 Yes 0x2713 No 0x2713 N/A

If Yes, provide delivery dates in "Comments. "
 
5. Is there a possibility of any legislative and/or other potential changes?

0x2713 Yes 0x2713 No 0x2713 N/A

If Yes, provide explanation in "Comments " .
  
6. What are the implementation date(s) for Production?  
7. To what extent will the Business Customer be involved with the test?  
8. Have the Business Customer point(s) of contact information been provided to the test team?

0x2713 Yes 0x2713 No
  
 
2. Applications Development Briefing
  Comments
1. Has all development testing been completed?

0x2713 Yes 0x2713 No

If No, when will the testing be completed?
  
2. Have procedures been established for delivery of software (e.g., SQuA, Endevor, ClearCase, emergency transmittal, etc.)?

0x2713 Yes 0x2713 No

If Yes, has a copy of the delivery schedule been provided to the test team?

0x2713 Yes 0x2713 No

If No, provide explanation in "Comments " .
  
3. Will all project system software be delivered on the agreed transmittal date?

0x2713 Yes 0x2713 No

If No, provide the delivery schedule for remaining software in "Comments " .
  
4. List the transmittal memorandum number(s) for this test in "Comments" ?

Was a copy of the transmittal memorandum provided?

0x2713 Yes 0x2713 No
  
5. Have procedures been established for delivery of functional/operational documentation (e.g., DocIT, hard copy, E-mail, etc.)?

0x2713 Yes 0x2713 No
  
6. Has all system/application documentation such as design and operational documentation been provided (e.g., FSP, CPB, COH, PRP, CRL, ICD, etc.) to the test team?

0x2713 Yes 0x2713 No

If No, list documentation not included in the inventory delivered in "Comments" .
  
7. Has the delivery schedule for remaining documentation been determined?

0x2713 Yes 0x2713 No 0x2713 N/A
  
8. Were there any outstanding problems from developer testing?

0x2713 Yes 0x2713 No

If Yes, what was their impact?
  
9. Were any software components not test?

0x2713 Yes 0x2713 No

If No, list software components not tested in "Comments" .
  
10. What project/system software was not compatibility tested?
  
11. Were any dependencies identified (e.g., stub or drivers) during testing?

0x2713 Yes 0x2713 No

If Yes, list the dependencies in "Comments" .

What was the impact of the dependencies on the test.
  
12. Have the Applications Development point(s) of contact(s) information been provided to the test team?

0x2713 Yes 0x2713 No

Include individual program responsibility in the list of contacts.
  
 
3. Test Organization Briefing
  Comments
1. Has an approved Test Plan (SAT/FIT) been distributed to all stakeholders?

0x2713 Yes 0x2713 No

If No, when will the test plan distributed?
  
2. Has the RTVM been provided and verified for accuracy as part of the test plan?

0x2713 Yes 0x2713 No

If No, provided an explanation in "Comments " .
  
3. Have the test cases/test scripts been completed?

0x2713 Yes 0x2713 No

If No, will the test cases/test scripts be ready for the start of the test?

0x2713 Yes 0x2713 No

If No, provide explanation for test cases/test scripts not ready in "Comments " .
  
4. Has test data been created?

0x2713 Yes 0x2713 No

Will Live data be used for testing?

0x2713 Yes 0x2713 No

If Yes, has a Live Data Waiver been approved?

0x2713 Yes 0x2713 No

If Yes, identify location of Live Data Waiver in "Comments" .
  
5. Are there any critical items or tasks on which testing is dependent?

0x2713 Yes 0x2713 No

If Yes, list the items or tasks in "Comments" and the impact of the dependencies on the test.
  
6. Are there any testing modules, components or pieces of functionality that will not be tested?

0x2713 Yes 0x2713 No

If Yes, have they been identified as constraints in the test plan?

0x2713 Yes 0x2713 No

If No, identify constraints not in the test plan in "Comments" .

These constraints must be identified in the EOTSR.
  
7. Has the WBS been provided and verified for accuracy as part of the test plan?

0x2713 Yes 0x2713 No

If No, provide explanation in "Comments" .
  
8. Have all interface agreements with other systems (internal and external) been identified and established for testing?

0x2713 Yes 0x2713 No 0x2713 N/A

If No, provide explanation in "Comments" .
  
9. In addition to the Business Customer are there any other Customer(s) (e.g., CI, end user, or outside organization (bank), etc.) participating in the test?

0x2713 Yes 0x2713 No

If Yes, to what extent will the Customer(s) be involved with the test?
  
10. Have problem reporting and resolution procedures been identified and documented?

0x2713 Yes 0x2713 No

Have overage procedures been identified and documented?

0x2713 Yes 0x2713 No

Has the SAT ID been established for ITAMS?

0x2713 Yes 0x2713 No
  
11. Have status reporting procedures been identified and documented?

0x2713 Yes 0x2713 No

How often will status reporting occur (e.g., daily or weekly)?
  
12. Have all 5081s been submitted?

0x2713 Yes 0x2713 No 0x2713 N/A
  
13. Have logon capabilities been established for all equipment requiring logon?

0x2713 Yes 0x2713 No 0x2713 N/A
  
14. Have test tools been configured and ready for use (e.g., Rational Test Manager, Rational ClearQuest, Requisite Pro or other approved project specific test tools)?

0x2713 Yes 0x2713 No 0x2713 N/A
  
15. Has development of the EOTSR been discussed and scheduled?

0x2713 Yes 0x2713 No
  
16. Have the SAT/FIT test team point(s) of contact(s) information been provided to the Business Customer and Applications Development?

0x2713 Yes 0x2713 No

Include individual tester responsibility in the list of contacts.
 
 
4. Database/System Administrator Briefing :
  Comments
1. Has the test environment(s) readiness been verified?

0x2713 Yes 0x2713 No
  
2. Has the readiness of any/all databases required for the project to be tested been verified?

0x2713 Yes 0x2713 No
  
3. Have procedures for routine and emergency transmittals been established?

0x2713 Yes 0x2713 No
  
4. Have the Database/System Administrator point(s) of contact(s) information been provided to the test team?

0x2713 Yes 0x2713 No
  
 
5. TRR Findings and Readiness Concerns
  Comments
1. If the project/system is ready for SAT/FIT?

0x2713 Yes 0x2713 No

If not, list issues and concerns below.
  
List any issues and/or concerns:
 
 
 
2.. Schedule a follow-up TRR?

0x2713 Yes 0x2713 No

If Yes, an agenda confirming the date, time and location, as well as the topics to be covered, will be sent to all participants.

  

Exhibit 2.6.1-12 
TRR Memo - System is Ready

<<IRS Letterhead>>

<<mm/dd/yyyy>>



MEMORANDUM FOR DISTRIBUTION

 

 
FROM: Chief, <<Section Name and Symbols>>

 
SUBJECT: <<Project and/or Release Name>> Test Readiness Review Findings

 

 
The Test Readiness Review for <<Project and/or Release Name>> was held on <<mm/dd/yyyy>> . After discussing all issues, it was determined the system is ready for formal <<Systems Acceptability Test or Final Integration Testing>> to begin.

If applicable The following issues do not impact the readiness of the system for testing; however, they must be resolved/corrected timely to avoid delaying the test schedule.
If applicable The following issues do not impact the readiness of the system for testing; however, they must be resolved/corrected timely to avoid delaying the test schedule.
<<Issue #1...explain issue>> must be resolved by <<name of individual(s) responsible>> by <<mm/dd/yyyy>> .
<<Issue #2....explain issue>> must be resolved by <<name of individual(s) responsible>> by <<mm/dd/yyyy>>.
<<Issue #3....explain issue>> must be resolved by <<name of individual(s) responsible>> by <<mm/dd/yyyy>>.

Distribution

example of distribution list, tailor as appropriate to include all participants
Project Manager
Customer organization
Applications Development organization
Database Administrator organization
Test organization
Other organization

Exhibit 2.6.1-13 
TRR Memo - System is not Ready

<<IRS Letterhead>>

<<mm/dd/yyyy>>



MEMORANDUM FOR DISTRIBUTION

 

 
FROM: Chief, <<Section Name and Symbols>>

 
SUBJECT: <<Project and/or Release Name>> Test Readiness Review Findings

 

 
The Test Readiness Review for <<Project and/or Release Name>> was held on <<mm/dd/yyyy>> . After discussing all issues, it was determined the system is not yet ready for formal <<Systems Acceptability Test or Final Integration Testing>> to begin.

The following issues must be resolved/corrected before testing can begin:

<<Issue #1....explain issue>> must be resolved by <<name of individual(s) responsible>> by <<mm/dd/yyyy>>
<<Issue #2....explain issue>> must be resolved by <<name of individual(s) responsible>> by <<mm/dd/yyyy>>
<<Issue #3....explain issue>> must be resolved by <<name of individual(s) responsible>> by <<mm/dd/yyyy>>

Pending the resolution of these issues, a follow-up TRR is scheduled for <<insert date of meeting, location, building, conference room number and Teleconference number and access PIN>>. An agenda will be forwarded to all participants.

Distribution

example of distribution list, tailor as appropriate to include all participants
Project Manager
Applications Development organization
Database Administrator organization
Customer organization
TAD organization
Other participants

Exhibit 2.6.1-14 
Problem Ticket Resolution Guide

If Status Of Problem Ticket Is: And Then
Open Test is completed Identify the unresolved Problem Ticket(s) in the End of Test Status Report (EOTSR)
SAT-Pending Solution is correct Close the Problem Ticket
SAT-Pending Software solution is incorrect select "Reopen" .
SAT-Pending Documentation correction pages are not transmitted concurrently with the Problem Ticket resolution select "Reopen" .
SAT-Pending and concurrent transmittal of documentation Documentation is incorrect select "Reopen"
SAT-Pending with an explanation Explanation acknowledges the problem exists but does not address corrective action select "Reopen"
SAT-Pending Correction promised in next revision or transmittal, with no scheduled transmittal date included select "Reopen"
SAT-Pending with a scheduled transmittal date Deliverable is not transmitted as scheduled select "Reopen"
SAT-Pending with an explanation Problem originates in the requirements or another program Close and reissue Problem Ticket to the correct organization
Open New transmittal sent but the problem(s) remain unresolved select "Reopen"
Open Correction transmittal resolves the problem but creates a new problem Close the original Problem Ticket and issue a new Problem Ticket
Open with duplicates The duplicate was issued in error Associate duplicate Problem Ticket(s) with original and close the duplicate
Open Issued in error Contact the receiver, and close the Problem Ticket as No Trouble Found (NTF)
Closed Ticket was erroneously closed and/or issue not resolved Reopen ticket*

"*" Please NOTE - only Priority 3 tickets closed within 30 days can be "Reopened."

Exhibit 2.6.1-15 
ITAMS Problem Report

This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 2.6.1-16 
ITAMS Overage Report

This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 2.6.1-17 
Post Implementation Review

PIR Agenda for <<Project Name>>
 
A. Time, Date, Location

Your attendance is requested at the Post-Implementation Review (PIR) which has been scheduled for <<hh:mm - hh:mm>> on <<mm/dd/yyyy>>. The meeting will be held at <<insert meeting location; building, conference room number and Teleconference number and access PIN>>.

B. Purpose and Scope

This is a formal end of test meeting held to review the test and identify process improvement areas.

C. Objectives

Items to be discussed with customers, developers, and Test Assurance & Documentation representatives include the following, but are not limited to:


1. Deliverables

2. Testing Issues

3. Communication

4. Lessons Learned

5. Wrap-up
 
Attachment

PIR Discussion Sheet
Post-Implementation Review (PIR) Discussion sheet for <<Project and/or Release Name>>
 
Welcome and Introduction
Project/System:
Release/Version:
Meeting Information
Category Information
Date  
Time  
Location  
Teleconference Number  
PIN Access Code  
Attendees (roll call and sign-in)
Community Individuals Name
TAD  
<<MITS PMO>>  
<<Business Customer>>  
<<Application Development>>  
   
   
1. Deliverables Comments


1. Identify any concern(s) with the delivery of the documentation and what, if any, impact it had on the test.  
2. Identify any concern(s) with the delivery of the programs and transmittals and what, if any, impact it had on the test.  
3. Are there any findings from the documentation that need to be discussed?  
4. Where the scheduled dates met?

If not, why not and what can be done in the future to resolve this? 		 
5. How was the test affected by the Data Conversions (i.e., MF, TIF, CSP, etc) and/or Database Conversions?  
6. Were there any late or last minute changes to requirements or new UWRs submitted after the due date?

How was that handled? 		 
2. Testing Issues Comments
1. Were there any Problem Tickets issued during the test.

How were they resolved? 		 
2. Were the Problem Tickets completed accurately and concisely?

Were they useful in resolving the Problem Ticket issues(s)? 		 
3. Are there any outstanding Problem Tickets?

What steps are being taken to resolve them? 		 
4. Evaluate and discuss Production Startup.

If any error(s) were found, could TAD have discovered the error(s) during testing? 		 
5. Did any barriers arise because of the existing test procedures and schedules?

What can be done to improve the processes? 		 
6. Were any constraints identified during the test and what steps were taken to resolve them?

What contingency plans were in place? 		 
7. How did the availability of resources impact the test?

What, if anything, needs to be done in the future to revamp resource allocation? 		 
3. Communication Comments
1. Was the information provided at the status meetings informative and useful?  
2. Was the information from the status reports organized, informative and useful?  
3. What issues, if any were there with the current status report and status meeting procedures?

What will be done to address these items? 		 
4. Lessons Learned Comments
1. How can the test be improved?  
2. Is there anything TAD employees can do to assist the customers' and development processes?  
3. Are there any process improvements the customers and developers would like to submit to TAD?  
5. Upcoming Tests<<Identify next testing period, i.e., July 2008; January 2009>> Comments
1. Discuss all participants' responsibilities and duties for upcoming test(s).  
2. Identify new UWRs (i.e., Legislative, Sustaining Operations, Rust Replacement, Modernization, and/or Enhancement).  
3. Discuss upcoming Prioritization of projects and/or programs to be tested.  
4. Discuss and/or negotiate upcoming delivery dates and schedules.  
5. Identify any resources not available during the last test.

What resources will or will not be available for the upcoming test(s)? 		 
6. Wrap-Up Comments
1. Identify action items and commitments.  
2. Any other issues?  

Exhibit 2.6.1-18 
Files Communication Status Report (FCSR)

This image is too large to be displayed in the current screen. Please click the link to view the image.
Files Communication Status Report (FCSR) Instructions


Test Reference # - Unique ID number to be used for reference to this compatibility test document. For example, CT-1-2009-1 (Compatibility Test Jan 2009 Test 1).


Originator Information – Enter originator name, date, telephone number and organization. symbols.


Testing condition – Enter the condition to be tested and the associated test case document ID.


File(s) creation date – Enter the date the test file was created.


Recipient for impacted section – Enter the name, telephone, and symbols.


File ID(s) – Enter the identification numbers of the test file(s)


DSN – Enter the actual data-set name for the test data.


Comments/Status – Enter any information relating to the status of the test to date, description of data file(s), documentation of problems and solutions, volume figures, output-codes, etc. Note the specific absence of types of data from the test file.


Concurrences – The originating section chief must enter the date the FCSR was forwarded to the first impacted section chief. The impacted section chief(s) must enter the date their part of the compatibility testing was completed.

Exhibit 2.6.1-19 
Enterprise File Transfer Utility Registration (EFTU) Form 13605

This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 2.6.1-20 
Control and Authorization for File Transfer- Part I Form 12038

This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 2.6.1-21 
Control and Authorization for File Transfer- Part II Form 12038A

This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 2.6.1-22 
Request for Lab Access Form

This image is too large to be displayed in the current screen. Please click the link to view the image.
Request for Lab Access Form Instructions
Completing the Request for Lab Access Form:
  (1) The following instructions and procedures are keyed to the blocks on the Request for Lab Access Form (example on following page). The form is available from the Source Code and Documentation Control (SCDC) Lab Access Coordinator (LAC) or the following web-site: http://tad.web.irs.gov/scdcbr/t1sc/Lab_Access.htm
  (2) Complete the Request for Lab Access Form as follows:
    • Blocks 1-4: Requestor Information. Enter the requestor's name, date, office phone number, office location, and office symbols.
    • Blocks 5-7: Lab Access Information. Check which lab(s) the requestor needs access to, enter the beginning and ending dates access is needed for and enter the purpose for the access. When extended access is needed, enter March 31 of the following year for the ending date.
    • Block 8: ProxCard Number. For extended access, enter the requestor's ProxCard number. For temporary access, leave this block blank.
    • Block 9: Check either extended access or temporary access.
    • Blocks 10-12: Requestor's Manager Information. Print the Section Chief's name and office phone number. The Section Chief's signature is required.
    • Blocks 13-14: Escort Information. When requesting temporary access, print the requestor's escort's name, office phone number, and office location.
    • Block 15: The authorizing SCDC System Manager will sign here.
    •. Block 16: The authorizing SCDC LAC will sign here.
    • Block 17: Special Instructions: Use this area to enter any comments, special instructions, or requests, such as training requests.
  (3) After completing Blocks 1 - 14 and 17 (if applicable), forward the completed form to the SCDC LAC. Employees at the NCFB should deliver the form to the Lab Access box at B6-275. Employees not at NCFB may mail the form to the address in IRM 2.6.1.11.5.5. The form may also be faxed to the LAC but the original document must be provided to the LAC within five workdays.
  (4) All lab access requests require at least two workdays to process.

Exhibit 2.6.1-23 
National Office Directed Travel (NODT) Letter

This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 2.6.1-24 
Release Readiness Schedule & Status Report

This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 2.6.1-25 
Weekly Exception Report and Template

(1) Template for preparing the Weekly Exception Report.
   
Weekly Exception Report
Week ending mm/dd/yyyy
A list of this week's overage Problem Ticket(s) is located on the Test Assurance & Documentation Weekly Status Accounting Reports' Overage Report which may be accessed through the link below.
http://tad.web.irs.gov/metrics/status%5Faccounting/
[Project Name] [Developer's Symbols]
[Separate symbols with a slash when there are multiple developers.]
  Overall Status —[Use this template when there are significant issues which impact the SAT End Projected and Actual date(s) before an expected delivery date is reached. This template can also be used if a project is on schedule and there is a recurring issue(s) that requires executive level exposure or any other circumstance or delay deemed appropriate by the Branch Chief.]
Testing is [on schedule or number of days/weeks behind SAT End Projected schedule] for a mm/dd/yyyy completion. [Concisely state the reason if behind schedule.] [State the risk and mitigating action.]
  Documentation — [Use this template when scheduled documentation transmittal or delivery is incomplete or overdue. Concisely describe impact on test, as applicable.]
Documentation from [developer, customer or support symbols] is [incomplete or overdue]. [Describe when the documentation is expected.]
  Transmittals — [Use this template when scheduled program transmittals are incomplete or overdue.]
The transmittal(s) for [project name(s) or name of run(s) or name of program(s)] is/are [incomplete or overdue]. [Describe when the transmittal(s) is/are expected and concisely describe impact on test, as applicable.]
  Problem Tickets —
[Use this template to report Priority 1 Problem Tickets.]
Priority 1 Problem Ticket NNNNNNN was issued to [organizational symbols] on mm/dd/yyyy for [concisely describe problem.]
and/or
[Use this template to report Priority 1 or 2 Problem Tickets that become overage.]
Priority [1 or 2] Problem Ticket NNNNNNN is [Use NN if the number is greater than ten. If the number is ten or less, use the word.] NN days overage. [Concisely state the reason for the overage status and action taken during reporting week.]
and/or
[Use this template to report Priority 1 or Priority 2 Problem Ticket overage closures.]
Priority [1 or 2] Problem Ticket NNNNNNN was closed on mm/dd/yyyy.
and/or
[Use this template to report Priority 3 Problem Tickets that become overage.]
There [is/are] [Use NN if the number is greater than ten. If the number is ten or less, use the word.] overage Priority 3 Problem Ticket(s).
and/or
[Use this template to report Priority 3 Problem Ticket overage closures.]
There [was/were] [Use NN if the number is greater than ten. If the number is ten or less, use the word.] Priority 3 Problem Ticket(s) closed.
and/or
[Use this template to report Priority 3 Problem Ticket overage closures and Priority 3 Overage Problem Tickets remaining open.]
There [was/were] [Use NN if the number is greater than ten. If the number is ten or less, use the word.] Priority 3 Problem Ticket(s) closed and [NN] which remain overage.
  Contact — Section Chief, (xxx) xxx-xxxx
(2) Example of a Weekly Exception Report.
   
Test Assurance & Documentation Weekly Exception Report
Week ending mm/dd/yyyy
A list of this week's overage Problem Ticket(s) are located on the Test Assurance & Documentation Weekly Status Accounting Reports' Overage Report which may be accessed through the link below.
http://tad.web.irs.gov/metrics/status%5Faccounting/
XYZ - TY2009 Annual Test OS:CTO:AD:TA:XX:XX
  Overall Status — The test is approximately eight calendar days behind the scheduled mm/dd/yyyy completion date. Limited testing time was available this week due to a virus on the network. Significant response delays were encountered when downloading TIF data files, accessing the database, and conducting SQL searches. The XYZ SAT Team is working overtime to get back on schedule.
  Transmittals — The transmittal for the Return Chargeout program is incomplete. The current version does not contain full functionality. The new version is due by mm/dd/yyyy.
  Problem Tickets — Priority 2 Problem Ticket ####### is two days overage. A correction transmittal is expected on mm/dd/yyyy.
  Contact — Section Chief, (xxx) xxx-xxxx

Exhibit 2.6.1-26 
SAT Weekly Testing Report

This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 2.6.1-27 
Glossary

The following table defines key terms used in this document.

Accessibility Testing — Testing to determine whether a product satisfies Federal law that IT products used by the Federal government are accessible to persons with disabilities.
Agenda — A schedule of topics to be dealt with in a meeting.
Annual FIT — Annual FIT occurs immediately prior to filing season start-up for any calendar year. The scope of this test includes controlled data testing of threads supporting Submission Processing, Tax Account Maintenance and Customer Service. The Annual FIT also includes a simulation of the production start-up that occurs in January. The Annual FIT is executed in the last three months of each year.
Artifacts — The tangible result (output) of an activity or task performed by a project during the life cycle. Artifacts may be designated as work products or deliverables.
Business System Requirements Report (BSRR) — Is a Requirement Report that documents a feasible. quantifiable, verifiable set of requirements that define and bound the business system or subsystems(s) being developed or enhanced by the project. These requirements form the basis for the business solution design, development, integration, testing, and deployment.
Business System Concept Report (BSCR) — Documents the vision for a single business area or system, and a high-level business system (i.e. a system inclusive of all six solution perspectives that will achieve that vision. The BSCR includes specification of the solution business aspects (major business processes, organizations, and locations), technical aspects (data, applications, and technology), and infrastructure for development, to a conceptual-level of detail.
Business System Architecture Report (BSAR)— Is an Architecture Report that specifies the business and technical architectures — including business processes, organizations, locations, applications, data, and technologies — for a particular business area or business system. The BSAR provides the basis from which system design proceeds.
Capacity Testing — A process of testing the program(s) under heavy load by putting a large number of inputs, beyond the handling capacity, of the application.
Computer Operator Handbook (COH) — Provides detailed instructions to a computer operator on the proper execution and validation of a run or program.
Compatibility Data — Represents data passed through contiguous run stream during development or systems acceptability testing.
Compatibility Testing — A process of testing which ensures that unit and string tested programs accurately process data received from external programs/systems and accurately pass this data forward to subsequent programs/systems. The emphasis of this testing should be on data format, physical media (block/record length), blocking factors, padding and controls.
Computer Program Book (CPB) — A set of books that document processing and operating requirements.
Controlled Data — Data developed to test a specific set of conditions and expected results for a particular test objective. All controlled data tests are documented as test cases in the FIT Test Case Database.
Create Test Case — The activity that develops the document that describes the test cases used to verify program instructions, features, or the combination of features to be tested.
Customer — A generic term which denotes a customer of an information processing service. The customer or user is usually a National Office or a field organization with an established information processing need.
Desk Checking — The manual simulation of program execution or flow to detect errors and defects.
Design Specification Package (DSP) — A functional requirement specification which traces to one or more components during the design/development phase.
Design Specification Report (DSR) — Consist of two parts. The DSR Part 1, documents the logical design of the data and application perspectives. The DSR Part 2, documents physical design of the solution from all applicable perspectives.
Development, Integration and Testing Environment (DITE) — Supports all pre-production activities, from application development to integration and acceptance testing. It is made up of dispersed groups of computing platforms and other equipment used and maintained by IRS' system development and operations organizations and engaged contractors. It includes development and test environments at Computing Centers and new environments created by the Modernization program: Software Development Lab (SDL), Virtual Development Environment (VDE) and Enterprise Integration and Testing Environment (EITE).
Document Management for Information Technology (DocIT) — A web-based electronic document management system that has replaced Hummingbird DM. The tool provides documentation control for IT projects within the IRS.
Enterprise Integration and Testing Environment (EITE) — The EITE emulates the IRS production environment in order to enable applications to be tested in a manner that will mimic the production world. The environment supports the Modernization program as well as the modernized portions of the Systems Integration Testing (SIT), Systems Acceptability Test (SAT) and Final Integration Testing (FIT) environment of the IRS.
Executive Control Language (ECL) — UNISYS language used to identify software and hardware resources when running a job.
External Trading Partner (ETP) — An external trading partner is an entity outside the IRS which exchanges data with the IRS. Integration Testing with ETPs is a mandatory testing activity.
External Trading Partner Data — The external trading partner must create and make data available. The data is sent either on magnetic tape or diskette, or via electronic data transfer, and is subsequently used in data processing by the receiver. For output, data should be produced by the program and transmitted electronically to the external entity.
External Trading Partner Testing — Special testing conducted on programs that exchanges files with an entity outside the IRS.
Files Communication Status Report (FCSR) for Compatibility Testing — The form identifies stakeholders and documents compatibility testing conditions/files.
Final Integration Testing (FIT) — A system test consisting of integrated end-to-end testing of mainline tax processing systems to verify that new releases of interrelated systems and hardware platforms can collectively support the IRS business functions allocation to them.
FIT Project - Any instance of FIT, regardless of when it is conducted. Each FIT project requires a FIT Plan.
Functional Specifications Package (FSP) — A document that shows the structured analysis and communicates the functional requirements of the system under development; the major components of the FSP are data flow diagrams, data definitions, and process specifications.
Integration Testing — Testing of combined parts of an application to determine if they function together correctly. Usually performed after unit testing.
Interface Control Document (ICD) — An agreement between multiple organizations that must collaborate to produce the design of the solution interface.
Interface Testing — Testing conducted to ensure that the program or system components pass information and control correctly.
JAWS — Job access with Speech - Sec. 508 disability compliance.
Job Control Language (JCL) — IBM language used to identify software and hardware resources when running a job
Lessons Learned — A written record of ways to improve or obstacles to be avoided that were noted during dynamic testing of a software product.
Live Data — Unmodified, non-sanitized data extracted from taxpayer files, which identifies specific individual or corporate taxpayers. The use of live data must have a justification and its use is strictly prohibited without approval.
Peer Review — Peer review is the review of work products performed by peers during development of the work products to identify defects for correction.
Performance Testing — Determines whether the system undergoing testing can effectively process transactions under expected normal and peak workload conditions, within acceptable response time thresholds. Performance testing will uncover any bottlenecks and capacity constraints that may not have occurred during normal functional testing.
Project Folder(s) — Contains copies of all critical test documentation and may vary in volume depending on the size and/or complexity of the project.
Programming Requirements Package (PRP) — A document that communicates the requirements of the system under development.
Record Layout — Define the order, size and contents of the various fields in a record.
Regression Testing — Testing that is performed after making a functional improvement or repair to a program to ensure the change has not caused problems in other aspects of the program.
Requirements Traceability Verification Matrix (RTVM) — A tool showing the relationship between test requirement and test cases.
Review Test Results — Review of the output from the completed test plan. This could be any type of data output resulting from the execution of the test plan. These results should match those documented in the test package and be coordinated with the test specifications, and, if necessary, could be validated back to the software requirements.
Sanitized Data — Live data which has been altered after being extracted from production files to obscure the identity and location of the taxpayers. Sanitized Data should be treated as live data and at a minimum involve changes to the following: taxpayer names, taxpayer identification number (TIN), addresses and zip codes.
Scenario - Comprised of the event (i.e., type of input data that results in an action), the entry point into the system (e.g., IDRS, ISRP, etc.), and the action. There may be several scenarios per thread.
Schematics — A diagram that represents the elements of a system using abstract, graphic symbols rather than realistic pictures.
Service Level Agreement (SLA) — An agreement between the service provider and a customer that specifies, usually in measurable terms, the level of service, providing a common understanding about services, priorities, responsibilities, etc. Agreements between MITS and entities external to MITS are called SLAs.
Simulated Data — Does not contain live data, and imitates data as it appears on the actual taxpayers files.
Special FIT - Any FIT project that is conducted outside of the annual time frame. A special FIT is conducted at the discretion of TAD management and requires a formal FIT Plan that describes the details of the test.
Software Quality Assurance - Software tool from Arkdata used to control source code on UNISYS platform.
Systems Acceptability Test (SAT) — Testing performed by TAD to independently assess the quality of the application software by testing with controlled data to determine conformance of the system to customer requirements and to aid the customer and developer in determining the system’s production readiness.
TAD — Test, Assurance & Documentation Organization who conducts SAT Testing.
Test Case— A document specifying the test approach for a software feature or combination or features and the inputs, predicted results and execution conditions for the associated tests.
Test Data — Any material (computer records, paper records, databases, etc.) which simulates data as it appears in actual taxpayer files.
Test Environment — The preliminary setup of hardware, resources, data, utilities, etc., required to run a successful test.
Test File — Files used to test software. This can include test data from the developer, generated data, production or live data, converted production data, etc.
Test Plan — Is a document that describes the objectives, scope, approach, and focus of a software testing effort.
Test Results — A documented summary or printed output resulting from the execution of the test plan.
Test Activities — The activity that creates and finalizes test data, based upon the test case specifications, and executes the test steps as described in the test plan. The test results would then be reviewed against the software requirements in the test case specifications.
Test Success Criteria — The expected outcome of tests which verify that a software unit meets its requirements.
Thread - The data flow of a test execution path through the IRS production enterprise. Threads depict which runs are executed and contain an overall view of the systems through which the data passes.
Transmittal Package — Includes the software and files to be deployed, instructions for their deployment, and various documentation such as a description of features and improvements in the new software.
Transmit Software — Prepare, approve, and deliver the software transmittal package to TAD or production.
User Guides — A document designed to assist the individual or organization that uses the system to perform specific functions.
Unit Testing — The top-level activity, conducted by the developer, that detects errors and removes them from software. Independent testing of the smallest units (module or object) of code by the developer.
User AcceptanceTesting — Testing to determine whether people can easily use something (such as web, computer, document or device) for its intended purpose.
Validation — The process of evaluating software at the end of the development process to ensure compliance with requirements from the customer (end user). Data capture validation test consists of a partial run simulating the production cycle that occurred while the data was being captured. The successful execution of processing indicates the required data was captured and loaded properly on the FIT test platforms
Verification — Evaluation performed at the End of a Phase with the objective of ensuring that the requirements established during pervious phase have been met. It is an overall software evaluation activity that includes reviewing, inspecting, testing, checking, and auditing.
Version Control — Provide a means to systematically retain chronological copies of revised programs and program documentation.
Version Description Document — Is how Source Code and Documentation Control (SCDC) Branch within the TAD organization performs version control and promotes software changes through the VDD build process.
Web Testing — Is a computer-based test delivered via the internet and written in the "language" of the internet, HTML and possibly enhanced by scripts

Exhibit 2.6.1-28 
Acronyms

ABS Absolute
ACM Automated Configuration Management
ACS Automated Collection System
AD Applications Development
ADP Automatic Data Processing Handbooks
AFT Automated File Transfer
AIMS Audit Information Management System
ALN Access Locator Number
AUC Austin Campus Center
AWS Alternative Work Schedule
BC Brookhaven Campus
BMF Business Master File
BSAR Business System Architecture Report
BSCR Business System Concept Report
BSRR Business System Requirements Report
CC Cincinnati Campus
CFOL Corporate Files On-Line
CICS Customer Information Control System
CM
Capacity Management or
Configuration Management
CMB Capacity Management Branch
CMM Capability Maturity Model
COH Computer Operator Handbook
COTR Contracting Officer Technical Representative
COTS Commerical-off-the-shelf
CPB Computer Program Book
CR Change Request
CRL
Candidate Requirements List or
Core Record Layout
CUNPL Common Used Non-Production Libraries
DB2 Data Base Management
DBA Data Base Administrator
DITE Development, Integration and Test Environment
DLN Document Locator Number
DMS Data Management System
DocIT Document Management for Information Technology
DSP Design Specification Package
DSSB Distributed Systems Software Branch
ECC Enterprise Computer Center
ECC-DET Enterprise Computer Center - Detroit (DET)
ECC-MTB Enterprise Computer Center - (Martinsburg (MTB)
ECC-MEM Enterprise Computer Center - Memphis (MEM)
ECL Executive Control Language
EFNS Enterprise File Network Server
EFTU Enterprise File Transfer Utility
EITE Enterprise Integration and Testing Environment
ELC Enterprise Life Cycle
EMS Electronic Management System
EOps Enterprise Operations
EOTSR End of Test Status Report
ES Enterprise Services
FCSR File Communication Status Report
FIT Final Integration Testing
FLC File Location Code
FP Field Participant
FSP Functional Specifications Package
FTP File Transfer Protocol
GAT Government Acceptance Test
GEL Government Equipment Listings
GMF Generalized Mainframe
HW Hardware
IBM International Business Machine
ICD Interface Control Document
ICS Integrated Collection System
IDRS Integrated Data Retrieval
IMF Individual Master File
IRM Internal Revenue Manual
IRS Internal Revenue Service
ISRP Information Systems Remittance Processing
ISS IBM Scheduling Section
IRM Internal Revenue Manual
IRS Internal Revenue Service
ISSB Information Systems Support Branch
IT Information Technology
ITAMS Information Technology Asset Management System
ITI Information Technology Infrastructure
JAWS Job Access With Speech
JCL Job Control Language
LAC Lab Access Coordinator
LD Live Data
MADS Martinsburg Application Development Systems
MC Memphis Campus
MF Master File
MFT Master File Tax
MGB Management Governance Board
MITS Modernization Information and Technology Services
NCFB New Carrollton Federal Building
NCTRL Name Control
NDM Network Data Mover
NODT National Office Directed Travel
NTF No Trouble Found
OGE Office of Government Ethics
OC Ogden Campus
OLA Organizations Level Agreement
OS Operating System
PC Philadelphia Campus
PCIOS Processor Common Input/Output System
PIA Project Impact Assessment
PIR Post Implementation Review
PM & RRO Program Management and Release Readiness Organization
POC Point of Contact
PRIME Prime Systems Integration Contractor
PRINT Printer Replacement to Integrate New Tools
PRP Programming Requirements Package
QA Quality Assurance
RCS Request for Computer Services
REL Relative
RTVM Requirements Traceability Verification Matrix
SA Systems Administrator
SAT Systems Acceptability Test
SAT ID SAT Identification Number
SCDC Source Code and Documentation Control
SCP System Control Point
SD Software Deployment
SDL Software Development Lab
SIB System Information Bulletin
SLA Service Level Agreement Package
SOC Sub Object Class
SOW Statement of Work
SPC Submission Processing Center
SQuA Software Quality Assurance
SSA Social Security Administration
TAD Test, Assurance & Documentation
TCDB Test Case Database
TE/GE Tax Exempt and Government Entities
TIF Taxpayer Information File
TIN Taxpayer Identification Number
TP Taxpayer
TPS Tax Processing System
TRIDOC Technical Reference Information Document
TRR Test Readiness Review
TSRS TAD Status Reporting System
UNAX Unauthorized Access
URL Universal Resource Locator
UWR Unified Work Request
VDD Version Description Document
VDE Virtual Development Environment
VOB Version Object Base
WBS Work Breakdown Structure
WRAF Work Request Analysis Form
WRTS Work Request Tracking System

Prev

More Internal Revenue Manual