CIT333 :SOFTWARE ENGINEERING

BY
Dr. S.A. ADEPOJU
Department of Computer Science
Federal University of Technology
Minna

1
 MODULE 3: IMPLEMENTATION AND TESTING

Unit 1 Implementation
Unit 2 Testing Phase
Unit 3 Software Quality Assurance
Unit 4 Compatibility
Unit 5 Verification and Validation

2
 UNIT 1: IMPLEMENTATION

The implementation phase concerns with issues of quality, performance, baselines,

libraries, and debugging. The end deliverable is the product itself.

It is the process of translating design documentation and specifications into a working

software product

It represents a critical phase in the software development lifecycle, where theoretical

designs are transformed into functional software systems.

It is a stage where concepts meet reality, and developers' visions become tangible
solutions.
The deliverable at implementation stage are code and critical error removal

3
 TYPES OF ERRORS
• Critical errors
• Non-critical errors
Unknown errors

A critical error prevents the system from fully satisfying its usage. The errors have to be
corrected before the system can be given to a customer or even before future
development can progress.

A non-critical error is known but the occurrence of the error does not notably affect the
system's expected quality. There may indeed be many known errors in the system. They
are usually listed in the release notes and have well established work around.

Actually, the system is likely to have many, yet-to-be-discovered errors. The outcome of
these errors is unknown. Some may become critical while some may be simply fixed by
patches or fixed in the next release of the system

4
 Six sigma
By applying Six Sigma to software development, teams use data to identify and
eliminate defects in the software, reduce variation in the development process, and
improve the overall efficiency and effectiveness of the process

A summary of Six Sigma can be found in Natasha Baker‘s ―Key Concepts of Six
Sigma. The technique consists of five steps:
• Define- Involve defining the goal, projects and deliverables of the implementation-
must be measurable.
• Measure- Goals and implementation must be usable with metrics
• Analyze
• Improve
• Control

5
 Six sigma
Define: Project goals, scope, and customer requirements are clearly defined. This involves
understanding the software's purpose, target users, functionalities, and performance expectations.
Stakeholder input is gathered to establish clear project objectives and success criteria.
Measure: This involves collecting and analyzing data related to software performance, quality
metrics, and user feedback. Key performance indicators (KPIs) such as defect rates, cycle times,
and customer satisfaction scores are measured to assess current performance levels and identify
areas for improvement.
Analyze: Data analysis techniques such as root cause analysis, process mapping, and statistical
analysis are used to identify root causes of defects, inefficiencies, and bottlenecks in the software
implementation process. This phase aims to pinpoint the underlying issues that contribute to
software errors or delays.
Improve: Here. improvement strategies and solutions are implemented to address identified issues
and optimize the software implementation process. This may involve redesigning workflows,
automating repetitive tasks, standardizing coding practices, or enhancing testing procedures.
Control: This focuses on sustaining improvements and preventing regression. Control measures
such as implementing quality control checkpoints, establishing performance monitoring
mechanisms, and providing ongoing training and support are put in place to ensure that the
software implementation process remains efficient and effective over time. 6
By applying Six Sigma Software Implementation techniques, organizations can achieve
several benefits, including:

• Reduced defects and errors in software

• Improved software quality and reliability
• Faster delivery times and reduced cycle times
• Enhanced customer satisfaction and user experience
• Increased efficiency and productivity in software development processes
• Better alignment of software solutions with business goals and customer needs

7
 Major Tasks in Implementation

• Providing overall planning and coordination for the implementation

• Providing appropriate training for personnel
• Ensuring that all manuals applicable to the implementation effort are available when
needed
• Providing all needed technical assistance
• Scheduling any special computer processing required for the implementation
• Performing site surveys before implementation
• Ensuring that all prerequisites have been fulfilled before the implementation date
• Providing personnel for the implementation team Acquiring special hardware or
software
• Performing data conversion before loading data into the system
• Preparing site facilities for implementation
8
 Major Requirement in Implementation

Security: If suitable for the system to be implemented, there is need to include an overview of the system
security features and requirements during the implementation. This include system security features and security
during implementation.

System Security Features:

Security during Implementation

9
 Implementation support
This include supports such as: software, materials, equipment, and facilities
necessary for the implementation, as well as the personnel requirements and
training essential for the implementation.

Hardware: This section offers a list of support equipment and includes all
hardware used for testing time implementation
Software: This section provides a list of software and databases required to
support the implementation. Identify the software by name, code, or acronym.
Identify which software is commercial off-the-shelf and which is State-specific
Facilities: This section identifies the physical facilities and accommodations
required during implementation. Examples include physical workspace for
assembling and testing hardware components, desk space for software installers,
and classroom space for training the implementation stall
Materials: This section provides a list of required support materials, such as
magnetic tapes and disk packs
10
 Personnel
This include supports such as: software, materials, equipment, and facilities
necessary for the implementation, as well as the personnel requirements and training
essential for the implementation.

Personnel Requirements and Staffing

Training of Implementation Staff

Performance Monitoring
This section describes the performance monitoring tool and techniques and how it
will be used to help decide if the implementation is successful.
Configuration Management Interface
This section describes the interactions required with the Configuration Management
(CM) representative on CM-related issues, such as when software listings will be
distributed, and how to confirm that libraries have been moved from the development
to the production environment. 11
 Implementation Requirements by Site
This section describes the performance monitoring. tool and techniques and how it will be used to help
decide if the implementation is successful.

Site Name or identification for Site X

This section provides the name of the specific site or sites to be discussed in the
subsequent sections.

Site Requirements
This section defines the requirements that must he met for the orderly implementation of the system and
describes the hardware, software, and site specific facilities requirements for this area:
• Hardware Requirements - Describe the site-specific hardware requirements necessary to support the
implementation (such as. LAN hardware for a client/server database designed to run on a LAN).
• Software Requirements - Describe any software required to implement the system (such as, software
specifically designed for automating the installation process).
• Data Requirements - Describe specific data preparation requirements and data that must be
available for the system implementation. An example would be the assignment of individual IDs
associated with data preparation
• Facilities Requirements - Describe the site-specific physical facilities and accommodations required
during the system implementation period 12
Site implementation details

This section addresses the specifics of the implementation for this site. Include a
description of the implementation team.

Schedule,
Procedures
Database
Data Updates.

Back-Off Plan
This section specifies when to make the go/no go decision and the factors to be
included in making the decision. The plan then goes on to provide a detailed list of steps
and actions required to restore the site to the original, pre-conversion condition

13
 Post-Implementation Verification

This section describes the process for reviewing the implementation and deciding if it
was successful. It describes how an action item list will be created to rectify any noted
discrepancies

Activity Explain the Major Requirement in Implementation

14
 UNIT 2: TESTING
Software testing is an empirical examination carried out to provide stakeholders with
information about the quality of the product or service under test.
Also be viewed as the process of validating and verifying that a software
program/application/product
• Meets the business and technical requirements that guided its design and
development
• Works as expected
• Can be implemented with the same characteristics

The process of attempting to make this assessment whether the software product will be
satisfactory to its end users, its target audience, its purchasers, and other stakeholders.

Software testing, can be applied at any time in the development process, though
most of the test effort occurs after the requirements have been defined and the
coding process has been completed 15
 TESTING METHODS
software testing methods are divided into black box testing ,white box testing and Grey Box
Testing

BLACK BOX TESTING: considers the software as a "black box" in the sense that there is no
knowledge of internal implementation. Black box testing methods include: equivalence
partitioning, boundary value analysis, all-pairs testing, fuzz testing, model-based testing,
traceability matrix, exploratory testing and specification-based testing.

WHITE BOX TESTING: the tester has the privilege to the internal data structures and algorithms
including the code that implement these: White box testing is of different types namely API
testing (application programming interface) - Testing of the application using Public and Private
APIs

 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
 Mutation testing methods
16
 Static testing - White box testing includes all static testing
 TESTING METHODS

GREY BOX TESTING requires gaining access to internal data structures and
algorithms for purposes of designing the test cases, but testing at the user, or black-
box level

17
 TESTING METHODS
Black box testing is a testing technique that examines the software's functionality
without considering its internal code structure, design, or implementation details.
Testers assess the software's behavior based on input-output relationships and test
cases derived from functional requirements, specifications, and user scenarios.

White box testing, also known as structural testing or glass box testing, is a testing
technique that examines the software's internal code structure, logic, and
implementation details. Testers have access to the source code and knowledge of
the software's internal workings, allowing them to design test cases based on code
paths, branches, conditions, and algorithms.

Grey box testing is a hybrid testing approach that combines elements of both black
box and white box testing. Testers have limited knowledge of the software's internal
code structure and implementation details, allowing them to design test cases based
on a combination of functional requirements and code insights.
18
Integration testing is any type of software testing that seeks to reveal clash of individual
software modules to each other. Such integration flaws can result, when the new
modules are developed in separate branches, and then integrated into the main project.

Regression testing is any type of software testing that attempts to reveal software
regressions. Regression of the nature can occurs at any time software functionality, that
was previously working correctly, stops working as anticipated.

Acceptance testing is evaluated to determine whether it meets the specified

requirements and is ready for deployment to end users. This type of testing focuses on
validating the software's functionality, usability, performance, and compliance with
business needs and user expectations. It can broadly be categorized into two main types:

User Acceptance Testing (UAT) is performed by end users or stakeholders who will use
the software in real-world scenarios.

Business Acceptance Testing (BAT) focuses on verifying that the software aligns with the
organization's business objectives, processes, and requirements. 19
Destructive testing Destructive testing attempts to cause the software or a sub-system
to fail, in order to test its robustness

20
 FUNCTIONAL TESTING

This is a type of testing that evaluates the software's functionality by testing individual
features, functions, and behaviors against specified requirements. Functional testing
involves creating test cases based on functional requirements and executing these test
cases to validate that the software's features and functions work correctly, produce the
expected outputs, and handle various inputs and conditions.

Types of Functional Testing: Examples of functional testing include unit testing,

integration testing, system testing, regression testing, and user acceptance testing
(UAT). Each type of functional testing focuses on different levels and aspects of the
software's functionality.

21
 NON-FUNCTIONAL TESTING
Definition: Non-functional testing is a type of testing that evaluates the software's non-
functional attributes or quality characteristics, such as performance, reliability, usability,
security, scalability, and compatibility.
Non-functional testing involves creating test cases, scenarios, or simulations that
assess the software's performance under load, its responsiveness, its security
vulnerabilities, its compatibility with different platforms or devices, and its ability to
handle stress or peak loads.
Types of Non-Functional Testing: Examples of non-functional testing include
performance testing (load testing, stress testing, scalability testing), usability testing,
security testing, compatibility testing, reliability testing, and maintainability testing. Each
type of non-functional testing focuses on evaluating specific non-functional attributes of
the software.

22
Functional testing verifies that the software's features and functions work correctly
according to specified requirements, while non-functional testing assesses the
software's performance, usability, security, and other quality characteristics that
contribute to the overall user experience and system reliability.

23
Testing process
Testing process can take two forms: Usually the testing can be performed by an independent
group of testers after the functionality is developed before it is sent to the customer

Testing can be done on the following levels:

• Unit testing tests the minimal software component, or module. Each unit (basic
component) of the software is tested to verify that the detailed design for the unit has
been correctly implemented.

• Integration testing exposes defects in the interfaces and interaction between integrated
components (modules). Progressively larger groups of tested software components
corresponding to elements of the architectural design are integrated and tested until the
software works as a system.

• System testing tests a completely integrated system to verify that it meets its
requirements.

• System integration testing verifies that a system is integrated to any external or third party
systems defined in the system requirements
24
Alpha testing is simulated or actual operational testing by potential users/customers or
an independent test team at the developers' site. Alpha testing is often employed for
off-the-shelf software as a form of internal acceptance testing, before the software goes
to beta testing.
Alpha testing is a type of testing conducted by the internal development team or a
dedicated QA team within the organization before the software is released to external
users.

Beta testing comes after alpha testing. Versions of the software, known as beta
versions, are released to a limited audience outside of the programming team. The
software is released to groups of people so that further testing can ensure the product
has few faults or bugs. Sometimes, beta versions are made available to the open public
to increase the feedback field to a maximal number of future users.
Beta testing is a type of testing conducted by external users or a selected group of
customers in a real-world environment before the software is officially launched or
released to the general public.
25
Testing Tools

Program testing and fault detection can be aided significantly by testing tools and
debuggers. Testing/debug tools include features such as:
• Program monitors, permitting full or partial monitoring of program code
Including
• Formatted dump or Symbolic debugging, tools allowing inspection of program
variables on error or at chosen points
• Automated functional GUI testing tools are used to repeat system-level tests
through the GUI
• Benchmarks, allowing run-time performance comparisons to be made
• Performance analysis (or profiling tools) that can help to highlight hot spots and
resource usage

26
 Unit 3: SOFTWARE QUALITY ASSURANCE (SQA)

• Software Quality Assurance (SQA) is defined as a planned and systematic

approach to the evaluation of the quality of and adherence to software product
standards, processes, and procedures.

• It is is a process that assures that all software engineering processes, methods,

activities, and work items are monitored and comply with the defined standards.
These defined standards could be one or a combination of anything like ISO 9000,
CMMI model, ISO15504, etc

• SQA includes the process of assuring that standards and procedures are
established and are followed throughout the software acquisition life Cycle.

• SQA incorporates all software development processes starting from defining

requirements to coding until release. Its prime goal is to ensure quality.
27
 Unit 3: SOFTWARE QUALITY ASSURANCE (SQA)

• Testing software to ensure it is free of bugs and defects.

• Writing clear and concise documentation that users can understand.
• Conducting user testing to ensure that the software is user-friendly.

28
 Standards and Procedures
Standards are the established yardsticks to which the software products are
compared.
Procedures are the established criteria to which the development and control
processes are compared.
Types of standards
 Documentation Standards specify form and content for planning, control, and
product documentation and provide consistency throughout a project.

 Design Standards specify the form and content of the design product. They
provide rules and methods for translating the software requirements into the
software design and for representing it in the design documentation.

 Code Standards specify the language in which the code is to be written and define
any restrictions on use of language features. They define legal language
structures, style conventions, rules for data structures and interfaces, and internal
code documentation.
29
 Procedures

Procedures are explicit steps to be followed in carrying out a process. All processes
should have documented procedures. Examples of processes for which procedures
are needed are configuration management, non-conformance reporting and
corrective action, testing, and formal inspections..

30
 Software Quality Assurance Activities

Product evaluation and process monitoring are the SQA activities that assure the
software development and control processes described in the project's Management
Plan are correctly carried out and that the project's procedures and standards are
followed

Product evaluation is an SQA activity that assures standards are being followed.
Ideally, the first products monitored by SQA should be the project's standards and
procedures. SQA assures that clear and achievable standards exist and then
evaluates compliance of the software product to the established standards.

Process monitoring is an SQA activity that ensures that appropriate steps to carry
out the process are being followed. SQA monitors processes by comparing the
actual steps carried out with those in the documented procedures

31
A fundamental SQA technique is the audit, which looks at a process and/or a
product in depth, comparing them to established procedures and standards. Audits
are used to review management, technical, and assurance processes to provide an
indication of the quality and status of the software product.

The purpose of an SQA audit is to assure that proper control procedures are being
followed, that required documentation is maintained, and that the developer's status
reports accurately reflect the status of the activity

32
 SQA Relationships to Other Assurance Activities

• Configuration Management Monitoring: SQA assures that software Configuration

Management (CM) activities are performed in accordance with the CM plans,
standards, and procedures. SQA reviews the CM plans for compliance with
software CM policies and requirements and provides follow-up for non
conformances

• Verification and Validation Monitoring SQA assures Verification and Validation

(V&V) activities by monitoring technical reviews, inspections, and walkthroughs.
The SQA role in formal testing is described in the next section

• Formal Test Monitoring : SQA assures that formal software testing, such as
Acceptance testing, is done in accordance with plans and procedures. SQA
reviews testing documentation for completeness and adherence to standards.

33
 SQA Relationships to Other Assurance Activities

SQA takes place at

• Software Concept and Initiation Phase
• Software Requirements Phase
• Software Architectural (Preliminary) Design Phase
• Software Detailed Design Phase
• Software Implementation Phase
• Software Integration and Test Phase
• Software Acceptance and Delivery Phase
• Software Sustaining Engineering and Operations Phase

34
 Techniques and Tools
SQA should evaluate its needs for assurance tools versus those available off-the-shelf for applicability
to the specific project, and must develop the others it requires. Useful tools might include audit and
inspection checklists and automatic code standards analyzers.

Test Management Tools: These tools help organize and manage testing processes, including test
case creation, execution, tracking, and reporting

Automated Testing Tools: Automated testing tools play a crucial role in CI/CD pipelines, allowing
teams to execute tests automatically, ensuring that new changes do not break existing functionality.

Static Analysis Tools: These tools analyze source code before it is run to find potential security
vulnerabilities, bugs, and other code quality issues.

Performance Testing Tools: These tools are used to simulate user access to applications in order to
understand the behavior of the application under different load conditions.
Code Coverage Tools: These tools measure the extent to which the source code of a program is
executed during a test, which helps in understanding the areas of a program not exercised by a set of
test cases.
Issue Tracking and Collaboration Tools :Effective SQA requires constant communication and
collaboration, especially when issues need to be tracked and resolved systematically 35
 Software Quality Assurance Components
Test Planning and Strategy: Test planning and strategy involve creating a comprehensive roadmap for testing
activities. It includes defining test objectives, identifying test deliverables, determining test approaches, and
allocating resources

Test Design and Execution: Involve creating and executing test cases for the software. This component focuses
on designing test scenarios and creating detailed test cases that cover various aspects of the software’s
functionality. Test execution involves running these test cases, capturing results, and verifying that the software
behaves as expected.

Defect Management: Defect management is identifying, documenting, and tracking software defects or issues. It
involves capturing detailed information about each defect, prioritizing them based on severity, and facilitating
resolution. Defect management ensures that identified issues are properly addressed, allowing for the delivery of
a high-quality, bug-free software product.

Configuration Management: manages and controls software configuration elements changes throughout the
development lifecycle. It includes version control, change management, and guaranteeing the software’s integrity
and consistency. It helps maintain a stable and regulated environment, reducing risks associated with incorrect or
unauthorized modifications.

Metrics and Reporting: involve gathering and analyzing important data during testing to draw useful insights.
These metrics include test coverage, defect density, test execution progress, and other performance metrics.
They provide visibility into the software’s quality, allowing for informed decision-making and continual
development. 36
 UNIT 4
COMPATIBILITY TESTING

Compatibility testing is a type of testing that examines and compares functionality over multiple
browsers, devices, platforms, and OS to recognize potential discrepancies. Performing
compatibility testing verifies that your product/software works efficiently in its intended
environments
Why should you perform Compatibility Testing?
• A compatibility test is conducted to ensure that the concerned application can fulfill
expectations concerned with various devices-browser-OS combinations.
• Check application compatibility with networks, databases, browsers, hardware, devices,
operating systems, etc.
• The better way to analyze application behavior when placed in varied environments
• Robust compatibility testing highlights workability and security features to enhance application
performance.
• A convenient method to recognize bugs before the final product launch
• Delivery of error-free software apps that can guarantee success for your business

Compatibility testing can be automated using automation tools or can be performed manually and is a
part of non-functional software testing.
37
 Benefits of Compatibility Testing

• Improves Software Development Process: Compatibility test estimates the issues in the
software in the SDLC itself. But, it becomes easier to verify the app’s usability, scalability,
and stability across various platforms and deliver feedback.
• Detects Bugs before Production: A compatibility test is effective in the timely detection of
bugs in web and mobile apps, even in tricky areas. Since errors are recognized before
production.
• Complete User Satisfaction: By utilizing compatibility tests, you ensure that every portion
of your product is up and performing as it should across all software, browsers, and
devices.
• Successful Launches: One of the crucial advantages of compatibility testing, in
conjunction with other testing, is that it gives an entirely successful product launch!

38
 Types of Compatibility Testing

There are two distinct kinds of compatibility testing – backward compatibility testing and
forward compatibility testing.

• Backwards Compatibility Testing

This type of compatibility testing ensures that the latest versions of app work with older
software or hardware. The backwards compatibility test is crucial to offer a consistent user
experience to those consumers who could be using traditional devices that may be older
versions.

• Forward Compatibility Testing

This form of compatibility testing aims to set up the compatibility of the newest version of the
software with previous or existing devices. Depending on the advancements of the feature,
the app may become incompatible or inaccessible with traditional devices. Forward
compatibility testing is predictable as the modifications managed in the older versions are
better known.

39
Forward or backward compatibility tests have quite a few sub-categories:
• Software Testing: Software Testing ensures app compatibility with 3rd-party software
that the app will interact with.
• Device testing: Device testing makes certain that the app functions consistently with
each applicable device, such as Bluetooth devices, scanners, printers, tablets, mobile
devices, etc.
• Hardware tests: Hardware testing guarantees the app’s compatibility with all
hardware.
• Network testing: confirms the app can function with several networks of varying
bandwidths.
• Browser testing: Browser testing ensures that the app performs flawlessly across all
famous browsers.
• Version testing: Version testing confirms that the app remains compatible with earlier
versions.
• OS tests: OS testing ensures that the app is compatible with Linux, Mac, Windows, or
other different OSs.
• Mobile testing: Testing ensures the app is compatible with all mobile gadgets on iOS,
Android, and other mobile OS. 40
The compatibility testing procedure comprises four steps:

Design Test Cases & Configuration: In this phase, the QA team designs test cases and analyzes
the environments, hardware, software, and platforms to discover the behavior of the software.
Involving an expert team with skilled professionals could give a better understanding of compatibility
testing as they will quickly identify minor variations in output.

Set Up the Environment: In this phase, the QA engineers set up the platform or the test environment
where the app is expected to be validated and tested.

Testing Execution & Result Analysis: After setting up the platform or environment, the teams
implement the test cases and scrutinize the results. The test case results are examined, and the bugs
or defects/discrepancies are noted to submit to the stakeholders.

Validate and Retest: Once the outcome is generated and examined, the report is submitted for the
next level of scrutiny. Here, the recognized errors or defects are authenticated and resolved. Besides,
the developed software application will be re-tested and re-examined to ensure the software meets
the quality with no glitches and bugs before moving it to real production.

41
Types of Bugs in Software Compatibility Testing

• Usually, the compatibility bugs are UI (user interface) bugs like:

• Alteration in UI ( look & feel)
• Medication in a font size
• Alignment-related problems
• Change in color and CSS style
• Scroll bar-related problems
• Content or label overlapping
• Broken Frames or tables

42
Browser Stack Live: Use an industry-leading compatibility testing tool to test across new and
old versions of Edge, Safari, Chrome, IE, and Firefox on Windows and macOS. Also, run
your compatibility tests on various real Android and iOS devices for the most accurate test
results.

43
 UNIT 5: SYSTEM VERIFICATION AND VALIDATION

Verification and Validation is the process of investigating whether a software system satisfies
specifications and standards and fulfills the required purpose. Barry Boehm described
verification and validation as the following:

 Verification: Are we building the product right?

 Validation: Are we building the right product?

44
 Verification

Verification is the process of checking that software achieves its goal without any bugs. It is the
process to ensure whether the product that is developed is right or not. It verifies whether the
developed product fulfills the requirements that we have. Verification is simply known as Static
Testing.

Static Testing
Verification Testing is known as Static Testing and it can be simply termed as checking whether
we are developing the right product or not and also whether our software is fulfilling the
customer’s requirement or not.
Some of the activities that are involved in verification: Inspections, Reviews, Walkthroughs,
Desk-checking

45
 Validation

Validation is the process of checking whether the software product is up to the mark or in
other words product has high-level requirements. It is the process of checking the
validation of the product i.e. it checks what we are developing is the right product. it is a
validation of actual and expected products. Validation is simply known as Dynamic
Testing.
Dynamic Testing

Validation Testing is known as Dynamic Testing in which we examine whether we have

developed the product right or not and also about the business needs of the client. Here
are some of the activities that are involved in Validation.
[Link] Box Testing
[Link] Box Testing
[Link] Testing
[Link] Testing
46
47
Verification testing
Verification testing includes different activities such as business requirements, system
requirements, design review, and code walkthrough while developing a product.

It is also known as static testing, where we are ensuring that "we are developing the right
product or not". And it also checks that the developed application fulfilling all the
requirements given by the client.

Validation testing
Validation testing is testing where tester performed functional and non-functional testing.
Here functional testing includes Unit Testing (UT), Integration Testing (IT) and System
Testing (ST), and non-functional testing includes User acceptance testing (UAT).

Validation testing is also known as dynamic testing, where we are ensuring that "we have
developed the product right." And it also checks that the software meets the business needs
of the client.

48
Verification Validation
We check whether we are developing the right product We check whether the developed product is right.
or not.
Verification is also known as static testing. Validation is also known as dynamic testing.
Verification includes different methods like Inspections, Validation includes testing like functional testing,
Reviews, and Walkthroughs. system testing, integration, and User acceptance
testing.
It is a process of checking the work-products (not the It is a process of checking the software during or at the
final product) of a development cycle to decide end of the development cycle to decide whether the
whether the product meets the specified requirements. software follow the specified business requirements.

Quality assurance comes under verification testing. Quality control comes under validation testing.
The execution of code does not happen in the In validation testing, the execution of code happens.
verification testing.
In verification testing, we can find the bugs early in the In the validation testing, we can find those bugs, which
development phase of the product. are not caught in the verification process.
Verification testing is executed by the Quality Validation testing is executed by the testing team to
assurance team to make sure that the product is test the application.
developed according to customers' requirements.
Verification is done before the validation testing. After verification testing, validation testing takes place.

In this type of testing, we can verify that the inputs In this type of testing, we can validate that the user
follow the outputs or not. accepts the product or not.
49