Verification and Validation Plan

for

DITRIBUTED COMPONENT ROUTER for

SUPPLY CHAIN MANAGEMENT

Approved By Prepared By

Ms.Ponmary Pushpa Latha Christopher Justin .B

(Senior Lecturer) Reg.No:01i002
 Table of Contents

1. Introduction and Overview

1.1 Purpose of this Document

1.2 Scope of the Project
1.3 Definitions, Acronyms, and Abbreviations

2. Component Test Plan and Procedures

2.1 Component(n) Test Strategy Overview

2.2 Component Intro Page

3. System Test Plans and Procedures

3.1 System test strategy overview

3.2 Linking Integration
3.3 Coherence and Accuracy of Information

4. Acceptance Test and Preparation for Delivery

4.1 Procedure by which the software will be acceptance tested

4.2 Specific acceptance criteria
4.3 Scenario by which the software product will be installed
1. Introduction and Overview

1.1 Purpose of this Document

This document is the Verification and Validation Plan. It is intended to describe the plan
that is and will be used to ensure that the product meets the exact needs of our client. This
document will also relate the SRS to the SDS.

1.2 Scope of the Project

The scope of this software is to provide Distributed Component Router for Supply Chain
Management. Supply Chain Management is a network of facilities that perform the
function of procurement of materials, transformation of these materials into
intermediate and finished products and distribution of these finished to the
customers. Since the proposed system uses any transaction through the EJB based
component, which can hold the centralized code, so that any changes made will be
applicable in the centralized system. This will act as a router, so that the entire process
will be a distributed application.

1.3 Definitions, Acronyms, and Abbreviations

SCM Supply Chain Management

EJB Enterprise Java bean
SDS Software Design Specification
SRS Software Requirements Specification

Web-based An application in which all or part of it is downloaded from the Web

application each time it is run.
2. Component Test Plans and Procedures

2.1 Component(n) test strategy overview

Component testing is performed after completion of each component. The most-
recently completed component is tested, and the other already-completed components are
re-tested to verify that integration of the new component did not introduce any defects. A
component will not be considered completed until it has successfully passed all
component tests and is verified to have fulfilled the requirements set in the Software
Requirements Specification document. Other members of the team who did not
participate in the development of that particular component perform component tests
manually, and a record of each test result will be kept. As defects are found during
development and integration, tests that exercise the defect will be added to the test plans.
The methods that we will be using during the testing:

• Verify the results according to the input.

• Verify the transitions between the pages.
• Make sure the settings and all options works properly.

2.2 Component Test Plans and Procedures

Component1: Stock and Inventory Management

Test case group

Index Page
identification
Functions to be Functions Tested Include
tested
• Buttons to Select
 o Admin Login
o Add Product
o Pending Order
o Delivered Order
o Low Item Maintenance

Testing approach Testing whether Menu appears according to the customer who logs in
to the system
Pass/Fail criteria User has to enter username and password, which is valid and user
should be an authorized person. The buttons should navigate to the
correct pages and should produce the correct results.
Individual testTest Case 1:
cases • Test case identifier: Admin_login1
• Input: Enter Invalid username and password and click submit
• Expected output: Message should be displayed saying
username or password is Invalid.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test case has no
dependencies.
• References: None.

Test Case 2:
• Test case identifier: Admin_login2
• Input: Enter valid username and password and click submit
• Expected output: Success Message should be displayed saying
user is valid and logs in.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test case has no
dependencies
 • References: None.
Test Case 3:
• Test case identifier: Addproduct_1
• Input: Leave all fields empty and click submit
• Expected output: Message should be displayed saying
required fields do not hold information.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test case has no
dependencies.
• References: None.
Test Case 4:
• Test case identifier: Addproduct_2
• Input: Enter any input in any field and click reset
• Expected output: All fields should be reset to their original
value.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test case has no
dependencies.
• References: None.
Test Case 5:
• Test case identifier: Addproduct_3
• Input: Enter new, valid product information and click submit.
• Expected output: Success Message should be displayed saying
contact was added successfully.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test case requires that the
product information has already been added.
• References: None.
 Test Case 6:
• Test case identifier: Pending_Order
• Input: Click the View Pending order button.
• Expected output: All the Pending order should be displayed.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test can be done after the
login process.
• References: None.
Test Case 7:
• Test case identifier: Delivered_Order
• Input: Click the View delivered order button.
• Expected output: All the delivered order should be displayed.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test can be done after the
login process.
• References: None.
Test Case 8:
• Test case identifier: Low_Item_Maintenance
• Input: Click the View Low item button.
• Expected output: All the Low items in the stock should be
displayed.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test can be done after the
login process.
• References: None.

Component 2: Source
Test case group
Index Page
identification
Functions Tested Include

• Buttons to Select

Functions to be o Supplier Login

tested o New Supplier registration
o View product
o Check details

Testing approach Testing whether the buttons are navigating to the correct pages and
producing the proper results.
Pass/Fail criteria User has to enter username and password, which is valid and user
should be an authorized person. The buttons should navigate to the
correct pages and should produce the correct results.
Individual testTest Case 1:
cases • Test case identifier: Supplier_login1
• Input: Enter Invalid username and password and click submit
• Expected output: Message should be displayed saying
username or password is Invalid.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test case has no
dependencies.
• References: None.
Test Case 2:
• Test case identifier: Supplier_login2
• Input: Enter valid username and password and click submit
 • Expected output: Success Message should be displayed saying
user is valid and logs in.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test case has no
dependencies
• References: None.
Test Case 3:
• Test case identifier: Supplier_Registration1
• Input: Leave all fields empty and click submit
• Expected output: Message should be displayed saying required
fields do not hold information.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test case has no
dependencies.
• References: None.
Test Case 4:
• Test case identifier: Supplier_ Registration2
• Input: Leave any of the required field’s blank and click submit
• Expected output: Message should be displayed saying required
field does not hold information.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test case has no
dependencies.
• References: None.
Test Case 5:
• Test case identifier: Customer_ Registration3
• Input: Enter any input in any field and click reset
• Expected output: All fields should be reset to their original
 value.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test case has no
dependencies.
• References: None.
Test Case 6:
• Test case identifier: Supplier_ Registration4
• Input: Enter any phone number without the international code
in the Telephone Number field/Fax field.
• Expected output: Message should be displayed saying please
enter a valid phone number in prescribed format.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test case has no
dependencies.
• References: None.
Test Case 7:
• Test case identifier: Supplier_ Registration5
• Input: Enter new, valid username and enter valid information
in all other required fields and click submit
• Expected output: Success Message should be displayed saying
user was added successfully.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test case has no
dependencies.
• References: None.
Test Case 8:
• Test case identifier: View_Products
• Input: Click the View Products button.
 • Expected output: All the Products should be displayed.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test can be done after the
login process.
• References: None.
Test Case 9:
• Test case identifier: Check_details
• Input: Click the Check Details button.
• Expected output: All the details of the purchase order should
be displayed.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test can be done after the
login process.
• References: None.

Component 3: Purchase Order Management

Test case group

Index Page
identification
Functions to beFunctions Tested Include
tested
• Buttons to Select

o Purchase Order Generation

o Purchase Order Cancellation
o Quotation Update
Testing approach Testing whether the buttons are navigating to the correct pages and
producing the proper results.
Pass/Fail criteria The buttons should navigate to the correct pages and should produce
the correct results.
Individual test cases
Test Case 1:
• Test case identifier: Purchase_Order_Generation1
• Input: Leave all fields empty and click submit
• Expected output: Message should be displayed saying
required fields do not hold information.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test can be done after
the login process.
• References: None.
Test Case 2:
• Test case identifier: Purchase_Order_Generation2
• Input: Leave any of the required field’s blank and click
submit
• Expected output: Message should be displayed saying
required field does not hold information.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test can be done after
the login process.
• References: None.
Test Case 3:
• Test case identifier: Purchase_Order_Generation3
• Input: Enter any input in any field and click reset
• Expected output: All fields should be reset to their original
value.
 • Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test can be done after
the login process.
• References: None.
Test Case 4:
• Test case identifier: Purchase_Order_Generation4
• Input: Enter valid information in all the required fields and
click submit
• Expected output: Success Message should be displayed
saying new purchase order generated successfully.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test can be done after
the login process.
• References: None.

Test Case 5:
• Test case identifier: Purchase_Order_Cancellation1
• Input: Leave all fields empty and click submit
• Expected output: Message should be displayed saying
required fields do not hold information.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test can be done after
the login process.
• References: None.
Test Case 6:
• Test case identifier: Purchase_Order_Cancellation2
• Input: Leave any of the required field’s blank and click
submit
 • Expected output: Message should be displayed saying
required field does not hold information.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test can be done after
the login process.
• References: None.
Test Case 7:
• Test case identifier: Purchase_Order_Cancellation3
• Input: Enter any input in any field and click reset
• Expected output: All fields should be reset to their original
value.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test can be done after
the login process.
• References: None.
Test Case 8:
• Test case identifier: Purchase_Order_Cancellation4
• Input: Enter valid information in all the required fields and
click submit
• Expected output: Success Message should be displayed
saying purchase order cancelled successfully.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test can be done after
the login process.
• References: None.
Test Case 9:
• Test case identifier: Quotation_Update1
• Input: Leave all fields empty and click submit
 • Expected output: Message should be displayed saying
required fields do not hold information.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test can be done after
the login process.
• References: None.
Test Case 10:
• Test case identifier: Quotation_Update2
• Input: Leave any of the required field’s blank and click
submit
• Expected output: Message should be displayed saying
required field does not hold information.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test can be done after
the login process.
• References: None.
Test Case 11:
• Test case identifier: Quotation_Update3
• Input: Enter valid information in all the required fields and
click submit
• Expected output: Success Message should be displayed
saying Quotation updated successfully.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test can be done after
the login process.
• References: None.
Component 4: Sales Order Processing

Test case group

Index Page
identification
Functions Tested Include

• Buttons to Select

o Customer Login
o New Customer Registration
Functions to be
o View Product
tested
o Sales Order Form
o Sales Order Cancellation
o Delivery Chelan
o Delivery Chelan Cancellation

Testing approach Testing whether the buttons are navigating to the correct pages and
producing the proper results.
Pass/Fail criteria User has to enter username and password, which is valid and user
should be an authorized person. The buttons should navigate to the
correct pages and should produce the correct results.
Individual testTest Case 1:
cases • Test case identifier: Customer_login1
• Input: Enter Invalid username and password and click submit
• Expected output: Message should be displayed saying
username or password is Invalid.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test case has no
dependencies.
 • References: None.
Test Case 2:
• Test case identifier: Customer_login2
• Input: Enter valid username and password and click submit
• Expected output: Success Message should be displayed saying
user is valid and logs in.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test case has no
dependencies
• References: None.
Test Case 3:
• Test case identifier: Customer_Registration1
• Input: Leave all fields empty and click submit
• Expected output: Message should be displayed saying required
fields do not hold information.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test case has no
dependencies.
• References: None.
Test Case 4:
• Test case identifier: Customer_ Registration2
• Input: Enter any input in any field and click reset
• Expected output: All fields should be reset to their original
value.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test case has no
dependencies.
• References: None.
Test Case 5:
• Test case identifier: Customer_ Registration3
• Input: Enter new, valid username and enter valid information in
all other required fields and click submit
• Expected output: Success Message should be displayed saying
user was added successfully.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test case has no
dependencies.
• References: None.
Test Case 6:
• Test case identifier: View_Products
• Input: Click the View Products button.
• Expected output: All the Products should be displayed.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test can be done after the
login process.
• References: None.
Test Case 7:
• Test case identifier: Sales_Order1
• Input: Leave all fields empty and click submit
• Expected output: Message should be displayed saying required
fields do not hold information.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test can be done after the
login process.
• References: None.
Test Case 8:
 • Test case identifier: Sales_Order2
• Input: Leave any of the required field’s blank and click submit
• Expected output: Message should be displayed saying required
field does not hold information.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test can be done after the
login process.
• References: None.
Test Case 9:
• Test case identifier: Sales_Order3
• Input: Enter any input in any field and click reset
• Expected output: All fields should be reset to their original
value.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test can be done after the
login process.
• References: None.
Test Case 10:
• Test case identifier: Sales_Order4
• Input: Enter valid information in all the required fields and
click submit
• Expected output: Success Message should be displayed saying
new Sales order generated successfully.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test can be done after the
login process.
• References: None.
Test Case 11:
 • Test case identifier: Sales_Order_Cancellation1
• Input: Leave all fields empty and click submit
• Expected output: Message should be displayed saying required
fields do not hold information.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test can be done after the
login process.
• References: None.
Test Case 12:
• Test case identifier: Sales_Order_Cancellation2
• Input: Leave any of the required field’s blank and click submit
• Expected output: Message should be displayed saying required
field does not hold information.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test can be done after the
login process.
• References: None.
Test Case 13:
• Test case identifier: Sales_Order_Cancellation3
• Input: Enter any input in any field and click reset
• Expected output: All fields should be reset to their original
value.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test can be done after the
login process.
• References: None.
Test Case 14:
• Test case identifier: Sales_Order_Cancellation4
 • Input: Enter valid information in all the required fields and
click submit
• Expected output: Success Message should be displayed saying
Sales order has cancelled successfully.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test can be done after the
login process.
• References: None.
Test Case 15:
• Test case identifier: Delivery_chelan1
• Input: Leave all fields empty and click submit
• Expected output: Message should be displayed saying required
fields do not hold information.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test can be done after the
login process.
• References: None.
Test Case 16:
• Test case identifier: Delivery_chelan2
• Input: Enter any input in any field and click reset
• Expected output: All fields should be reset to their original
value.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test can be done after the
login process.
• References: None.
Test Case 17:
• Test case identifier: Delivery_chelan3
 • Input: Enter valid information in all the required fields and
click submit
• Expected output: Success Message should be displayed saying
delivery Chelan sent successfully.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test can be done after the
login process.
• References: None.
Test Case 18:
• Test case identifier: Delivery_Chelan_Cancellation1
• Input: Leave all fields empty and click submit
• Expected output: Message should be displayed saying required
fields do not hold information.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test can be done after the
login process.
• References: None.
Test Case 19:
• Test case identifier: Delivery_Chelan_Cancellation2
• Input: Enter any input in any field and click reset
• Expected output: All fields should be reset to their original
value.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test can be done after the
login process.
• References: None.
Test Case 20:
• Test case identifier: Delivery_Cancellation3
 • Input: Enter valid information in all the required fields and
click submit
• Expected output: Success Message should be displayed saying
Delivery Chelan has cancelled successfully.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test can be done after the
login process.
• References: None.

Component 5: Return

Test case group

Index Page
identification
Functions Tested Include

• Buttons to Select
Functions to be
tested
o Items Return to the Supplier
o Products Return to the Manufacturer

Testing approach Testing whether Menu appears according to the customer who logs
in to the system
Pass/Fail criteria User has to enter username and password, which is valid and user should be an
authorized person.
Individual test cases Test Case 1:
• Test case identifier: Item_Return1
• Input: Leave all fields empty and click submit
• Expected output: Message should be displayed saying
 required fields do not hold information.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test can be done after
the login process.
• References: None.
Test Case 2:
• Test case identifier: Item_return_2
• Input: Enter any input in any field and click reset
• Expected output: All fields should be reset to their original
value.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test can be done after
the login process.
• References: None.
Test Case 3:
• Test case identifier: Item_return_3
• Input: Enter new, valid item information and click submit.
• Expected output: Success Message should be displayed
saying item has returned successfully.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test case requires that
the corresponding item information have already been return.
• References: None.
Test Case 4:
• Test case identifier: Product_Return1
• Input: Leave all fields empty and click submit
• Expected output: Message should be displayed saying
required fields do not hold information.
 • Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test can be done after
the login process.
• References: None.
Test Case 5:
• Test case identifier: Product_return_2
• Input: Enter any input in any field and click reset
• Expected output: All fields should be reset to their original
value.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test can be done after
the login process.
• References: None.
Test Case 6:
• Test case identifier: Product_return_3
• Input: Enter new, valid item information and clicks submit.
• Expected output: Success Message should be displayed
saying Product has returned successfully.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test case requires that
the corresponding product information have already been
returned.
• References: None.

Component 6: Reports
Test case group
Index Page
identification
Functions Tested Include

• Buttons to Select
Functions to be tested
o Purchase Order reports
o Sales Order reports

Testing approach Testing whether Menu appears according to the customer who logs
in to the system
Pass/Fail criteria User has to enter username and password, which is valid and user
should be an authorized person.
Individual test cases Test Case 1:

• Test case identifier: Purchase_order_report

• Input: Click the View Purchase order report button.
• Expected output: All the reports related to purchase order should
be displayed.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
• Precedence and dependencies: This test can be done after the
login process.
• References: None.

Test Case 2:

• Test case identifier: Sales_order_report

• Input: Click the View sales order report button.
• Expected output: All the reports related to sales order should be
displayed.
• Environment: No special testing environment is required.
• Special procedures: No special procedures are required.
 • Precedence and dependencies: This test can be done after the
login process.
• References: None.

3. System Test Plans and Procedures

3.1 System test strategy overview

The entire software product is tested after each individual module has already
been tested. The integration tests ensure that the modules work together as well as they
works individually.

3.2 Linking Integration

Test Case Group: Linking Integration
Features Tested: Links and buttons from the various screens within the
application.
Testing Approach: Inspection
Pass/Fail Criteria: All modules must be functioning as tested individually
in the component verification. When user clicks the supplier link it should
link correctly to the supplier login page.

3.3 Coherence and Accuracy of Information

Test Case Group: Coherence and accuracy of information.

Features Tested: Information content of each page.
Testing Approach: Inspection of the information and its organization,
accuracy, and flow.
 Pass/Fail Criteria: The information must be correct and accurate, yet
simple enough for 3rd graders. The organization and flow must be logical
so that the concepts can be understood easily.

4. Acceptance Test and Preparation for Delivery

4.1 Procedure by which the software product will be acceptance tested

User acceptance test of a system is the key factor for the success of the system.
The system under consideration was listed for user acceptance by keeping constant touch
with the perspective user of the system at the time of design, development and making
changes whenever required. This was done with the regards of the following Points:
• The components at the highest levels of the system will be tested first.
Time permitting, each branch will be followed to a sub-component and
then tested until the most detailed components at the lowest levels have all
been tested and any errors have been corrected.
• The team members will verify the product by going through the test cases,
especially usability and qualitative testing.
• The product will be evaluated to ensure that it meets design specifications
stated in the SRS and SDS. Client will participate in acceptance testing
throughout product development, after various releases.

4.2 Specific acceptance criteria

The client expects the following:
• The application should be accessible to all clients from their desk
regardless of their location.
• The application will have a standard graphical user interface.
• Less time consuming and more efficient.
• The application should receive input from the user and the user will be
directed to the correct page and information.
• The application will be tested for invalid inputs
4.3 Scenario by which the software product will be installed
As SCM is a web application so the software must only be installed on the server.
Client machines will have to be connected to the server, so no installation is required in
the client side.