Verification Chris

8/8/2019 Verification Chris

http://slidepdf.com/reader/full/verification-chris 1/29

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 thefunction 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

application

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

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 testsmanually, 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

identificationIndex Page

Functions to be

tested

Functions Tested Include

• 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 test

cases

Test Case 1:

• 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.




dependencies




Test Case 3:

• Test case identifier: Addproduct_1

• Input: Leave all fields empty and click submit


required fields do not hold information.




dependencies.


Test Case 4:


• Input: Enter any input in any field and click reset

• Expected output: All fields should be reset to their original

value.



•

Precedence and dependencies: This test case has nodependencies.


Test Case 5:


• Input: Enter new, valid product information and click submit.


contact was added successfully.



• Precedence and dependencies: This test case requires that the

product information has already been added.




Test Case 6:

• Test case identifier: Pending_Order

• Input: Click the View Pending order button.

• Expected output: All the Pending order should be displayed.



• Precedence and dependencies: This test can be done after the

login process.


Test Case 7:

• Test case identifier: Delivered_Order

• Input: Click the View delivered order button.

• Expected output: All the delivered order should be displayed.




login process.


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.




login process.


Component 2: Source



Test case group


Functions to be

tested



o Supplier Login

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.




Individual test

cases

Test Case 1:

• Test case identifier: Supplier_login1







dependencies.


Test Case 2:

• Test case identifier: Supplier_login2









dependencies


Test Case 3:

• Test case identifier: Supplier_Registration1


• Expected output: Message should be displayed saying required

fields do not hold information.




dependencies.


Test Case 4:

•

Test case identifier: Supplier_ Registration2• Input: Leave any of the required field’s blank and click submit


field does not hold information.




dependencies.


Test Case 5:

• Test case identifier: Customer_ Registration3





value.




dependencies.


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.




dependencies.


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


user was added successfully.




dependencies.


Test Case 8:

• Test case identifier: View_Products

• Input: Click the View Products button.



• Expected output: All the Products should be displayed.




login process.


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.




login process.


Component 3: Purchase Order Management

Test case group


Functions to be

tested



o Purchase Order Generation

o Purchase Order Cancellation

o Quotation Update




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






• Precedence and dependencies: This test can be done after

the login process.


Test Case 2:


• Input: Leave any of the required field’s blank and click

submit


required field does not hold information.




the login process.

•

References: None.Test Case 3:




value.






the login process.


Test Case 4:


• 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.




the login process.


Test Case 5:

•

Test case identifier: Purchase_Order_Cancellation1• Input: Leave all fields empty and click submit






the login process.


Test Case 6:

• Test case identifier: Purchase_Order_Cancellation2


submit








the login process.


Test Case 7:

• Test case identifier: Purchase_Order_Cancellation3



value.




the login process.


Test Case 8:

•

Test case identifier: Purchase_Order_Cancellation4• Input: Enter valid information in all the required fields and

click submit


saying purchase order cancelled successfully.




the login process.


Test Case 9:

• Test case identifier: Quotation_Update1









the login process.


Test Case 10:

• Test case identifier: Quotation_Update2


submit






the login process.


Test Case 11:• Test case identifier: Quotation_Update3


click submit


saying Quotation updated successfully.




the login process.




Component 4: Sales Order Processing

Test case group


Functions to be

tested



o Customer Login

o New Customer Registration

o View Product

o Sales Order Form

o Sales Order Cancellation

o Delivery Chelan

o Delivery Chelan Cancellation


producing the proper results.Pass/Fail criteria User has to enter username and password, which is valid and user



Individual test

cases

Test Case 1:

• Test case identifier: Customer_login1







dependencies.




Test Case 2:

• Test case identifier: Customer_login2







dependencies


Test Case 3:

• Test case identifier: Customer_Registration1






•

Precedence and dependencies: This test case has nodependencies.


Test Case 4:




value.




dependencies.




Test Case 5:


• Input: Enter new, valid username and enter valid information in

all other required fields and click submit


user was added successfully.




dependencies.


Test Case 6:

• Test case identifier: View_Products

• Input: Click the View Products button.

• Expected output: All the Products should be displayed.




login process.• References: None.

Test Case 7:

• Test case identifier: Sales_Order1







login process.


Test Case 8:




• Input: Leave any of the required field’s blank and click submit






login process.


Test Case 9:




value.




login process.

•




click submit


new Sales order generated successfully.




login process.


Test Case 11:



• Test case identifier: Sales_Order_Cancellation1







login process.


Test Case 12:


• Input: Leave any of the required field’s blank and click submit






login process.

•





value.




login process.


Test Case 14:





click submit


Sales order has cancelled successfully.




login process.


Test Case 15:

• Test case identifier: Delivery_chelan1







login process.

•





value.




login process.


Test Case 17:





click submit


delivery Chelan sent successfully.




login process.


Test Case 18:

• Test case identifier: Delivery_Chelan_Cancellation1







login process.

•


• Test case identifier: Delivery_Chelan_Cancellation2



value.




login process.


Test Case 20:

• Test case identifier: Delivery_Cancellation3




click submit


Delivery Chelan has cancelled successfully.




login process.


Component 5: Return

Test case group


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









the login process.


Test Case 2:

• Test case identifier: Item_return_2



value.




the login process.


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.



• Precedence and dependencies: This test case requires that

the corresponding item information have already been return.


Test Case 4:

• Test case identifier: Product_Return1









the login process.


Test Case 5:

• Test case identifier: Product_return_2



value.




the login process.


Test Case 6:

• Test case identifier: Product_return_3

• Input: Enter new, valid item information and clicks submit.

•

Expected output: Success Message should be displayedsaying Product has returned successfully.



• Precedence and dependencies: This test case requires that

the corresponding product information have already been

returned.


Component 6: Reports



Test case group


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


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.




login process.


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.






login process.


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: InspectionPass/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.

Verification Chris

Documents

Transcript of Verification Chris