Project Title

Test Plan

Cohort: A

Group: 1
Group members:

ABC 123 (Team leader)

XYZ 456
1.1.1 Document Acceptance and Release Notice
This document is authorised for release once all signatures have been obtained.

PREPARED: Date: / /
(for acceptance) <Name>
Project Manager, Student Group

ACCEPTED: Date: / /
(for release)
Project Sponsor, VIT
Table of Contents

1. Introduction..............................................................................................................................1

1.2 Scope.................................................................................................................................1
1.3 Quality Objective..............................................................................................................1
1.4 Roles and Responsibilities................................................................................................1

2 Test Methodology.....................................................................................................................1

2.1 Overview...........................................................................................................................1
2.2 Test Levels........................................................................................................................1
2.3 Test Completeness.............................................................................................................2

3 Test Deliverables.......................................................................................................................2

3.1 Overview...........................................................................................................................2
3.2 Test Cases..........................................................................................................................2

4 Resources and Environment Needs........................................................................................2

4.1 Testing Tools.....................................................................................................................2

4.2 Test Cases..........................................................................................................................2

5 References.................................................................................................................................3
List of Figures

Fig 1. 1 My lecturer..............................................................................................................................1

Fig 3. 1 Testing strategy diagram.........................................................................................................2

List of Tables

Table 3. 1 Test Case table....................................................................................................................2

Glossary

API Application Program Interface

AUT Application Under Test
1. Introduction

The primary goal of an auto warehouse management system is to manage the movement and
storage of auto items inside a warehouse and to conduct transactions. It is a critical link in the
supply chain. Shipping, receiving, and selecting are all included in this. Manhattan, Redpraire, etc.
are used by most shops to manage the auto warehouse management system business process flows.
To complicate matters further, there are several application adjustable factors, and the number of
available options is growing all the time. Testing a warehouse management system needs a
thorough understanding of what you're testing and why. Auto warehouse management system
implementations need thorough testing to verify the project is a success; this is a vital element of
the process [1]. We use iterative testing to make sure that the system is thoroughly tested both
during the design/build process and before it goes online. Functional and technical testing are
included in this.

1.2 Scope

Managing sales and inventories of auto components are made simpler with this project's emphasis
on lower-cost accessories that also increase profit. To achieve the project's primary goal of
increasing revenue, the modules in the system must be structured in a way that maximizes
efficiency and for that, the testing of the auto warehouse management system to go successful is
very important.

1.3 Quality Objective

As a starting point, be sure what you want to accomplish is very clear. Testing is the act of running
software to look for bugs. It is necessary to create test cases to carry out the actual testing. A test
case is a setting in which software is put through its paces to detect faults. So, a good test case
identifies previously unnoticed flaws. Performing appropriate testing will reveal bugs, which may
then be fixed to produce software that adheres to the standards. To achieve this goal, one must shift
their perspective dramatically [6]. According to conventional wisdom, a successful test is one where
no mistakes are discovered. It is our goal to build tests that are can notify a wide range of faults in a
short period and with little effort.

1.4 Roles and Responsibilities

Designation Responsibilities
Page 1
 Project Test Lead The person in charge of the project testing.
This individual is also responsible for the
quality of the output.
Testing Designer This individual creates the test scripts,
scenarios, and test lives [5].
Test Approver The individual reviews validate and approve
the team’s test design materials.
Tester Executes test scripts and reports findings.

2 Test Methodology

2.1 Overview

Both software development and software testing use it. Agile model testing is conducted from the
viewpoint of the end-users [2]. Rather than focusing on rigorous testing processes, the focus is on
iterative testing on the newly built software component, as well as regression testing on the
complete product to see if any new issues have been introduced. The emphasis is shifted from
"testers as quality watchdogs" to "the whole team as quality watchdog" in the agile testing
methodology. The testing methodology's name implies that testers must be able to keep up with the
quick pace of development and make necessary adjustments to the test suite. In this sort of software
testing, the goal is to test as early in the development process as feasible from the standpoint of the
client. As early as possible in the software development process, testers provide the essential
information, comments, and ideas to the development team, rather than after the project has reached
its final phases. With the advent of the agile paradigm, software development now has a tried-and-
true approach. It is thus possible to put into reality the notion of "maximize stakeholder value,"
which leaves the consumer content and pleased.

Page 2
2.2 Test Levels

In the first technique, simply the product's general functionality is examined. Inputs and outputs are
gathered and tested. It is this kind of testing that is known as "black box" testing. It has no interest
in the product's interior workings. White box testing is the alternative strategy. Here, the product's
internal workings are tested. The correctness of each technique is evaluated. Black box testing is
more time-consuming. However, both of these methods are critical to the final output. The whole
product should be tested by a sufficient number of tests in both categories.

Black Box Testing: It is necessary to do black-box tests to determine if a software is meeting its
specifications and to check for errors or omissions in its functioning. Valid or nearly valid input is
used in functional tests to exercise code whose intended outcome is known. 'Boundary values,' for
example, fall within this category. Response time, memory use, throughput, device utilization, and
execution time are all evaluated as part of a performance test's overall score. To assess a system's
resilience and error handling capabilities, stress tests push it to or above its defined limitations [4].
To gauge or verify a system's dependability, reliability tests track how well it responds to
representative user input over time. Incorrect or missing functions, interface problems, external
database access, performance flaws, and start-ups and termination faults may all be found by doing
black-box testing

White Box Testing: It is done to find flaws with the program's internal structure via white box
testing. This requires a thorough understanding of the program's internal workings. This is a
frequent aim of white-box testing: to verify that a test case runs on every possible route through a
software, if possible. White box testing has the advantage of considering the full program
implementation, even when the software specification is ambiguous or partial, which is a basic
strength shared by all-white box methodologies. Test or code coverage metrics, which quantify the
proportion of code exercised by test cases, are often used to represent the success or completeness
of white box testing.

2.3 Test Completeness

The test would be completed when all the test cases are executed and all the bugs reported are fixed
by the team

Page 3
3 Test Deliverables

3.1 Overview

We understand the importance of a test case. So, we need to learn more about test cases and how
these test cases are built [5]. Test cases should be able to uncover the most faults in the least amount
of time and effort, which is what most people anticipate from them.

3.2 Test Cases

Table 3-1 Test Case Table

Input Test Case Provided Output Output Test Case

Provider Input Expected Generated Outcome
Admin Notify the Set a Successful Successful Successful
supplier when minimum contact is contact is
the product value of auto made with the made with the
almost goes out product supplier and supplier and
of stock below which an invoice of an invoice of
the system the transaction the
contacts the is generated transaction is
supplier generated
Admin Updates Check The system is The system is Successful
Inventory whether the working working
system has properly properly
reduced the
number of
products in
the
warehouse in
case of any
orders.
Customer Provides Name, email- Data is added Data is added Successful
personal id, password, to the system to the system
information for and card

Page 4
 login or sign up details
Customer Searches and Pays online Cart value is Cart value is Successful
add the product for the cart correctly correctly
to the cart value calculated and calculated and
after after
successful successful
order is order is
counted and counted and
updated in the updated in the
system system

4 Resources and Environment Needs

4.1 Testing Tools

Tools required are functional testing tool, load testing tool, and volume testing tool.

4.2 Hardware/Software Requirements

Hardware required is a minimum of 4GB of RAM, 256GB of internal free memory, and software
requirements are Windows 8 or above and Java Development Kit.

5 References
[1] SCJunction, “How to Prepare for your Warehouse Management System implementation,”
www.scjunction.com. https://www.scjunction.com/blog/how-to-prepare-for-a-successful-
warehouse-management-system-implementation (accessed May 14, 2022).
[2] SAP, “SAP Help Portal,” help.sap.com.
https://help.sap.com/docs/SAP_Solution_Manager/fbc7b5ecf5094fe0b6a2eb966160008f/
48e151fddb163184e10000000a421937.html?version=7.2.06 (accessed May 14, 2022).
[3] T. Shahaf, “Test Plans: Basics to Best Practices,” Perforce Software.
https://www.perforce.com/blog/alm/test-plans-basics-best-practices

Page 5
[4] ReQtest, “Agile board to Prioritize, Delegate & Track tasks | ReQtest,” ReQtest, 2016.
https://reqtest.com/features/agile-board/ (accessed May 14, 2022).
[5] H2KInfosys, “Different roles in a software testing team - Software testing,” Mar. 29, 2018.
https://www.h2kinfosys.com/blog/different-roles-software-testing-team/
[6] veridian, “Warehouse Management System Testing: How Do You Want to Test Your WMS?,”
Veridian, Jul. 13, 2018. https://veridian.info/warehouse-management-system-testing/

Page 6