Appendix E Test Plan

REVISION HISTORY

The following is a revision history table for the Dog E-DayCare system's Software Test Cases document.

Date	Configuration ID	Version	Description	Author(s)

INTRODUCTION

Software testing is a critical quality assurance step in the software development process. Testing of the Dog E-DayCare system is undertaken to identify errors in the product before delivery to the client. Thorough testing ensures the product will meet user requirements, minimizing costs in the long run, bolstering client satisfaction, and promoting repeat business.

The purpose of this document is to provide the Test Plan for the Dog E-DayCare system. The Test Plan details the testing strategy, metrics, artifacts, schedule, procedures, and test cases. Two sets of sample test cases have been developed: class test cases and integration test cases. Class test cases focus on classes and their operations within a specific sub-system . Integration test cases take a larger view of the product, uncovering errors that could occur as sub-systems interact.

Goals and Objectives

Dog E-DayCare connects dog owners to dog-care service providers, providing a Web-based national forum to locate, purchase, and monitor pet-care services. The mission of the Dog E-DayCare project team is to fill a gap in the current market for online pet-care resources. For dog owners, finding a service that meets their immediate needs can be challenging and for dog-care service providers, there is a vibrant market to be reached. Dog E-DayCare envisions bringing together dog owners and service providers nationally to support this challenge.

Statement of Scope

While there are several online directories of pet-care services, there are few E-businesses offering a service locator as well as the ability to purchase and monitor pet-care services online.

The Dog E-DayCare system will be released in two phases. In the first phase, it will allow dog owners to search for services within a radius of their choice, and based on their specific needs, whether they are looking for ongoing in-home daycare, daycare outside the home, or an afternoon walk and grooming. Once a dog owner selects a service, the Dog E-DayCare system will allow them to submit all required information, schedule, and pay for service.

Dog-care service providers who have registered with Dog E-DayCare will have access to the system through two different forums: client software on their workstations and/or the Web. The system will notify service providers of potential clients, allowing them to communicate with dog owners, and access submitted information. Service providers will be able to coordinate scheduling of multiple clients, e-mail clients, and bill clients .

Phase II of the Dog E-DayCare system will introduce a range of additional tools to facilitate communication between the Customer and Service Provider. Discussion forums, chat rooms, and instant messaging will greatly enhance Customer-Service Provider relations. In addition, with selected Service Providers, Customers will be able to view their dogs online and receive an update of their dog's status. Dog E-DayCare users will also be able to access dog-care "tips of the day."

Dog E-DayCare also envisions partnering with community service organizations. For example, matching puppy raisers to puppies for Guiding Eyes for the Blind, or potential dog owners to rescued dogs on behalf of Lab Rescue. Community service is the foundation on which Dog E-DayCare is built.

Major Constraints

As identified in the Software Requirements Specification, the most obvious limitation in this project is the experience of the project team. This is our first attempt at going through the entire software development life cycle and presenting a product that satisfies requirements in a timely and efficient manner.

Thorough testing is particularly imperative in this context.

TEST PLAN

The Test Plan provides an incremental and iterative process of testing from small to large. The Dog E-DayCare system has been designed using an object-oriented approach. Its smallest components are the classes that encapsulate the responsibilities and attributes associated with the system's various functions. Sets of related classes have been organized into sub-systems. The testing process first examines the classes within sub-systems through class testing, and then examines the interactions among sub-systems through integration testing. Integration testing is followed by validation testing and system testing, which are not addressed in this plan.

The overall system description, the test strategy, testing resources and output, and the test schedule are detailed below.

System Description

The Dog E-DayCare system is composed of seven sub-systems. Each sub-system has an associated interface and represents a set of related responsibilities. The sub-systems comprise the following:

• Application Controller
• User Management
• Resource Management
• Order
• Accounting
• Customer Relationship Management [1]
• Persistence

The Application Controller sub-system provides a " core " for the entire application. The controller acts as a "grand central station" for each and every process that takes place within the scope of the application. The User Management sub-system provides a central location for handling each and every piece of user data. The Resource Management sub-system provides the application with its overall scheduling capabilities. The Order sub-system has responsibility for supporting the ordering of products and services from Service Providers by Dog E-DayCare clients . The Accounting sub-system is responsible for processing the financial transactions. The Customer Relationship Management sub-system provides the application with the ability to provide an opportunity for interaction between the customers and service care providers. [2] Finally, the Persistence Sub-system is responsible for the storage, retrieval, and update of data.

The following System Collaboration Diagram (see Figure E1) demonstrates the collaboration or "hand-shaking" that takes place throughout the major sub-systems within the application. The Application Controller is the core of the system ” each sub-system generates a request and a corresponding response. The Application Controller must handle both the request and the response. It receives the request, processes a response, and returns the response to the calling function. This can also cross over into other layers of the system. For example, if the Accounting sub-system request requires information from the Ordering sub-system to accomplish its tasks , the Application Controller mediates between these sub-systems to formulate a response and provide it to the requester.

Figure E1: Collaborations between Major Sub-Systems

3.1.1 System Collaboration Diagram

Figure E1 depicts the collaborations that exist between the major Dog E-DayCare sub-systems.

Testing Strategy

In the object-oriented context, no operation can be tested in isolation. This poses a challenge to testers. The overall objective of testing is to uncover errors. The strategy for testing the Dog E-DayCare system entails first thoroughly testing the classes within sub-systems through Class Testing, and then testing interactions among sub-systems through scenario-based Integration Testing.

A set of test cases is developed for each testing method. Test cases for both Class and Integration Testing must exercise the requirements of the system. For the purpose of this Test Plan, a sample of tests has been developed and provided in Appendices E1 and E2.

Further details on Class Testing and Integration Testing in general are provided in Section 4: Testing Procedures, below.

Testing Resources

3.3.1 Staffing

The project team developing the Dog E-DayCare system consists of four members as detailed in the table below. Testing is a joint activity in which all team members participate. This activity is led by the Documentation Specialist.

Team Members:

• Web Software Developer, Sr.
• Web Designer, Sr.
• Documentation Specialist, Sr.
• Project Lead ” Software Engineer

3.3.2 Tools

The hardware used for testing the Dog E-DayCare system will include:

• SQL Server 2000 to host the system
• Desktop (Pentium III processor) with a standard 56K modem to access the system
• Laptop to record test results

The software required for testing will include the stubs and drivers developed to support class testing.

Testing Metrics

It is envisioned that both Class Testing and Integration Testing will be carried out through several iterations, until all errors are corrected. For each iteration, Class Testing will involve recording the following metrics:

• For each class, indicators of test failure (as identified in the test cases)
• Number of failure indicators per class
• Number of failure indicators per sub-system
• A categorization of failure indicators by severity
• Number of repeat failures (not resolved in the previous iteration)
• Hours spent by test team in test process
• Hours spent by development team in correcting failures

Integration Testing will involve recording a similar set of metrics for each iteration; however, the level of analysis will be the scenario. In other words:

• For each scenario, indicators of test failure (as identified in the test cases)
• Number of failure indicators per scenario
• A categorization of failure indicators by severity
• Number of repeat failures (not resolved in the previous iteration)
• Hours spent by test team in test process
• Hours spent by development team in correcting failures

Testing Artifacts

The artifacts of testing that will be provided to the client include:

• Test Plan
• Test Cases
• Test Results
• Test Report

Testing Schedule

Class Testing will be undertaken as each set of sub-systems is completed. The following provides general information on how testing will be scheduled:

• PS+35 days: Class testing of Application Controller and Persistence sub-systems
• PS+49 days: Class testing of User Management and Order sub-systems
• PS+64 days: Class testing of Resource Management and Accounting sub-systems
• PS+86 days: Scenario-based Integration Testing

A detailed project schedule is provided in Appendix E3.

[1] This feature set will be available in Phase II.

[2] This feature set will be available in Phase II.

TEST PROCEDURES

Class Testing

Per the Project Schedule, class testing will take place as pairs of sub-systems have been completed. Test cases for class testing must be explicitly associated with the class to be tested . Effective class testing depends on well- articulated test cases. The test cases detail the:

• Description . The description includes the test's purpose (i.e., which class will be tested) and the particular responsibilities that will be tested.
• Required stubs and/or drivers . As stated previously, components of an object-oriented system cannot be tested in isolation. Because of the collaborations that must take place within and across sub-systems, class testing will likely require the use of stubs and drivers. In object-oriented testing, a stub is a stand-in for a subclass, and a driver is a sort of tester class that accepts test case data, passes data back to the class, and prints relevant results.
• Test steps. The test steps detail the events and states the system will move through from the beginning through to the end of the test.
• Expected results. The expected results provide the indicators of test success and test failure.

Integration Testing

Per the Project Schedule, Integration Testing will take place once all sub-systems have been developed and tested. Test cases are scenario based, reflecting what users need to do with the Dog E-DayCare system. Similar to the test cases above, the integration test cases detail the:

• Description . The description includes the test's purpose (i.e., which scenario or use case will be tested) and the particular sub-systems that must interact in order for the scenario to be completed.
• Required stubs and/or drivers . In object-oriented testing, stubs and drivers are critical for Class Testing. However, if Class Testing is thorough, stubs and drivers would not be necessary for completion of Integration Testing.
• Test steps. The test steps detail the events and states the system will move through from the beginning through to the end of the test.
• Expected results. The expected results provide the indicators of test success and test failure.

Sample Class and Integration Test Cases are provided in Appendices E1 and E2, respectively.

APPENDIX E1 CLASS TESTING TEST CASES

Class tests are developed for each sub-system of the Dog E-DayCare TM system. A sample of class test cases follows .

Application Controller Sub System

The Application Controller sub-system provides a " core " for the entire application. The controller acts as a "grand central station" for each and every process that takes place within the scope of the application.

5.1.1 Test Case: ApplicationController:ApplicationController CI: DD.0001.TEST001

5.1.1.1 Description

This test case tests to see if the user functions invoked by the Application user interface are handled correctly. This interface is invoked by the other sub-systems when actions are performed and requests are made from their respective user interfaces. This particular test focuses on the user who is attempting to search for a service care provider within their area.

5.1.1.2 Required Stubs/Drivers

The SearchUI will be invoked, which is part of the presentation layer.

5.1.1.3 Test Steps

1. The user will press the Search button within the Order sub-system, which is part of the presentation layer.
2. The user will be presented with a form to fill in his search criteria.
3. The search criteria will be concatenated to form a full select query against the database. ("Select * from ServiceSchedule where location = inputlocation and date/time = inputdatetime, and servicetype = inputservicetype order by location")
4. The user's search criteria will be evaluated and the results will be displayed.
5. The user may then select the desired result and schedule the service.

5.1.1.4 Expected Results

Test Success

The application controller sub-system successfully handles the routing of the information so that the query data goes from the presentation layer to the application controller layer, to the persistence layer, and ultimately is used to query the database. Success will be measured by the accuracy of the information (results) that is returned as a result of the query string.

Test Failure

1. The concatenation that must take place to form the query could be invalid, which would result in an error message when the query is executed against the database.
2. The route that the Application Controller must take may not be followed because of a flaw in the logic.
3. The query string concatenation may not be sufficient and the wrong data could be returned.

5.1.2 Test Case: ApplicationController:ApplicationController CI: DD.0001.TEST002

5.1.2.1 Description

This test case tests to see if the user functions invoked by the Application user interface are handled correctly. This interface is invoked by the other sub-systems when actions are performed and requests are made from their respective user interfaces. This particular test will verify that the user is able to view the Tip of the Day when the Tip of the Day button is pressed.

5.1.2.2 Required Stubs/Drivers

The CommunicationUI from the Customer Relationship Management module will be used heavily in conjunction with the communication class within that same sub-system.

5.1.2.3 Test Steps

1. The user will successfully log on to the system.
2. The user will press the Tip of The Day button.
3. The Tip of the Day will be displayed within the user interface.

5.1.2.4 Expected Results

Test Success

The success of the test must be measured based on the Application Controller sub-system's ability to use the system data to determine the date and use that as the query string to invoke the persistence sub-system that will use the query string against the database. The test passes if the Tip of the Day is returned with the correct Tip of the Day for today's date.

Test Failure

1. An exception may occur if the incorrect date is retrieved from the system time, and therefore the wrong Tip of the Day is returned.
2. An exception may also occur if the correct tip is displayed, but in an incorrect format.

5.1.3 Test Case: ApplicationController:ApplicationController CI: DD.0001.TEST003

5.1.3.1 Description

This test case tests to see if the user functions invoked by the Application user interface are handled correctly. This interface is invoked by the other sub-systems when actions are performed and requests are made from their respective user interfaces. This specific test will determine if the user's account balance is updated after a payment is made.

5.1.3.2 Required Stubs/Drivers

1. The PaymentUI, which is part of the presentation layer, must have been invoked and a payment must be attempted.
2. The Accounting sub-system and its interfaces will be invoked.

5.1.3.3 Test Steps

1. The user will successfully log on to the system.
2. The user will navigate to his account information.
3. The user will select the option to make a payment on his balance.
4. The user will be presented a form with which to indicate the amount of the payment and provide/change his credit card information.
5. The user will enter an amount and use his preregistered credit card information.
6. The user will press the Pay button.

5.1.3.4 Expected Results

Test Success

The success of this test can be measured by the user's new balance reflecting the recent payment on his account balance. Performing a query against the database to determine if the account balance is correct will test this. The ApplicationController is tested because it is its responsibility to ensure that the correct route is followed to ultimately commit the transaction and return a successful message.

Test Failure

1. An exception may occur if the query string is malformed . This could be caused by invalid data entry or faulty logic.
2. An exception may also occur if the update is unsuccessful and the query returns an invalid balance.

Test Case: ApplicationController:ApplicationController CI: DD.0001.TEST004

5.1.4.1 Description

This test case tests to see if the user functions invoked by the Application user interface are handled correctly. This interface is invoked by the other sub-systems when actions are performed and requests are made from their respective user interfaces. This particular test will ensure that the service care provider can successfully update their scheduling information.

5.1.4.2 Required Stubs/Drivers

The Resource Management sub-system will be invoked, with particular attention to the resource class, which is used for scheduling.

5.1.4.3 Test Steps

1. The service care provider will successfully log on to the system.
2. The service care provider will press the Resource button.
3. A form will be presented, which will allow the service care provider to specify that it wants to edit its resource schedule.
4. The service care provider will modify its employee's schedule to exclude the dog shearer on a particular day.

5.1.4.4 Expected Results

Test Success

The success of this test can be determined by a query performed against the database, which is invoked when the user attempts to search for that particular service. The application controller will be tested because it is its responsibility to accept the query string and commit the transaction to the database via the Persistence sub-system.

Test Failure

1. An exception may occur if the concatenation of the query string is faulty, which will result in a database SQL error.
2. An exception may also occur if the user cannot see the changes updated via the user interface, which indicates that the test was unsuccessful.

User Management Sub System

The User Management sub-system provides a central location for handling each and every piece of user data. This is very important in the parsing of the system.

5.2.1 Test Case: Security Manager :: addUser(In User : User) CI: DD.0001.TEST005

5.2.1.1 Description

The purpose of the test is to determine whether the Security Manager class is carrying out its responsibilities as expected. Security Manager is a critical class of the User Management sub-system, adding and removing users and their roles and authenticating users. This test will focus specifically on adding a user to the system.

5.2.1.2 Required Stubs/Drivers

Driver: IUserInterfaceDriver (smaller version of IUserInterface class)

• RegisterUIDriver (smaller version of RegisterUI class)

Stubs: UserStub (smaller version of User class)

• NextStub (captures next button clicks)

5.2.1.3 Test Steps

1. Open Register User Interface.
2. Input information "about you."
3. Click Next.
4. Input information "about your dog."
5. Click Next.
6. Input username and password.
7. Click Finish.
8. View results.

5.2.1.4 Expected Results

Test Success

1. Driver displays information entered for user.

Test Failure

1. Driver does not display information entered for user.

5.2.2 Test Case: Security Manager :: removeUser(In User : User) CI: DD.0001.TEST006

5.2.2.1 Description

The purpose of the test is to determine whether the Security Manager class is carrying out its responsibilities as expected. Security Manager is a critical class of the User Management sub-system, adding and removing users and their roles and authenticating users. This test will focus specifically on removing a user.

5.2.2.2 Required Stubs/Drivers

Driver: IUserInterfaceDriver (smaller version of IUserInterface class)

• RegisterUIDriver (smaller version of RegisterUI class)

Stubs: UserStub (smaller version of User class)

• NextStub (captures next button clicks)

5.2.2.3 Test Steps

1. Open Register User Interface.
2. Select option to "cancel registration."
3. Input user id in appropriate field.
4. Click Remove.
5. View results.

5.2.2.4 Expected Results Description

Test Success

1. User id removed no longer appears in user id table.

Test Failure

1. User id removed persists in user id table.

5.2.3 Test Case: Security Manager :: authenticateUser(In User : User): Boolean CI: DD.0001.TEST007

5.2.3.1 Description

The purpose of the test is to determine whether the Security Manager class is carrying out its responsibilities as expected. Security Manager is a critical class of the User Management sub-system, adding and removing users and their roles and authenticating users. This test will focus specifically on user authentication.

5.2.3.2 Required Stubs/Drivers

Driver: IUserInterfaceDriver (smaller version of IUserInterface class)

• LoginUIDriver (smaller version of LoginUI class)

Stubs: UserStub (smaller version of User class)

• NextStub (captures next button clicks)
• RoleStub (captures role assigned to user)

5.2.3.3 Test Steps

1. Open Login User Interface.
2. Input username and password.
3. Click Login.
4. View results.

5.2.3.4 Expected Results

Test Success

1. User enters a correct username and password, the welcome page appears, and the name of the user is displayed in the upper-right corner.
2. User enters an incorrect name and password. A login failure message is displayed asking the user to try again.

Test Failure

1. User enters a correct username and password. A login failure message is displayed.
2. User enters an incorrect username and password, the welcome page appears, and the name of the user is displayed in the upper-right corner.

5.2.4 Test Case: Customer :: getDogs() : Collection CI: DD.0001.TEST008

5.2.4.1 Description

The purpose of the test is to determine whether the Customer class is carrying out its responsibilities as expected. Customer's role in the User Management sub-system is to receive, store, and return a range of information associated with a particular Customer. This test will focus specifically on retrieving a list of all dogs belonging to a particular Customer.

5.2.4.2 Required Stubs/Drivers

Driver: IUserInterfaceDriver (smaller version of IUserInterface class)

• SearchUIDriver (smaller version of SearchUI class)

Stubs: UserStub (smaller version of User class)

• NextStub (captures next button clicks)
• DogStub (small version of Animal Owner, Animal, and Dog classes)

5.2.4.3 Test Steps

1. Open Search User Interface (for Service Providers).
2. Input Customer ID.
3. Click Search.
4. View results.

5.2.4.4 Expected Results

Test Success

1. The names of all dogs owned by the customer are listed in the results page.

Test Failure

1. The names of dogs owned by other customers are listed in the results.
2. No dog names are listed in the results.

5.2.5 Test Case: Customer :: getInvoices() : Collection CI: DD.0001.TEST009

5.2.5.1 Description

The purpose of the test is to determine whether the Customer class is carrying out its responsibilities as expected. Customer's role in the User Management sub-system is to receive, store, and return a range of information associated with a particular Customer. This test will focus specifically on retrieving a correct list of all invoices associated with a Customer.

5.2.5.2 Required Stubs/Drivers

Driver: IUserInterfaceDriver (smaller version of IUserInterface class)

• SearchUIDriver (smaller version of SearchUI class)

Stubs: UserStub (smaller version of User class)

• NextStub (captures next button clicks)
• InvoiceStub (smaller version of Invoice class)

5.2.5.3 Test Steps

1. Open Dog E-DayCare TM search interface (for Service Providers).
2. Enter Customer ID.
3. Click on Search.
4. View results.

5.2.5.4 Expected Results

Test Success

1. All invoices associated with the customer are listed.

Test Failure

1. Invoices associated with another customer are listed.
2. None of the invoices associated with the customer are listed.

5.2.6 Test Case: Service Provider :: addServiceOffering() CI: DD.0001.TEST010

5.2.6.1 Description

The purpose of the test is to determine whether the Service Provider class is carrying out its responsibilities as expected. Service Provider's role in the User Management sub-system is to receive, store, and return a range of information associated with a particular Service Provider. This test will focus specifically on adding a service offering for a specific Service Provider.

5.2.6.2 Required Stubs/Drivers

Driver: IUserInterfaceDriver (smaller version of IUserInterface class)

• RegisterUIDriver (smaller version of RegisterUI class)

Stubs: ServiceProviderStub (smaller version of Service Provider class)

• ServiceStub(smaller version of Service class)
• NextStub (captures next button clicks)

5.2.6.3 Test Steps

1. Open Service Details page of Company Registration.
2. Input service information requested .
3. Click "add another service."
4. Input service information requested.
5. Click Next.
6. View results.

5.2.6.4 Expected Results

Test Success

1. Services information for particular company is present in Service Table.

Test Failure

1. Service information for particular company is not present in Service Table.

5.2.7 Test Case: Service Provider:: getAddress() CI: DD.0001.TEST011

5.2.7.1 Description

The purpose of the test is to determine whether the Service Provider class is carrying out its responsibilities as expected. Service Provider's role in the User Management sub-system is to receive, store, and return a range of information associated with a particular Service Provider. This test will focus specifically on retrieving address information for a service provider.

5.2.7.2 Required Stubs/Drivers

Driver: IUserInterfaceDriver (smaller version of IUserInterface class)

• SearchUIDriver (smaller version of SearchUI class)

Stubs: ServiceProviderStub (smaller version of ServiceProvider class)

• NextStub (captures Next button clicks)

5.2.7.3 Test Steps

1. Open Dog E-DayCare TM search interface (for Customers).
2. Enter name of Service Provider.
3. Click on Search.
4. View results.

5.2.7.4 Expected Results

Test Success

1. If address information is available, correct address information is displayed in search results.
2. If address information is not available, no address information is displayed in search results.

Test Failure

1. If address information is available, incorrect address information is displayed in search results.
2. If address information is not available, someone's address information is displayed in search results.

Resource Management Sub System

This Resource Management sub-system provides the application with its overall scheduling capabilities. It uses various respective classes and sub-systems to ensure that the user has up-to-date information regarding the services of interest.

5.3.1 Test Case: ResourceUI :: showCreate() CI: DD.0001.TEST012

5.3.1.1 Description

The purpose of this test case is to test the Resource Management User Interface class' (ResourceUI) showCreate() method to determine if it can display the "Register Company - resource details" screen (see SDS section 11.22) as an add screen.

5.3.1.2 Required Stubs/Drivers

Driver: IUserInterfaceDriver (smaller version of IUserInterface class)

Stubs: ResourceStub (smaller version of Resource class)

• NextStub (captures next button clicks)
• OtherButtonsStub (captures other buttons clicked)

5.3.1.3 Test Steps

1. Execute the IUserInterfaceDriver in a Web browser.
2. Select "Staff" from the Resource Type drop-down list.
3. Enter a Staff Member's First Name (if resource type = Staff).
4. Enter a Staff Member's Last Name (if resource type = Staff).
5. Select an item in the Position drop-down list.
6. Determine that the Height, Width, and Length fields are protected.
7. Press the Next button.

5.3.1.4 Expected Results

Test Success

1. The IUserInterfaceDriver should display the "Register Company - resource details" screen in the Web browser.
2. The Resource Type drop-down list should contain an entry for Staff and permit its selection.
3. The Staff Member First Name should be enterable.
4. The Staff Member Last Name should be enterable.
5. The Position drop-down list should be enterable and permit the selection of one of its items.
6. The Height, Width, and Length fields should be protected.
7. The Next stub should return a basic Web page.

Test Failure

1. Report all failures.

5.3.2 Test Case: ResourceUI :: showEdit() CI: DD.0001.TEST013

5.3.2.1 Description

The purpose of this test case is to test the Resource Management User Interface class' (ResourceUI) showEdit() method to determine if it can display the "Register Company - resource details" screen (see SDS section 11.22) as an edit screen.

5.3.2.2 Required Stubs/Drivers

Driver: IUserInterfaceDriver (smaller version of IUserInterface class)

Stubs: ResourceStub (smaller version of Resource class)

• NextStub (captures Next button clicks)
• OtherButtonsStub (captures other buttons clicked)

5.3.2.3 Test Steps

1. Execute the IUserInterfaceDriver in a Web browser.
2. Determine that "Staff" is displayed from the Resource Type drop-down list.
3. Update the Staff Member's First Name (if resource type = Staff).
4. Update the Staff Member's Last Name (if resource type = Staff).
5. Select another item in the Position drop-down list.
6. Determine that the Height, Width, and Length fields are protected.
7. Press the Next button.

5.3.2.4 Expected Results

Test Success

1. The IUserInterfaceDriver should display the "Register Company - resource details" screen in the Web browser.
2. The Resource Type drop-down list should display an entry for Staff.
3. The Staff Member First Name should be updated.
4. The Staff Member Last Name should be updated.
5. The Position drop-down list should be enterable and permit the selection of one of its items.
6. The Height, Width, and Length fields should be protected.
7. The Next stub should return a basic Web page.

Test Failure

1. Report all failures.

5.3.3 Test Case: ResourceUI :: showSearch() CI: DD.0001.TEST014

5.3.3.1 Description

The purpose of this test case is to test the Resource Management User Interface class's (ResourceUI) showSearch() method to determine if it can display the Resource Search screen (example not present in SDS).

5.3.3.2 Required Stubs/Drivers

Driver: IUserInterfaceDriver (smaller version of IUserInterface class)

Stubs: ServiceProviderStub (smaller version of ServiceProvider class)

• ResourceStub (smaller version of Resource class)
• SearchStub (captures Search button clicks)
• OtherButtonsStub (captures other buttons clicked)

5.3.3.3 Test Steps

1. Execute the IUserInterfaceDriver in a Web browser.
2. Determine that the Service Provider drop-down list displayed.
3. Determine that the Resource Type drop-down list displayed.
4. Select a service provider from the Service Provider drop-down list.
5. Select a resource type from the Resource Type drop-down list.
6. Press the Search button.

5.3.3.4 Expected Results

Test Success

1. The IUserInterfaceDriver should display the "Register Company - resource details" screen in the Web browser.
2. The Service Provider drop-down list should display service providers.
3. The Resource Type drop-down list should display the resource types that the selected service provider supports.
4. The service provider selected should be visible in the drop-down list.
5. The resource type selected should be visible in the drop-down list.
6. The Search stub should return a basic Web page.

Test Failure

1. Report all failures.

Order Sub System

The Order sub-system has responsibility for supporting the ordering of products and services from Service Providers by Dog E-DayCare clients .

5.4.1 Test Case: OrderUI :: showCreate() CI: DD.0001.TEST015

5.4.1.1 Description

The purpose of this test case is to test the Order User Interface class' (OrderUI) showCreate() method to determine if it can display the "Order - initiate order" screen (see SDS section 11.10) and if the drop-down lists are populated .

5.4.1.2 Required Stubs/Drivers

Driver: IUserInterfaceDriver (smaller version of IUserInterface class)

Stubs: OrderStub (smaller version of Order class)

• ServiceProviderStub (smaller version of ServiceProvider class)
• ServiceStub (smaller version of Service class)
• AppointmentStub (smaller version of Appointment class)
• OtherButtonsStub (captures other buttons clicked)

5.4.1.3 Test Steps

1. Execute the IUserInterfaceDriver in a Web browser.
2. Select an item in the Service Provider drop-down list.
3. Select an item in the Service drop-down list.
4. Select an item in the Service Duration drop-down list.
5. Select an item in the Time Frame drop-down list.

5.4.1.4 Expected Results

Test Success

1. The IUserInterfaceDriver should display the "Order - initiate order" screen in the Web browser.
2. The Service Provider drop-down list should contain a list of service providers.
3. The Service drop-down list should contain a list of services offered by the selected service provider.
4. The Service Duration drop-down list should contain a list of service durations available for the selected service.
5. The Time Frame drop-down list should contain a list of all openings for the selected service.

Test Failure

1. Report all failures.

5.4.2 Test Case: OrderUI :: showEdit() CI: DD.0001.TEST016

5.4.2.1 Description

The purpose of this test case is to test the Order User Interface class' (OrderUI) showEdit() method to determine if it can display the "Order - order details" screen (see SDS section 11.12).

5.4.2.2 Required Stubs/Drivers

Driver: IUserInterfaceDriver (smaller version of IUserInterface class)

Stubs: OrderStub (smaller version of Order class)

• OtherButtonsStub (captures other buttons clicked)

5.4.2.3 Test Steps

1. Execute the IUserInterfaceDriver in a Web browser.
2. Determine if the correct Service Provider is displayed.
3. Determine if the correct Service is displayed.
4. Determine if the correct Location is displayed.
5. Determine if the correct Phone Number is displayed.
6. Determine if the correct Email Address is displayed.
7. Determine if the correct Appointment is displayed.

5.4.2.4 Expected Results

Test Success

1. The IUserInterfaceDriver should display the "Order - order details" screen in the Web browser.
2. The Service Provider name should display.
3. The Service name should display.
4. The Location should display.
5. The Phone Number should display.
6. The Email Address should display.
7. The Appointment should display.

Test Failure

1. Report all failures.

5.4.3 Test Case: OrderUI :: showSearch() CI: DD.0001.TEST017

5.4.3.1 Description

The purpose of this test case is to test the Order User Interface class' (OrderUI) showSearch() method to determine if it can display the "Search" screen (see SDS section 11.26) and conduct a search using a stub to display the "results."

5.4.3.2 Required Stubs/Drivers

Driver: IUserInterfaceDriver (smaller version of IUserInterface class)

Stubs: SearchStub (captures Search button clicks)

• OtherButtonsStub (captures other buttons clicked)

5.4.3.3 Test Steps

1. Execute the IUserInterfaceDriver in a Web browser.
2. Enter a value in the Customer ID field.
3. Press the Search button.
4. Enter a value in the Customer Name field.
5. Press the Search button.
6. Enter a value in the Order ID field.
7. Press the Search button.
8. Enter a value in the Invoice ID field.
9. Press the Search button.

5.4.3.4 Expected Results

Test Success

1. The IUserInterfaceDriver should display the "Search" screen in the Web browser.
2. The screen should permit entry of a Customer ID.
3. The Search stub should return a basic Web page.
4. The screen should permit entry of a Customer Name.
5. The Search stub should return a basic Web page.
6. The screen should permit entry of an Order ID.
7. The Search stub should return a basic Web page.
8. The screen should permit entry of an Invoice ID.
9. The Search stub should return a basic Web page.

Test Failure

1. Report all failures.

5.4.4 Test Case: OrderUI :: showList() CI: DD.0001.TEST018

5.4.4.1 Description

The purpose of this test case is to test the Order User Interface class' (OrderUI) showList() method to determine if it can display the "Search Results - Customer Search Results" screen (see SDS section 11.27).

5.4.4.2 Required Stubs/Drivers

Driver: IUserInterfaceDriver (smaller version of IUserInterface class)

Stubs: OrderStub (smaller version of Order class)

• InvoiceStub (smaller version of the Invoice class)
• AddressStub(smaller version of the Address class)
• OtherButtonsStub (captures other buttons clicked)

5.4.4.3 Test Steps

1. Execute the IUserInterfaceDriver in a Web browser.
2. Determine if the correct Customer Name is displayed.
3. Determine if the correct Address is displayed.
4. Determine if the correct Email Address is displayed.
5. Determine if the correct Phone Number is displayed.
6. Determine if the correct Order Numbers are displayed.
7. Determine if the correct Invoice Numbers are displayed.

5.4.4.4 Expected Results

Test Success

1. The IUserInterfaceDriver should display the "Search Results - Customer Search Results" screen in the Web browser.
2. The Customer Name should display.
3. The Address should display.
4. The Email Address should display
5. The Phone Number should display.
6. The Order Numbers should display.
7. The Invoice Numbers should display.

Test Failure

1. Report all failures.

5.4.5 Test Case: OrderLineItem CI: DD.0001.TEST019

5.4.5.1 Description

The purpose of this test case is to test the OrderLineItem class to determine if it correctly handles order- line-item related data.

5.4.5.2 Required Stubs/Drivers

Driver: OrderLineItem Test Driver: a small console application that assigns a value to the OrderLineItem and prints out the result in a console window.

Stub: N/A

5.4.5.3 Test Steps

1. Execute the OrderLineItem Test Driver in a console window. The test driver application should execute the following methods of OrderLineItem class:
   • SetServiceName()
   • SetUnitPrice()
   • SetQuantity()
   • GetServiceName()
   • GetUnitPrice()
   • GetQuantity()
   • GetTotalPrice()
   • GetTax()
   • GetTotalPriceWithTax()
2. Review the console printout to see if all property values are correctly assigned and returned.
3. Review the console printout to see if the getTotalPrice method return value is the result of Quantity multiply UnitPrice and then add Tax.

5.4.5.4 Expected Results

Test Success

1. All property values assigned match property value returned.
2. The total price matches the calculation from quantity, unit price, and tax values.

Test Failure

1. Property value assigned does not match property value returned.
2. Total price does not match the calculation from quantity, unit price, and tax values.

5.4.6 Test Case: ServiceResourceRequirement CI: DD.0001.TEST020

5.4.6.1 Description

The purpose of this test case is to test the ServiceResourceRequirement class to determine if it correctly handles the service resource requirement related data.

5.4.6.2 Required Stubs/Drivers

Driver: ServiceResourceRequirement Test Driver: a small console application that assigns a value to ServiceResourceRequirement and prints out the result in a console window.

Stubs: N/A

5.4.6.3 Test Steps

1. Execute the ServiceResourceRequirement Test Driver in a console window. The test driver application should execute the following methods of Order class:
   • SetQuantity()
   • SetPercentage()
   • SetResourceType()
   • GetQuantity()
   • GetPercentage()
   • GetResourceType()
2. Review the console printout to see if all property values are correctly assigned and returned.

5.4.6.4 Expected Results

Test Success

1. All property values assigned match property values returned.
2. If quantity value is less than 1, an exception is raised.
3. If percentage value is greater than 1, an exception is raised.

Test Failure

1. Property values assigned do not match property values returned.
2. If quantity value is less than 1, no exception is raised.
3. If percentage value is greater than 1, no exception is raised.

5.4.7 Test Case: Service CI: DD.0001.TEST021

5.4.7.1 Description

The purpose of this test case is to test the Service class to determine if it correctly handles the service-related data.

5.4.7.2 Required Stubs/Drivers

Driver: Service Test Driver: a small console application that assigns a value to the order and prints out the result in a console window.

Stubs: ServiceResourceRequirement class or stub

5.4.7.3 Test Steps

1. Execute the Service Test Driver in a console window. The test driver application should execute the following methods of Order class:
   • SetName()
   • SetDescription()
   • SetUnitCost()
   • GetResourceRequirement()
   • GetName()
   • GetDescription()
   • GetUnitCost()
2. Review the console printout to see if all property values are correctly assigned and returned.

5.4.7.4 Expected Results

Test Success

1. All property values assigned match property value returned.

Test Failure

1. Property values assigned do not match property value returned.

5.4.8 Test Case: Order CI: DD.0001.TEST022

5.4.8.1 Description

The purpose of this test case is to test the Order class to determine if it correctly handles the order-related data.

5.4.8.2 Required Stubs/Drivers

Driver: Order Test Driver: a small console application that assigns a value to the order and prints out the result in a console window.

Stubs: OrderLineItem class or stub

• Invoice class or stub
• Payment class or stub
• Customer class or stub

5.4.8.3 Test Steps

1. Execute the Order Test Driver in a console window. The test driver application should execute the following methods of Order class:
   • SetOrderDateTime
   • SetCompletionDateTime
   • SetOrderStatus
   • GetOrderLineItems
   • GetTotalPrice
   • GetCustomer
   • GetPayment
   • GetInvoice
2. Review the console printout to see if all property values are correctly assigned and returned.
3. Review the console printout to see if the getTotalPrice method return value is the total of all OrderLineItem prices.

5.4.8.4 Expected Results

Test Success

1. All property values assigned match property value returned.
2. The total price matches the calculation from order line items.

Test Failure

1. Property values assigned do not match property value returned.
2. Total price does not match the calculation from order line items.

Accounting Sub System

The Accounting sub-system is responsible for processing the financial transactions.

5.5.1 Test Case: Accounting:InvoicePrint CI: DD.0001.TEST023

5.5.1.1 Description

The purpose of this test is to determine if the service care provider is able to print the invoices for billing.

5.5.1.2 Required Stubs/Drivers

1. There must be orders placed against the service care provider in question via the order sub-system and the OrderService class.
2. The Accounting sub-system will be invoked, with the invoice class in particular.

5.5.1.3 Test Steps

1. A test customer order must be placed against a predetermined service care provider.
2. The service care provider must log on to the system successfully.
3. The service care provider must select the invoices that need to be printed.

5.5.1.4 Expected Results

Test Success

1. The invoices printing out successfully with the correct data will determine the success of the test.

Test Failure

1. The test can be deemed unsuccessful if the invoice does not print.
2. The test will also be unsuccessful if the format is incorrect.
3. The test will be unsuccessful if the wrong line items are printed.

5.5.2 Test Case: Accounting:Payment CI: DD.0001.TEST024

5.5.2.1 Description

The purpose of this test is to determine if a representative of the service care provider can enter a payment receipt within the Accounting sub-system.

5.5.2.2 Required Stubs/Drivers

The Accounting sub-system will be invoked, with particular attention to the Payment class.

5.5.2.3 Test Steps

1. The service care provider must successfully log on to the system.
2. The service care provider must invoke the Accounting user interface to enter the payment receipt.
3. The service care provider must enter a payment receipt and press the button to commit the transaction.

5.5.2.4 Expected Results

Test Success

1. A sub-sequent query indicates the customer's balance reflecting the recent payment.
2. A successful message is displayed.

Test Failure

1. The customer's balance does not reflect the payment receipt.
2. The customer's balance reflects an incorrect amount that is a result of faulty logic within the program.

5.5.3 Test Case: Accounting:InvoiceList CI: DD.0001.TEST025

5.5.3.1 Description

The purpose of this test is to ensure that every time a service care provider requests to view invoices, the correct invoices will be displayed.

5.5.3.2 Required Stubs/Drivers

The Application sub-system is required, with particular interest paid to the Invoice class.

5.5.3.3 Test Steps

1. The service care provider will successfully log on to the system.
2. The service care provider will select the button to view their invoices.
3. The system will determine who is logged on and display the appropriate invoices for that user.

5.5.3.4 Expected Results

Test Success

1. All invoices for that service care provider are displayed with the correct information.

Test Failure

1. The invoice(s) that are displayed are for the wrong service care provider.
2. The invoice(s) indicate an incorrect balance or other incorrect information.

Customer Relationship Management Sub System

The Customer Relationship Management sub-system provides the application with the ability to provide an opportunity for interaction between the customers and service care providers. It also provides the system administrator with the ability to gain feedback from the customer in an effort to continually revamp the application. [3]

5.6.1 Test Case (This Feature Set Will be Available in Phase II)

Persistence Sub System

The Persistence sub-system has responsibility for supporting persistent data. The purpose of this group of test cases is to determine whether the PersistenceManager class is carrying out its responsibilities as expected. PersistenceManager is a critical part of the system that handles the persistence activities of all objects. Based on the system architecture design, the Persistence Layer Java code library from http://artyomr.narod.ru has been selected to execute the majority of the persistence functionality. The Persistence Layer code library uses an XML file to store the database map and class map information. So, the correctness of the XML file in terms of correctly mapping the class structure design with the database design will essentially determine whether the objects can be correctly persisted to the database. This will be a major area of potential fault of the implementation and hence one of the major focus areas of the testing of the Persistence sub-system.

Due to limited space, the document specifies in detail the example of Customer object persistence. Please be reminded that tests in similar patterns will need to be executed for EVERY object that needs to be persisted.

5.7.1 Test Case: PersistenceManager :: loadXMLConfig() CI: DD.0001.TEST026

5.7.1.1 Description/Purpose

This test case tests the persistence manager's functionality to load the class map and the database map from the XML file. Potential errors are usually related to bad XML file entries: either file is a not valid XML file or it does not load correctly into the class map and database map.

5.7.1.2 Required Stubs/Drivers

DatabaseMap and ClassMap configuration XML file in format specified by http://artyomr.narod.ru/docs/pl/XMLConfigLoader.html

5.7.1.3 Test Steps

1. Edit Config.xml with all database map and class map information according to http://artyomr.narod.ru/docs/pl/XMLConfigLoader.html
2. Start PersistenceManager application by running java PersistenceManager.class from command prompt, loading Config.xml as the configuration.
3. Exit PersistenceManager application.

5.7.1.4 Expected Results

Test Success

1. The PersistenceManager application successfully starts without error messages.

Test Failure

1. XML parser error when loading Config.xml
2. Error parsing class map and database map information

5.7.2 Test Case: PersistenceManager :: saveObject() CI: DD.0001.TEST027

5.7.2.1 Description/Purpose

This test case tests the persistence manager's functionality to save an object to the database.

5.7.2.2 Required Stubs/Drivers

1. DatabaseMap and ClassMap configuration XML file in format specified by http://artyomr.narod.ru/docs/pl/XMLConfigLoader.html
2. Customer registration screens

5.7.2.3 Test Steps

1. Edit Config.xml with all database map and class map information according to http://artyomr.narod.ru/docs/pl/XMLConfigLoader.html
2. Start PersistenceManager application by running java PersistenceManager.class from command prompt, loading Config.xml as the configuration.
3. Browse to DogEDayCare home page from the Web site.
4. Click Register button.
5. Input customer information.
6. Click Register to create a new Customer.
7. Use SQL Tool to open the database.
8. Execute "SELECT * FROM CUSTOMER" SQL statement and review the result.
9. Execute "SELECT * FROM DOG" SQL statement and review result.

5.7.2.4 Expected Results

Test Success

1. The customer and dog information should exist in the database.

Test Failure

1. RMI error when one clicks the Register button.
2. There is an error in executing SQL statement.
3. Customer and Dog did not get added to the database.

5.7.3 Test Case: PersistenceManager :: retrieveObject() CI: DD.0001.TEST028

5.7.3.1 Description/Purpose

This test case tests the persistence manager's functionality to retrieve an object from the database.

5.7.3.2 Required Stubs/Drivers

1. DatabaseMap and ClassMap configuration XML file in format specified by http://artyomr.narod.ru/docs/pl/XMLConfigLoader.html
2. Customer information screens

5.7.3.3 Test Steps

1. Edit Config.xml with all database map and class map information according to http://artyomr.narod.ru/docs/pl/XMLConfigLoader.html
2. Start PersistenceManager application by running java PersistenceManager.class from command prompt, loading Config.xml as the configuration.
3. Browse to DogEDayCare home page from the Web site.
4. Log on to DogEDayCare system.
5. Click Edit Customer Profile button.
6. Review the information retrieved from the persistence manager.

5.7.3.4 Expected Results

Test Success

1. The Customer and Dog information should be retrieved and match what was input.

Test Failure

1. RMI error when one clicks Edit Customer Profile button
2. Cannot retrieve Customer and Dog information
3. There is an error in executing SQL statement
4. Customer and Dog information retrieved but does not match the data that was input.

[3] This feature set will be available in Phase II.

APPENDIX E2 INTEGRATION TESTING TESTS

Integration Tests are scenario based, capturing key activities that the Dog E-DayCare System TM allows the User to perform.

Test Case Customer Registration CI DD 0001 TEST029

6.1.1 Description

Registering with the Dog E-DayCare System is the key task that allows users to take advantage of the services Dog E-DayCare has to offer. Registration requires collaboration among three sub-systems: User Management, Application Controller, and Persistence. The purpose of this test is to find errors in the interactions that must take place across these sub-systems.

6.1.2 Required Stubs/Drivers

No stubs or drivers required.

6.1.3 Test Steps

1. User opens Dog E-DayCare welcome page.
2. User selects "Register."
3. The Register Customer/About You page displays.
4. User fills in fields and clicks Next .
5. The Register Customer/About Your Dog page displays.
6. User fills in fields and clicks Next.
7. Register Customer/User ID, Password page displays.
8. User fills in fields and clicks Next.
9. Register Customer/Verify Information page displays with appropriate information.
10. User reviews information and clicks Finish.
11. Register Customer/Thank You page displays.
12. User receives confirmation e-mail.

6.1.4 Expected Results

Test Success

1. User is able to successfully move through each step of the registration process.
2. The User information displayed in the Verify Information page is correct.
3. The Thank You page appears and User receives e-mail confirmation.

Test Failure

1. User cannot click from one step in the registration process to the next.
2. User information displayed in the Verify Information page is incorrect.
3. User does not receive a confirmation e-mail.

Test Case Reallocate Resources CI DD 0001 TEST030

6.2.1 Description

One of the key services Dog E-DayCare provides to dog-care companies is the ability to manage their resources (e.g., staff, kennels, and play areas), allocating and reallocating resources in response to, for example, staff illness , rainy weather, etc.

Reallocating resources requires collaboration among several sub-systems: User Management, Order, Resource Management, Application Controller, and Persistence. The purpose of this test is to find errors in the interactions that must take place across these sub-systems.

6.2.2 Required Stubs/Drivers

No stubs or drivers required.

6.2.3 Test Steps

1. User opens Schedule/This Week page.
2. User selects appointment whose resources need to be reallocated.
3. Schedule/Appointment Details page displays.
4. User selects option to "reallocate" resources.
5. Schedule/Resource Details page displays.
6. User revises resource details as necessary and clicks Next.
7. Schedule/Confirm Changes page displays.
8. User clicks Finish.
9. Revised Schedule/Appointment Details page displays.

6.2.4 Expected Results

Test Success

1. User is able to successfully move through each step of the reallocation process.
2. Reallocation information displayed in the Confirm Changes page is correct.
3. Appointment Details have been updated.

Test Failure

1. User cannot click from one step in the reallocation process to the next.
2. User information displayed in the Confirm Changes page is incorrect.
3. Appointment Details have not been updated.

Test Case Search for Service Provider and Initiate Order CI DD 0001 TEST031

6.3.1 Description

The Dog E-DayCare System allows Customers to search for Service Providers based on geographic location and service desired. From the Search Results, a user can initiate an order.

Searching for a service provider and initiating an order requires collaboration among several sub-systems: User Management, Order, Application Controller, and Persistence. The purpose of this test is to find errors in the interactions that must take place across these sub-systems.

6.3.2 Required Stubs/Drivers

No stubs or drivers required.

6.3.3 Test Steps

1. User opens Search for Service Provider page.
2. User enters required information and clicks "search."
3. Search Results page displays all Service Providers that match criteria.
4. User selects "initiate order" button associated with the Service Provider of their choice.
5. Order/Initiate Order page displays.

6.3.4 Expected Results

Test Success

1. The Search Results page displays Service Providers matching the User's criteria.
2. The Order/Initiate Order page displays the name of the Service Provider selected and the services available from the selected Service Provider in the appropriate fields.

Test Failure

1. Search Results page does not display.
2. Search Results do not match criteria.
3. Order/Initiate Order page does not display correct Service Provider information.

Test Case Place Order CI DD 0001 TEST032

6.4.1 Description

The Dog E-DayCare System allows Customers to place an order for the service they need, from a Service Provider of their choice, and within a desired timeframe.

Placing an order requires collaboration among several sub-systems: Order, User Management, Resource Management, Application Controller, and Persistence. The purpose of this test is to find errors in the interactions that must take place across these sub-systems.

6.4.2 Required Stubs/Drivers

No stubs or drivers required.

6.4.3 Test Steps

1. Order/Initiate Order page is displayed.
2. User fills in all fields.
3. User selects "view openings."
4. Order/Openings page displays.
5. User selects an available appointment time.
6. Order/Order Details page displays.
7. User selects "place order."
8. Order/Order Confirmation page displays.
9. An e-mail is sent to the User.

6.4.4 Expected Results

Test Success

1. The User is able to move successfully through each step in the process of placing an order.
2. The Order/Openings page displays the correct information on available appointment times.
3. The Order/Order Details page displays the correct information.
4. An e-mail is sent to the User.

Test Failure

1. The Order/Openings page displays incorrect information.
2. The Order/Order Details Page displays incorrect information.
3. An e-mail is not sent to the User.

Test Case Pay for Service CI DD 0001 TEST033

6.5.1 Description

The Dog E-DayCare System allows Customers to pay online for the dog-care services they have received.

Paying for service requires collaboration among several sub-systems: Accounting, Order, User Management, Application Controller, and Persistence. The purpose of this test is to find errors in the interactions that must take place across these sub-systems.

6.5.2 Required Stubs/Drivers

No stubs or drivers required.

6.5.3 Test Steps

1. User opens the Payment/Initiate Payment page.
2. User enters the Order Id number and clicks "next."
3. The Payment/Payment Details page displays.
4. User reviews Payment Details and selects "next."
5. The Payment/Billing Address page displays.
6. User reviews information and clicks "next."
7. The Payment/Credit Card Details page displays.
8. User enters information and clicks "next."
9. The Payment/Make Payment page displays.
10. User reviews information and clicks "pay now."
11. The Payment/Payment Confirmation page displays.
12. An e-mail is sent to the User.

6.5.4 Expected Results

Test Success

1. The User is able to move successfully through each step in the process of making a payment for service.
2. The Payment/Payment Details page displays the correct information.
3. The Payment/Billing Address page displays the correct information.
4. The Payment/Make Payment page displays the correct information.
5. An e-mail is sent to the User.

Test Failure

1. The Payment/Payment Details page displays incorrect information.
2. The Payment/Billing Address page displays incorrect information.
3. The Payment/Make Payment page displays incorrect information.
4. An e-mail is not sent to the User.

APPENDIX E3 PROJECT SCHEDULE

Figure E2 is an example of a project schedule.

Figure E2: Project Schedule

NOTES

1. This feature set will be available in Phase II.

2. This feature set will be available in Phase II.

3. This feature set will be available in Phase II.