University Of Polytechnic

(Greater Noida, Uttar Pradesh)

PROJECT - II (DPCS9999)

Weather App

Mohammad Khurram & Harshit Gaur

Admission No.: 20GPTC4060075 & 21GPTC4060020

In partial fulfillment of requirements for the award of the degree

DIPLOMA IN COMPUTER SCIENCE & ENGINEERING

(Under the guidance of Er. Nutan Gusain)
 WEATHER APP
MAJOR PROJECT (DPCS9999)

OF

DIPLOMA IN DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

SEMESTER, FALL (2022-23)

SUBMITTED TO
UNIVERSITY POLYTECHNIC, GALGOTIAS UNIVERSITY

SUBMITTED BY: - GUIDE: -

Mohammad Khurram (20GPTC4060075) NUTAN GUSAIN

Harshit Gaur (21GPTC4060020)

GALGOTIAS UNIVERSITY
Plot No.2, Sector 17-A Yamuna Expressway, Greater Noida,
Gautam Buddha Nagar, Uttar Pradesh, India,
Session, Fall (2022-23)

1|Page
 Galgotias University

Department of Computer Science

CERTIFICATE

This is to certify that Mohammad khurram and Harshit Guar, student of Diploma in Computer
Science & Engineering, Sixth Semester, Department of Computer Science of Galgotias
University, has pursued the Major Project titled “Weather App” under the supervision of Er.
Nutan Gusian, Assistant Professor, and the report has been submitted in partial fulfillment of
requirements for the award of the degree, Diploma in Computer Science & Engineering by
Galgotias University in the Year 2023.

Er. Nutan Gusain Er. Rajeev Sharma

Assistant Professor (Guide) Program Chair

2|Page
 ACKNOWLEDGEMENT

I express my sincere regard and indebtedness to my project internal guide Er. Nutan Gusin and,
for her valuable time, guidance, encouragement, support, and cooperation throughout the
duration of our project. I would sincerely like to thank the IT Department for giving me the
opportunity to work on enhancing my technical skills while undergoing this project. This
project was done under the guidance of Er. Nutan Gusain Assistant Professor. This project
helped in understanding the various parameters which are involved in the development of a
web application and the working and integration of front end along with the back end to create
a fully functional web application.

I would like to thank Er. Nutan Gusain (Assistant Professor), and the whole department for
their constant support.

Mohammad Khurram & Harshit Gaur

Admission no: 20GPTC4060075 & 21GPTC4060020

3|Page
 ABSTRACT

This project involves building a weather app using HTML, CSS, and JavaScript and integrating
it with the Open Weather API to fetch real-time weather data for a user-selected location. The
app allows users to enter a city name or zip code and receive current weather data, including
temperature, humidity, wind speed, and weather conditions, in a visually appealing and easy-
to-understand format.

The project aims to provide a useful tool for users to access accurate and up-to-date weather
data for any location around the world and enhance their overall experience of accessing
weather data. The project feasibility study shows that the project is technically, economically,
and operationally feasible, with minimal costs and equipment requirements.

The project involves several key components, including designing the user interface,
integrating the Open Weather API, and implementing functionality to fetch and display weather
data. The project can be tested using both black-box and white-box testing techniques to ensure
its functionality and reliability.

Overall, building a weather app with HTML, CSS, and JavaScript and integrating it with the
Open Weather API is a valuable project that offers significant benefits to both users and
developers. With careful planning and execution, the project can be successfully completed to
provide a functional and user-friendly weather app for users to access accurate and up-to-date
weather data for any location around the world.

4|Page
 INDEX

S.No. Index

Chapter 1 INTRODUCTION

1.1 Introduction

1.2 Aim

1.3 Feasibility Study

1.4 Gantt chart

1.5 Organization of Report

Chapter 2 SOFTWARE REQUIREMENTS SPECIFICATION

2.1 Hardware Requirements

2.2 Software Requirements

Chapter 3 DESIGN & PLANNING

3.1 Software Development Life Cycle

3.2 ER Diagram

Chapter 4 IMPLEMENTATION DETAILS

4.1 Front end

4.2 Back end

4.3 Visual Studio Code

4.4 Methodology

Chapter 5 TESTING

5.1 Unit Testing

5.2 Integration testing

5|Page
 5.3 Software Verification and Validation

5.4 Black box

5.5 White box

Chapter 6 RESULTS

6.1 Files and Folder

6.2 Main page

6.3 Taking input from the user

6.4 Output

6.5 Responsive

6.6 Code

Chapter 7 CONCLUSION

6|Page
 Chapter 1: Introduction

1.1 Introduction
This project involves building a weather app using HTML, CSS, and JavaScript, and
integrating it with the Open Weather API to fetch real-time weather data for a user-selected
location. The aim of the project is to provide a simple and intuitive way for users to check the
weather conditions in different cities around the world.

The weather app will allow users to enter a city name or zip code and receive current weather
data, including temperature, humidity, wind speed, and weather conditions. The app will also
display a weather icon to provide a visual representation of the current weather conditions.

1.2 AIM
The aim of this project is to build a functional and user-friendly weather app using HTML,
CSS, and JavaScript, and integrate it with the Open Weather API to fetch real-time weather
data for a user-selected location. The app should allow users to enter a city name or zip code
and receive current weather data, including temperature, humidity, wind speed, and weather
conditions, in a visually appealing and easy-to-understand format. The goal of this project is to
create a useful tool that provides accurate and up-to-date weather information for any location
around the world and enhances the user's overall experience of accessing weather data.

By building a weather app with HTML, CSS, and JavaScript and integrating it with the Open
Weather API, we can create a useful tool that provides valuable information to users and
enhances their overall experience of accessing weather data. This project will also provide an
opportunity to practice and improve our skills in web development and API integration.

7|Page
1.3 Feasibility Study

A feasibility study is a high-level capsule version of the entire System analysis and Design
Process. The study begins by classifying the problem definition. Feasibility is to determine if
it’s worth doing. Once an acceptance problem definition has been generated, the analyst
develops a logical model of the system. A search for alternatives is analyzed carefully. There
are 3 parts in feasibility study.

1) Operational Feasibility

2) Technical Feasibility

3) Economical Feasibility

1.3.1 Operational Feasibility

Operational feasibility is the measure of how well a proposed system solves the problems and
takes advantage of the opportunities identified during scope definition and how it satisfies the
requirements identified in the requirements analysis phase of system development. The
operational feasibility assessment focuses on the degree to which the proposed development
projects fits in with the existing business environment and objectives about development
schedule, delivery date, corporate culture and existing business processes. To ensure success,
desired operational outcomes must be imparted during design and development. These include
such design-dependent parameters as reliability, maintainability, supportability, usability,
producibility, disposability, sustainability, affordability, and others.

Building and operating a weather app with HTML, CSS, and JavaScript and integrating it with
the Open Weather API is operationally feasible, as it does not require any specialized
equipment or resources. The app can be hosted on a basic web server or cloud platform, and
updates can be made as needed.

8|Page
1.3.2 Technical Feasibility

This involves questions such as whether the technology needed for the system exists, how
difficult it will be to build, and whether the firm has enough experience using that technology.
The assessment is based on outline design of system requirements in terms of input, processes,
output, fields, programs, and procedures. This can be qualified in terms of volume of data,
trends, frequency of updating to introduce the technical system. The application is the fact that
it has been developed on windows XP platform and a high configuration of 1GB RAM on Intel
Pentium Dual core processor. This is technically feasible. The technical feasibility assessment
is focused on gaining an understanding of the present technical resources of the organization
and their applicability to the expected needs of the proposed system. It is an evaluation of the
hardware and software and how it meets the need of the proposed system.

Building a weather app with HTML, CSS, and JavaScript and integrating it with the Open
Weather API is technically feasible. There are numerous tutorials and resources available
online that can help developers learn how to build web apps and integrate APIs. Moreover, the
Open Weather API provides extensive documentation and support to help developers integrate
the API into their applications.

1.3.3 Economical Feasibility

Establishing the cost-effectiveness of the proposed system i.e., if the benefits do not outweigh
the costs, then it is not worth going ahead. In the fast-paced world today there is a great need
for online social networking facilities. Thus, the benefits of this project in the current scenario
make it economically feasible. The purpose of the economic feasibility assessment is to
determine the positive economic benefits to the organization that the proposed system will
provide. It includes quantification and identification of all the benefits expected. This
assessment typically involves a cost/benefits analysis.

Building a weather app with HTML, CSS, and JavaScript and integrating it with the Open
Weather API is economically feasible, as there are no significant costs associated with these
tools. The necessary software (text editor and web browser) is free, and the Open Weather API
offers a free plan with a limited number of API calls per day.

9|Page
1.4 Gantt chart

10 | P a g e
 1.5 Organization of the Report

1. INTRODUCTION

This section includes the overall view of the project i.e., the basic problem definition and the
general overview of the problem which describes the problem in layman terms. It also specifies
the software used and the proposed solution strategy.

2. SOFTWARE REQUIREMENTS SPECIFICATION

This section includes the Software and hardware requirements for the smooth running of the
application.

3. DESIGN & PLANNING

This section consists of the Software Development Life Cycle model. It also contains technical
diagrams like the Data Flow Diagram and the Entity Relationship diagram.

4. IMPLEMENTATION DETAILS

This section describes the different technologies used for the entire development process of the
Front-end as well as the Back-end development of the application.

5. RESULTS AND DISCUSSION

This section has screenshots of all the implementation i.e., user interface and their description.

6. SUMMARY AND CONCLUSION

This section has screenshots of all the implementation i.e., user interface and their description.

11 | P a g e
 Chapter 2: Software Requirements Specification

2.1 Hardware Requirements

Number Description

1. • Modern Operating System:

2. • x86 64-bit CPU (Intel / AMD architecture)

3. • Minimum 4 GB RAM.

4. • 2 GB free disk space.

5. • Internet Connection

2.2 Software Requirements

Number Description Type

1. Operating System Windows 10/11

2. Language HTML , CSS , JAVASCRIPT

3. OpenWeatherApi API key

4. IDE Visual Studio Code

12 | P a g e
 CHAPTER 3: DESIGN & PLANNING

3.1 Software Development Life Cycle Model

3.1.1WATERFALL MODEL

• The waterfall model was selected as the SDLC model due to the following reasons:
• Requirements were very well documented, clear and fixed. Technology was adequately
understood.
• Simple and easy to understand and use. There were no ambiguous requirements.
• Easy to manage due to the rigidity of the model. Each phase has specific deliverables
and a review process.
• Clearly defined stages.
• Well understood milestones.
• Easy to arrange tasks.

13 | P a g e
3.2 ER Diagram

14 | P a g e
 Chapter 4: Implementation Details

In this Section we will do Analysis of Technologies to use for implementing the project.

4.1: FRONT END

4.1.1 HTML

Hypertext Markup Language (HTML) is the standard markup language for documents
designed to be displayed in a web browser. It can be assisted by technologies such as Cascading
Style Sheets (CSS) and scripting languages such as JavaScript. Web browsers receive HTML
documents from a web server or from local storage and render the documents into multimedia
web pages. HTML describes the structure of a web page semantically and originally included
cues for the appearance of the document.

HTML elements are the building blocks of HTML pages. With HTML constructs, images, and
other objects such as interactive forms may be embedded into the rendered page. HTML
provides a means to create structured documents by denoting structural semantics for text such
as headings, paragraphs, lists, links, quotes, and other items. HTML elements are delineated
by tags, written using angle brackets. Tags such as <imp /> and <input /> directly introduce
content into the page. Other tags such as <p> surround and provide information about document
text and may include other tags as sub-elements. Browsers do not display HTML tags but use
them to interpret the content of the page.

HTML can embed programs written in a scripting language such as JavaScript, which
affects the behavior and content of web pages. Inclusion of CSS defines the look and layout of
content. The World Wide Web Consortium (W3C), former maintainer of the HTML and
current maintainer of the CSS standards, has encouraged the use of CSS over explicit

presentational HTML since 1997.

15 | P a g e
 4.1.4 CSS

CSS

Cascading Style Sheets (CSS) is a style sheet language used for describing the presentation of
a document written in a markup language like HTML.CSS is a cornerstone technology of the
World Wide Web, alongside HTML and JavaScript.CSS is designed to enable the separation
of presentation and content, including layout, colors, and fonts. This separation can improve
content accessibility, provide more flexibility and control in the specification of
presentation characteristics, enable multiple web pages to share formatting by specifying
the relevant CSS in a separate .CSS file, and reduce complexity and repetition in the structural
content.

CSS information can be provided from various sources. These sources can be the web browser,
the user and the author. The information from the author can be further classified into inline,
media type, importance, selector specificity, rule order, inheritance, and property definition.
CSS style information can be in a separate document, or it can be embedded into an HTML
document. Multiple style sheets can be imported. Different styles can be applied depending on
the output device being used; for example, the screen version can be quite different from the
printed version, so that authors can tailor the presentation appropriately for each medium. The
style sheet with the highest priority controls the content display. Declarations not set in the
highest priority source are passed on to a source of lower priority, such as the user agent style.
The process is called cascading.

One of the goals of CSS is to allow users greater control over presentation. Someone who finds
red italic headings difficult to read may apply a different style sheet. Depending on the browser
and the web site, a user may choose from various style sheets provided by the designers or may
remove all added styles and view the site using the browser's default styling or may override

just the red italic heading style without altering other attributes.

16 | P a g e
4.2: BACK END

4.2.1 JavaScript

JavaScript is a high-level, interpreted scripting language that conforms to the ECMAScript

specification. JavaScript has curly-bracket syntax, dynamic typing, prototype-based object-
orientation, and first-class functions. Alongside HTML and CSS, JavaScript is one of the core
technologies of the World Wide Web. JavaScript enables interactive web pages and is an
essential part of web applications. The vast majority of websites use it, and major web browsers
have a dedicated JavaScript engine to execute it.As a multi-paradigm language, JavaScript
supports event- driven, functional, and imperative (including object-oriented and prototype-
based) programming styles. It has APIs for working with text, arrays, dates, regular
expressions, and the DOM, but the language itself does not include any I/O, such as
networking, storage, or graphics facilities. It relies upon the host environment in which it is
embedded to provide these features.

Initially only implemented client-side in web browsers, JavaScript engines are now
embedded in many other types of host software, including server-side in web servers and
databases, and in non- web programs such as word processors and PDF software, and in
runtime environments that make JavaScript available for writing mobile and desktop
applications, including desktop widgets.

The terms Vanilla JavaScript and Vanilla JS refer to JavaScript not extended by any
frameworks or additional libraries. Scripts written in Vanilla JS are plain JavaScript code.
Google’s Chrome extensions, Opera's extensions, Apple's Safari 5 extensions, Apple's
Dashboard Widgets, Microsoft's Gadgets, Yahoo! Widgets, Google Desktop Gadgets, and
Serence Klipfolio are implemented using JavaScript.

17 | P a g e
 4.3 Visual Studio Code

Visual Studio Code is a free and open-source code editor developed by Microsoft for Windows,
macOS, and Linux operating systems. It provides developers with a lightweight, yet powerful
platform for writing, debugging, and testing code.

Visual Studio Code supports a wide range of programming languages, including JavaScript,
Html, Java, C#, and many others. It also comes with a rich set of features, including IntelliSense
code completion, debugging tools, code refactoring, version control integration, and many
more.

In addition to its built-in features, Visual Studio Code also supports a large number of
extensions that can be installed from the Visual Studio Code Marketplace, making it highly
customizable to meet the needs of different developers and teams.

18 | P a g e
4.4 Methodology

Step 1: Create the basic HTML structure of the app.

In the above code, we have created the basic HTML structure of the weather app. We have
created a container div to hold the app, a search box to enter the city name, a search button to
trigger the search, and a weather-data div to display the weather information. We have also
included a reference to our stylesheet and JavaScript file.

19 | P a g e
Step 2: Style the app using CSS.

In the above code, we have styled the app using CSS. We have set the background color of the
body, font family, and other styles for the container, search box, input, button, and weather-
data div. We have also set styles for the weather icon image.

20 | P a g e
Step 3: Fetch the weather data from Open Weather API using JavaScript

Open Weather API Key: To access the weather data from Open Weather API, you need to
register for an API key. The API key is required to make requests to the Open Weather API
and receive weather data.

Open Weather API Documentation: The Open Weather API documentation provides
information about the API endpoints, parameters, and responses, which is necessary to
integrate the API into the app.

21 | P a g e
 Chapter 5: Testing

5.1 Unit Testing

5.1.1 Introduction

In computer programming, unit testing is a software testing method by which individual

units of source code, sets of one or more computer program modules together with
associated control data, usage procedures, and operating procedures, are tested to
determine whether they are fit for use. Intuitively, one can view a unit as the smallest
testable part of an application. In procedural programming, a unit could be an entire
module, but it is more commonly an individual function or procedure. In object-
oriented programming, a unit is often an entire interface, such as a class, but could be
an individual method. Unit tests are short code fragments created by programmers or
occasionally by white box testers during the development process. It forms the basis for
component testing. Ideally, each test case is independent from the others. Substitutes
such as method stubs, mock objects, fakes, and test harnesses can be used to assist
testing a module in isolation. Unit tests are typically written and run by software
developers to ensure that code meets its design and behaves as intended.

5.1.2

22 | P a g e
The goal of unit testing is to isolate each part of the program and show that the
individual parts are correct. A unit test provides a strict, written contract that the piece
of code must satisfy. As a result, it offers several benefits.

1) Find problems early: Unit testing finds problems early in the development cycle.
In test- driven development (TDD), which is frequently used in both extreme
programming and scrum, unit tests are created before the code itself is written. When
the tests pass, that code is considered complete. The same unit tests are run against that
function frequently as the larger code base is developed either as the code is changed
or via an automated process with the build. If the unit tests fail, it is a bug either in the
changed code or the tests themselves. The unit tests then allow the location of the fault
or failure to be easily traced. Since the unit tests alert the development team of the
problem before handing the code off to testers or clients, it is still early in the
development process.

2) Facilitates Change: Unit testing allows the programmer to refactor code or upgrade
system libraries later, and make sure the module still works correctly (e.g., in regression
testing). The procedure is to write test cases for all functions and methods so that
whenever a change causes a fault, it can be quickly identified. Unit tests detect changes
which may break a design contract.

3) Simplifies Integration: Unit testing may reduce uncertainty in the units themselves
and can be used in a bottom-up testing style approach. By testing the parts of a program
first and then testing the sum of its parts, integration testing becomes much easier.

4) Documentation: Unit testing provides a sort of living documentation of the system.

Developers looking to learn what functionality is provided by a unit, and how to use it,
can look at the unit tests to gain a basic understanding of the unit's interface (API). Unit
test cases embody characteristics that are critical to the success of the unit. These
characteristics can indicate appropriate/inappropriate use of a unit as well as negative
behaviors that are to be trapped by the unit.

23 | P a g e
5.2: Integration Testing

Integration testing (sometimes called integration and testing, abbreviated I&T) is the
phase in software testing in which individual software modules are combined and tested
as a group. It occurs after unit testing and before validation testing. Integration testing
takes as its input modules that have been unit tested, groups them in larger aggregates,
applies tests defined in an integration test plan to those aggregates, and delivers as its
output the integrated system ready for system testing.

5.2.1 Purpose

The purpose of integration testing is to verify functional, performance, and reliability

requirements placed on major design items. These "design items", i.e., assemblages (or
groups of units), are exercised through their interfaces using black-box testing, success
and error cases being simulated via appropriate parameter and data inputs. Simulated
usage of shared data areas and inter-process communication is tested and individual
subsystems are exercised through their input interface. Test cases are constructed to test
whether all the components within assemblages interact correctly, for example across
procedure calls or process activations, and this is done after testing individual modules,
i.e., unit testing. The overall idea is a "building block" approach, in which verified
assemblages are added to a verified base which is then used to support the integration
testing of further assemblages. Software integration testing is performed according to
the software development life cycle (SDLC) after module and functional tests. The
cross- dependencies for software integration testing are schedule for integration testing,
strategy and selection of the tools used for integration, define the cyclomatic complexity
of the software and software architecture, reusability of modules and life cycle and
versioning management. Some different types of integration testing are big-bang, top-
down, and bottom-up, mixed (sandwich) and risky-hardest. Other Integration Patterns
are collaboration integration, backbone integration, layer integration, client-server
integration, distributed services integration, and high-frequency integration.

24 | P a g e
5.2.1.1 Big

In the big-bang approach, most of the developed modules are coupled together to form
a complete software system or major part of the system and then used for integration
testing. This method is very effective for saving time in the integration testing process.
However, if the test cases and their results are not recorded properly, the entire
integration process will be more complicated and may prevent the testing team from
achieving the goal of integration testing. A type of big-bang integration testing is called
"usage model testing" which can be used in both software and hardware integration
testing. The basis behind this type of integration testing is to run user-like workloads in
integrated user-like environments. In doing the testing in this manner, the environment
is proofed, while the individual components are proofed indirectly through their use.
Usage Model testing takes an optimistic approach to testing because it expects to have
few problems with the individual components. The strategy relies heavily on the
component developers to do the isolated unit testing for their product. The goal of the
strategy is to avoid redoing the testing done by the developers, and instead flesh out
problems caused by the interaction of the components in the environment.

5.2.1.2 Top-down and Bottom-up

Bottom-up testing is an approach to integrated testing where the lowest-level

components are tested first, then used to facilitate the testing of higher-level
components. The process is repeated until the component at the top of the hierarchy is
tested. All the bottom or low-level modules, procedures, or functions are integrated and
then tested. After the integration testing of lower-level integrated modules, the next
level of modules will be formed and can be used for integration testing. This approach
is helpful only when all or most of the modules of the same development level are
ready. This method also helps to determine the levels of software developed and makes
it easier to report testing progress in the form of a percentage. Top-down testing is an
approach to integrated testing where the top integrated modules are tested, and the
branch of the module is tested step by step until the end of the related module. Sandwich
testing is an approach to combine top-down testing with bottom-up testing.

25 | P a g e
5.3 Software Verification and Validation

5.3.1 Introduction

In software project management, software testing, and software engineering,

verification, and validation (V&V) is the process of checking that a software system
meets specifications and that it fulfills its intended purpose. It may also be referred to
as software quality control. It is normally the responsibility of software testers as part
of the software development lifecycle. Validation checks that the product design
satisfies or fits the intended use (high-level checking), i.e., the software meets the user
requirements. This is done through dynamic testing and other forms of review.
Verification and validation are not the same thing, although they are often confused.
Boehm succinctly expressed the difference between

• Validation: Are we building the right product?

• Verification: Are we building the product, right?

According to the Capability Maturity Model (CMMI-SW v1.1)

Software Verification: The process of evaluating software to determine whether the

products of a given development phase satisfy the conditions imposed at the start of
that phase.

Software Validation: The process of evaluating software during or at the end of the
development process to determine whether it satisfies specified requirements.

In other words, software verification is ensuring that the product has been built
according to the requirements and design specifications, while software validation
ensures that the product meets the user's needs, and that the specifications were correct
in the first place. Software verification ensures that "you built it right". Software
validation ensures that "you built the right thing". Software validation confirms that the
product, as provided, will fulfill its intended use.

26 | P a g e
From Testing Perspective

• Fault – wrong or missing function in the code.

• Failure – the manifestation of a fault during execution.
• Malfunction – according to its specification the system does not meet its
specified functionality.

Both verification and validation are related to the concepts of quality and of software
quality assurance. By themselves, verification and validation do not guarantee software
quality; planning, traceability, configuration management and other aspects of software
engineering are required. Within the modeling and simulation (M&S) community, the
definitions of verification, validation and accreditation are similar:

• M&S Verification is the process of determining that a computer model,

simulation, or federation of models and simulations implementations and their
associated data accurately represent the developer's conceptual description and
specifications.

• M&S Validation is the process of determining the degree to which a model,

simulation, or federation of models and simulations, and their associated data
are accurate representations of the real world from the perspective of the
intended use(s).

27 | P a g e
5.3.2 Classification

In mission-critical software systems, where flawless performance is necessary, formal methods

may be used to ensure the correct operation of a system. However, often for non-mission-
critical software systems, formal methods prove to be very costly, and an alternative method
of software V&V must be sought out. In such cases, syntactic methods are often used.

5.3.3 Test Cases

A test case is a tool used in the process. Test cases may be prepared for software verification
and software validation to determine if the product was built according to the requirements of
the user. Other methods, such as reviews, may be used early in the life cycle to provide software
validation.

28 | P a g e
5.4: Black-Box

Black-box testing is a method of software testing that examines the functionality of an

application without peering into its internal structures or workings. This method of test can be
applied virtually to every level of software testing: unit, integration, system, and acceptance. It
typically comprises most if not all higher-level testing but can also dominate unit testing as
well.

5.4.1 Test Procedures

Specific knowledge of the application's code/internal structure and programming knowledge

in general is not required. The tester is aware of what the software is supposed to do but is not
aware of how it does it. For instance, the tester is aware that a particular input returns a certain,
invariable output but is not aware of how the software produces the output in the first place.

5.4.2 Test Cases

Test cases are built around specifications and requirements, i.e., what the application is
supposed to do. Test cases are generally derived from external descriptions of the software,
including specifications, requirements and design parameters. Although the tests used are
primarily functional in nature, non-functional tests may also be used. The test designer selects
both valid and invalid inputs and determines the correct output, often with the help of an oracle
or a previous result that is known to be good, without any knowledge of the test object's internal
structure.

29 | P a g e
5.5: White-Box

White-box testing (also known as clear box testing, glass box testing, transparent box testing,
and structural testing) is a method of testing software that tests internal structures or workings
of an application, as opposed to its functionality (i.e., black-box testing). In white box testing
an internal perspective of the system, as well as programming skills, are used to design test
cases. The tester chooses inputs to exercise paths through the code and determines the
appropriate outputs. This is analogous to testing nodes in a circuit, e.g., in-circuit testing (ICT).
White-box testing can be applied at the unit, integration, and system levels of the software
testing process. Although traditional testers tended to think of white box testing as being done
at the unit level, it is used for integration and system testing more frequently today. 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
has the potential to miss unimplemented parts of the specification or missing requirement.

5.5.1 Levels

1) Unit testing: White-box testing is done during unit testing to ensure that the code is working
as intended, before any integration happens with the previously tested code. White- box testing
during unit testing catches any defects early on and aids in any defects that happen later on
after the code is integrated with the rest of the application and therefore prevents any type of
errors later on.

2) Integration testing: White box testing at this level is written to test the interactions of each
interface with each other. The Unit level testing made sure that each code was tested and
working accordingly in an isolated environment and integration examines the correctness of
the behavior in an open environment using white box testing for any interactions of interfaces
that are known to the programmer.

3) Regression testing: White-box testing during regression testing is the use of recycled white-
box test cases at the unit and integration testing levels.

30 | P a g e
5.5.2

White-box testing's basic procedures involve the tester having a deep level of understanding of
the source code being tested. The programmer must have a deep understanding of the
application to know what kinds of test cases to create so that every visible path is exercised for
testing. Once the source code is understood then the source code can be analyzed for test cases
to be created. These are the three basic steps that white-box testing takes in order to create test
cases:

• Input involves different types of requirements, functional specifications, detailed

designing of documents, proper source code, security specifications. This is the preparation
stage of white- box testing to layout all of the basic information.

• Processing involves performing risk analysis to guide whole testing process, proper test
plan, execute test cases and communicate results. This is the phase of building test cases to
make sure they thoroughly test the application the given results are recorded accordingly.

• Output involves preparing final report that encompasses all of the above preparations
and results.

31 | P a g e
System testing of software or hardware is testing conducted on a complete, integrated system
to evaluate the system's compliance with its specified requirements. System testing falls within
the scope of black-box testing, and as such, should require no knowledge of the inner design
of the code or logic. As a rule, system testing takes, as its input, all of the "integrated" software
components that have passed integration testing and also the software system itself integrated
with any applicable hardware system(s). The purpose of integration testing is to detect any
inconsistencies between the software units that are integrated together (called assemblages) or
between any of the assemblages and the hardware. System testing is a more limited type of
testing; it seeks to detect defects both within the "inter-assemblages" and also within the system
as a whole.

System testing is performed on the entire system in the context of a Functional Requirement
Specification(s) (FRS) and/or a System Requirement Specification (SRS). System testing tests
not only the design, but also the behavior and even the believed expectations of the customer.
It is also intended to test up to and beyond the bounds defined in the software/hardware
requirements specification.

32 | P a g e
 Chapter 6: Results

6.1 Folder and Files

33 | P a g e
6.2 Main Page

34 | P a g e
6.3 Taking Input from the User

35 | P a g e
6.4 Output

36 | P a g e
6.5 Responsive

37 | P a g e
6.6 Code (VS .CODE IDE)

38 | P a g e
 Chapter 7: Conclusion

Building a weather app with HTML, CSS, and JavaScript and integrating it with the Open
Weather API is a feasible and valuable project. The app provides a useful tool for users to
access accurate and up-to-date weather data for any location around the world. It also offers an
opportunity for developers to practice and improve their skills in web development and API
integration.

The project involves several key components, including designing the user interface,
integrating the Open Weather API, and implementing functionality to fetch and display weather
data. The project can be tested using both black-box and white-box testing techniques to ensure
its functionality and reliability.

Moreover, the feasibility study shows that the project is technically, economically, and
operationally feasible, with minimal costs and equipment requirements. It is essential to ensure
compliance with any relevant legal and regulatory requirements and potential risks before
proceeding with the project.

Overall, building a weather app with HTML, CSS, and JavaScript and integrating it with the
Open Weather API is a valuable project that offers significant benefits to both users and
developers. With careful planning and execution, the project can be successfully completed to
provide a functional and user-friendly weather app for users to access accurate and up-to-date
weather data for any location around the world.

39 | P a g e