SUMMER TRAINING REPORT

Carried out with

Submitted by

ABHISHEK BANSAL
(68196302817)
In partial fulfillment for the award of degree
of

BACHELOR OF TECHNOLOGY
in
ELECTRONICS AND COMMUNICATION ENGINEERING

Maharaja Surajmal Institute of Technology

C-4 Janak Puri, New Delhi-110058
Affiliated to GGSIPU | NAAC Accredited 'A' Grade | ISO 9001:2015 Certified
Approved by AICTE
 CONTENTS

Certificate …………………………………………………………………………………. i
List of Figures ……………………………………………………………………………. ii
Acknowledgement ……………………………………………………………………….. iii
Company Profile ………………………………………………………………………… iv
Abstract ....………………………………………………………………………………… v
Chapters
1 Software Testing
1.1 Introduction …………………………………………...…………………… 1
1.2 Tester ……………………………………………………………………… 1
1.3 Myths …………………………………………...…………………………. 3

2 Testing Activities
2.1 QA, QC and Testing ……………………………………………………….. 4
2.2 Audit and Inspection ………………………………………………………. 5
2.3 Testing and Debugging ……………………………………………………. 5

3 Testing Process
3.1 Manual Testing ……….………………………….………………………... 6
3.2 Automation Testing ………………………………….…………………….. 6
3.3 Automation Process ……………………………………………………….. 7
3.4 Tools ………………………………………………………………………. 7

4 Testing Methods
4.1 Black-Box Testing ………………………………………………………... 8
4.2 White-Box Testing ………………………………….……………………... 9
4.3 Grey-Box Testing ………………………………………….….………….. 10

5 Testing Levels
5.1 Functional Testing ……………………………………....………………... 11
5.2 Non-Functional Testing ………………………….………………………. 13

6 Testing Documentation
6.1 Test Plan ………………………………………………………………….. 16
6.2 Test Scenario ………………………………….………………………….. 17
6.3 Test Case ………………………………………….….…………………... 17

Project …………………………………………………………………………………… 18
Conclusion ………………………………………………………………………………. 27
References ……………………………………………………………………………….. 28
 LIST OF FIGURES

Fig 1.1 Software Testing

Fig 1.2 Software Tester

Fig 2.1 Testing Assurance

Fig 3.1 Automation Testing

Fig 4.1 Black Box Testing

Fig 4.2 White Box Testing

Fig 4.3 Grey Box Testing

Fig 5.1 Functional Testing

Fig 5.2 Non-functional Testing

Fig 6.1 Test Documentation

Fig P.1 OrangeHRM

Fig P.2 Login Panel

Fig P.3 My Info Module

Fig P.4 Test Cases

Fig P.5 Test Scenarios

Fig P.6 Test Execution

ii
 ACKNOWLEDGEMENT

The success and outcome of learning Software Testing required a lot of guidance and
assistance from many people and I am privileged to have most of along the completion of
my course and the project. All that I have done is only due to such supervision and assistance
and I would not forget to thank my instructor Gagan Goswami.

I respect and thank LearnVern for providing me an opportunity to do the course and project
work and giving me all support and guidance, which made me, complete the course duly. I
am thankful for and fortunate enough to get constant encouragement, support, and guidance
from LearnVern Team that helped us in successfully completing my course and project work.

I hereby perceive this opportunity as a big milestone in my career development. I will use
gained skills and knowledge in the best possible way and continue to work on their
improvement.

ABHISHEK BANSAL
68196302817

iii
 COMPANY PROFILE

INTRODUCTION

LearnVern is a training portal where anyone can learn any course in vernacular languages.
It is franchisee of TOPS Technologies which is the Best IT Training, Outsourcing and
Placement Company with Offices across Gujarat and having trained over 100,000 students
across India. Each of the subjects we teach at LearnVern are offered in native languages,
have perfect examples and lots of practical insights and are taught by experts in their fields.

Started with a vision of bridging the gap between skills required and talent created by
colleges. Today TOPS Technologies is one of the largest IT Training and Finishing Schools
with expertise in ASP.Net, PHP, Java, iPhone, Android, Software Testing, SEO, Web
Design.

COURSE

Software Testing is an integral part of Software development process due to the need of
delivering a defect-free software product. The video tutorials of this course will cover
Manual Software Testing with definitions, types, concepts and tools. After successful
completion of the course, you would be able to unleash your potentials in testing various
web applications.

TOOLS

 Orange HRM v3.0

 Microsoft Office Suite

iv
 ABSTRACT

Software Testing is an indispensable activity involved in the software development process.

The requirement of qualified software testers has always been on rising as quality plays a
crucial role in software development. Software testing is the process of verifying a system
with the purpose of identifying any errors, gaps or missing requirement versus the actual
requirement. Software testing is broadly categorised into two types - functional testing and
non-functional testing.

In the IT industry, large companies have a team with responsibilities to evaluate the
developed software in context of the given requirements. Different companies have different
designations for people who test the software based on their experience and knowledge such
as Software Tester, Software Quality Assurance Engineer, QA Analyst, etc.

v
 Chapter 1

SOFTWARE TESTING

1.1 INTRODUCTION

Testing is the process of evaluating a system or its component(s) with the intent to find
whether it satisfies the specified requirements or not. In simple words, testing is executing a
system in order to identify any gaps, errors, or missing requirements in contrary to the actual
requirements.

According to ANSI/IEEE 1059 standard, Testing can be defined as - A process of analyzing

a software item to detect the differences between existing and required conditions (that is
defects/errors/bugs) and to evaluate the features of the software item.

Fig 1.1 Software Testing

1.2 TESTER

In the IT industry, large companies have a team with responsibilities to evaluate the
developed software in context of the given requirements. Moreover, developers also conduct
testing which is called Unit Testing.

1
In most cases, the following professionals are involved in testing a system within their
respective capacities -

 Software Tester

 Software Developer

 Project Lead/Manager

 End User

Different companies have different designations for people who test the software based on
their experience and knowledge such as Software Tester, Software Quality Assurance
Engineer, QA Analyst, etc.

It is not possible to test the software at any time during its cycle. The next two sections state
when testing should be started and when to end it during the SDLC.

Fig 1.2 Software Tester

An early start to testing reduces the cost and time to rework and produce error-free software
that is delivered to the client. However, in Software Development Life Cycle (SDLC),
testing can be started from the Requirements Gathering phase and continued till the
deployment of the software.

2
1.3 MYTHS

There are many myths among people related to software testing.

TOO EXPENSIVE

There is a saying, pay less for testing during software development or pay more for
maintenance or correction later. Early testing saves both time and cost in many aspects,
however reducing the cost without testing may result in improper design of a software
application rendering the product useless.

TIME CONSUMING

During the SDLC phases, testing is never a time-consuming process. However, diagnosing
and fixing the errors identified during proper testing is a time-consuming but productive
activity.

COMPLETE TESTING IS POSSIBLE

It becomes an issue when a client or tester thinks that complete testing is possible. It is
possible that the team has tested all paths but occurrence of complete testing is never
possible. There might be some scenarios that are never executed by the test team or the client
during the software development life cycle and may be executed once the project has been
deployed.

TESTER'S ONLY TASK IS TO FIND BUGS

Reality − Finding bugs in a software is the task of the testers, but at the same time, they are
domain experts of the particular software. Developers are only responsible for the specific
component or area that is assigned to them but testers understand the overall workings of the
software, what the dependencies are, and the impacts of one module on another module.

3
 Chapter 2

TESTING ACTIVITIES

2.1 QA, QC & TESTING

Most people get confused when it comes to pin down the differences among Quality
Assurance, Quality Control, and Testing. Although they are interrelated and to some extent,
they can be considered as same activities, but there exist distinguishing points that set them
apart. The following table lists the points that differentiate QA, QC, and Testing.

Fig 2.1 Testing Assurance

QUALITY ASSURANCE
QA includes activities that ensure the implementation of processes, procedures and standards
in context to verification of developed software and intended requirements. It focuses on
processes and procedures rather than conducting actual testing on the system.

QUALITY CONTROL
It includes activities that ensure the verification of a developed software with respect to
documented (or not in some cases) requirements. It focuses on actual testing by executing
the software with an aim to identify bug/defect through implementation of procedures and
process. It can be considered as the subset of Quality Assurance.

TESTING
It includes activities that ensure the identification of bugs/error/defects in a software. It
focuses on actual testing. It is a preventive process. Testing is the subset of Quality Control.

4
2.2 AUDIT AND INSPECTION

AUDIT
It is a systematic process to determine how the actual testing process is conducted within an
organization or a team. Generally, it is an independent examination of processes involved
during the testing of a software. As per IEEE, it is a review of documented processes that
organizations implement and follow. Types of audit include Legal Compliance Audit,
Internal Audit, and System Audit.

INSPECTION
A formal technique involves formal or informal technical reviews of any artifact by
identifying any error or gap. As per IEEE94, inspection is a formal evaluation technique in
which software a person or a group other than the author to detect faults, violations of
development standards, and other problems examines requirements, designs, or codes in
detail.

Formal inspection meetings may include the following processes: Planning, Overview
Preparation, Inspection Meeting, Rework, and Follow-up.

2.3 TESTING AND DEBUGGING

TESTING
It involves identifying bug/error/defect in a software without correcting it. Normally
professionals with a quality assurance background are involved in bugs identification.
Testing is performed in the testing phase.

DEBUGGING
It involves identifying, isolating, and fixing the problems/bugs. Developers who code the
software conduct debugging upon encountering an error in the code. Debugging is a part of
White Box Testing or Unit Testing. Debugging can be performed in the development phase
while conducting Unit Testing or in phases while fixing the reported bugs.

5
 Chapter 3
TESTING PROCESS

3.1 MANUAL TESTING

Manual testing includes testing a software manually, i.e., without using any automated tool
or any script. In this type, the tester takes over the role of an end-user and tests the software
to identify any unexpected behavior or bug. There are different stages for manual testing
such as unit testing, integration testing, system testing, and user acceptance testing.

Testers use test plans, test cases, or test scenarios to test a software to ensure the
completeness of testing. Manual testing also includes exploratory testing, as testers explore
the software to identify errors in it.

3.2 AUTOMATION TESTING

Automation testing, which is also known as Test Automation, is when the tester writes
scripts and uses another software to test the product. This process involves automation of a
manual process. Automation Testing is used to re-run the test scenarios that were performed
manually, quickly, and repeatedly.

Fig 3.1 Automation Testing

6
It is not possible to automate everything in a software. The areas at which a user can make
transactions such as the login form or registration forms, any area where large number of
users can access the software simultaneously should be automated.

3.3 AUTOMATION PROCESS

Automation is done by using a supportive computer language like VB scripting and an

automated software application. There are many tools available that can be used to write
automation scripts. Before mentioning the tools, let us identify the process that can be used
to automate the testing process -

 Identifying areas within a software for automation

 Selection of appropriate tool for test automation
 Writing test scripts
 Development of test suits
 Execution of scripts
 Create result reports
 Identify any potential bug or performance issues

3.4 TOOLS

The following tools can be used for automation testing -

 HP Quick Test Professional

 Selenium
 IBM Rational Functional Tester
 SilkTest
 TestComplete
 Testing Anywhere
 WinRunner
 LoadRunner
 Visual Studio Test Professional
 WATIR

7
 Chapter 4
TESTING METHODS

4.1 BLACK-BOX TESTING

The technique of testing without having any knowledge of the interior workings of the
application is called black-box testing. The tester is oblivious to the system architecture and
does not have access to the source code. Typically, while performing a black-box test, a
tester will interact with the system's user interface by providing inputs and examining outputs
without knowing how and where the inputs are worked upon.

Fig 4.1 Black Box Testing

ADVANTAGES
1. Well suited and efficient for large code segments.
2. Code access is not required.
3. Clearly separates user's perspective from the developer's perspective through visibly
defined roles.
4. Large numbers of moderately skilled testers can test the application with no knowledge
of implementation, programming language, or operating systems.

DISADVANTAGES
1. Limited coverage, since only a selected number of test scenarios is actually performed.
2. Inefficient testing, due to the fact that the tester only has limited knowledge about an
application.
3. Blind coverage, since the tester cannot target specific code segments or error prone areas.
4. The test cases are difficult to design.

8
4.2 WHITE-BOX TESTING

White-box testing is the detailed investigation of internal logic and structure of the code.
White-box testing is also called glass testing or open-box testing. In order to perform this
testing on an application, a tester needs to know the internal workings of the code. The tester
needs to have a look inside the source code and find out which unit/chunk of the code is
behaving inappropriately.

Fig 4.2 White Box Testing

ADVANTAGES
1. As the tester has knowledge of the source code, it becomes very easy to find out which
type of data can help in testing the application effectively.
2. It helps in optimizing the code.
3. Extra lines of code can be removed which can bring in hidden defects.
4. Due to the tester's knowledge about the code, maximum coverage is attained during test
scenario writing.

DISADVANTAGES
1. Due to the fact that a skilled tester is needed to perform white-box testing, the costs are
increased.
2. Sometimes it is impossible to look into every nook and corner to find out hidden errors
that may create problems, as many paths will go untested.
3. It is difficult to maintain white-box testing, as it requires specialized tools like code
analysers and debugging tools.

9
4.3 GREY-BOX TESTING

Grey-box testing is a technique to test the application with having a limited knowledge of
the internal workings of an application. In software testing, the phrase the more you know,
the better carries a lot of weight while testing an application.

Fig 4.3 Grey Box Testing

Mastering the domain of a system always gives the tester an edge over someone with limited
domain knowledge. Unlike black-box testing, where the tester only tests the application's
user interface; in grey-box testing, the tester has access to design documents and the
database. Having this knowledge, a tester can prepare better test data and test scenarios while
making a test plan.

ADVANTAGES
1. Offers combined benefits of black-box and white-box testing wherever possible.
2. Grey box testers don't rely on the source code; instead they rely on interface definition
and functional specifications.
3. Based on the limited information available, a grey-box tester can design excellent test
scenarios especially around communication protocols and data type handling.
4. The test is done from the point of view of the user and not the designer.

DISADVANTAGES
1. Since the access to source code is not available, the ability to go over the code and test
coverage is limited.
2. The tests can be redundant if the software designer has already run a test case.
3. Testing every possible input stream is unrealistic because it would take an unreasonable
amount of time; therefore, many program paths will go untested.

10
 Chapter 5
TESTING LEVELS

5.1 FUNCTIONAL TESTING

This is a type of black-box testing that is based on the specifications of the software that is
to be tested. The application is tested by providing input and then the results are examined
that need to conform to the functionality it was intended for. Functional testing of a software
is conducted on a complete, integrated system to evaluate the system's compliance with its
specified requirements.

Fig 5.1 Functional Testing

An effective testing practice will see the above steps applied to the testing policies of every
organization and hence it will make sure that the organization maintains the strictest of
standards when it comes to software quality.

UNIT TESTING
This type of testing is performed by developers before the setup is handed over to the testing
team to formally execute the test cases. Unit testing is performed by the respective
developers on the individual units of source code assigned areas. The goal of unit testing is
to isolate each part of the program and show that individual parts are correct in terms of
requirements and functionality.

11
INTEGRATION TESTING
Integration testing is defined as the testing of combined parts of an application to determine
if they function correctly. Integration testing can be done in two ways: Bottom-up integration
testing and Top-down integration testing. Bottom-up Integration testing begins with unit
testing, followed by tests of progressively higher-level combinations of units called modules
or builds. In Top-down Integration testing, the highest-level modules are tested first and
progressively, lower-level modules are tested thereafter.

SYSTEM TESTING
System testing tests the system as a whole. Once all the components are integrated, the
application as a whole is tested rigorously to see that it meets the specified Quality Standards.
It is the first step in the Software Development Life Cycle, where the application is tested as
a whole. The application is tested thoroughly to verify that it meets the functional and
technical specifications. The application is tested in an environment that is very close to the
production environment where the application will be deployed.

REGRESSION TESTING
Whenever a change in a software application is made, it is quite possible that other areas
within the application have been affected by this change. Regression testing is performed to
verify that a fixed bug hasn't resulted in another functionality or business rule violation. The
intent of regression testing is to ensure that a change, such as a bug fix should not result in
another fault being uncovered in the application.

ACCEPTANCE TESTING
This is arguably the most important type of testing, as it is conducted by the Quality
Assurance Team who will gauge whether the application meets the intended specifications
and satisfies the client’s requirement. The QA team will have a set of pre-written scenarios
and test cases that will be used to test the application. By performing acceptance tests on an
application, the testing team will reduce how the application will perform in production.
There are also legal and contractual requirements for acceptance of the system.

12
5.2 NON- FUNCTIONAL TESTING

This section is based upon testing an application from its non-functional attributes. Non-
functional testing involves testing a software from the requirements which are non-
functional in nature but important such as performance, security, user interface, etc.

Fig 5.2 Non-functional Testing

PERFORMANCE TESTING
It is mostly used to identify any bottlenecks or performance issues rather than finding bugs
in a software. There are different causes that contribute in lowering the performance of a
software -
 Network delay
 Client-side processing
 Database transaction processing
 Load balancing between servers
 Data rendering

Performance testing is considered as one of the important and mandatory testing type in
terms of the following aspects -

 Speed
 Capacity
 Stability

13
USABILITY TESTING
Usability testing is a black-box technique and is used to identify any error(s) and
improvements in the software by observing the users through their usage and operation.
According to Nielsen, usability can be defined in terms of five factors, i.e. efficiency of use,
learn-ability, memory-ability, errors/safety, and satisfaction. According to him, the usability
of a product will be good and the system is usable if it possesses the above factors.

SECURITY TESTING
Security testing involves testing a software in order to identify any flaws and gaps from
security and vulnerability point of view. Listed below are the main aspects that security
testing should ensure -

 Confidentiality
 Integrity
 Authentication
 Availability
 Authorization
 Non-repudiation
 Software is secure against known and unknown vulnerabilities
 Software data is secure
 Software is according to all security regulations
 Input checking and validation
 SQL insertion attacks
 Injection flaws
 Session management issues
 Cross-site scripting attacks
 Buffer overflows vulnerabilities
 Directory traversal attacks

14
PORTABILITY TESTING
This Portability testing includes testing a software with the aim to ensure its reusability and
that it can be moved from another software as well. Following are the strategies that can be
used for portability testing -

 Transferring an installed software from one computer to another.

 Building executable (.exe) to run the software on different platforms.

Portability testing can be considered as one of the sub-parts of system testing, as this testing
type includes overall testing of a software with respect to its usage over different
environments. Computer hardware, operating systems, and browsers are the major focus of
portability testing. Some of the pre-conditions for portability testing are as follows -

 Unit testing has been performed on the associated components.

 Integration testing has been performed.
 Test environment has been established.
 Software should be designed and coded, keeping in mind the portability
requirements.

15
 Chapter 6
TESTING DOCUMENTATION

6.1 TEST PLAN

A test plan outlines the strategy that will be used to test an application, the resources that
will be used, the test environment in which testing will be performed, and the limitations of
the testing and the schedule of testing activities. Typically the Quality Assurance Team Lead
will be responsible for writing a Test Plan.

Fig 6.1 Test Documentation

A test plan includes the following -

1. Introduction to the Test Plan document
2. Assumptions while testing the application
3. List of test cases included in testing the application
4. List of features to be tested
5. What sort of approach to use while testing the software
6. List of deliverables that need to be tested
7. The resources allocated for testing the application
8. Any risks involved during the testing process
9. A schedule of tasks and milestones to be achieved

16
6.2 TEST SCENARIO

It is a one line statement that notifies what area in the application will be tested. Test
scenarios are used to ensure that all process flows are tested from end to end. A particular
area of an application can have as little as one test scenario to a few hundred scenarios
depending on the magnitude and complexity of the application.

The terms 'test scenario' and 'test cases' are used interchangeably, however a test scenario
has several steps, whereas a test case has a single step. Viewed from this perspective, test
scenarios are test cases, but they include several test cases and the sequence that they should
be executed. Apart from this, each test is dependent on the output from the previous test.

6.3 TEST CASE

Test cases involve a set of steps, conditions, and inputs that can be used while performing
testing tasks. The main intent of this activity is to ensure whether a software passes or fails
in terms of its functionality and other aspects. There are many types of test cases such as
functional, negative, error, logical test cases, physical test cases, UI test cases, etc.

Furthermore, test cases are written to keep track of the testing coverage of a software.
Generally, there are no formal templates that can be used during test case writing. However,
the following components are always available and included in every test case -
1. Test case ID
2. Product module
3. Product version
4. Revision history
5. Purpose
6. Assumptions
7. Pre-conditions
8. Steps
9. Expected outcome
10. Actual outcome
11. Post-conditions

17
 PROJECT
“MANUAL TESTING OF ORANGE HRMS”

INTRODUCTION
Orange HRM is an open source HR software providing employees of the company with the
ability to view relevant information such as personal information and updating personal
information with an internet enabled PC without having to involve the HR department.

Fig P.1 OrangeHRM

In this project the complete Orange HRM Software is tested for any type of defects, errors,
bugs or missing requirements as it is essential since it makes sure that the customer finds the
organization reliable and their satisfaction in the application is maintained.

18
 Fig P.2 Login Panel

The functionality of this software spans through the entire system, making information
available anywhere, anytime. An ESS-User can only edit certain fields in the ESS Module,
maintaining the security and confidentiality of employee information.

FEATURES
When an ESS-User logs into the system for the first time, the first thing they will see is the
“Personal Details”. They are able to edit and enter certain fields.

Fig P.3 My Info Module

19
After login following details have to be filled during registration –
1. Personal Details
2. Contact Details
3. Emergency Contacts
4. Dependents
5. Immigration
6. Job
7. Salary
8. Report-to

Note: ‘*’ marked fields are restricted fields where an ESS-User cannot make changes to the
following details and need to be populated by the HR Admin and the respective ESS
Supervisor.

20
TEST PLAN

Product Name Orange HRM-PIM Test Plan Version 1.0

Product Version 3.0 Test Plan Template 1.0
Version

1. OBJECTIVE
The objective Test Plan is to define scope of the testing, schedules and deliverables.

2. AREAS TO BE TESTED
 My Info Module
 Photograph
 Contact Details
 Emergency Contact
 Dependents
 Immigration
 Job
 Salary
 Report To
 Qualifications
 Membership

3. AREAS NOT REQUIRING TESTING

 Other than the above.

4. HIGH LEVEL TEST OVERVIEW

 INTEGRATION TESTS:
N/A

21
  PROGRESSION TESTS:
Functional test cases added to TestLink and classified as Sanity, Regression and
Progress which will be executed as part of testing.

 NEGATIVE / CORNER TESTS:

Will be authored for all new features

 INTERNATIONALIZATION (I18N) TESTS:

N/A

 LOCALIZATION TESTS:
N/A

5. ACCEPETANCE TESTS
 N/A

6. L& P TESTS
 Covered in Performance Test Plan

7. REGRESSION TESTING
 Automated Regression suite will be executed as part of Regression.

8. ENVIRONMENTS COVERAGE
 Browser compatibility (Cross Browser testing): we cover different types of
browsers...
1. IE (Internet Explorer)
2. Chrome
3. Firefox.

22
9. AUTOMATION STRATEGY

 We are going to use QTP/Selenium for automating test cases.

10. TESTING TIME LINES/SCHEDULES

Iteration (or) Build Start Date End Date

No
Iteration#1(Build#1) 05-June-2020 10-June-2020

11. TESTING STRATEGY

 Existing functionalities will be validated as part of regression tests.

 New functionalities will be validated as part of progression tests.
 Fixed defects will be validated.

12. RESOURCES
 Human Resources:
QA team consists of following team members:
1. Nishant Kaushik
2. Abhishek Bansal
3. Shubham Chaudhary

 Software/Hardware Resources (Technical Resources)

Host servers 3

13. RISKS & MITIGATION:

S No. Risk Mitigation

1 Resource is on vacation Maintain backup resource

2 Hardware failure during testing Make ready It team, also
maintain backup h/w resources.

23
14. ENTRY CRITERIA

 Requirement Spec Doc

 Test Plan
 Test cases
 Unit Tests cases should pass

15. EXIT CRITERIA

 Zero Installer defects.

 Completion of Planned Test Case’s Execution.
 No P1/P2 Functional defect from any iteration

24
TEST CASES
These are the set of conditions and variables which determines whether the software satisfies
requirements and functions properly. Test Cases are always written in Excel Sheets to
incorporate step-by-step testing of all scenarios.

Fig P.4 Test Cases

25
TEST SCENARIOS
These are the functionalities that are to be tested.

Fig P.5 Test Scenarios

TEST EXECUTION
In execution all test cases according to their scenarios are implemented and bugs or errors
are reported as per respective Test Case ID with Reporting Date, Priority and Severity.

Fig P.6 Test Execution

26
 CONCLUSION

Software Testing is necessary because we all make mistakes. Some of those mistakes are
unimportant, but some of them are expensive or dangerous. Since we assume that our work
may have mistaken, hence we all need to check our own work. However some mistakes
come from bad assumptions and blind spots, so we might make the same mistakes when we
check our own work as we made when we did it. So we may not notice the flaws in what we
have done.

Ideally, we should get someone else to check our work because another person is more likely
to spot the flaws. It is really required to point out the defects and errors that were made
during the development phases. It’s essential since it makes sure that the customer finds the
organization reliable and their satisfaction in the application is maintained.

So software testing is necessary in order to provide the facilities to the customers like the
delivery of high quality product or software application which requires lower maintenance
cost and hence results into more accurate, consistent and reliable results.

27
 REFERENCES

 https://www.learnvern.com
 https://www.tutorialspoint.com/software_testing/index.htm
 https://www.orangehrm.com/
 https://www.geeksforgeeks.org/software-testing-basics/
 https://www.softwaretestingmaterial.com/software-testing/
 https://en.wikipedia.org/wiki/Software_testing
 https://www.softwaretestinghelp.com/

28