United States Department of Agriculture (USDA) eGovernment Program

***USDA Proof of Concept Prototype***

***Test Approach***

**Version 1.0**

**June 3, 2003**

![](media/image1.jpeg){width="1.75in" height="1.2666666666666666in"}

Table of Contents

[Introduction 3](#introduction)

[Test Objectives 3](#test-objectives)

[Test Model and Execution Overview
3](#test-model-and-execution-overview)

[Testing Methodology 3](#testing-methodology)

[Execution Schedule 4](#execution-schedule)

[Execution Approach 4](#execution-approach)

[Create System Change Requests (SCRs)
5](#create-system-change-requests-scrs)

[Test Environment 6](#test-environment)

[Browser Side Configuration 6](#browser-side-configuration)

[Entry and Exit Criteria 6](#entry-and-exit-criteria)

#  Introduction

This document outlines the approach to be used for USDA Prototype
testing. Test objectives, test model organization, methodology, test
environment topology, entry criteria and exit criteria are defined in
this approach document.

The Prototype testing includes test scenarios that validate the overall
look and feel and functionality scoped out in the design phase. Testing
will be executed in the production environment after the code is
migrated from the development environment. Pages will be delivered in
six small migrations throughout the two-week testing phase. Issues found
during testing will be logged in an issues tracking tool and re-checked
during subsequent passes of testing.

# Test Objectives

The test objectives are:

-   Validate that the creative design, content, and information
    architecture for the pages defined as in-scope have been implemented
    correctly for the Prototype; and

-   Validate that links to pages provided by external scenarios are
    working and link to the correct page(s).

# Test Model and Execution Overview

## Testing Methodology

Testing verifies that the creative design, content, and information
architecture are properly implemented on the site. Test scenarios
include validating correct images, content, links, functionality, passed
values, and javascript error checking on forms.

The Prototype test model is comprised of six cycles based on the
migrations provided by the development team. The migrations are
described in more detail in the Execution Schedule section of this
document. The test cycles are listed below.

+---------------------+------------------------------------------------+
| **Cycle No.**       | **Script**                                     |
+=====================+================================================+
| **1. Migration 1**  | -   Home Page and Portals                      |
|                     |                                                |
|                     | -   Customize Pages                            |
|                     |                                                |
|                     | -   Prototype Bottom Frame Links               |
+---------------------+------------------------------------------------+
| **2. Migration 2**  | -   Registration Pages                         |
|                     |                                                |
|                     | -   Online Trade Assistance                    |
+---------------------+------------------------------------------------+
| **3. Migration 3**  | -   eLearning                                  |
|                     |                                                |
|                     | -   Food Safety Alerts                         |
+---------------------+------------------------------------------------+
| **4. Migration 4**  | -   EIS                                        |
+---------------------+------------------------------------------------+
| **5. Migration 5**  | -   eGrants                                    |
+---------------------+------------------------------------------------+
| **6. Migration 6**  | -   eExtension                                 |
+---------------------+------------------------------------------------+

Test cycles are defined to match the order of items delivered to the
production environment. Cycles provide a mechanism to structure the
order of testing, to segment the execution of the test, and to
facilitate management and status reporting.

## Execution Schedule

All the test scenarios in the test model are run in their entirety
several times. Each of these iterations is considered a pass. The first
full pass identifies all errors. After the pass is completed, the
development team corrects any issues that were found. These corrected
issues are re-checked during the next pass. If a significant number of
errors still exist after the second full pass, these issues are
corrected and a third full pass is executed. The use of passes reduces
the number of issues found in the system during each pass and helps
eliminate their re-introduction into new releases of code.

Prior to each pass, code is migrated to the production environment. This
approach provides a mechanism for precisely controlling and containing
code changes in the test environment. The production environment will
receive six migrations of code from the development team. The migration
schedule and the items included in each migration are outlined below:

  ------------------------------------------------------------------------------
  **Migration**   **Date**   **Items Included**
  --------------- ---------- ---------------------------------------------------
  Migration 1     6/11/03    Home Page, My USDA Pages, Customize Pages

  Migration 2     6/12/03    Registration Pages, Online Trade Assistance

  Migration 3     6/13/03    eLearning, Food Safety Alerts

  Migration 4     6/18/03    EIS

  Migration 5     6/19/03    eGrants

  Migration 6     6/20/03    eExtension, External Scenario Links
  ------------------------------------------------------------------------------

## Execution Approach

During the Execution Phase, the functional team will use test scripts to
test the prototype site. The prototype test scripts will include
expected results that will be compared to actual results. The execution
process involves the following:

+---+-----------------------+-------------------------------------------+
| * | **Activity**          | **Task**                                  |
| * |                       |                                           |
| \ |                       |                                           |
| # |                       |                                           |
| * |                       |                                           |
| * |                       |                                           |
+---+-----------------------+-------------------------------------------+
|   | **Establish           |                                           |
|   | Production            |                                           |
|   | Environment**         |                                           |
+---+-----------------------+-------------------------------------------+
| 1 | Set-Up equipment      | -   Install browsers                      |
+---+-----------------------+-------------------------------------------+
|   | **Execute Test Pass** |                                           |
+---+-----------------------+-------------------------------------------+
| 2 | Migrate Code          | -   A detailed migration log, which       |
|   |                       |     includes all changes migrated into    |
|   |                       |     the test environment.                 |
+---+-----------------------+-------------------------------------------+
| 3 | Execute a step from   | -   Perform each step in the script       |
|   | the test script       |     exactly as stated.                    |
+---+-----------------------+-------------------------------------------+
| 4 | Compare the actual    | -   Analyze the output                    |
|   | results to the        |                                           |
|   | expected results      | -   Ensure that the output matches the    |
|   |                       |     expected result document listed under |
|   |                       |     the "Expected Result Reference"       |
+---+-----------------------+-------------------------------------------+
| 5 | Document results      | -   If the actual result matches the      |
|   |                       |     expected result, then initial the     |
|   |                       |     "Actual Result" column                |
|   |                       |                                           |
|   |                       | -   If the actual result does not match   |
|   |                       |     the expected result, document the     |
|   |                       |     actual result in write the system     |
|   |                       |     change request (SCR) number in the    |
|   |                       |     "SCR" column.                         |
+---+-----------------------+-------------------------------------------+
| 6 | Close any prior SCRs  | -   For the previous pass (i.e. for the   |
|   | logged for that step  |     2nd pass if you are working on the    |
|   |                       |     3rd pass), ensure that no SCRs were   |
|   |                       |     logged for that step.                 |
|   |                       |                                           |
|   |                       | -   If an SCR was logged for the step on  |
|   |                       |     the previous pass and if there is no  |
|   |                       |     SCR logged to the step on the current |
|   |                       |     pass, document the change by closing  |
|   |                       |     the SCR.                              |
+---+-----------------------+-------------------------------------------+
| 7 | Emergency Migration   | Emergency migration will only be allowed  |
|   |                       | when show-stopper errors (errors that     |
|   |                       | significantly impact the functionality of |
|   |                       | the site) exists                          |
+---+-----------------------+-------------------------------------------+
| 8 | Repeat steps 3 -- 6   |                                           |
|   | for each step in the  |                                           |
|   | scenario script and   |                                           |
|   | for each cycle in the |                                           |
|   | pass                  |                                           |
+---+-----------------------+-------------------------------------------+
|   | **Correct Errors      |                                           |
|   | Causing               |                                           |
|   | Discrepancies**       |                                           |
+---+-----------------------+-------------------------------------------+
| 1 | Review SCRs --        | Test Team Lead task                       |
| 0 | approve, reject or    |                                           |
|   | defer and set         |                                           |
|   | priority              |                                           |
+---+-----------------------+-------------------------------------------+
| 1 | Assign SCRs to        | Lead Developer task                       |
| 1 | programmers based on  |                                           |
|   | priority              |                                           |
+---+-----------------------+-------------------------------------------+
| 1 | Fix SCR               | Programmer task                           |
| 2 |                       |                                           |
|   |                       | -   Make program modification             |
|   |                       |                                           |
|   |                       | -   Set status of SCR to "Fixed" so that  |
|   |                       |     it can be re-tested and closed.       |
+---+-----------------------+-------------------------------------------+
|   | **Correct Errors      |                                           |
|   | Causing               |                                           |
|   | Discrepancies**       |                                           |
+---+-----------------------+-------------------------------------------+
| 1 | When all SCRs are     |                                           |
| 3 | fixed execute the     |                                           |
|   | next Regression Test  |                                           |
|   | pass (steps 2 -- 8)   |                                           |
+---+-----------------------+-------------------------------------------+

## Create System Change Requests (SCRs)

Each time a discrepancy between the actual results and the expected
results is found, a system change request (SCR) will to be created to
track the issue. The discrepancy may be, but is not limited to an error,
a defect, an environmental problem, a usability enhancement or an
incorrect expected result.

Prior to assigning a SCR to the development team, the tester will
perform a preliminary investigation of the discrepancy to avoid
assigning SCRs that result from inaccurate expected results or other
test processing. Each SCR will be prioritized based on the requirements
of the test schedule. Fixing the discrepancy may involve program changes
and/or modifications to the test model. If a program change is required,
the code will be fixed in the development environment and unit tested.
The fix will then be migrated to the test environment to be regression
tested there.

# Test Environment

Testing of the prototype will be conducted in the production
environment. Code and data modifications will not take place in the
production environment. All discrepancies encountered during testing
will be recreated and fixed in the development environment and then
migrated back to the production environment.

## Browser Side Configuration

Three browser test PCs will be used during testing. Each PC will have a
screen resolution of 800x600.

The following table defines which browsers and OS combinations will be
tested:

  --------------------------- ------------------- -----------------------
  **Machine Configuration**   **Netscape**        **Internet Explorer**

  Windows 2000                6.x                 5.5

  Windows 2000                6.x                 5.5

  Windows 2000                7.x                 6.0
  --------------------------- ------------------- -----------------------

# Entry and Exit Criteria

Entry and exit criteria act as checkpoints to be evaluated prior to
entering or exiting the test phase. Tests begin once entry criteria are
met. The test phase is exited once the exit criteria are met.

The following criteria must be met before functional testing can begin

-   The production environment is set up and configured;

-   Test PC's are properly configured;

-   Code is migrated into the production environment; and

-   Test scripts and expected results are documented.

The following criteria must be met before functional testing is
complete:

-   Test scripts are executed;

-   Discrepancies, issues, and defects are fully documented as SCRs; and

-   SCRs are resolved and have been re-tested.

#