ST_final (2).docx

TESTING INCOME TAX WEBSITE USING CYPRESS WEB AUTOMATION
Dept of ISE, BIT 2023-24 1
CHAPTER 1.................................................................................................................................................1
INTRODUCTION ...................................................................................................................................1
1.1 TESTING APPROACH...............................................................................................................3
1.1.1 Static, Dynamic and Passive Testing ................................................................................3
1.1.2 Exploratory Approach .......................................................................................................3
1.1.3 The Box Approach .............................................................................................................3
CHAPTER 2.................................................................................................................................................6
TESTING TOOLS ...................................................................................................................................6
2.1 CYPRESS ....................................................................................................................................6
2.1.1 COMPONENTS .................................................................................................................7
2.2 Cypress vs Selenium ....................................................................................................................8
2.3 Cypress Grid.................................................................................................................................9
2.4 Test report using Cypress and Mochawesome reporter..............................................................10
2.5 Problem Definition.....................................................................................................................11
CHAPTER 3...............................................................................................................................................12
IMPLEMENTATION............................................................................................................................12
3.1 CODE...............................................................................................................................................13
CHAPTER 4 ..............................................................................................................................................16
TESTING...............................................................................................................................................16
5.1 Testing Objectives......................................................................................................................16
5.2 Testing Principles.......................................................................................................................16
5.3 Validation Testing......................................................................................................................16
5.6 Test report ..................................................................................................................................17
CHAPTER 5 ..............................................................................................................................................19
Home page .............................................................................................................................................19
Search by ingredients.............................................................................................................................19
The result for search by Ingredients .......................................................................................................20
Search by recipe name............................................................................................................................20
Results for search by recipe name ..........................................................................................................21
CHAPTER 6 ..............................................................................................................................................22
CONCLUSIONS....................................................................................................................................22
CHAPTER 1
INTRODUCTION
Software testing is an investigation conducted to provide stakeholders with information aboutthe
quality of the software product or service under test. Software testing can also provide an
objective, independent view of the software to allow the business to appreciate and understandthe

risks of software implementation. Test techniques include the process of executing a program or
application with the intent of finding failures and verifying that the software product is fit for
use. Software testing involves the execution of a software component or system component to
evaluate one or more properties of interest. In general, these properties indicate the extent to
which the component or system under test:
 meets the requirements that guided its design and development,
 responds correctly to all kinds of inputs,
 performs its functions within an acceptable time,
 is sufficiently usable,
 can be installed and run in its intended environments
 Achieves the general result its stakeholder’s desire.
As the number of possible tests for even simple software components is practically infinite, all
software testing uses some strategy to select tests that are feasible for the available time and
resources. As a result, software testing typically (but not exclusively) attempts to execute a
program or application with the intent of finding failures due to software faults. Software
testing can provide objective, independent information about the quality of software and risk
of its failure to users or sponsors.
Software testing can be conducted as soon as executable software (even if partially complete)
exists. The overall approach to software development often determines when and how testing
is conducted. For example, in a phased process, most testing occurs after system requirements
have been defined and then implemented in testable programs. In contrast, under an agile
approach, requirements, programming, and testing are often done concurrently. It is the process
of evaluating and verifying that a software product or application does what it is supposed to
do. The benefits of testing include preventing bugs, reducing development costs and improving
performance.

1.1 TESTING APPROACH
There are many approaches available in testing. Reviews, walkthroughs, or inspections are
referred to as static testing, whereas executing programmed code with a given set of test cases
is referred to as dynamic testing.
1.1.1 Static, Dynamic and Passive Testing
Static testing is often implicit, like proofreading, plus when programming tools/text editors
check source code structure or compilers (pre-compilers) check syntax and data flow as static
program analysis. Dynamic testing takes place when the program itself is run. Dynamic testing
may begin before the program is 100% complete in order to test particular sections of code and
are applied to discrete functions or modules. Typical techniques for these are either using
stubs/drivers or execution from a debugger environment. Static testing involves verification,
whereas dynamic testing also involves validation.
Passive testing means verifying the system behavior without any interaction with the software
product. Contrary to active testing, testers do not provide any test data but look at system logs
and traces. They mine for patterns and specific behavior in order to make some kind of
decisions. This is related to offline runtime verification and log analysis.
1.1.2 Exploratory Approach
Exploratory testing is an approach to software testing that is concisely described as
simultaneous learning, test design, and test execution. Cam Kaner, who coined the term in
1984, defines exploratory testing as a style of software testing that emphasizes the personal
freedom and responsibility of the individual tester to continually optimize the quality of his/her
work by treating test related learning, test design, test execution, and test result interpretation
as mutually supportive activities that run in parallel throughout the project.
1.1.3 The Box Approach
Software testing methods are traditionally divided into white box and black box testing. These
two approaches are used to describe the point of view that the tester takes when designing test
cases. A hybrid approach called grey box testing may also be applied to software testing.
Software testing methods are traditionally divided into white, black and grey-box testing.

White Box Testing
White-box testing (also known as clear box testing, glass box testing, transparent box testing
and structural testing) verifies the internal structures or workings of a program, as opposed to
the functionality exposed to the end-user. In white-box testing, an internal perspective of the
system (the source code), as well as programming skills, are used to design test cases. The
tester chooses inputs to exercise paths through the code and determine the appropriate outputs.
White box testing can be applied at the unit, integration, and system levels of the software
testing process; it is usually done at the unit level. It can test paths within a unit, paths between
units during integration, and between subsystems during a system level test. Though this
method of test design can uncover many errors or problems, it might not detect unimplemented
parts of the specification or missing requirements. Techniques used in white-box testing
include the following:
 API Testing - testing of the application using public and private APIs (application
programming interfaces)
 Code Coverage - creating tests to satisfy some criteria of code coverage (e.g., the test
designer can create tests to cause all statements in the program to be executed at least
once)
 Fault Injection Methods - intentionally introducing faults to gauge the efficacy of
testing strategies
 Mutation Testing Methods
 Static Testing Methods
Code coverage tools can evaluate the completeness of a test suite that was created with any
method, including black-box testing. This allows the software team to examine parts of a
system that are rarely tested and ensures that the most important function points have been
tested. Code coverage as a software metric can be reported as a percentage for:
 Function coverage, which reports on functions executed
 Statement coverage, which reports on the number of lines executed to complete the test
 Decision coverage, which reports on whether both the True and the False branch of a
given test has been executed.
 creating tests to satisfy some criteria of code coverage

Black Box Testing
Black-box testing (also known as functional testing) treats the software as a black box,
examining functionality without any knowledge of internal implementation, without seeing the
source code. The testers are only aware of what the software is supposed to do, not how it does
it. Black-box testing methods includes, equivalence partitioning, boundary value analysis, all
pairs testing, state transition tables, decision table testing, fuzz testing, model based testing, use
case testing, exploratory testing, and specification-based testing.
Specification based testing aims to test the functionality of software according to the applicable
requirements. This level of testing usually requires thorough test cases to be provided to the
tester, who then can simply verify that for a given input, the output value. Test cases are built
around specifications and requirements that is what the application is supposed to do. It uses
external descriptions of the software, including specifications, requirements, and designs to
derive test cases. These tests can be functional or non-functional, though usually functional.
One advantage of the black box technique is that no programming knowledge is required.
Whatever biases the programmers may have had, the tester likely has a different set and may
emphasize different areas of functionality. On the other hand, black-box testing has been said
to be like a walk in a dark labyrinth without a flashlight as they do not examine the source code,
there are situations when a tester writes many test cases to check something that could have
been tested by only one test case or leaves some parts of the program untested.
Grey Box Testing
Grey box testing involves having knowledge of internal data structures and algorithms for
purposes of designing tests while executing those tests at the user, or black-box level. The tester
will often have access to both the source code and the executable binary. Grey-box testing may
also include reverse engineering to determine, for instance, boundary values or error messages.
Manipulating input data and formatting output do not qualify as grey box, as the input and
output are clearly outside of the black box that we are calling the system under test. This
distinction is particularly important when conducting integration testing between two modules
of code written by two different developers, where only the interfaces are exposed for the test.

CHAPTER 2
TESTING TOOLS
Testing Tools in software testing can be defined as products that support various test activities
starting from planning, requirement gathering, build creation, test execution, defect logging and
test analysis. These testing tools are mainly used for testing software firmness, thoroughness,
and other performance parameters. There are tons of software testing tools available in the
market, and with the plethora of choices it becomes difficult to zero in on the best testing tools.
2.1 CYPRESS
Cypress is an open-source, full-featured, and easy-to-use end to end testing framework for web
application testing. Cypress is a relatively new player in the automation testing space and has
been gaining a lot of traction lately, as evident from the number of Forks (2.2K) and Stars
(36.6K) for the project.
Unlike Cypress, Cypress is preferred by front-end developers and automation testers who are
well-versed with JavaScript. However, Cypress is slowly catching up with Cypress, and the
six-month download trend comparison of Cypress and Cypress indicates that the war between
the two frameworks will continue to intensify in the coming months.
Cypress is a renowned end-to-end testing framework that enables frontend developers and test
automation engineers to perform Web and API testing. Since it is a JavaScript-based test
automation framework, it is widely preferred by the developer community. Cypress is a testing
tool that is targeted toward developers and QA engineers. It uses a unique DOM manipulation
technique and operates directly in the browser. It supports various browser versions of Google
Chrome, Mozilla Firefox, Microsoft Edge (Chromium-based) and Electron.
Cypress offers two options: end-to-end and component tests. There are benefits and
considerations for each choice, and the decision will depend on the needs of what you are
currently trying to accomplish.E2E Testing is a technique that tests your app from the web
browser through to the back end of your application, as well as testing integrations with third-
party APIs and services. These types of tests are great at making sure your entire app is
functioning as a cohesive whole.

Modern web frameworks provide ways to write applications by breaking them into smaller
logical units called components. Components can range from fairly small (like a button) to
more complex (like a registration form).Because of their nature, components tend to be easily
testable, which is where Cypress Component Testing comes into play.
2.1.1 COMPONENTS
Cypress has two components.
 Test Runner
 Dashboard
1.) Test Runner
Tests are run on a unique interface that usually allows us to see and understand what is
happening on our tests.
Figure 2.1: Test runner and its components.
Various components present in test runner as shown in Figure 2.1 are:
 Test Status: This menu shows how many tests passed/failed and the time is taken for
them to finish.
 URL Preview: This shows us the URL on which tests are performed.

 Viewport: Sets the app's viewport size to test the response.
 Command log: This shows us the command log as the tests execute.
2.) Dashboard
The dashboard component in cypress allows us to see and access recorded tests when cypress
tests are running from the CI provider. It provides insight into what happened in our test. It
provides data on the total number of passed, failed and skipped test cases. The stack trace and
screenshots of the failed tests are available. The video of test execution is available.
Management of test data, framework and their access is possible. The Figure 2.2 shows
components present in dashboard.
Figure 2.2: Dashboard and its components.
2.2 Cypress vs Selenium
Cypress is an automation web testing tool that’s fast, easy, and reliable for testing the things
(web components) that run in a browser. It’s an open-source test automation framework for
testing JavaScript web and enables you to perform unit, integration, and end-to-end tests.
Selenium is an automation tool that automates web applications for testing purposes. Unlike
Cypress, it’s not limited to web-based testing but can also be used for administration tasks.

Like Cypress, it’s open source. It supports tests written in multiple languages, not just
JavaScript. It has been around since 2002 and is quite mature in the testing world.
It’s time to decide which tool is the best. Selenium is a legacy system that has been around for
a long time, since 2002. Selenium has a huge install base and is more widely used than any
other automation testing tool. Cypress is newer and gaining in popularity. Cypress is fast for
API, front-end, and end-to-end testing, thanks to its architectural differences. The downside is
that so far, it only supports JavaScript.
Even though Selenium supports multiple languages, it’s tough for developers and testers to
adapt quickly because it’s complex. Cypress, meanwhile, is easier to learn and fast to use. Due
to its simpler architecture, testers tend to prefer it for automation testing. As a result, Cypress
is the winner for its ease of use and faster execution, but it cannot replace Selenium completely,
nor can it be used alongside Selenium. Selenium also supports the biggest projects, running
thousands of tests.
Both frameworks require significant coding/scripting, lack strong user administration or
reporting, and use element locator techniques that are often flaky, causing lots of rework. As a
result, you will spend a lot of time authoring and maintaining tests and supporting your team.
Low code tools like Testim help you modernize your test automation using artificial
intelligence to speed the authoring of tests, reduce test maintenance, and help you scale
efficiently. The time savings will more than offset the licensing costs.
2.3 Cypress Grid
Cypress Grid is a cloud-based test execution platform offered by Cypress.io, which allows
developers to run their Cypress tests across multiple machines and browsers in parallel, in order
to improve the speed and efficiency of their testing process.
With Cypress Grid, developers can run their tests across a range of browser versions, operating
systems, and devices, all in the cloud. This allows them to easily test their applications in a
variety of real-world scenarios, without the need to maintain an extensive and expensive in-
house testing infrastructure.

Using Cypress Grid is relatively straightforward. Developers simply need to configure their
Cypress tests to use the Grid, and then run them using the Cypress CLI. The Grid takes care of
provisioning the necessary resources, distributing the tests across them, and collating the
results.
Overall, Cypress Grid is a powerful tool for improving the speed, scalability, and reliability of
the testing process for web applications, and is used by many developers and organizations
around the world.
2.4 Test report using Cypress and Mochawesome reporter
Mocha and Cypress both provide options for using different types of reporters to generate test
results and output. Mocha supports a wide range of built-in and third-party reporters that allow
developers to customize the format and content of their test results. For example, some popular
Mocha reporters include Spec, Dot, List, and TAP, each of which generates a different style of
test output.
Similarly, Cypress also provides options for using different reporters to generate test results
and output. By default, Cypress uses its own built-in reporter, which provides a detailed and
comprehensive view of test results and allows developers to see individual test steps, command
durations, and more. However, Cypress also supports a range of third-party reporters, such as
Mochawesome, which generate more visually appealing and customizable reports.
Using a reporter in either Mocha or Cypress can be useful for several reasons. For one, it can
make it easier to visualize and understand the results of a large number of tests, especially when
working in a team setting. Additionally, it can help identify specific test failures or issues more
quickly, by providing more detailed information about the context and steps leading up to a
failure.Overall, using a reporter in Mocha or Cypress can be a useful tool for improving the
speed, efficiency, and effectiveness of web application testing.
Setup
1 install cypress-mochawesome-reporter
2 npm i --save-dev cypress-mochawesome-reporter or yarn add -D cypress-mochawesome-
reporter

3 Change cypress reporter & setup hooks
4 Edit config file (cypress.config.js by default)
5 Add to cypress/support/e2e.js “import 'cypress-mochawesome-reporter/register';”
6 run cypress
2.5 Problem Definition
Our activity mainly focuses on testing the income tax website. We have taken the example of
paying the tax online, PAN verification and displaying successful transactions.
The main objectives of this program –
 To automate the process of visiting the website.
 To automate the process of Sign up and Login.
 To automate the process of PAN verification.
 To automate the process of paying the tax.
 To automate the process of viewing the completed transactions.

CHAPTER 3
IMPLEMENTATION
Cypress is a NodeJS-based test automation framework for the modern web. It uses JavaScript
as a programming language.
JAVASCRIPT
JavaScript (JS) is a lightweight, interpreted, or just-in-time compiled programming language
with first-class functions. While it is most well-known as the scripting language for Web pages,
many non-browser environments also use it, such as Node.js, Apache CouchDB and Adobe
Acrobat.
There are many advantages of using JavaScript, including:
 Versatility: JavaScript can be used for both front-end and back-end development, which
makes it a versatile language.
 Interactivity: JavaScript allows you to create interactive web pages that respond to user
actions, such as clicking a button or scrolling.
 Popularity: JavaScript is one of the most popular programming languages in the world,
with a vast community of developers and a wide range of resources available.
 Speed: JavaScript is a fast language, allowing for quick execution of code and faster
load times for web pages.
 Easy to learn: JavaScript has a simple syntax and is relatively easy to learn compared to
other programming languages.
 Compatibility: JavaScript is supported by all major web browsers, which means that it
can be used on any device with an internet connection. the database to run best on that
hardware and software platform, and create the database and load the data. This section
focuses on the implementation of the cooking management system. The steps and the
technologies used are listed below.

3.1 CODE
describe('Income Tax', function () {
Cypress.on('uncaught:exception', (err, runnable) => {
console.log(err);
return false;
})
it('Visit the URL', function () {
cy.visit('http://localhost/income%20tax/signup.php')
cy.wait(1000)
});
it('Sign up', function () {
cy.wait(1000)
cy.get("#name").type("Darshan")
cy.get('#contact').type('1234567890')
cy.get('#pan').type('ABCDE1234A')
cy.get('#aadhaar').type('123456781234')
cy.get('#occupation').type('farmer')
cy.get('#username').type('dp19')
cy.get('#password').type('123456789')
cy.get('#cpassword').type('123456789')
cy.get('.btn-primary').click()
});
it('Login', function () {
cy.wait(1000)

cy.get(':nth-child(2) > .nav-link').click();
cy.get('.btn').click()
});
it('Pay tax' , function() {
cy.wait(1000)
cy.get('.nav > :nth-child(1) > .nav-link').click()
cy.get('#year').select('2022-23')
cy.get(':nth-child(2) > #exampleInputEmail1').type('1000000')
cy.wait(1000)
cy.get('#button').click()
cy.get('#select').select('Netbanking')
cy.get('.my-3 > #exampleInputEmail1').type('dp@bank')
cy.get('.my-3 > .mb-3 > #exampleInputPassword1').type('1234567890')
cy.get('#pmethod > .my-2 > .btn').click()
});
it('Show successful transactions' , function() {
cy.wait(1000)

cy.get(':nth-child(3) > .nav-link').click()
cy.get('#year').select('All')
cy.get(':nth-child(4) > form > .btn').click()
});
it('Verify PAN' , function() {
cy.wait(1000)
cy.get('.nav > :nth-child(2) > .nav-link').click()
cy.get('.form-control').type('ABCDE1234A')
cy.get('.form-check > .btn').click()
});
});

CHAPTER 4
TESTING
Software Testing is a method to check whether the actual software product matches expected
requirements and to ensure that software product is Defect free. It involves execution of
software/system components using manual or automated tools to evaluate one or more
properties of interest. The purpose of software testing is to identify errors, gaps or missing
requirements in contrast to actual requirements.
5.1 Testing Objectives
 Testing is the process of executing a program with the intent of finding an error.
 A good test case design is one that has a probability of finding a yet undiscovered
error.
 A successful test is one that uncovers a yet undiscovered error.
 These above objectives imply a dramatic change in view port.
 Testing cannot show the absence of defects, it can only show that software errors are
present.
5.2 Testing Principles
 All tests should be traceable to end user requirements.
 Tests should be planned long before testing begins.
 Testing should begin on a small scale and progress towards testing in large.
 Exhaustive testing is not possible.
5.3 Validation Testing
The process of evaluating software during the development process or at the end of the
development process to determine whether it satisfies specified business requirements.
Validation Testing ensures that the product meets the client's needs. It can also be defined as
to demonstrate that the product fulfills its intended use when deployed in an appropriate
environment. As a tester, it is always important to know how to verify the business logic or
scenarios that are given to you. One such method that helps in detailed evaluation of the
functionalities is the Validation Process.

Whenever you are asked to perform a validation test, it takes great responsibility as you need
to test all the critical business requirements based on the user’s needs. There should not be even
a single miss on the requirements asked by the user. Hence a keen knowledge of validation
testing is much important.
As a tester, you need to evaluate if the test execution results comply with what is mentioned in
the requirements document. Any deviation should be reported immediately and that deviation
is thus called a bug. Table 5.1 shows the testing validations.
Table 5.1: Validation Testing validations
Sl
NO INPUT OUTPUT RESULT
1 Visit the website Successfully visited Pass
2 Sign up Successfully Signed in Pass
3 Login Successfully Logged in Pass
4 Pay tax Payment Successful Pass
5 Pan verification Pan verified Pass
6 Transaction Transaction successful Pass
5.6 Test report
 No. of test cases executed: 6
 No. of test cases passed: 6
 No. of test cases failed: 0
 No. of test cases not detected: 0
The test report generated by Mochawesome reporter in the HTML format is shown in the Figure 5.1.

Figure 5.1: Test report by Mochawesome Reporter.

CHAPTER 5
Home page
SNAPSHOTS
Figure 6.1 is the landing page when we open the project which has the options for searching
by recipe name or ingredients.
Figure 6.1: Home page
Search by ingredients
The user gets the option to add the filters for the recipe which includes the drop down for
course, cuisine and diet, as shown in the Figure 6.2.
Figure 6.2: Food search by ingredients page

The result for search by Ingredients
The results for the mentioned ingredients and the filters as shown in Figure 6.2 are obtained
and can be seen in Figure 6.3.
Figure 6.3: results for search by ingredients
Search by recipe name
The user can select the search by recipe name and mention the desired recipe name along with
filters as shown in Figure 6.4.
Figure 6.4: search by recipe name

Results for search by recipe name
The results for search by recipe name is obtained and shown in Figure 6.5 according to users
input.
Figure 6.5: search by receipe name
The recipe instruction along with the ingredients required and the link of the website for further
information is provided as shown in Figure 6.6.
Figure 6.6: detailed information about receipe

CHAPTER 6
CONCLUSIONS
We can conclude by stating that the automation process is fast and appropriate process to
enhance the testing ability of the code. We are able to find out the loopholes in the process and
come to a conclusion about how many test cases can be satisfied using the testing tool. The
more number of test cases solved helps out in clearing all the anomalies or exceptions where
we get to know the root cause and be able to track it down. In this scenario we are able to test
the efficiency of Facebook features which are used in the web pages and hence the issues can
be sorted out easily, swiftly and correctly.

ST_final (2).docx

Recommended

Recommended

More Related Content

Similar to ST_final (2).docx

Similar to ST_final (2).docx (20)

Recently uploaded

Recently uploaded (20)

ST_final (2).docx