Unit-2 Application Testing Basics

Application Testing
 Application Testing is a part of the Software Application Development process
that is carried out for verifying the correctness and validating the functional
features of the application being developed.
 It is a process which ensures that a software application functions properly and
according to the requirements specified.
 Application testing refers to testing any software application using scripts, tools,
or test automation frameworks to identify errors.
 Types of Application Design:
1. Web Application
2. Mobile Application
3. IoT Application
4. Cloud Application
Web Application

 Web applications are programs or software made by third parties, hosted on a

remote server, and accessible from any web browser on any device.
 An application that interacts with a network is called a web application.
 Types of Web Application:
1) Static Web Application:
 A static web application is a collection of HTML, CSS, and JavaScript to facilitate
displaying important content and information.
2) Dynamic Web Application:
 A dynamic web application, which displays live data based on user requests.
3) E-Commerce Web Application:
 An e-commerce web application is any business that allows customers to
purchase goods or services over the internet.
4) Portal Web Application:
 A portal web application is a website that provides access to many different pages
and links. Portal web applications are often used for online shopping, news sites,
blogs, and search engines.
5) Content Management System:
 A content management system (CMS) allows website owners to create, edit, and
publish content, including images, text, and video, without involving a technical
team.
Mobile Application Design
 Mobile application development is the set of processes and procedures involved
in writing software for small, wireless computing devices, such as smartphones
and other hand-held devices.
 There are three major development approaches when building mobile
applications
1) Native Applications:
These applications are built using integrated development environments (IDEs) and
languages for mobile OS such as Apple iOS or Google Android.
2) Hybrid Application:
These are web apps that act like native apps. They are developed using technologies
such as HTML, JavaScript and Cascading Style Sheets (CSS).
3) Cross-Platform Applications:
Cross-platform native mobile applications can be written in variety of different
programming languages and frameworks, but they are compiled into a native
application running directly on the operating system of the device.
IoT Application
 IoT refers to the billions of physical objects or “things” connected to the Internet,
all collecting and exchanging data with other devices and systems over the
Internet.
 Types of IoT:
1) Consumer IoT: Primarily for everyday use
Ex: smartphones, home appliances
2) Commercial IoT: Primarily used in the healthcare and transport industries
Ex: smart pacemakers and monitoring systems, supermarkets, stores, hotels.
3) Military Things (IoMT): Primarily used for the application of IoT technologies in
the military field.
Ex: surveillance robots and human-wearable biometrics for combat
4) Industrial Internet of Things (IIoT): Primarily used with industrial
applications, such as in the manufacturing and energy sectors.
Ex: Digital control systems, smart agriculture and industrial big data.
5) Infrastructure IoT: Primarily used for connectivity in smart cities.
Ex: infrastructure sensors such as bridges, railway tracks.
Cloud Application
 Cloud applications are software that users access primarily through the internet,
meaning at least some of it is managed by a server and not users' local machines.
 Types of Cloud Application:
1) Public Cloud:
 Public cloud is open to all to store and access information via the Internet using
the pay-per-usage method.
Ex: Microsoft, Google App Engine
2) Private Cloud:
 Private cloud is also known as an internal cloud or corporate cloud. It is used by
organizations to build and manage their own data center internally.
Ex: IBM, Oracle
3) Hybrid Cloud:
 Hybrid Cloud is a combination of the public cloud and the private cloud.
Ex: Gmail, Google Drive, Amazon Web Service
4) Community Cloud:
 Community cloud allows systems and services to be accessible by a group of several
organizations to share the information between the organization and a specific
community.
Ex: Healthcare Community Cloud
Software Design Architectural
 Architecture serves as blueprint of software.
 The software needs an architectural design to represent the design of the software.
 It provides an abstraction to manage the system complexity and establish a communication
and coordination mechanism among components.
 Software architectural design is the process of defining a collection of hardware and software
components and their interfaces to establish the framework for the development of a
computer system.

 System Category Consists of

 A set of components(eg. Database, computational modules) that will perform a function required by
the system
 The set of connectors will help in coordination and communication between the components
 Conditions that how components can be integrated to form the system
 Semantic models that help the designer to understand the overall properties of the system
Taxonomy of Architectural Styles
 There are five types of architectural style.
1) Data-centered architectures
2) Data-flow architectures
3) Call and return architectures
4) Object-oriented architectures
5) Layered architectures
Data-centered Architectures
 A data store resides at the center of this architecture and is accessed frequently
by other components that update, add, or delete data within the store.
 Client software accesses a central repository.
 Client software accesses the data independent of any changes to the data or
the actions of other client software.
 A variation on this approach transforms the repository into a “blackboard”
that sends notifications to client software when data of interest to the client
changes.
 Data-centered architectures promote integrability that means existing
components can be changed and new client components added to the
architecture without concern about other clients.
 Data can be passed among clients using blackboard mechanism.
Advantage of Data centered architecture
 Repository of data is independent of clients
 Client work independent of each other
 It may be simple to add additional clients.
 Modification can be very easy
Disadvantage of Data centered architecture
 There is a single point of failure.
 The evolution of data is costly and difficult.
Data-flow architectures

 This architecture is applied when input data are to be transformed through a

series of computational or manipulative components into output data.
 Fig shows pipe and filter architecture.
 A pipe-and-filter pattern has a set of components, called filters, connected by
pipes that transmit data from one component to the next.
 Each filter will work independently and is designed to take data input of a certain
form and produces data output to the next filter of a specified form. The filters
don’t require any knowledge of the working of neighbouring filters.
 If the data flow degenerates into a single line of transforms, then it is termed as
batch sequential. This structure accepts the batch of data and then applies a
series of sequential components to transform it.
Advantage of Data Flow architecture
 It encourages repurposing, and modification.
 With this design, concurrent execution is supported.
Disadvantage of Data Flow architecture
 It frequently degenerates into batch sequential system
 Data flow architecture does not allow applications that require greater user
engagement.
 It is not easy to coordinate two different but related streams
Call and Return Architecture
 This architectural style enables you to achieve a program structure that is
relatively easy to modify and scale.
 A number of substyles exist within this category:
1) Main program/subprogram architectures.
 The main program structure decomposes into number of subprograms or
function into a control hierarchy. Main program contains number of
subprograms that can invoke other components.
2) Remote procedure call architectures.
 This components is used to present in a main program or sub program
architecture distributed among multiple computers on a network.
Advantage of Call and Return architecture
 They enable code modularity.
 They are easy to scale and modify.
Disadvantage of Call and Return architecture
 If interfaces are not well-defined, it may lead to tight data coupling.
 If internal data structures change, it may result in ripples to other modules.
Object- Oriented Architecture
 The components of a system encapsulate data and the operations that must be applied to manipulate
the data.
 The coordination and communication between the components are established via the message
passing.
 Characteristics of Object Oriented architecture:
Object protect the system’s integrity.
Object is unaware of the depiction of other items.
Advantage of Object Oriented architecture
 It enables the designer to separate a challenge into a collection of autonomous objects.
 Other objects are aware of the implementation details of the object, allowing changes to be made
without having an impact on other objects.
Disadvantage of Object Oriented architecture
 Object-Oriented architecture has difficulty to determine all the necessary classes and objects
required for a system.
 This methodology do not lead to successful reuse on a large scale without an explicit reuse
procedure.
Layered architectures
 A number of different layers are defined, each accomplishing operations that
progressively become closer to the machine instruction set.
 At the outer layer, components service user interface operations.
 At the inner layer, components perform operating system interfacing.
 Intermediate layers provide utility services and application software functions.
Advantages of Layered Architecture
 It supports incremental development.
 A series of layers can help partition complex problems.
 It is secure.
 The application is portable.
 Layers can be reused.
Disadvantages of Layered Architecture
 Clean separation between layers is hard to achieve.
 Multiple layers of processing may lead to the degradation of performance.
 It is difficult to structure some systems into layers.
Software Design Component
 A software component is a modular building block for the computer software.
 Component is defined as a modular, deployable and replaceable part of the system which
encloses the implementation and exposes a set of interfaces.
 Three important views of component:
1) An Object-Oriented View
2) The Traditional View
3) A Process-Related View
1) An Object-Oriented View
 Object-Oriented View component contains a set of collaborating classes.
 Each class within a component has been fully elaborated to include all attributes
and operations that are relevant to its implementation.
 As part of the design elaboration, all interfaces that enable the classes to
communicate and collaborate with other design classes must also be defined.
 To achieve object-oriented design it elaborates analysis classes and the
infrastructure classes.
2) The Traditional View
 Traditional View component is a functional element of a program that
incorporates processing logic, the internal data structures that are required to
implement the processing logic, and an interface that enables the component to
be invoked and data to be passed to it.
 A traditional component, also called a module, resides within the software
architecture and serves one of three important roles:
 (1) A control component that coordinates the invocation of all other problem
domain components
 (2) A problem domain component that implements a complete or partial function
that is required by the customer
 (3) an infrastructure component that is responsible for functions that support the
processing required in the problem domain.
3) A Process-Related View:
 The process-related view uses pre-existed modules for the creation of new
modules.
 Databases and libraries are used to store pre-existed modules.
 The process-related view majorly focuses on the reusability feature of the
component design.
Software Design Interface
 User interface is the front-end application view to which user interacts in order
to use the software.
 User can manipulate and control the software as well as hardware by means of
user interface.
 There are two types of User Interface:
1) Command Line Interface
2) Graphical User Interface
User Interface Design Process
 user interface analysis and design process begins at the interior of the spiral and
encompasses four distinct framework activities:
(1) interface analysis and modelling
(2) interface design
(3) interface construction
(4) interface validation
1) Interface analysis and modelling
 Interface analysis focuses on the profile of the users who will interact with the
system.
 Skill level, business understanding, and general receptiveness to the new system
are recorded and different user categories are defined.
 Once general requirements have been defined, a more detailed task analysis is
conducted.
 Those tasks that the user performs to accomplish the goals of the system are
identified, described, and elaborated.
2) Interface design
 The goal of interface design is to define a set of interface objects and actions that
enable a user to perform all defined tasks in a manner that meets every usability
goal defined for the system.
3) interface construction:
 Interface construction normally begins with the creation of a prototype that
enables usage scenarios to be evaluated.
 As the iterative design process continues, a user interface tool kit may be used to
complete the construction of the interface.
4) interface validation:
 Interface validation focuses on
 (1) the ability of the interface to implement every user task correctly, to
accommodate all task variations, and to achieve all general user requirements
 (2) the degree to which the interface is easy to use and easy to learn
 (3) the users’ acceptance of the interface as a useful tool in their work
What is Requirements?
 A requirement is a specification of need or want.
 Sets of requirements are used to capture the information needed to design,
build, and test a process, service, product, or system.

Types of Requirements:
1) Business Requirements
2) User Requirements
3) System Requirements
Business Requirements:

 Business requirements are high-level descriptions of what the organization wants to

achieve with the software.
 They are often broad and focused on the business goals and objectives.
 Business Goals: Increase customer satisfaction, reduce costs, and improve
operational efficiency.
 Stakeholder Needs: Needs and expectations of stakeholders such as customers,
employees, or partners.
 Market Requirements: How the software will help the organization compete in the
market.
 Compliance Requirements: Adherence to regulatory or industry standards.
2) System Requirements:

 It describes the technical specifications and conditions that the system must meet.
 It is usually more detailed:
 Hardware Requirements
 Specific hardware configuration needed to run the system
 Software Requirements
 Required operating systems, software libraries, or framework
 Performance Requirements
 Response times, throughput, and other performance metrics
 Security Requirements
 Authentication, Authorization, encryption and other security measures
 Integration Requirements
 How the system will interact with other systems or APIs
 Functional Requirements
 Specific functionalities that system must perform
3) User Requirements:
 User requirements focus on the needs and expectations of the end-users who
will interact with the system.
 These requirements are typically more user-centered:
 User Stories/Use Cases: Descriptions of how users will interact with the system
to achieve their goals.
 User Interface Requirements: Specifications for the look and feel of the user
interface.
 Usability Requirements: Ease of use, accessibility, and overall user experience
 Functional Requirements: Specific tasks or functions that users need to
perform.
Key differences

 Focus:
• System Requirements: Technical and implementation-focused.
• Business Requirements: Business objectives and high-level goals.
• User Requirements: End-user needs and interaction with the system.
 Detail Level:
 System Requirements: Highly detailed and specific.
 Business Requirements: Broad and general.
 User Requirements: Detailed in terms of user interaction but not
necessarily technical.
Key differences

 Stakeholders:
 System Requirements: Typically involve developers, system
architects, and IT professionals.
 Business Requirements: Involve business analysts, executives, and
other business stakeholders.
 User Requirements: Involve end-users, product managers, and user
experience designers.
Test Level
 Software testing is generally carried out at different levels. There are four such
levels namely unit testing, integration testing, system testing and acceptance
testing.
 The first three levels of testing activities are done by the testers and the last level
of testing is done by the customer/user.
 Each level has specific testing objectives.
1) Unit Testing:
 We develop software in parts / units and every unit is expected to have a defined
functionality. We may call it a component, module, procedure, function, etc., which
will have a purpose and may be developed independently and simultaneously.
 A unit is the smallest testable piece of software, which may consist of hundreds or
even just few lines of source code, and generally represents the result of the work of
one or few developers.
 individual units or components of a software application are tested to ensure they
behave as expected.
 To perform this kind of testing, knowledge of programming is necessary. So only
programmers do this kind of test, not testers.
 The primary objective of executing the unit testing is to confirm the unit components
with their performance.
Example:
 In a program we are checking if the loop, method, or function is working fine.
Cont..

 Purpose: It helps validate the smallest testable parts (units) of an

application to ensure they work as intended.
 Isolation: Units are tested in isolation from the rest of the codebase,
often using mock objects to simulate dependencies.
 Frameworks: There are various unit testing frameworks depending on
the programming language, such as JUnit for Java, pytest for Python,
NUnit for .NET, etc.

 Unit testing helps improve code quality, facilitates code refactoring, and
enhances overall software maintainability.
2) Integration Testing
 Integration testing is testing in which a group of components is combined to
produce output.
 The purpose of integration testing is to verify that the units function correctly
together as integrated components or subsystems of the larger system.
 The focus of the integration testing level is to expose defects at the time of
interaction between integrated components or units.
 We combine two or more units because they share some relationship. This
relationship is represented by an interface and is known as coupling.
 The coupling is the measure of the degree of interdependence between
units.
 Two units with high coupling are strongly connected and thus, dependent on
each other.
 Two units with low coupling are weakly connected and thus have low
dependency on each other.
Cont..

 Coupling increases as the number of calls amongst units increases or the amount of
shared data increases.
 A design with high coupling may have more errors.
Types of Integration Testing
1)Top-Down approach
2) Bottom-Up approach
3) Incremental approach
4) Big- Bang approach
5) Sandwich approach
Top-Down Integration

 It starts from the main unit and keeps on adding all called units of the
next level.
 After completion of integration testing at this level, add the next level of
units and so on till we reach the lowest level units leaf units)
Bottom-Up Integration

 In bottom-up integration, we start from the bottom, (i.e. from leaf units)
and keep on adding upper level units till we reach the top (i.e. root
node).
Sandwich Approach

 A sandwich strategy runs from top and bottom concurrently, depending

upon the availability of units and may meet somewhere in the middle.
 In practice, sandwich integration approach is more popular. This can be
started as and when two related units are available. We may use any
functional or structural testing techniques to design test cases.
Cont..

 Scope: It focuses on testing the interactions between integrated

units/modules rather than testing them in isolation.
 Purpose: To detect defects in the interfaces and interactions between
integrated components/modules. It ensures that integrated units work
together as expected, handle data transfers correctly, and maintain proper
communication.
 Tools and Techniques: Automated testing tools and frameworks are often
used to facilitate integration testing, especially for complex systems where
manual testing would be impractical.

 Integration testing helps ensure that the integrated components of a system

function correctly together, reducing the risk of issues when deploying the
software.
3) System Testing:
 When we are done with the unit and integration testing, we can proceed with the system testing.
 System testing is a level of software testing that evaluates the complete and integrated software
product. It is conducted on a complete, integrated system to evaluate its compliance with specified
requirements.
 To check the end-to-end flow of an application or the software as a user is known as System
testing.
 In this testing only focus on the required input and output without focusing on internal working.
 System testing involve testing the whole system. All of the modules/components are linked
together to see whether the system performs as planned.
 it also tests for non-functional requirements like performance, security, reliability, stress, load, etc.
This is the only phase of testing which tests both functional and non-functional requirements of
the system. A team of the testing persons does the system testing under the supervision of a test
team leader.
Types of System testing
1) Functional Testing
2) Non- Functional Testing
Cont..

 Utmost care should be taken for the defects found during the system
testing phase. A proper impact analysis should be done before fixing the
defect.
 Sometimes, if the system permits, instead of fixing the defects, they are
just documented and mentioned as the known limitations.
 This may happen in a situation when fixing is very time consuming or
technically it is not possible in the present design, etc.
 After the completion of this phase, customers are invited to test the
software.
Cont..

 Scope: System testing tests the entire software system as a whole to

ensure that it meets its functional and non-functional requirements. It
focuses on validating the overall behavior of the system in its intended
environment.
 Objectives: The primary objectives of system testing include:
• Verifying that the system meets its specified requirements and performs
as expected.
• Testing functional and non-functional aspects such as usability,
performance, reliability, security, and compatibility.
• Identifying defects or issues that may exist in the integrated system.
4) Acceptance Testing
 The testing done for the purpose of accepting a product is known as acceptance
testing.
 Acceptance testing, a testing technique performed to determine whether or not the
software system has met the requirement specifications.
 Acceptance testing is done by the customer for their satisfaction, and check whether
the application is working according to given business scenarios, real-time scenarios.
 UAT(User Acceptance Testing) is done in the final phase of testing after Unit,
integration and system testing is done.
 The main Purpose of UAT is to validate end to end business flow.
Types of Acceptance testing:
1) User Acceptance Testing (UAT)
2) Business Acceptance Testing (BAT)
3) Contract Acceptance Testing (CAT)
4) Alpha Testing
5) Beta Testing
Cont..

 Beta testing is done by many potential customers at their sites without

any involvement of developers / testers.
 However, alpha testing is done by some potential customers at the
developer’s site under the direction and supervision of developers
testers.
Test Suit
 A set of test cases is called a test suite.
 A test suite in software testing is a collection of test cases that are designed
to validate that a software program performs as expected.
 A test suite for all successful and unsuccessful test cases.
 All test suites should be preserved as we preserve source code and other
documents.
 They are equally valuable and useful for the purpose of maintenance of the
software.
Components of a Test Suit

 Test Cases:
 Individual scenarios that check specific functionality or features of the
software. Each test case includes:
 Test data: The input data for the test.
 Pre-conditions: Conditions that must be met before the test can run.
 Expected results: The expected output or behavior of the software.
 Post-conditions: Conditions that should be met after the test runs.

 Test Scripts:
 Automated scripts that execute test cases. They are particularly useful for
regression testing and large projects where manual testing is time-consuming.
Cont..

 Test Data:
 The specific inputs used for running the tests. This data can be static or
dynamically generated.
 Configuration Files:
 Files that set up the environment and parameters needed for the tests.
Types of Test Suites

 Smoke Test Suite:

 A subset of test cases that cover the most important functionality.
 It's a quick check to see if the major features are working before proceeding
with more detailed testing.
 Regression Test Suite:
 Ensures that new code changes don't negatively affect the existing
functionality. This suite includes all the test cases that have previously passed
to confirm they still work after changes.
 Functional Test Suite:
 Focuses on testing specific functionalities of the software to ensure they work
according to requirements.
Types of Test Suites

 Integration Test Suite:

 Verifies that different modules or services within the application work together
as expected.
 Performance Test Suite:
 Tests the performance aspects such as load, stress, and scalability of the
application.
 Acceptance Test Suite:
 Ensures the software meets business requirements and is ready for
production.
Building a Test Suite

 Identify Test Requirements:

 Determine what needs to be tested based on requirements, specifications,
and user stories.
 Design Test Cases:
 Create detailed test cases that include the input data, execution steps, and
expected results.
 Organize Test Cases:
 Group test cases into suites based on functionality, modules, or testing type
(e.g., smoke, regression).
 Automate Test Cases:
 Where possible, automate test cases to increase efficiency and repeatability.
Building a Test Suite

 Execute Test Suite:

 Run the test suite in the appropriate environment. Use test management tools
to track execution and results.
 Analyse Results:
 Review the results to identify defects or areas for improvement.
 Maintain Test Suite:
 Regularly update the test suite to reflect changes in the application, add new
test cases for new features, and remove outdated ones.
Tools for Managing Test Suites

 Test Management Tools:

 Tools like TestRail, Zephyr, and qTest help manage test cases, test suites, and
track testing progress.
 Automation Frameworks:
 Tools like Selenium, JUnit, TestNG, and Robot Framework help automate the
execution of test cases.
 Continuous Integration Tools:
 Tools like Jenkins, Bamboo, and GitLab CI/CD automate the execution of test
suites as part of the build process.
Preparation of test Suit
 There are three way to prepare test suit
1) Static test suite: Collection of Scenarios is manually selected from the Universe.

2) Filter based suite: You specify which scenarios to be selected based on a set of
Scenario custom field filters or tag based filters.

3) Requirements based suite: You specify a set of Requirements based on which, the
required Scenarios are pooled from traceability information in the Universe.
Selection of test suit
1) Select All Test Suit
 This is the simplest technique where we do not want to take any risk. We want to
run all test suit for any change in the program.

2) Select Test Cases Randomly

 We may select test cases randomly to reduce the size of the test suite.
 We decide how many test cases are required to be selected depending upon time
and available resources.

3) Select Modification Traversing Test Cases

 We select only those test cases that execute the modified portion of the program and
the portion which is affected by the modification(s).
Test Principles
 There are seven principles in software testing:

1. Testing shows the presence of defects

2. Exhaustive testing is not possible
3. Early testing
4. Defect clustering
5. Pesticide paradox
6. Testing is context-dependent
7. Absence of errors fallacy
1) Testing shows the presence of defects:
 Testing can show that defects are present, but it cannot prove that there are no
defects. Even after thorough testing, defects might still not be found.

2) Exhaustive testing is not possible:

 It is the process of testing the functionality of the software in all possible inputs
(valid or invalid) and pre-conditions is known as exhaustive testing.
 Exhaustive testing is impossible means the software can never test at every test
case.

3) Early testing:
 To find the defect in the software, early test activity shall be started. The defect
detected in the early phases of SDLC will be very less expensive.
4) Defect clustering:
 A small number of modules usually contain most of the defects detected. We have
various reasons for this, such as the modules could be complicated; the coding part
may be complex, and so on.

5) Pesticide paradox:
 Repeating the same test cases, again and again, will not find new bugs.
 So it is necessary to review the test cases and add or update test cases to find new
bugs.

6) Testing is context-dependent:
 The testing approach depends on the context of the software developed. Different
types of software need to perform different types of testing.
7) Absence of errors fallacy:
 If a built software is 99% bug-free but it does not follow the user requirement then it
is unusable. It is not only necessary that software is 99% bug-free but it is also
mandatory to fulfil all the customer requirements.