Jewellery Management System

Dissertation submitted to
Shri Ramdeobaba College of Engineering & Management, Nagpur
in partial fulfillment of requirement for the award of
degree of

Bachelor of Engineering
In

ELECTRICAL ENGINEERING
By

Yugal Mehandole (91)

Guide

Prof. N.M. Deshkar

Shri Ramdeobaba College of

Engineering Management,
Nagpur440013
(An Autonomous Institute affiliated to Rashtrasant Tukdoji Maharaj Nagpur University
, Nagpur)

May -2021

Date: -12/05/2021
 Shri Ramdeobaba College of Engineering & Management, Nagpur
(An Autonomous Institute affiliated to Rashtrasant Tukdoji Maharaj Nagpur University
Nagpur)
Department of Electrical Engineering

CERTIFICATE
This is to certify that the Thesis on “Jewellery management System” is a
bonafide work of Mr. Yugal Mehandole (91) submitted to the Rashtrasant
Tukdoji Maharaj Nagpur University, Nagpur in partial fulfillment for the
award of Bachelor of Engineering, in Electrical Engineering, has been
carried out at Callisto IT Solutions during the academic year 2020-2021.

Date: 15/05/2021
Place: Nagpur

Prof. N.M. Deshkar Mrs. Neelima Shamkuwar

Project Guide Industry Mentor
Department of Electrical Engineering Business Analyst

Dr. V. T. Barhate Prof. Kaushik Roy

H.O.D In charge, CD and PC
Department of Electrical Engineering

Dr. R. S. Pande
Principal

ii
 DECLARATION

I, hereby declare that the thesis titled “Jewellery management System”

submitted herein has been carried out in the Callisto IT Solutions. The
work is original and has not been submitted earlier as a whole or a part for
the award of any degree/diploma at this or any other institution/university.

Date: 15/05/2021

Place: Nagpur

Yugal Mehandole
91
 Approval Sheet

This thesis/dissertation/report entitled “Jewellery Management System” by Yugal Mehandole is

approved for the degree of Bachelor of Engineering.

Name & signature of Supervisor(s) Name & signature of External.

Examiner(s) Prof. N.M DESHKAR

-

Name & signature RRC Members Name & signature of HOD

Prof. Shubhangi Neware Dr. Vinay Barhate

- -

- -

Date:12/05/2021

Place: Nagpur
 ACKNOWLEDGEMENTS

The written word has an unfortunate tendency to convert genuine appreciation

into an embossed formality. But this is solitary mode by which we can record our
approaches everlastingly. Numerous individuals have contributed their time and
energies in aiding us complete our disserting labor magnificently
.
We would like to express our sincere gratefulness to our guide Prof. N.M.
DESHKAR, Electrical Department, internship guide NEELIMA SHAMKUWAR
ma’am, Callisto IT Solutions, Nagpur whose uninterrupted supervision and stimulation
facilitated us to triumph grand altitudes. We extend our thanks to Dr. V.T. BARHATE,
Head, Electrical Engineering Department and Dr. R. S. PANDE, Principal, RCOEM,
for their constant support and help which encouraged us a lot in completing this project.

We would also like to express our sincere gratefulness thanks to AMBIKA

MISHRA ma’am, Human Resource manager and last but not the least we would like to
acknowledge our parents, friends, contemporaries and all those people known or
unknown individuals who have directly or indirectly helped us in carrying out our work
successfully.
 Abstract
Software testing is any activity aimed at evaluating an attribute or capability of a
program or system and determining that it meets its required results. Although crucial
to software quality and widely deployed by programmers and testers, software testing
still remains an art, due to limited understanding of the principles of software. The
difficulty in software testing stems from the complexity of software: we cannot
completely test a program with moderate complexity. Testing is more than just
debugging. The purpose of testing can be quality assurance, verification and validation,
or reliability estimation. Testing can be used as a generic metric as well. Correctness
testing and reliability testing are two major areas of testing. Software testing is a trade-
off between budget, time and quality.

TITLE OF INTERNSHIP: Software testing (manual and automation)

INTERNSHIP DETAILS:

- OBJECTIVE:

1) Learning different software testing tools like selenium webdriver, Jira, My

SQL.

2) Manual and automation testing on JMS and preparing test cases on it.

3) Learning and preparing execution report.

4) Learning and Preparing Bug reports

5) Learning Ad Hoc testing and performing it on Gtpl bank website.

METHODOLOGY AND OUTCOMES: Explained in objectives as given in the order

with all the objectives are achieved till now except automation part left. Software testing
is done manually and partly automotive on JMS. Test cases prepared on different test
scenarios.

Project Worked:

 Soochi Management System (Manual Testing)

 Automation testing on JMS

 Ad hoc testing on GTPL bank website

 Table of contents

Sr. No Contents Page No.

Cover Page i

Thesis certificate ii - v

Declaration vi

Approval sheet vii

Acknowledgement viii

Abstract ix

List of figure xi

List of table xii

1 INTRODUCTION 1-6

1.1 Company Profile 1

1.2 About the System under Test 2

1.3 Scope of Work 3

1.4 Operating Environment – Hardware and Software 6

2 TEST PLANNING 7-10

2.1 Objectives of Testing 7

2.2 Software Requirement Specification 8

2.3 Master Test Plan (IEEE format) 9

2.4 Review of Test Basis (prototype testing) 10

3 TEST ANALYSIS & DESIGN 11-21

3.1 Use Case Diagram of the System 11

3.2 Unit Test Plan 14

3.3 Test Harness 17

 3.4 Test Cases 18

3.5 Test summary 22

4. USER (TESTER) MANUAL 23-28

4.1 Test User specifications 23

4.2 Test Script 24

4.3 Requirement traceability Matrix 25

4.4 Bug Report 26

Drawbacks and limitations 29-30

Conclusion 31

List of Figures

Figure Figure Name Page No.

No.
3.1 11
Admin Use case diagram

3.2 Login use case 12

3.3 13
Purchase module use case diagram
3.4 Key reasons to perform unit testing 14

3.5 Test Harness 17

3.6 Login Page Test cases 18

3.7 Purchase page test cases 20

4.1 Test plan block diagram 24

4.2 Requirement Traceability matrix of Jewellery 25

Management system

4.3 Bug Report of Login Page 28

 List of Tables

Table No. Name of Table Page No.

Table 1.4.1 Hardware specification 6

Table 1.4.2 Hardware Specifications (Server Side) 6

Table 1.4.3 Software Specifications ( Client Side) 6

Table 3.1 Test Summary Report 22

ix
 CHAPTER 1

INTRODUCTION
1.1 Company Profile:

Callisto IT Solutions is a turnkey software and business solution

provider. Established in 2013 based in Nagpur of our clients across all over
India.
Callisto has experience in providing custom web solutions as Web
Application, Website Design & Development, Search Engine Ranking Services
and Content Management Solutions, e-Commerce Solutions, Website Analytics
and Web Services. Company believe to deliver secure, reliable and scalable
applications that help businesses excel in today's rapidly evolving economy

We bring up Our Work to the Developments and testing to steer

customers through the next generation of business innovation, specialized in the
Billing ERP Solutions in the Retail market industry providing business solutions
to the customer.

Callisto IT Solutions is an IT company with Creative team of professionals,

specializing in various aspects and areas of the IT industry.

Within the short span of time, we have achieved the creativity of Web-
Development and Digital Marketing and Software Testing, with the promise that
our client businesses flourish and create a great brand experience for their
customers.

Our team carries an expertise in latest tools and techniques that help
us to provide 100% satisfaction to our customers. Technology & research is
rapidly improvising, and so is the need to evolve and reinvent the knack of services.

Callisto IT Solutions, take pride in quality of services and over-the-top

excellence in performance. Our services and products includes Artificial Intelligence,
Digital Reach, Internet of Things, , our area of expertise expands over research products

1
and development. Our team of hard-working developers in the field tries to bring out the
best in the end results that better suits our client’s requests.

1.1.1 Mission

To provide quality & skill-based education at reasonable charges to the students

or working professional who wants to pursue a career in the field of information
technologies and to prepare them best suited to the demand of the IT industry.To help,
unlock the hidden potential of individuals by providing inspiration, confidence and clear
direction.

1.1.2 Vision

To be the world-class leader in the domain of technical education and training

systems catering to the changing needs of dynamic IT field while achieving the highest
level of quality, professional values, the satisfaction of all stakeholders, and
contributing to the technological, economic and social development of the country.

1.2 About the System under Test

1.2.1 Introduction:

Jewellery Management System is a web based application that helps to manage

business and Customer Information in a better way. It provides methods to back up
the database to current system which is very important for business transaction. It
provides Details of overall business transactions including information on
sells/purchase in and sells/purchase out.
It also provides cost cutting technique for business process to gain maximum
profit. It contains several modules like Sales, Purchase, Bills, Reports, and GST
Reports etc.
Generate barcode wise beautiful invoices with customer information and
images.
Manage inventory carat wise, weight wise, barcode wise, images wise, item wise,
item group wise, purity wise, stock summary, stock register, stock valuation. Extract
sales, purchase reports inventory & accounting reports and analyses age wise stock,
outstanding in days, outstanding interest, outstanding in weight reports.
1.3 Scope of Work

The scope of project is limited to the testing of the features described in succeeding
sections of this document. Various kind testing we can perform on project but there is
Scope that need to decide which testing comes under the scope that we have to perform
on project.

1.3.1 Functional and Nonfunctional Testing is in scope

List out the functionality in scope

 Verifying New reports using Database based on requirements

 Verifying Modified existing report based on business requirements

1.3.2 Testing Out of Scope

1. Print Bill component Functionality is out of scope
2. Automation Testing is out of Scope.

Testing work under the scope:

Functional Testing:

Functional Test Strategy

The goal of functional testing is to uncover defects to verify that the system
meets its specified business requirements (BRD attached with Team Track).

Functional testing is undertaken on the complete, integrated system to evaluate

the system’s compliance with its specified requirements. Functional test cases and test
data will be used for testing. Test cases should validate the functional requirements for
both positive and negative scenarios

Smoke testing: - New registration button is added in the login window and build is
deployed with the new code. We perform smoke testing on a new build.
  Test Conditions

Test conditions are developed to validate the functionality of the application

with respect to business requirements.

 Test Coverage
100% of functional requirements

100% of Business requirements

 Entry Criteria
QA deployment is completed successfully.

Unit testing has been completed successfully by the development team.

Connectivity to testing environment established.

Functional test cases are developed and reviewed.

 Exit Criteria
All planned test cases (covering both Positive and Negative scenarios) have been
executed successfully

Testing results reviewed and updated with pass or deferred results.

No high/medium priority open defects are present in the application.

Integration testing Approach

Integration testing is performed to expose faults in the interaction and in the

interfaces between integrated units. During this testing, all the units are put together and
an application or module is tested in totality. Integration testing is used to check if data
flows from one unit to another without breaking in between and seamlessly.
Regression testing Approach

Regression testing is done whenever there is any major business requirement change.

Testing work beyond the scope:

Non-Functional testing:
 Stress Testing
 Load Testing
 Performance Testing

Objective of Project

The activities performed for testing a project will be:

 List out high level test requirements

 Analyze the requirements
 Test Case preparation according to requirements
 Test data preparation (Existing production or data from test database will
be used as test data)
 Test Execution
 List the deliverable elements of requirement
 Defect reporting and management
 Retesting & Regression tests where applicable

1.4 Operating Environment

Test Environmental

Testing will be done on test database or production database available on

1.4.1 Software Requirements to test projects

The following tools will be used to support the test process specified in this plan.

Configuration Tools : SVN

Defect Reporting Tools : Jira
Programming Language : Core Java, Html,
Database : MySQL
Operating System : Windows 7, Windows 10.

1.4.2 Hardware Requirements

Hardware Specifications (Client

Side)

RAM Minimum 1GB and above

Hard Disk Minimum 2 GB and above
Table 1.1: Hardware specification
Hardware Specifications (Server Side)

RAM Minimum 4GB and above

Hard Disk Minimum 25 GB and above
Table 1.2: hardware Specifications (Server Side)

Software Specifications (Client Side)

Operating System Windows XP/Later

Internet Explorer-6/Later and any
Web Browser
web browser
Table 1.3: Software Specifications (Client Side)
 CHAPTER 2

TEST PLANNING
2.1 Objectives of
Testing

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

2.2 Software requirement specification

A software requirements specification (SRS) is a detailed description of a
software system to be developed with its functional and non-functional requirements.
The SRS is developed based the agreement between customer and contractors. It may
include the use cases of how user is going to interact with software system. The
software requirement specification document consistent of all necessary requirements
required for project development. To develop the software system, we should have clear
understanding of Software system. To achieve this, we need to continuous
communication with customers to gather all requirements.

A good SRS defines the how Software System will interact with all internal
modules, hardware, communication with other programs and human user interactions
with wide range of real life scenarios. Using the Software requirements
specification (SRS) document on QA lead, managers creates test plan. It is very
important that testers must be cleared with every detail specified in this document in
order to avoid faults in test cases and its expected results.

It is highly recommended to review or test Software Requirement Specification

documents before start writing test cases and making any plan for testing. Let’s see how
to test SRS and the important point to keep in mind while testing it.

1. Correctness of Software Requirement Specification should be checked. Since the

whole testing phase is dependent on SRS, it is very important to check its correctness.
There are some standards with which we can compare and verify.

2. Ambiguity should be avoided. Sometimes in SRS, some words have more than one
meaning and this might have confused testers making it difficult to get the exact
reference. It is advisable to check for such ambiguous words and make the meaning
clear for better understanding.

3. Requirements should be complete. When tester writes test cases, what exactly is
required from the application, is the first thing which needs to be clear. For e.g. if
application needs to send the specific data of some specific size then it should be clearly
mentioned in SRS that how much data and what is the size limit to send.

4. Consistent requirements. The SRS should be consistent within itself and consistent
to its reference documents. If you call an input “Start and Stop” in one place, don’t call
it “Start/Stop” in another. This sets the standard and should be followed throughout the
testing phase.

5. Verification of expected result: Software Requirement Specification should not

have statements like “Work as expected”, it should be clearly stated that what is
expected since different testers would have different thinking aspects and may draw
different results from this statement.

6. Testing environment: some applications need specific conditions to test and also a
particular environment for accurate result. SRS should have clear documentation on
what type of environment is needed to set up.
7. Pre-conditions defined clearly: one of the most important part of test cases is pre-
conditions. If they are not met properly then actual result will always be different
expected result. Verify that in SRS, all the pre-conditions are mentioned clearly.

8. Requirements ID: these are the base of test case template. Based on requirement Ids,
test case ids are written. Also, requirements ids make it easy to categorize modules so
just by looking at them, tester will know which module to refer. SRS must have them
such as id defines a particular module.

9. Security and Performance criteria: security is priority when a software is tested

especially when it is built in such a way that it contains some crucial information when
leaked can cause harm to business. Tester should check that all the security related
requirements are properly defined and are clear to him. Also, when we talk about
performance of a software, it plays a very important role in business so all the
requirements related to performance must be clear to the tester and he must also know
when and how much stress or load testing should be done to test the performance.

10. Assumption should be avoided: sometimes when requirement is not cleared to

tester, he tends to make some assumptions related to it, which is not a right way to do
testing as assumptions could go wrong and hence, test results may vary. It is better to
avoid assumptions and ask clients about all the “missing requirements” to have a better
understanding of expected results.

11. Deletion of irrelevant requirements: there are more than one team who work on
SRS so it might be possible that some irrelevant requirements are included in SRS.
Based on the understanding of the software, tester can find out which are these
requirements and remove them to avoid confusions and reduce work load.

12. Freeze requirements: when an ambiguous or incomplete requirement is sent to

client to analyze and tester gets a reply, that requirement result will be updated in the
next SRS version and client will freeze that requirement. Freezing here means that result
will not change again until and unless some major addition or modification is
introduced in the software.
2.3 Master Test Plan (IEEE format)

Test Plan Identifier:

Jewellery Management System

2.3.1 Definition:
“A Test Plan Is a Document Detailing the Objectives, Target Market, Internal Beta
Team, And Processes for A Specific Beta Test for A Software or Hardware Product.
The Plan Typically Contains a Detailed Understanding of the Eventual Workflow.”

The purpose of this document is to describe the plan for testing the main functionalities
of e-Learning hub. The document will also describe the activities related to testing the
website and the environment and tools that will be used to test the website.

2.4 Review of Test Basis (prototyping 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 behavioral data while evaluating the user
experience

• To evaluate new designs prior to the actual, go, live to ensure that the designs
are clear, easy to use and meet user’s 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
are going in the right direction.

CHAPTER 3

ANALYSIS AND DESIGN

3.1 Admin Use Case Diagram

Login

View
Dashboar
d

Generate
Purchase

Admin Generate
Sales Invoice

Manage Stock

Manage
Schemes

Maintain HRM

Maintain CRM

Manage Profile
settings 11
 Maintain Banking
Reconciliation

Fig. 3.1: Admin Use case diagram

If No Then
Login use case
Enter Email and Password

Login

Email
and
Passwo
rd
Validat
e

Login To The System

En
d

12
 Purchase use case diagram

Add Purchase Bills

View Purchase Bills

Old Gold Purchase Bills

View Old Purchase

Purchas
e
Module

GST Reports

All Purchase Reports

Fig. 3.3: Purchase module use case diagram

 3.2 Unit test plan

3.2.1 What is Unit Testing?

UNIT TESTING is a type of software testing where individual units or components of a

software are tested. The purpose is to validate that each unit of the software code
performs as expected. Unit Testing is done during the development (coding phase) of an
application by the developers. Unit Tests isolate a section of code and verify its
correctness. A unit may be an individual function, method, procedure, module, or
object.
In SDLC, STLC, V Model, Unit testing is first level of testing done before integration
testing. Unit testing is a White Box testing technique that is usually performed by the
developer. Though, in a practical world due to time crunch or reluctance of developers
to tests, QA engineers also do unit testing.

Here, are the key reasons to perform unit testing:

Fig 3.4 : Key reasons to perform unit testing

3.2.2 How to do Unit Testing

In order to do Unit Testing, developers write a section of code to test a specific

function in software application. Developers can also isolate this function to test more
rigorously which reveals unnecessary dependencies between function being tested and
other units so the dependencies can be eliminated. Developers generally
use Unit Test framework to develop automated test cases for unit testing.

Unit Testing is of two types

 Manual

 Automated

Unit testing is commonly automated but may still be performed manually. Software
Engineering does not favor one over the other but automation is preferred. A manual
approach to unit testing may employ a step-by-step instructional document.

Under the automated approach-

 A developer writes a section of code in the application just to test the function.
They would later comment out and finally remove the test code when the
application is deployed.

 A developer could also isolate the function to test it more rigorously. This is a
more thorough unit testing practice that involves copy and paste of code to its
own testing environment than its natural environment. Isolating the code helps
in revealing unnecessary dependencies between the code being tested and
other units or data spaces in the product. These dependencies can then be
eliminated.

 A coder generally uses a Unit Test Framework to develop automated test cases.
Using an automation framework, the developer codes criteria into the test to
verify the correctness of the code. During execution of the test cases, the
framework logs failing test cases. Many frameworks will also automatically flag
and report, in summary, these failed test cases. Depending on the severity of a
failure, the framework may halt subsequent testing.
  The workflow of Unit Testing is 1) Create Test Cases 2) Review/Rework
3) Baseline 4) Execute Test Cases

3.2.3Unit Testing Tools

There are several automated unit test software available to assist with unit testing. We
will provide a few examples below:

1. Junit: Junit is a free to use testing tool used for Java programming language. It
provides assertions to identify test method. This tool test data first and then
inserted in the piece of code.
2. NUnit: NUnit is widely used unit-testing framework use for all .net languages. It
is an open source tool which allows writing scripts manually. It supports data-
driven tests which can run in parallel.
3. JMockit: JMockit is open source Unit testing tool. It is a code coverage tool with
line and path metrics. It allows mocking API with recording and verification
syntax. This tool offers Line coverage, Path Coverage, and Data Coverage.
4. EMMA: EMMA is an open-source toolkit for analyzing and reporting code
written in Java language. Emma support coverage types like method, line, basic
block. It is Java-based so it is without external library dependencies and can access
the source code.
5. PHPUnit: PHP Unit is a unit testing tool for PHP programmer. It takes small
portions of code which is called units and test each of them separately. The tool
also allows developers to use pre-define assertion methods to assert that a system
behave in a certain manner.
3.3 Test Harness in Software Testing

Test Harness in Software Testing is a collection of stubs, drivers and other

supporting tools required to automate test execution. Test harness executes tests by
using a test library and generates test reports. Test harness contains all the information
needed to compile and run a test like test cases, target deployment port(TDP), source
file under test, stubs, etc.

Fig 3.5 : Test Harness

3.3.1 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 a code level

 Increase the productivity of the system through automation

 Enhance the quality of software components and application

 To handle the complex condition that testers are finding difficult to simulate
3.4 Test Cases:

• A test case describes an input, action, or event and an expected response,

• A test case can have information that includes as test case identifier, expected
results etc.
• A test case is a set of conditions or variables.
• The process of developing test cases can also help find problems in
the requirements or design of an application.
• In using test cases, the tester is trying to break the application.

3.4.1 Login Page

Fig 3.6 : Test cases of Login page of Jewellery Management system

3.4.2 Login Page

Fig 3.6(contd.)
3.4.3 Purchase Page

Fig 3.7 :Purchage page test cases

Purchase Page

Fig 3.7 ( contd.)

3.5 Test Summary Report

Functions %TC Executed %TC Passed Priority

Login 100% 100% High
Purchase 100% 100% High

Table3.1: Test Summary Report

 CHAPTER 4

USER (TESTER) MANUAL

4.1 Test user specification

4.1.1 Test Procedure Specifications:

The objective of compiling the test procedure specification is to specify the steps
for executing a test case and the process for determining whether the software passed or
failed the test.

The test procedure specification consists of following essential parts:

1)Test procedure specification identifier: A unique identifier is to be allocated so that

the test procedure specification document can be distinguished from all other
documents.

2) Objective: It describes the objective of the test procedure and its corresponding test
cases.

3) Special requirements: It describes a comprehensive list of all special

requirements for the execution of the particular test procedure.

4) Procedure steps: It describes a comprehensive list of all steps of the procedure.

Possible steps may consist of the following:

# Set up
# Start
# Proceed
# Measure
# Shut Down
# Restart
# Stop & finally
# Wind up
4.2 Test script

Fig 4.1: Test plan block diagram

A TEST SCRIPT is a set of instructions that is performed on a system under
test to verify that the system performs as expected. They can be written in either a
human language (used for manual testing) or a scripting / programming language
(used for automated testing). A test script is a part of a test case and a test case can
have either a single test script or multiple test scripts. Multiple test scripts are
associated with a single test case when:
o Each test script provides a different way to test the scenario in the test case. For
instance, a test case might require several scripts to test the scenario in different
test environments.
o Both manual and automated scripts exist to exercise the test case.

ISTQB Definition
Test script: A sequence of instructions for the execution of a test.
Some scripting languages used in automated testing are:
o JavaScript
o Perl
o Python
o Ruby
o Tcl
 There are also many Test Automation Tools/Frameworks that generate the test
scripts for you; without the need for actual coding. Many of these tools have their
own scripting languages (some of them based on a core scripting language).

4.3 Requirement Traceability Matrix: -

 A requirements traceability matrix is a document that traces and maps user
requirements, requirement Ids from requirement specification document] with the
test case ids.
 Matrix showing the relationship between the test requirement and the test cases.
 Traceability matrix is used by testing team to verify how far the test cases prepared
.
 It helps in creating a snap shot to identify coverage gaps.
 If a Test Case fails, traceability helps determine the corresponding functionality
easily
.
Fig 4.2 : Requirement Traceability matrix of Jewellery Management system
Fig 4.2 contd:
4.4 Bug report

4.4.1 What is a Defect or Bug?

 A software bug is an error, flaw, failure, or fault in a computer program or

system that causes it to produce an incorrect or unexpected result, or to behave
in unintended ways.
 A Software Defect / Bug is a condition in a software product which does not
meet a software requirement
 A defect is an error in coding or logic that causes a program to malfunction or to
produce incorrect/unexpected results.
 While testing when a tester executes the test cases he might observe that the
actual test results do not match from the expected results. The variation in the
expected and actual results is known as defects

4.4.2 Why there are bug/defect in software?

There are many reasons for which a software contains bugs

 Miscommunication or no communication

 Software complexity

 Changing requirements

 Programming errors

 Poorly documented code –

 Time pressures

 Lack of skilled Testers

 Software development tools

 Obsolete automation scripts

 Not Proper test environment

 Code or writing the test cases without understanding the requirement

 Releasing software patches frequently without completing the software

testing life cycle.

 Giving very less or no time for regression testing

4.4.3 Bug Report in JMS

Fig 4.3: Bug Report of Login Page

Drawbacks and Limitations:

1. We use testing to disclose many hidden errors but this methodology never
guarantees the absence of errors. It is only used to identify the known errors. It
never gives any information about those defects which remain uncovered.
2. Testing do not provide you any help when you have to make a decision either
“you should release the product consisting errors for meeting the deadline” or
“you should release late by compromising the deadline”.
3. Software testing does not predict or estimate the proper functioning of the
product under different conditions, but it may prove to be helpful in delivering
the information w.r.t. Incorrect or improper functioning of the product.
4. While injecting the defects, software testing unable to find the root causes which
may help in placing defects at the first place. Identifying the root causes of
defects/errors helps in injection of defects for future purposes.
5. Testing cannot be done against system requirements. We also cannot detect any
errors in requirements or ambiguous requirement leads the complete testing
process to inadequate testing.
6. When it comes to major constraints like Time & Budget, it requires attentive
planning of test effort. Mostly, we compromise in between thoroughness and
budget at the time of testing.
Manual Testing Limitations: GUI object size difference and color combination are the
two essential measures which are very difficult to find by using manual testing. Manual
testing process is not suitable for large scale projects and limited time projects.
Comparing huge amount of data will be unrealistic in terms of manual testing.
1. It requires more time and resources to accomplish quality goal. Many times, it
requires both.
2. When it comes to performance testing, it seems to be very impractical in
terms of manual testing.
3. With manual testing, it possesses least accuracy.
4. Executing recursive tests again and again take too much amount of time which
lead to project delay and incomplete testing.
5. GUI object size difference and color combination are the two essential
measures which are very difficult to find by using manual testing.
 6. Manual testing process is not suitable for large scale projects and limited time
projects.
7. Comparing huge amount of data will be unrealistic in terms of manual testing.
8. At the time of software maintenance, processing of change requests takes
huge amount of time.

Testing Tools Limitations:

1. Unrealistic expectation from tools.

2. Many times, testers make mistakes by underestimating factors like time,
cost, and effort for initial introduction of tool.
3. Testers repeated the miscalculation of time and effort required to achieve
prominent amount of benefit from tool.
4. Testers underestimate the effort required to maintain the test assets which are
generated by tool.
5. Testing teams are too much dependent on tools.
Conclusion:

Following are the tangible benefits of the system:

 Admin can access monthly report online.

 Monthly purchase, sales report date wise

 Payment mode, details of customer can easily be fetch

 Bill get generated online including GST.

 Ease of doing business

 Secure data
 Bibliography

Web References:

 www.Javascripttutorial.com
 www.w3schools.com
 https://www.professionalqa.com/software-testing-limitations
 https://bugherd.com/blog/bug-reporting/
 https://en.wikipedia.org/wiki/Software_requirements_specification
Internship Completion Certificate from Industry
 CANDIDATE DETAILS

NAME: Yugal Mehandole Roll No: 91

Mobile No:9028587174

Email ID : RKNEC ID: