PROJECT REPORT

ON

Cloud Based Retail CRM

SUBMITTED IN FULFILLMENT OF DEGREE

IN

Master of Computer Applications

(BATCH ***********)
 Table of Contents:
Sr. no: Title Page no.
1. INTRODUCTION
1.1 Company Profile
1.2 About the System under Test
1.3 Scope of Work
1.4 Operating Environment - Hardware and Software
1.5 Detailed Description of Tool(s) Used in Testing
2. TEST PLANNING
2.1 Objectives of Testing
2.2 Software Requirement Specification
2.3 Master Test Plan (IEEE format)
2.4 Review of Test Basis (prototype testing)
3. TEST ANALYSIS & DESIGN
3.1 Use Case Diagram of the System
3.2 Module Hierarchy Diagram
3.3 Unit Test Plan
3.4 Test Harness
3.5 Development of Test Scenario as per requirements
3.6 Requirement Traceability Matrix (Horizontal
traceability)
3.7 Test Case Design
3.8 Test Data Generation
3.9 Test Execution
3.10 Defect Screens (Snapshots)
3.11Test Log
3.12 Defect Report
3.13 Defect Metrics (List of all defect metrics employed
and its values)
3.14 Test Summary Report
4. USER (TESTER) MANUAL
4.1 Test Procedure Specification
4.2 Test Scripts
4.3 RTM (vertical traceability)
4.4 Configuration Management (Test Item transmittal
Report)
 CHAPTER 1 : INTRODUCTION

1.1 Company Profile

Software architecture is not just a buzzword to push senior resources in a software development.
Architecture not only brings down the cost of software but also reduces product development
risks. A smart architect foresees and guards against issues of scalability, extensibility,
performance and security. WMIS has accumulated experience of designing systems that align
with changing business needs. Our architects come with a deep understanding of Microsoft
Technologies, J2EE & open source technology stack, with good handle on upcoming trends in
cloud and mobile technologies. Web Minds Technology is a leader in Software Development and
empowers IT individuals with competitive advantage. Web Minds Technology dedicates itself to
simplify the technology trends with its great R&D Division. Web Minds Technology is an Indian
Software Development Company. A rapidly growing software company with a team of
experienced intellectuals working in various technologies. It deals with Product and Service
based applications in all major areas. We are committed to the qualitative, efficiency,
innovativeness and timeliness of our deliverables with high focus on maximum customer
satisfaction. Web Minds Technology is a high end full service IT solution Company based in
India. Established in 2010, we are pioneer in providing total offshore and onshore web based
solutions for small to large corporate companies. Web Minds Technology provides IT services to
clients globally as partners to conceptualize and realize technology driven business
transformation initiatives. Today we are comprised of a team of programming technicians,
designers, and marketing executives- selectively chosen to lead our clients in their IT solutions.

Web Minds Technology has grown from strength to strength in both our Business and Software
Solutions arena. From our IT Consulting as well as Custom Application Development, Web
Development and E-commerce all of which help our customers with their diverse yet demanding
needs. We are geared towards generating business value to the companies by providing expertise
personnel and software services.
Our Services

Web Minds Technology provides various Software Development services to the clients located
worldwide in order to rationalize their business processes and e-enabling their business. We, at
Web Minds Technology strongly believe that technology is a true business enhancer and you
should not implement technology for the sake of it. That's why; we help you make best use of
information technology. With the use of our services such as application development,
application migration and application maintenance for your existing applications, you can
formulate the best possible use of technology. We are a team of professional organization teamed
by competent, committed, qualified and experienced personnel in various field. With the help of
our commitment to professionalism and excellence. The programmers we design are developed
to meet specific organizational needs. We provide a service that provides clients with value for
each rupee invested. So feel free to come forward and avail the opportunity of getting reasonably
priced consultancy services from us.

IT PROVIDES THE FOLLOWING SERVICES TO THE CLIENTS:-

1. Web Development
2. Android Development
3. Node Js Development
4. Internet of Things
5. Oracle and My SQL.
6. Linux and Unix
Address-

1st Floor, Near Pranit Computer , Karvenagar, Pune-411052.

Contact Person- Mr. Shekhar Thube.

Mob- 9503522733.

www. webmindstechnosys.com

1.2 About the System under Test

In many organizations the Distributors’ and the retailer or the wholesaler data is
managed manually so it is very tedious and crucial task to manage huge data manually. Some
organizations use the CRM systems to manage their data but it is an e-CRM and it uses internet
and centralized data so availability of data is 24/7. And it also provides more functionalities than
CRM. Some organizations use CRM but it’s not provide the facilities of Customization. Many
CRM systems has the lack of communication facilities such as mails and SMS communication but
this system will provide fully customized e-CRM functionalities to business organization with the
advantage of mail, SMS facilities and some more flexible facilities that are not found generally in
many CRM systems that are available in market such as Distributor and retailer details
management, Book the order through Missed call, Placed orders and sales order management,
Contact us enquiry management.
The project titled as “Food CRM “is a web based application. This application is useful for the
Company Owner, Distributor and the Retailer or the wholesaler. This System is developed for
the business organizations to manage their customer’s data effectively and to improve their
profit which will helps to increase the organizations business. It will not just to maintain
customer’s details and their data but it also provides some features that helps to business
organizations to increase communication with their customers using some facilities of this
system such as Email and SMS facilities.

Business organizations can also generate reports in various formats and these reports help
business organizations for various types of analysis like date wise report and all. They can use
these reports in decision making processes and also for customer satisfaction by analyzing their
needs and problems. Here the retailer can book the order just give the simple missed call on the
websites Toll-free no (Missed call no). Then his/her mobile no is updated to respective
Distributor and the Admin panel. Here the admin can add the distributor and maintain all the
data regarding distributor like Placed order, Date wise Order report, list of Distributor list. Same
the Distributor can add the Retailer or the wholesaler through his/her own distributor panel.
Here admin can see all the details regarding respective distributor and respective dealer. In this
application we integrate the Missed call Service API and SMS API. This application is useful for
the Admin to see all the data at one click only. It a CRM application it maintain the
communication between the Admin, Distributor and the Retailer.
Here is the Separate panel for the Admin and the Distributor. There is no any panel for the
Retailer. By using this application the efficiency of the Business is increased. This application is
developed as per the requirement of the client.
 This application is related with all the food products like Ground Nut oil, Soybean Oil, Dal and
Pulses, Turmeric Powder, Coriander powder etc. It also provides the customization facility to
Admin so that Admin can customize this system as per his/her organizational needs like add the
product category and subcategory. Business organizations can manage their Distributor and
Retailer management and support tasks through this system. They can also manage their sales
orders, Contact us enquiry, Retailer Missed call no, and much more through this system.

1.3 Scope of Work

1) To reduce the workload for maintaining Distributor and retailer data manually, this
system will helps to manage this details and their complete data.
2) Using this system admin can manage all Distributor, Orders, contacts us enquiry, Order
management, Product category and subcategory customization.
3) Admin can also generate the Date wise Report using this system.
4) This system provides the facility of customization so admin can customize the system as
per their needs.
5) This system provides mail manager facility and SMS facility by using this facility admin can
communicate with the distributor and the retailer within the organization as well as with
the customers.
6) Admin can also manage their documents and tasks through this system.
7) System can send the SMS to Distributor, Customers for promoting their products or SMS
as a response to customer’s complaints or requests.

1.4 Operating Environment - Hardware and Software

1.2 Operational Environments

Hardware Specifications (Client Side)

RAM Minimum 512MB and above

 Hard Disk Minimum 40 GB and above

Processor Pentium-IV and above

Hardware Specifications (Server Side)

RAM Minimum 2GB and above

Hard Disk Minimum 80 GB and above

Processor Pentium-IV and above

Software Specifications (Client Side)

Operating System Windows XP/Later

Internet Explorer-6/Later
Web Browser
Mozilla Firefox

Software Specifications (Server Side)

Operating System Windows XP/Later

Internet Explorer-6/Later
Web Browser
Mozilla Firefox

Technology Java 1.7, J2EE., Android

Testing Platform Manual + Automation (Selenium )

Database SqLite

Development Tool(Editor) Android Studio

Server Cloud Server ---Amazon

Supporting Technology Ajax, JavaScript, Jquery.

1.5 Detailed Description of Tool(s) Used in Testing

Automation for Web Applications: Selenium

Selenium testing is applied for this application. It is tested Many, perhaps most, software
applications today are written as web-based applications to be run in an Internet browser. The
effectiveness of testing these applications varies widely among companies and organizations. In
an era of highly interactive and responsive software processes where many organizations are
using some form of Agile methodology, test automation is frequently becoming a requirement
for software projects. Test automation is often the answer. Test automation means using a
software tool to run repeatable tests against the application to be tested. For regression testing
this provides that responsiveness.

There are many advantages to test automation. Most are related to the repeatability of the tests
and the speed at which the tests can be executed. There are a number of commercial and open
source tools available for assisting with the development of test automation. Selenium is possibly
the most widely-used open source solution. This user’s guide will assist both new and
experienced Selenium users in learning effective techniques in building test automation for web
applications.

This user’s guide introduces Selenium, teaches its features, and presents commonly used best
practices accumulated from the Selenium community. Many examples are provided. Also,
technical information on the internal structure of Selenium and recommended uses of Selenium
are provided.

Test automation has specific advantages for improving the long-term efficiency of a software
team’s testing processes. Test automation supports:

 Frequent regression testing

 Rapid feedback to developers
 Virtually unlimited iterations of test case execution
 Support for Agile and extreme development methodologies
 Disciplined documentation of test cases
 Customized defect reporting
 Finding defects missed by manual testing

To Automate or Not to Automate for Our Application?

Is automation always advantageous? When should one decide to automate test cases?

It is not always advantageous to automate test cases. There are times when manual testing may
be more appropriate. For instance, if the application’s user interface will change considerably in
the near future, then any automation might need to be rewritten anyway. Also, sometimes there
simply is not enough time to build test automation. For the short term, manual testing may be
more effective. If an application has a very tight deadline, there is currently no test automation
available, and it’s imperative that the testing get done within that time frame, then manual testing
is the best solution.

Introducing Selenium

Selenium is a set of different software tools each with a different approach to supporting test
automation. Most Selenium QA Engineers focus on the one or two tools that most meet the
needs of their project, however learning all the tools will give you many different options for
approaching different test automation problems. The entire suite of tools results in a rich set of
testing functions specifically geared to the needs of testing of web applications of all types.
These operations are highly flexible, allowing many options for locating UI elements and
comparing expected test results against actual application behavior. One of Selenium’s key
features is the support for executing one’s tests on multiple browser platforms.

Selenium’s Tool Suite

Selenium is composed of multiple software tools. Each has a specific role.

Selenium 2 (aka. Selenium WebDriver)

Selenium 2 is the future direction of the project and the newest addition to the Selenium toolkit.
This brand new automation tool provides all sorts of awesome features, including a more
cohesive and object oriented API as well as an answer to the limitations of the old
implementation.

As you can read in Brief History of The Selenium Project, both the Selenium and WebDriver
developers agreed that both tools have advantages and that merging the two projects would make
a much more robust automation tool.

Selenium 2.0 is the product of that effort. It supports the WebDriver API and underlying
technology, along with the Selenium 1 technology underneath the WebDriver API for maximum
flexibility in porting your tests. In addition, Selenium 2 still runs Selenium 1’s Selenium RC
interface for backwards compatibility.

Selenium 1 (aka. Selenium RC or Remote Control)

As you can read in Brief History of The Selenium Project, Selenium RC was the main Selenium
project for a long time, before the WebDriver/Selenium merge brought up Selenium 2, the
newest and more powerful tool.

Now Selenium 1 is deprecated and is not actively supported (mostly in maintenance mode).

Selenium IDE

Selenium IDE (Integrated Development Environment) is a prototyping tool for building test
scripts. It is a Firefox plugin and provides an easy-to-use interface for developing automated
tests. Selenium IDE has a recording feature, which records user actions as they are performed
and then exports them as a reusable script in one of many programming languages that can be
later executed.

Selenium-Grid

Selenium-Grid allows the Selenium RC solution to scale for large test suites and for test suites
that must be run in multiple environments. Selenium Grid allows you to run your tests in parallel,
that is, different tests can be run at the same time on different remote machines. This has two
advantages. First, if you have a large test suite, or a slow-running test suite, you can boost its
performance substantially by using Selenium Grid to divide your test suite to run different tests
at the same time using those different machines. Also, if you must run your test suite on multiple
environments you can have different remote machines supporting and running your tests in them
at the same time. In each case Selenium Grid greatly improves the time it takes to run your suite
by making use of parallel processing.

Supported Browsers and Platforms

In Selenium 2.0, the supported browsers vary depending on whether you are using Selenium-
WebDriver or Selenium-RC.

Selenium-WebDriver

Selenium-WebDriver supports the following browsers along with the operating systems these
browsers are compatible with.

 Google Chrome
 Internet Explorer 7, 8, 9, 10, and 11 on appropriate combinations of Vista, Windows 7,
Windows 8, and Windows 8.1. As of April 15 2014, IE 6 is no longer supported. The
driver supports running 32-bit and 64-bit versions of the browser where applicable
  Firefox: latest ESR, previous ESR, current release, one previous release
 Safari
 Opera
 HtmlUnit
 phantomjs
 Android (with Selendroid or appium)
 iOS (with ios-driver or appium)

Selenium 1.0 and Selenium-RC.

This is the old, support platform for Selenium 1.0. It should still apply to the Selenium 2.0
release of Selenium-RC.

Browser Selenium IDE Selenium 1 (RC) Operating Systems

Windows, Linux,
Firefox 3.x Record and playback tests Start browser, run tests
Mac
Windows, Linux,
Firefox 3 Record and playback tests Start browser, run tests
Mac
Windows, Linux,
Firefox 2 Record and playback tests Start browser, run tests
Mac
Test execution only via Selenium
IE 8 Start browser, run tests Windows
RC*
Test execution only via Selenium
IE 7 Start browser, run tests Windows
RC*
Test execution only via Selenium
IE 6 Start browser, run tests Windows
RC*
Test execution only via Selenium
Safari 4 Start browser, run tests Windows, Mac
RC
Test execution only via Selenium
Safari 3 Start browser, run tests Windows, Mac
RC
Test execution only via Selenium
Safari 2 Start browser, run tests Windows, Mac
RC
Test execution only via Selenium Windows, Linux,
Opera 10 Start browser, run tests
RC Mac
Test execution only via Selenium Windows, Linux,
Opera 9 Start browser, run tests
RC Mac
Opera 8 Test execution only via Selenium Start browser, run tests Windows, Linux,
 RC Mac
Google Test execution only via Selenium Windows, Linux,
Start browser, run tests
Chrome RC Mac
Test execution only via Selenium Partial support
Others As applicable
RC possible**

* Tests developed on Firefox via Selenium IDE can be executed on any other supported browser
via a simple Selenium RC command line.

** Selenium RC server can start any executable, but depending on browser security settings
there may be technical limitations that would limit certain features.

CHAPTER 2: TEST PLANNING

2.1 Objectives of Testing

Software Testing has different goals and objectives. The major objectives of Software testing are
as follows:

 Finding defects which may get created by the programmer while developing the software.
 Gaining confidence in and providing information about the level of quality.
 To prevent defects.
 To make sure that the end result meets the business and user requirements.
 To ensure that it satisfies the BRS that is Business Requirement Specification and SRS
that is System Requirement Specifications.
 To gain the confidence of the customers by providing them a quality product.

Software testing helps in finalizing the software application or product against business and user
requirements. It is very important to have good test coverage in order to test the software
application completely and make it sure that it’s performing well and as per the specifications.

While determining the test coverage the test cases should be designed well with maximum
possibilities of finding the errors or bugs. The test cases should be very effective. This objective
can be measured by the number of defects reported per test cases. Higher the number of the
defects reported the more effective are the test cases.

Once the delivery is made to the end users or the customers they should be able to operate it
without any complaints. In order to make this happen the tester should know as how the
customers are going to use this product and accordingly they should write down the test
scenarios and design the test cases. This will help a lot in fulfilling all the customer’s
requirements.

2.2 Software Requirement Specification

A software requirements specification (SRS) is a document that captures complete description

about how the system is expected to perform. It is usually signed off at the end of requirements
engineering phase.

Qualities of SRS:
  Correct
 Unambiguous
 Complete
 Consistent
 Ranked for importance and/or stability
 Verifiable
 Modifiable
 Traceable

Types of Requirements:

The below diagram depicts the various types of requirements that are captured during SRS.

What is Stability Testing?

Stability testing, a software testing technique adopted to verify if application can continuously
perform well within or just above the acceptable period.

It is a NON-Functional Testing technique conducted as part of performance testing often referred

as load or Endurance testing.
What is State Transition Testing?

State Transition testing, a black box testing technique, in which outputs are triggered by changes
to the input conditions or changes to 'state' of the system. In other words, tests are designed to
execute valid and invalid state transitions.

When to use?

 When we have sequence of events that occur and associated conditions that apply to
those events
 When the proper handling of a particular event depends on the events and conditions that
have occurred in the past
 It is used for real time systems with various states and transitions involved

Deriving Test cases:

 Understand the various state and transition and mark each valid and invalid state
 Defining a sequence of an event that leads to an allowed test ending state
 Each one of those visited state and traversed transition should be noted down
 Steps 2 and 3 should be repeated until all states have been visited and all transitions
traversed
 For test cases to have a good coverage, actual input values and the actual output values
have to be generated

Advantages:

 Allows testers to familiarise with the software design and enables them to design tests
effectively.
 It also enables testers to cover the unplanned or invalid states.

Example:

A System's transition is represented as shown in the below diagram:

The tests are derived from the above state and transition and below are the possible scenarios that
need to be tested.

Tests Test 1 Test 2 Test 3

Start State Off On On
Input Switch ON Switch Off Switch off
Output Light ON Light Off Fault
Finish State ON OFF On
2.3 Master Test Plan (IEEE format)

Introduction

This document is a high-level overview defining our testing strategy for the Sorted Binary Tree
application. Its objective is to communicate project-wide quality standards and procedures. It
portrays a snapshot of the project as of the end of the planning phase. This document will
address the different standards that will apply to the unit, integration and system testing of the
specified application. We will utilize testing criteria under the white box, black box, and system-
testing paradigm. This paradigm will include, but is not limited to, the testing criteria, methods,
and test cases of the overall design. Throughout the testing process we will be applying the test
documentation specifications described in the IEEE Standard 829-1983 for Software Test
Documentation.

Team Interaction

The following describes the level of team interaction necessary to have a successful product.

 The Test Team will work closely with the Development Team to achieve a high quality
design and user interface specifications based on customer requirements. The Test Team
is responsible for visualizing test cases and raising quality issues and concerns during
meetings to address issues early enough in the development cycle.

 The Test Team will work closely with Development Team to determine whether or not
the application meets standards for completeness. If an area is not acceptable for testing,
the code complete date will be pushed out, giving the developers additional time to
stabilize the area.

 Since the application interacts with a back-end system component, the Test Team will
need to include a plan for integration testing. Integration testing must be executed
successfully prior to system testing.
Test Objective

The objective our test plan is to find and report as many bugs as possible to improve the integrity
of our program. Although exhaustive testing is not possible, we will exercise a broad range of
tests to achieve our goal. We will be testing a Binary Search Tree Application utilizing a pre-
order traversal format. There will be eight key functions used to mange our application: load,
store, clear, search, insert, delete, list in ascending order, and list in descending order. Our user
interface to utilize these functions is designed to be user-friendly and provide easy manipulation
of the tree. The application will only be used as a demonstration tool, but we would like to
ensure that it could be run from a variety of platforms with little impact on performance or
usability.

Process Overview

The following represents the overall flow of the testing process:

1. Identify the requirements to be tested. All test cases shall be derived using the current
Program Specification.

2. Identify which particular test(s) will be used to test each module.

3. Review the test data and test cases to ensure that the unit has been thoroughly verified
and that the test data and test cases are adequate to verify proper operation of the unit.

4. Identify the expected results for each test.

5. Document the test case configuration, test data, and expected results.

6. Perform the test(s).

7. Document the test data, test cases, and test configuration used during the testing process.
This information shall be submitted via the Unit/System Test Report (STR).

8. Successful unit testing is required before the unit is eligible for component
integration/system testing.
 9. Unsuccessful testing requires a Bug Report Form to be generated. This document shall
describe the test case, the problem encountered, its possible cause, and the sequence of
events that led to the problem. It shall be used as a basis for later technical analysis.

10. Test documents and reports shall be submitted. Any specifications to be reviewed,
revised, or updated shall be handled immediately.

Testing Process

b. Design System
Test

a. Organize c. Design/Build e. Design/Build

Project Test Proc. Test Proc. f. Signoff

d. Organize
Project

Figure 1: Test Process Flow

The diagram above outlines the Test Process approach that will be followed.

a. Organize Project involves creating a System Test Plan, Schedule & Test Approach, and
assigning responsibilities.

b. Design/Build System Test involves identifying Test Cycles, Test Cases, Entrance & Exit
Criteria, Expected Results, etc. In general, test conditions/expected results will be
identified by the Test Team in conjunction with the Development Team. The Test Team
will then identify Test Cases and the Data required. The Test conditions are derived from
the Program Specifications Document.
 c. Design/Build Test Procedures includes setting up procedures such as Error
Management systems and Status reporting.

d. Build Test Environment includes requesting/building hardware, software and data set-
ups.

e. Execute System Tests – The tests identified in the Design/Build Test Procedures will be
executed. All results will be documented and Bug Report Forms filled out and given to
the Development Team as necessary.

f. Signoff - Signoff happens when all pre-defined exit criteria have been achieved.

Testing Strategy

The following outlines the types of testing that will be done for unit, integration, and system
testing. While it includes what will be tested, the specific use cases that determine how the
testing is done will be detailed in the Test Design Document. The template that will be used for
designing use cases is shown.
Tested By: Kanchan Tapkir

Test Type Manual

Test Case Number ED01

Test Case Name Registration

Login

Test Case Description Checking the Functionality of Registration and Login Button

Item(s) to be tested

1 Checking the Functionality of Registration Button

2 Checking the Functionality of Login Button

Specifications

Expected

Input Output/Result

Registration Details Registration Page should be open

Login details Login Page should be open

Procedural Steps

1 Provide valid data for registration.

2 Provide invalid data for registration.

3 Provide valid data for Login

4 Provide invalid data for Login.

Figure 2: Test Case for Login and Registration

Unit Testing

Unit Testing is done at the source or code level for language-specific programming errors such
as bad syntax, logic errors, or to test particular functions or code modules. The unit test cases
shall be designed to test the validity of the programs correctness.

White Box Testing

In white box testing, the UI is bypassed. Inputs and outputs are tested directly at the code level
and the results are compared against specifications. This form of testing ignores the function of
the program under test and will focus only on its code and the structure of that code. Test case
designers shall generate cases that not only cause each condition to take on all possible values at
least once, but that cause each such condition to be executed at least once. To ensure this
happens, we will be applying Branch Testing. Because the functionality of the program is
relatively simple, this method will be feasible to apply.

Each function of the binary tree repository is executed independently; therefore, a program flow
for each function has been derived from the code.

Branch Testing

Using the program flow graph for each function, we will be able to determine all of the branches
that will need to tested and will be used to develop the corresponding test cases.
Insert

Delete
 Search

List

Read (Load)
 Store/Write

Black Box Testing

Black box testing typically involves running through every possible input to verify that it results
in the right outputs using the software as an end-user would. We have decided to perform
Equivalence Partitioning and Boundary Value Analysis testing on our application.
Equivalence Partitioning

In considering the inputs for our equivalence testing, the following types will be used:

 Legal input values – Test values within boundaries of the specification equivalence
classes. This shall be input data the program expects and is programmed to transform
into usable values.
 Illegal input values – Test equivalence classes outside the boundaries of the specification.
This shall be input data the program may be presented, but that will not produce any
meaningful output.

The equivalence partitioning technique is a test case selection technique in which the test
designer examines the input space defined for the unit under test and seeks to find sets of input
that are, or should be, processed identically. The following table represents our equivalence
classes, both valid and invalid.
Input/Output Event Valid Equivalence Classes Invalid Equivalence Classes

Input maximum number 25 values > 25 values

of allowed values

Input integers Integers between –999 and 999 Integers > 999

Integers < -999

Non-integers (characters)

Non-integers (decimal values)

Load external file Comma delimited file with only No commas

one value per line

Multiple entries per line

No file content

File exists
File does not exist

Store external file File exists File does not exist

Boundary Value Testing

The acceptable range of values for this application was set by the development team. Due to the
limitations of the GUI, the developers also limited the size of the input values to three digit
integers. The valid and invalid ranges are shown below along with the corresponding valid and
invalid boundary test values.

Acceptable Range: -999  x  999

Invalid Range: - < x < -999 and 999 < x < + 

Valid Boundary Tests:

Boundary1: x = -999

Boundary2: x = 0

Boundary3: x = 999

Invalid Boundary Tests:

Boundary4: x = 1000

Boundary5: x = -1000

Boundary6: x = -999999

Boundary7: x = 999999

Integration Testing

Incremental Testing
There are two primary modules that will need to be integrated: the Graphic User Interface
module and the Tree Repository module (back-end). The two components, once integrated, will
form the complete Binary Search Tree Application. The following describes these modules as
well as the steps that will need to be taken to achieve complete integration. We will be
employing an incremental testing strategy to complete the integration.

Module 1 - Graphic User Interface (GUI) Module

This module provides a simple GUI where the user can perform the different actions (functions).
This module will be tested separate from the backend to check if each interface (e.g. insert
button) is functioning properly, and in general, to test if the mouse-event actions are working
properly. The testing will be performed by writing a stub for each element in the interface.

Module 2 – Tree Repository Backend Module

The “tree repository” provides the storage for the data elements and implements the algorithms
and associated functionality of the binary tree. This module will be tested separate from the GUI
by printing out the results to the Console. In testing this module we will follow the incremental
testing method i.e. testing one function first and then keep adding additional function and test it
again until all the required functions are tested.

When the GUI is combined with the backend module, we will have a complete binary search tree
application. To achieve complete integration of these two modules, we will test each element in
the GUI by replacing the stubs with the appropriate function from the back end. The results will
be displayed within the GUI instead of through the Console. In testing the combined modules,
we will follow the incremental testing method. Each stub will be replaced one at a time and
tested. This will be done until all stubs have been replaced by the appropriate functions from the
backend.

System Testing

The goals of system testing are to detect faults that can only be exposed by testing the entire
integrated system or some major part of it. Generally, system testing is mainly concerned with
areas such as performance, security, validation, load/stress, and configuration sensitivity. But in
our case well focus only on function validation and performance. And in both cases we will use
the black-box method of testing.

Function Validation Testing

The integrated “Binary Search Tree Application” will be tested based on the requirements to
ensure that we built the right application. In doing this test, we will try to find the errors in the
inputs and outputs, that is, we will test each function to ensure that it properly implements the
Binary Search Tree algorithms, and that the resulting tree displays the values in the proper
location graphically. The behavior of each function, as well as their respective algorithms, are
contained in the Software Program Specification.

Function Expected Behaviour

Load see Software Program Specification

Store see Software Program Specification

Insert see Software Program Specification

Delete see Software Program Specification

Search see Software Program Specification

Clear see Software Program Specification

List in Ascending Order see Software Program Specification

List in Descending Order see Software Program Specification

In addition, we will test:

 The interfaces to ensure they are functioning as desired (i.e. check if each interface is
behaving as expected, specifically verifying the appropriate action is associated with
each mouse_click event).
 The interaction between the GUI and the backend repository. In this case the data will be
inserted and check if they are processed in the backend and give the expected output.

Performance testing

This test will be conducted to evaluate the fulfillment of a system with specified performance
requirements. It will be done using black-box testing method. And this will be performed by:

 Storing the maximum data in the file and trying to insert, and observe how the application
will perform when it is out of boundary.
 Deleting data and check if it follows the right sorting algorithm to sort the resulting data
or output.
 Trying to store new data and check if it over writes the existing once.
 Trying to load the data while they are already loaded

Entry and Exit Criteria

This section describes the general criteria by which testing commences, temporarily stopped,
resumed and completed within each testing phase. Different features/components may have
slight variation of their criteria, in which case, those should be mentioned in the feature test plan.
The testing phase also maps to the impact level definition when a defect is entered in the bug-
tracking phase.
Unit Testing

Unit Testing is done at the source or code level for language-specific programming errors such
as bad syntax, logic errors, or to test particular functions or code modules. The unit test cases
shall be designed to test the validity of the programs correctness.

Black Box Phase

Black box testing typically involves running through every possible input to verify that it results
in the right outputs using the software as an end-user would. We will use Equivalence
Partitioning and Boundary Value Analysis complexity metrics in order to quantifiably determine
how many test cases needed to achieve maximum code coverage.

Black Box Entry Criteria

The Black Box Entry Criteria will rely on the component specification, and user interface
requirements. Things that must be done on entry to the Black Box stage:

 All Binary Tree functions, Load, Store, Clear, Sort Ascending, Sort Descending, Insert,
Delete, Search, must either be coded or stubs created.
 The type of Black Box testing Methods will be determined upon entry. We will use
Equivalency Partition, and Boundary Value Analysis.
 Equivalency Partition will include, Integer data types only, No Character data types
accepted, each data field will be comma delimited, and there will be 1 value per line in
the data file.
 Boundary Value Analysis will include, Integer data type values will have a boundary
value of (-999,999). Zero is included. The file size is limited to 25 entries.
Black Box Exit Criteria

The Black Box Exit Criteria listed below explains what needs to be completed in-order to exit
Black Box phase. To exit the Black Box phase 100% success rate must be achieved. Things that
must be done upon exiting the Black Box stage:

 The Equivalence Classes will have been created for the valid and invalid input values.
For our Binary Tree program the input domain values for Equivalence Partitions will
include Integer data types only, each data field will be delimited by a comma and carriage
return, and one data value per line in the input data file.
 The Equivalency Partition Method will have generated Test Cases based on the
Equivalence classes. The invalid input domain values for Equivalence classes will
include loading an empty input data file, inputting character strings, entering a delimiter
other that a comma, and entering more than one data value per line in the input data file.
 Boundary Value Analysis will have generated Test Cases based on the boundary values
of Integer data type values of (-999,999). These Test Cases will test for values above and
below the specified boundary values. For example, values that include infinity, negative
infinity, zero, and decimal numbers.
 Another set of Test Cases will have been created based on the boundary value of the file
size limited to 25 entries. These Test Cases will test for zero entries in the data input file,
and greater than 25 entries.
 All code bugs that are exposed are corrected.

White Box Phase

The White Box criteria apply for purposes of focusing on internal program structure, and
discover all internal program errors. Defects will be categorized and the quality of the product
will be assessed.
White Box Entry Criteria

The White Box Entry Criteria will rely on the QA engineers verifying that the major features
work alone but not necessarily in combination; exception handling will not be implemented. The
design and human interface are stable. Things that must be done on entry to the White Box stage:

 All Binary Tree functions, Load, Store, Clear, Sort Ascending, Sort Descending, Insert,
Delete, Search, must be coded.
 The type of White Box testing Methods will be determined upon entry. We will use Basis
Path Testing and Function Validation testing on all Binary Tree properties.
 Black Box Testing should be in its late stages.

After the White Box criteria have been met, the product enters the White Box stage. During
White Box stage Development Engineering’s emphasis is on refining the product and fixing
defects. Information Design’s emphasis is on developing product user documentation.

White Box Exit Criteria

The Binary Tree in the White Box stage should have a generally stable feel to it. White Box
testing continues until the Black Box or next milestone criteria are met. To exit the White Box
phase 100% success rate must be achieved. The following describes the state of the product
upon exit from the White Box Stage:

 All Binary Tree functions, Load, Store, Clear, Sort Ascending, Sort Descending, Insert,
Delete, and Search are implemented, operational and tested.
 All Branch Testing test cases will be generated. The test cases will be generated from the
Control Flow diagrams of all functions.
 The Binary Tree graphical interface has been reviewed and found to satisfactory by
development Engineers, and QA Engineers, and is stable, that is, no further changes to
dialog boxes or other interface elements are planned. Minor changes (word-smiting, etc.)
are acceptable, but must be arranged with the Development and Test Engineers.
  All code bugs that are exposed are corrected.

Integration Test

There are two modules that will be integrated for Integration Testing. The two modules are The
Graphic User Interface module and the Tree Repository module (back-end). The two
components will consist of a mixture of stubs, driver, and full function code. The following
describes the entry and exit criteria for Integration testing.

Integration Test Entry Criteria

The Integration Test Entry Criteria will rely on both modules to be operational. The Binary Tree
design and human interface must be stable. Things that must be done on entry to the Integration
Test stage:

 All Binary Tree functions, Load, Store, Clear, Sort Ascending, Sort Descending, Insert,
Delete, Search, must either be coded and/or stubs created.
 The Graphical User Interface must either be coded and/or a driver and stubs must be
created. The driver is implemented to facilitate test case input and output values.
 Interfaces and interactions between the Binary Tree Module and the Graphical User
Interface must be operational.
 A bottom-up Integration Test Strategy will be conducted. The low level details of the
Binary Tree and graphical interface will be integrated. A driver will be written to
facilitate test case input and output values. The driver will temporarily satisfy high-level
details of the input and output values.
 Black Box Testing should either be in its late stages or completed.
 White Box Testing should have begun.

Integration Test Exit Criteria

The Integration Test Exit Criteria will rely on both modules to be operational. The Binary Tree
design and human interface must be stable. To exit the Integration Testing phase 100% success
rate must be achieved. Things that must be done on exit from the Integration Test stage:
  All code bugs that are exposed are corrected.
 The Binary Tree Module and Graphical User Interface Module will interact together with
complete accuracy, according to the System Specification Design. All discrepancies are
corrected.
 Both Modules are ready for System Testing. Stubs and drivers are replaced with fully
functional code.
 Black Box Testing is completed.
 White Box Testing should either be in its late stages or completed.

System Test

The System Test criteria apply for purposes of categorizing defects and the assessing the quality
level of the product. All elements of the Binary Tree Module and Graphical User Interface are
meshed together and tested as a whole. System test focuses on functions and performance,
reliability, instillation, behavior during special conditions, and stress testing.

System Test Entry Criteria

The Entrance Criteria specified by the Development Engineers, should be fulfilled before System
Test can commence. In the event, that any criterion has not been achieved, the System Test may
commence if both Development and Test Engineers are in full agreement that the risk is
manageable.

 The Graphical User Interface and the Binary Tree back-end Module must be fully
functional.
 All developed code must be unit tested. Unit and Link Testing must be completed and
signed off by the development team.
 All test hardware and environments must be in place, and free for System test use.
 All Black Box testing must be complete and exposed bugs must be corrected.
 All White Box testing must be complete and exposed bugs must be corrected.
 Integration Testing must be complete and exposed bugs must be corrected
 Function Validation Testing is the accepted method of testing for all Binary Tree
functions: Load, Store, Clear, Sort Ascending, Sort Descending, Insert, Delete, and
Search. The Graphical User Interface will be the method of interacting with the system,
so the GUI will be tested thoroughly.
  Development and Test Engineers agree that Function Validation Testing will cover
function performance, reliability, stress and load testing.

System Exit Criteria

The Exit Criteria must satisfy all the criteria listed below. This verifies that all elements of the
project mesh properly. This is to make sure that all the system functions and performs according
to the System Specification Document.

 All Function Validation Testing is 100 percent successful. Testing for all Binary Tree
functions: Load, Store, Clear, Sort Ascending, Sort Descending, Insert, and Delete, and
Search interact with complete accuracy.
 No degradation of System performance across different platforms of Windows operating
system will be affected. (Windows 95 or above is acceptable)
 The Graphical User Interface performs to System Specification Requirements.
 All the Binary Tree properties are expressed correctly through the Graphical User
Interface.
 All input fields on the Graphical User Interface are working correctly.
 All high priority errors from System Testing must be fixed and tested.
 If any medium or low-priority errors are outstanding – the Development Engineers and
Test manager must sign off the implementation risk as acceptable.

Shipping or Live Release

The Binary Tree testing is scaled down and combines all phases of testing into two phases –
Function Complete and Regression testing – and follows the release criteria.

Shipping/Live Release Entry Criteria

The criteria for entering the final stages are as follows:

 QA verifies that all open product defects, regardless of fixed defects, documented,
deferred, or otherwise addressed.
  QA verifies that regression testing on all product defects and the entire product has been
completed.
 QA verifies that all bugs “For Verify” have been regressed.

The software is frozen when the product passes its final milestone. If any code changes are made
after the final milestone, the features fixed must be re-tested. QA, and Development Engineers
closely monitor fixes that go into the final build to minimize risk. After the final milestone
criteria have been met, the product enters the Live Release stage.

Shipping/Live Release exit Criteria

The Shipping/Live Release stage is when the product is ready for general availability to the
public and the user documentation is final. The product must fully satisfy its release
specifications and the user documentation must adequately describe the product’s functionality.
Both should be ready for use by the end user.

 QA tests the final product version to verify that the product to be released to the general
public is of the utmost quality and satisfies original design specifications.
 The product must receive approval from the product team.
 QA and Development must prepare Release Notes.

The product is now ready to ship or published to production environment.

Bug Tracking/ Bug Process

During testing, the testing team members normally encounter behavior that goes against a
specified or implied design requirement in the product. When this happens, we will document
and reproduce the bugs for the developers.

Expectation of a bug:
  Keep track of what version of the application the bug is found
 Determine if bug has already been written up
 Indicate the steps to reproduce the bug – write enough details for others looking at the
bug to be able to duplicate it; exclude unnecessary steps (i.e. If access point is irrelevant,
be more general in your steps).
 Actual results – be specific on your findings.
 Expected results – how the product should behave based on the specified or implied
requirements.
 Implications – How does the defect affect the quality of the product?

The following chart defines the impact levels to be used when entering bugs.

Impact Definitions

1 – Fatal Test Stopper: If you can’t access a function and need the bug to be fixed
immediately. The defect prevents QA from testing the feature area, sub-
area or functionality of the feature.

2 – Serious Beta Stopper: This is a bug that users would experience such as: data
corruption, calculation errors, incorrect data, UE’s and system crash on
common user scenarios, significant QA risk, and major UI defects.

3 – Minor Live Release: A bug that must be fixed before the product is officially
completed, UE’s or crashes, content, and UI and graphic changes required
for release.

Various Roles in Bug Resolution

 Author – The person who wrote the bug; this will be someone on the QA team
 Resolver – Normally an Engineer assigned to a specific area of the application.
 Verifier – normally a QA Engineer responsible for testing the fix and closing the bug.
Bug Report Form
Roles and Responsibilities

Development Team

Code Development Project Leader – Mr.Shailesh

 Ensure Phase 1 is delivered to schedule and quality

 Ensure exit criteria are achieved prior to system test signoff
 Regularly review testing progress with test controller.
 Raise and manage issues/risks relating to project or outside test teams control.
 Review and sign off test approach, plans and schedule.

SQA Project Leader – Mr.Sanjay

 Ensure Phase 1 is delivered to schedule and quality

 Regularly review testing progress
 Manage issues/risks relating to System Test Team
 Provide resources necessary for completing system test

Testing Team

Test Planner / Controller – Miss. Kanchan Tapkir

 Ensure Phase 1 is delivered to schedule and quality

 Produce high level and detailed test conditions
 Produce expected results
 Report progress at regular status reporting meetings
 Co-ordinate review and signoff of test conditions
 Manage individual test cycles and resolve tester queries/problems.

Lead Tester – Mr.Shashank

 Identify test data

 Execute test conditions and mark-off results
  Prepare software error reports
 Administrate error measurement system
 Ensure test systems outages/problems are reported immediately and followed up.
 Ensure entrance criteria are achieved prior to system test start.
 Ensure exit criteria are achieved prior to system test signoff.

Test Schedule

The section contains the overall project schedule. It discusses the phases and key milestones as
they relate to quality assurance. It discusses the testing goals and standards that we’d like to
achieve for each phase of testing that will be deployed, e.g., Usability Testing, Code Complete
Acceptance, Beta Testing, Integration Testing, Regression Testing, System Testing.

The key dates for overall Binary Tree development and Testing are outlined below. For details
on the schedule, refer to the Binary Tree Project Schedule (this document). For details on general
Engineering QA deliverables, refer to the test plan document.

Binary Tree
Program End Date
Milestones Notes QA Deliverables/Roles

Planning Phase 02/20/2019 At this Milestone, the high level High-level test planning activities,
planning should be completed. which include preliminary
Some of the deliverables are: development of Master QA Plan
Project Plan, Program function (this document, QA schedule.
specifications.

Design Phase 02/27/2019 This is a feature-driven milestone
where the requirements and
initiatives are further defined and
solutions are finalized. The
deliverables for this phase are
Program source code and other
design related documents.
Development and Test engineers
participate actively in feature
design by inspecting and
reviewing the requirements and
design documents. As the design
documents are completed, the test
engineers are encouraged to start
working on the Test Plan
document and test design
planning.

Code 03/06/2019 This milestone is when all The Test Engineers should have
Binary Tree
Program End Date
Milestones Notes QA Deliverables/Roles

Complete infrastructure development and completed or in the final stages of

functions should be complete. The their preliminary Infrastructure
-Infrastructure testing team should have Test Plan, test cases and other QA
preformed unit & integration documents related to test
testing before checking the code execution for each feature or
into any build. component such as test scenarios,
expected results, data sets, test
procedures, scripts and applicable
testing tools.

Code 03/10/2019 This milestone includes unit testing
Complete and code review of each function
component prior to checking the
-Function code into the test phase. The
deliverables include system-testing
specification, Unit testing
specifications, Integration plan.
The Test Engineers should have
provided Code Complete
Assessment Test to Development
Engineer one week prior to Code
Complete Review date. The Test
Engineers should also have
completed or in the final stages of
their preliminary White Box Test
Plan, test cases and other QA
documents related to test
execution for each feature or
component such as test scenarios,
expected results, data sets, test
procedures, scripts and applicable
testing tools.
Binary Tree
Program End Date
Milestones Notes QA Deliverables/Roles

Beta Ready 03/15/2019 This milestone represents that all 2 Weeks regression of Binary
features are ready for Beta release Tree features to Beta and
shutdown. preparation for Beta Shutdown.

Feature 03/15/2019 This phase allows for feature clean
Complete up to verify remaining bug fixes
and regression testing around the
bug fixes. This milestone indicates
that the feature is ready for Beta
regression.
All bugs verified and QA
documentation is finalized. The
test Engineers should assess that
Binary Tree features are ready for
Beta regression and have started
their preliminary Test Summary
Reports.

Regression 03/20/2019 This milestone represents that all Complete regression test
Test Binary Tree code and GUI execution of complete system and
interface to the Binary Tree is update Test Summary Reports for
ready for Regression Testing. regression.

Ship/Live 04/03/2019 Product is out. Any unfinished Testing

documents should be complete.

Deliverables

 Program function specifications

 Program source code

 Test plan document - this document should address testing objectives, criteria, standards,
schedule and assignments, and testing tools.
 Unit Testing Plan
 Integration Plan
 System Testing Plan

 Test Design Document

 Unit white-box test design – covers white testing criteria, methods and test cases
 Unit black-box test design – covers black-box testing criteria, methods and test cases
  System test design – covers system test criteria, methods, and test cases, scripts.

 Test report document

 Unit white-box test report – covers unit white box test results, problems, summary
and analysis
 Unit black-box test report – covers unit black box test results, problems, summary
and analysis
 System Test report – covers system test results, problems, summary and analysis
2.4 Review of Test Basis (prototype testing)

What is Test Basis in Software Testing?

Test Basis is defined as the source for creation of test Cases. It can be the Application itself or
the requirement documents like SRS (Software Requirement Specification), BRS (Business
Requirement Specification), etc.

This tutorial explains "Test-Basis". with the help of a case study

Consider a scenario, where the client sends a request to add a functionality to Flight Reservation
to allow sending an order via email.

He also specifies the GUI fields and buttons he wants.

Even though, the application is yet to be developed, try and develop a few test cases for this
requirement.

A few test cases among the many you could have thought of are listed below

 Check the response when valid Email ID is entered, and send is pressed
 Check the response when invalid Email ID are entered and send is pressed
 Check the response when Email ID is empty and send is pressed

You may have also realized that to create test cases you need to look at something to base your
test. This is nothing but Test Basis. This test basis could be the actual Application Under Test
(AUT), or maybe even by experience but most of the times, like, in this case, would be based on
documents.

In fact, this is what happens during the different phases of V- Model.

 .

Where test plans are created using the corresponding documents, and once the code is ready, it is
ready for testing.

What is Test Basis?

Test basis is defined as the source of information or the document that is needed to write test
cases and also for test analysis.

Test basis should be well defined and adequately structured so that one can easily identify test
conditions from which test cases can be derived.

Typical Test Basis:

 Requirement document
 Test Plan
 Codes Repository
 Business Requirement
What is Prototype Testing?

Prototype Testing is conducted with the intent of finding defects before the website goes live.
Online Prototype Testing allows seamlessly to collect quantitative, qualitative, and behavioural
data while evaluating the user experience.

Characteristics of Prototype Testing:

 To evaluate new designs prior to the actual go live to ensure that the designs are clear,
easy to use and meet users requirements.
 Is best when iterative testing is built into the development process, so that changes can be
easily made often to ensure that major issues do not arise well before going live.
 Provides confirmation about the new design direction, branding and messaging is going
in the right direction.
 CHAPTER 3 : TEST ANALYSIS &
DESIGN
3.1 Use Case Diagram of the System

1) Admin
2) Distributor
Retailer-
3.2 Module Hierarchy Diagram

Admin

Dealer
Retailer
3.3 Unit Test Plan
Unit Testing

UNIT TESTING is a level of software testing where individual units/ components of a software
are tested. The purpose is to validate that each unit of the software performs as designed. A unit
is the smallest testable part of any software. It usually has one or a few inputs and usually a
single output. In procedural programming, a unit may be an individual program, function,
procedure, etc. In object-oriented programming, the smallest unit is a method, which may belong
to a base/ super class, abstract class or derived/ child class. (Some treat a module of an
application as a unit. This is to be discouraged as there will probably be many individual units
within that module.) Unit testing frameworks, drivers, stubs, and mock/ fake objects are used to
assist in unit testing.

Definition by ISTQB

 Unit testing: See component testing.

 Component testing: The testing of individual software components.

Unit Testing Method

It is performed by using the White Box Testing method.

When is it performed?

Unit Testing is the first level of software testing and is performed prior to Integration Testing.

Who performs it?

It is normally performed by software developers themselves or their peers. In rare cases, it may
also be performed by independent software testers.
Unit Testing Tasks

 Unit Test Plan

o Prepare
o Review
o Rework
o Baseline
 Unit Test Cases/Scripts
o Prepare
o Review
o Rework
o Baseline
 Unit Test
o Perform

Unit Testing Benefits

 Unit testing increases confidence in changing/ maintaining code. If good unit tests are
written and if they are run every time any code is changed, we will be able to promptly
catch any defects introduced due to the change. Also, if codes are already made less
interdependent to make unit testing possible, the unintended impact of changes to any
code is less.
 Codes are more reusable. In order to make unit testing possible, codes need to be
modular. This means that codes are easier to reuse.
 Development is faster. How? If you do not have unit testing in place, you write your code
and perform that fuzzy ‘developer test’ (You set some breakpoints, fire up the GUI,
provide a few inputs that hopefully hit your code and hope that you are all set.) But,
if you have unit testing in place, you write the test, write the code and run the test.
Writing tests takes time but the time is compensated by the less amount of time it takes to
run the tests; You need not fire up the GUI and provide all those inputs. And, of course,
unit tests are more reliable than ‘developer tests’. Development is faster in the long run
too. How? The effort required to find and fix defects found during unit testing is very
less in comparison to the effort required to fix defects found during system testing or
acceptance testing.
 The cost of fixing a defect detected during unit testing is lesser in comparison to that of
defects detected at higher levels. Compare the cost (time, effort, destruction, humiliation)
of a defect detected during acceptance testing or when the software is live.
 Debugging is easy. When a test fails, only the latest changes need to be debugged. With
testing at higher levels, changes made over the span of several days/weeks/months need
to be scanned.
 Codes are more reliable. Why? I think there is no need to explain this to a sane person.
Unit Testing Tips

 Find a tool/framework for your language.

 Do not create test cases for everything. Instead, focus on the tests that impact the
behaviour of the system.
 Isolate the development environment from the test environment.
 Use test data that is close to that of production.
 Before fixing a defect, write a test that exposes the defect. Why? First, you will later be
able to catch the defect if you do not fix it properly. Second, your test suite is now more
comprehensive. Third, you will most probably be too lazy to write the test after you have
already fixed the defect.
 Write test cases that are independent of each other. For example, if a class depends on a
database, do not write a case that interacts with the database to test the class. Instead,
create an abstract interface around that database connection and implement that interface
with a mock object.
 Aim at covering all paths through the unit. Pay particular attention to loop conditions.
 Make sure you are using a version control system to keep track of your test scripts.
 In addition to writing cases to verify the behaviour, write cases to ensure the performance
of the code.
 Perform unit tests continuously and frequently.
 Unit Test Plan

Sr. Requirements Typical Components Detailed

Description

a) Test Strategy and

Approach

b) Test Scope
1) Introduction

c) Test Assumptions

a) Defects Discovered and

Corrected
Walkthrough
2)
(Static Testing) b) Improvement Ideas
 c) Structured
Programming
Compliance

d) Language Standards

e) Development
Documentation
Standards

a) Input Test Data

b) Initial Conditions
Test Cases
3) (Dynamic
Testing) c) Expected Results

d) Test Log Status

a) Test Strategy and

Approach

b) Platform

c) Libraries
Environment
4)
Requirements d) Tools

e) Test Procedures

f) Status Reporting
3.4 Test Harness

What is Test Harness?

Test harness enables the automation of tests. It refers to the system test drivers and other
supporting tools that requires to execute tests. It provides stubs and drivers which are small
programs that interact with the software under test.

Test harness execute tests, by using a test library and generates a report. It requires that your test
scripts are designed to handle different test scenarios and test data.

Why use Test Harness?

 Automate the testing process

 Execute test suites of test cases
 Generate associated test reports
 Support for debugging
 To record the test results for each one of the tests
 Helps the developers to measure code coverage at code level
 Increase the productivity of the system thorough automation
 Enhance the quality of software components and application
 To handle the complex condition that testers are finding difficult to simulate

There are two context where Test Harness is used

 1. Automation testing: It contains the test scripts, parameters necessary to run these scripts
and gather results to analyze it
2. Integration testing: It is used to put together two units of code or module that interact
with each other to check whether or not the combined behavior is as expected or not

3.5 Development of Test Scenario as per requirements

What is a Test Scenario?

A Test Scenario is any functionality that can be tested. It is also called Test Condition or Test
Possibility. As a tester, you may put yourself in the end user’s shoes and figure out the real-
world scenarios and use cases of the Application Under Test.

What is Scenario Testing?

Scenario Testing is a variant of Software Testing where Scenarios are Used for Testing.
Scenarios help in an Easier Way of Testing of the more complicated Systems

Why create Test Scenarios?

Test Scenarios are created for following reasons,

 Creating Test Scenarios ensures complete Test Coverage

 Test Scenarios can be approved by various stakeholders like Business Analyst,
Developers, Customers to ensure the Application Under Test is thoroughly tested. It
ensures that the software is working for the most common use cases.
 They serve as a quick tool to determine the testing work effort and accordingly create a
proposal for the client or organize the workforce.
 They help determine the most important end-to-end transactions or the real use of the
software applications.
 For studying the end-to-end functioning of the program, Test Scenario is critical.

When not create Test Scenario?

Test Scenarios may not be created when

 The Application Under Test is complicated, unstable and there is a time crunch in the
project.
  Projects that follow Agile Methodology like Scrum, Kanban may not create Test
Scenarios.
 Test Scenario may not be created for a new bug fix or Regression Testing. In such cases,
Test Scenarios must be already heavily documented in the previous test cycles. This is
especially true for Maintenance projects.

How to create a Test Scenario

As a tester, you can follow these five steps to create Test Scenarios-

 Step 1: Read the Requirement Documents like BRS, SRS, FRS, of the System Under
Test (SUT). You could also refer uses cases, books, manual, etc. of the application to be
tested.
 Step 2: For each requirement, figure out possible users actions and objectives. Determine
the technical aspects of the requirement. Ascertain possible scenarios of system abuse
and evaluate users with hacker's mindset.
 Step 3: After reading the Requirements Document and doing your due Analysis, list out
different test scenarios that verify each feature of the software.
 Step 4: Once you have listed all possible Test Scenarios, a Traceability Matrix is created
to verify that each & every requirement has a corresponding Test Scenario
 Step 5: The scenarios created are reviewed by your supervisor. Later, they are also
reviewed by other Stakeholders in the project.

3.6 Requirement Traceability Matrix (Horizontal traceability)

What is Traceability Matrix?(TM)

A Traceability Matrix is a document that co-relates any two-baseline documents that require a
many-to-many relationship to check the completeness of the relationship.

It is used to track the requirements and to check the current project requirements are met.

What is RTM (Requirement Traceability Matrix)?

Requirement Traceability Matrix or RTM captures all requirements proposed by the client or
software development team and their traceability in a single document delivered at the
conclusion of the life-cycle.
In other words, it is a document that maps and traces user requirement with test cases. The main
purpose of Requirement Traceability Matrix is to see that all test cases are covered so that no
functionality should miss while doing Software testing.

Requirement Traceability Matrix – Parameters include

 Requirement ID
 Risks
 Requirement Type and Description
 Trace to design specification
 Unit test cases
 Integration test cases
 System test cases
 User acceptance test cases
 Trace to test script

Types of Traceability Test Matrix

 Forward traceability: This matrix is used to check whether the project progresses in the
desired direction and for the right product. It makes sure that each requirement is applied
to the product and that each requirement is tested thoroughly. It maps requirements to test
cases.

 Backward or reverse traceability: It is used to ensure whether the current product

remains on the right track. The purpose behind this type of traceability is to verify that we
are not expanding the scope of the project by adding code, design elements, test or other
work that is not specified in the requirements. It maps test cases to requirements.

 Bi-directional traceability ( Forward+Backward): This traceability metrics ensures

that all requirements are covered by test cases. It analyzes the impact of a change in
requirements affected by the Defect in a work product and vice versa.

How to create Requirement Traceability Matrix

Let's understand the concept of Requirement Traceability Matrix through a Guru99 banking
project.
On the basis of Business Requirement Document (BRD) and Technical Requirement
Document (TRD), testers start writing test cases.

Let suppose, the following table is our Business Requirement Document or BRD for Guru99
banking project.

Here the scenario is that the customer should be able to login to Guru99 banking website with
the correct password and user#id while manager should be able to login to the website through
customer login page.

Note: QA teams do not document the BRD and TRD. Also some companies use Function
Requirement Documents (FRD) which are similar to Technical Requirement Document but the
process of creating Traceability Matrix remains the same.

Let's Go Ahead and create RTM Testing

Step 1: Our Test Case is

"Verify Login, when correct ID and Password is entered, it should login successfully"

Step 2: Identify the Technical Requirement that this test case is verifying. For our test case, the
technical requirement is T94 is being verified.

Step 3: Note this Technical Requirement in the Test Case.

Step 4: Identify the Business Requirement for which this TR (Technical Requirement-T94) is
defined

Step 5: Note the BR (Business Requirement) in Test Case

Step 6: Do above for all Test Cases. Later Extract the First 3 Columns from your Test Suite.
RTM in testing is Ready!

Advantage of Requirement Traceability Matrix

 It confirms 100% test coverage

 It highlights any requirements missing or document inconsistencies
 It shows the overall defects or execution status with a focus on business requirements
 It helps in analyzing or estimating the impact on the QA team's work with respect to
revisiting or re-working on the test cases
Test Case Test Case Input Expected Actual Test Technical
ID Procedure Data Output Output Status requirem
ent
BED- Checking the 1.Enter valid Login page Login page Pass TP1
LO-01 functionality of User name should be displayed
Login Button 2 .Enter valid displayed
Password
3. Click on
Login Button

3.7 Test Case Design

3.8 Test Data Generation

What is Test Data Generation? Why test data should be created before test execution?

Depending on your testing environment you may need to CREATE Test Data (Most of the
times) or atleast identify a suitable test data for your test cases (is the test data is already created).

Typically test data is created in-sync with the test case it is intended to be used for.

Test Data can be generated -

 Manually
 Mass copy of data from production to testing environment
 Mass copy of test data from legacy client systems
 Automated Test Data Generation Tools
1] Test case For Admin Login Page:
Project Name: Food CRM.
Prepared Date:-12-03-2019. Prepared By: Amit Dhende
Module Name: Login. Reviewed Date:-15-03-2019
Project Code: - FCRM. Reviewed By:- : Amit Dhende

Total no of test Cases:-04

Total no of test Cases Passed:-04
Total no of test Cases failed:-00
Total no of test Cases executed:-04
Total no of test Cases pending:-00

Test Test Case Input Expected Actual Test

Case Procedure Data Output Output Status
ID
FCRM- Checking the 1.Enter valid Admin Admin Pass
LG-01 functionality Usernames in Welcome Welcome
of Admin textbox page page
LOGIN 2. Enter valid should be displayed
Button Password in displayed
textbox
3. Click on
Admin
LOGIN
Button

FCRM Checking the 1.Enter Admin Admin Pass

-LG-02 functionality invalid User Welcome Welcome
of Admin Name in text page page is
LOGIN box should not not
Button 2. Enter valid be displayed
 Password in displayed
password
textbox
3. Click on
Admin
LOGIN
Button
FCRM Checking the 1.Enter valid Admin Admin Pass
-LG-03 functionality User name in Welcome Welcome
of Admin User name page page is
LOGIN textbox should not not
Button 2. Enter be displayed
invalid displayed
Password in
password
textbox
3. Click on
Admin
LOGIN
Button
FCRM - Checking the 1.Enter Admin Admin Pass
LG-04 functionality invalid User Welcome Welcome
of Admin name in User page page is
LOGIN name textbox should not not
Button 2. Enter be displayed
invalid displayed
Password in
password
textbox
3. Click on
Admin
 LOGIN
Button

2] Test case For Add Distributor Page:

Project Name: Food CRM.
Prepared Date:-12-03-2019. Prepared By:- : Amit Dhende
Module Name: Add Distributor. Reviewed Date:-15-03-2019
Project Code: - FCRM. Reviewed By:- : Amit Dhende

Total no of test Cases:-04

Total no of test Cases Passed:-04
Total no of test Cases failed:-00
Total no of test Cases executed:-04
Total no of test Cases pending:-00

Test Test Case Input Expected Actual Test

Case Procedure Data Output Output Status
ID
FCRM- Checking the 1.Enter valid Distributor Distributor Pass
AD-01 functionality First name, added added
of Add last name and Successful Successfully
Distributor the firm name ly should displayed
Button in textbox be
2. Enter valid displayed
Mobile no
and email id.
3.Select valid
State,
District,
Taluka, and
village
3. Click on
Add Button
FCRM Checking the 1.Enter Distributor Distributor Pass
-AD-02 functionality invalid First added not added
of Add name, last Successful Successfully
Distributor name and the ly should displayed
Button firm name in not be
textbox displayed
2. Enter valid
Mobile no
and email id.
3.Select valid
State,
District,
Taluka, and
village
3. Click on
Add Button
FCRM Checking the 1.Enter valid Distributor Distributor Pass
-AD-03 functionality First name, added not added
of Add last name and Successful Successfully
Distributor the firm name ly should displayed
Button in textbox not be
2. Enter displayed
invalid
Mobile no
and email id.
3.Select valid
State,
District,
Taluka, and
village
3. Click on
Add Button
FCRM - Checking the 1.Enter valid Distributor Distributor Pass
AD-04 functionality First name, added not added
of Add last name and Successful Successfully
Distributor the firm name ly should displayed
Button in textbox not be
2. Enter valid displayed
Mobile no
and email id.
3.Select
invalid State,
District,
Taluka, and
village
3. Click on
Add Button
3.9 Test Execution