UNIT -1

INTRODUCTION TO SOFTWARE TESTING

WHAT IS TESTING?

 Testing is an important element of development life cycle (SDLC)

 Testing is base for software quality control and software quality assurance process..

 testing includes two basic goals: validation and verification

 Validation: Are we building the right product?

 Verification: Does it meet its specification?
(Where it can be code, a model, a design diagram, a requirement etc…)
WHAT IS TESTING?

 Software testing is nothing but an art of investigating software to ensure that its quality under test is in line with
the requirement of the client.

 Software testing is carried out in a systematic manner with the intent of finding defects in a system.

 One small defect can cause a lot of financial loss.

 It is for this reason that software testing is now emerging as a very powerful field in IT.
WHY IS SOFTWARE TESTING IMPORTANT?

 The final step in the development of an application is software testing, where code is examined by asking
questions of it.
 This review can end quickly or continue until all parties involved are satisfied. Software testing finds defects and
problems early in the development cycle so that they can be repaired before the product is released.
 This strategy guarantees that clients receive only high-quality items, which improves customer happiness and
confidence.
 To understand the importance of software testing, consider the example of Starbucks. In 2015, the company lost
millions of dollars in sales when its point-of-sale (POS) platform shut down due to a faulty system refresh caused
by a software glitch.
 The following are important reasons why software testing techniques should be incorporated into
application development.
WHY IS SOFTWARE TESTING IMPORTANT?

• Defects can be identified early: Software testing is important because if there are any bugs they can be
identified early and can be fixed before the delivery of the software.
• Improves quality of software: Software Testing uncovers the defects in the software, and fixing them
improves the quality of the software.
• Increased customer satisfaction: Software testing ensures reliability, security, and high performance which
results in saving time, costs, and customer satisfaction.
• Helps with scalability: Software testing type non-functional testing helps to identify the scalability issues
and the point where an application might stop working.
• Saves time and money: After the application is launched it will be very difficult to trace and resolve the
issues, as performing this activity will incur more costs and time. Thus, it is better to conduct software testing
at regular intervals during software development.
V-MODEL

 The V-model is an SDLC model where execution of processes happens in a sequential manner in a V-shape.
 It is also known as Verification and Validation model.
 The V-Model is an extension of the waterfall model and is based on the association of a testing phase for each
corresponding development stage.
 This means that for every single phase in the development cycle, there is a directly associated testing phase.
 This is a Highly-disciplined model and the next phase starts only after completion of the previous phase.
 Under the V-Model, the corresponding testing phase of the development phase is planned in parallel. So, there are
Verification phases on one side of the ‘V’ and Validation phases on the other side. The Coding Phase joins the two
sides of the V-Model.
V-MODEL
V-MODEL - VERIFICATION PHASES

 There are several Verification phases in the V-Model, each of these are explained in detail
below.
 Business Requirement Analysis
 This is the first phase in the development cycle where the product requirements are understood from
the customer’s perspective.
 This phase involves detailed communication with the customer to understand his expectations and
exact requirement.
 This is a very important activity and needs to be managed well, as most of the customers are not sure
about what exactly they need.
 The acceptance test design planning is done at this stage as business requirements can be used as
an input for acceptance testing.
V-MODEL - VERIFICATION PHASES

 Module Design

 In this phase, the detailed internal design for all the system modules is specified, referred to as Low
Level Design (LLD). It is important that the design is compatible with the other modules in the
system architecture and the other external systems. The unit tests are an essential part of any
development process and helps eliminate the maximum faults and errors at a very early stage.
These unit tests can be designed at this stage based on the internal module designs.
V-MODEL - CODING PHASE

 The actual coding of the system modules designed in the design phase is taken up in the Coding phase.
 The best suitable programming language is decided based on the system and architectural requirements.
 The coding is performed based on the coding guidelines and standards.
V-MODEL - VALIDATION PHASES

The different Validation Phases in a V-Model are explained in detail below.

 Unit Testing
 Unit tests designed in the module design phase are executed on the code during this validation phase.
Unit testing is the testing at code level and helps eliminate bugs at an early stage, though all defects
cannot be uncovered by unit testing.
 Integration Testing
 Integration testing is associated with the architectural design phase. Integration tests are performed to
test the coexistence and communication of the internal modules within the system.
 System Testing
 System testing is directly associated with the system design phase. System tests check the entire system
functionality and the communication of the system under development with external systems. Most of
the software and hardware compatibility issues can be uncovered during this system test execution.
V-MODEL - VALIDATION PHASES

 Acceptance Testing

 Acceptance testing is associated with the business requirement analysis phase and involves testing
the product in user environment. Acceptance tests uncover the compatibility issues with the other
systems available in the user environment. It also discovers the non-functional issues such as load and
performance defects in the actual user environment.
 ADVANTAGES & DISADVANTAGES OF THE V-MODEL

Disadvantages of the V-Model

Advantages of the V-Model  High risk and uncertainty.
 This is a highly-disciplined model and Phases are  Not a good model for complex and object-oriented
completed one at a time. projects.
 Works well for smaller projects where requirements  Poor model for long and ongoing projects.
are very well understood.
 Not suitable for the projects where requirements are at
 Simple and easy to understand and use. a moderate to high risk of changing.
 Easy to manage due to the rigidity of the model. Each  Once an application is in the testing stage, it is difficult
phase has specific deliverables and a review process. to go back and change a functionality.
 No working software is produced until late during the
life cycle.
WHAT IS QUALITY

 Software Quality Assurance (SQA)

Quality  Software quality assurance (also called quality management) is
an umbrella activity that is applied throughout the software
Developed product meets it’s specification process
 Quality Management  It is planned and systematic pattern of activities necessary to
provide high degree of confidence in the quality
 Ensuring that required level of product quality is achieved  Software quality assurance (SQA) encompasses
Defining procedures and standards  An SQA process
Applying procedures and standards to the product and process  Specific quality assurance and quality control tasks
Checking that procedures are followed  Effective software engineering practice
Collecting and analyzing various quality data  Control of all software work products
 A procedure to ensure compliance with software
development standards
 Measurement and reporting mechanisms
SQA ACTIVITIES
QUALITY CONTROL

 Many people get confused between quality control (QC) and quality assurance (QA). Let's take a look at quality control function in high-
level.
 As we have already discussed, organizations can define their own internal quality standards, processes and procedures; the organization
will develop these over time and then relevant stakeholders will be required to adhere by them.
 The process of making sure that the stakeholders are adhered to the defined standards and procedures is called quality control. In
quality control, a verification process takes place.

 Certain activities and products are verified against a defined set of rules or standards.
 Every organization that practices QC needs to have a Quality Manual. The quality manual outlines the quality focus and the objectives in
the organization.
 The quality manual gives the quality guidance to different departments and functions.
 Therefore, everyone in the organization needs to be aware of his or her responsibilities mentioned in the quality manual.
DIFFERENCE BETWEEN QA & QC
Points Quality Assurance Quality Control
QA is a group of activities which ensures that the
QC is a group of activities to detect the
Definition quality of processes which is used during the
defects in the developed software.
development of the software always be maintained.
The focus of QC is to identify defects in the
The focus of QA is to prevent defects in the
Focus developed software by paying attention to
developing software by paying attention to processes.
testing processes.
Establishment of the high-quality management system Detecting and eliminating the quality problem
How and periodic audits for conformance of the elements by using testing techniques and tools
operations of the developing software. in the developed software.
QC ensures identification and elimination of
QA ensures prevention of quality problem elements
defects by using processes and techniques to
What by using systematic activities including
achieve and maintain high quality of the
documentation.
software.
DIFFERENCE BETWEEN QA & QC

Points Quality Assurance Quality Control

Orientation QA is process oriented. QC is product oriented.

QA is a proactive process. It concerns to QC is a reactive process because it concerns

Type of process improve development so; defects do not to identify defects after the development of
arise in the testing period. product and before its release.

Each and every member of the Only the specific testing team is responsible
Responsibility
development team is responsible for QA for QC

Example Verification is the example of QA Validation is the example of QC

SOFTWARE DEVELOPMENT LIFE CYCLE

 An effective Software Development Life Cycle (SDLC) should result in a high quality system that meets customer
expectations, reaches completion within time and cost evaluations, and works effectively and efficiently in the current
and planned Information Technology infrastructure.
 Software Development Life Cycle (SDLC) is used by analysts to develop an information system. SDLC includes the
following activities:
1. Requirement Gathering
2. Requirement Analysis OR Feasibility Study
3. Designing
4. Coding
5. Testing
6. Implementation OR Deployment
7. Maintenance
1. Requirement
Gathering
2.RequirementAnalysis
OR
Feasibility Study

3. Designing

4. Coding

5. Testing

6. Implementation
OR
Deployment

7. Maintenance
NEED FOR SDLC

 The development team must determine a suitable life cycle model for a particular plan and then observe to it.
 Without using an exact life cycle model, the development of a software product would not be in a systematic and
disciplined manner.
 When a team is developing a software product, there must be a clear understanding among team representative
about when and what to do. Otherwise, it would point to and project failure.
 Now Lets understand each phase mentioned above, in detail.
REQUIREMENT GATHERING

 A very first phase of SDLC and the important one is requirement gathering.
 In this step system analyst will collect all the requirement of new proposed system or from the existing
system for modification.
 It will collect all the information form the people involve with the system. .
 Though, it is the first phase for requirement gathering, so all the requirement gathered are feasible or not
will be analyzed in next phase that is Requirement analysis.
REQUIREMENT ANALYSIS
 Requirements analysis, also called requirements engineering, is the process of determining user expectations for a
new or modified product.
 These features, called requirements, must be quantifiable, relevant and detailed.
 In software engineering, such requirements are often called functional specifications. Requirements analysis is an
important aspect of project management.
 Feasibility Study - As name suggests feasibility study is the feasibility analysis or it is a measure of the software
product in terms of how much beneficial product development will be for the organization in a practical point of
view.
 Technical Feasibility – In Technical Feasibility current resources both hardware software along with required technology
are analyzed/assessed to develop project.
 This technical feasibility study gives report whether there exists correct required resources and technologies which will be
used for project development.
REQUIREMENT ANALYSIS
 It checks whether the existing computer system supports the candidate system or not or up to what extent it supports.
 It basically centers around Hardware, Software etc. For e.g. Current Computer is operating at 77 % capacity and running
another application can Overload the system so need new system.

Operational Feasibility – In Operational Feasibility degree of providing service to requirements is analyzed along with
how much easy product will be to operate and maintenance after deployment.

Economic Feasibility – In Economic Feasibility study cost and benefit of the project is analyzed.
Means under this feasibility study a detail analysis is carried out what will be cost of the project for development which
includes all required cost for final development like hardware and software resource required, design and development cost
and operational cost and so on.

Legal Feasibility – In Legal Feasibility study project is analyzed in legality point of view.
This includes analyzing barriers of legal implementation of project, data protection acts or social media laws, project
certificate, license, copyright etc.
Overall it can be said that Legal Feasibility Study is study to know if proposed project conform legal and ethical
requirements.
REQUIREMENT ANALYSIS

Schedule Feasibility – In Schedule Feasibility Study mainly timelines/deadlines is analyzed for proposed
project which includes how many times teams will take to complete final project which has a great impact on
the organization as purpose of project may fail if it can’t be completed on time

 As soon as the requirement analysis and the feasibility study is complete, next task is to form SRS (Software
Requirement Specification) is documented after all requirements are refined by eliminating unsuitable or not
feasible.
 After the requirement analysis phase is complete, we have all the requirement that is clearly defined, precise, and
no change in that is required in future.
 Now its time to process all the requirement defined in SRS document for the next phase which is the Design
phase.
REQUIREMENT ANALYSIS

 Economic: Can we complete the project within the budget or not?

 Legal: Can we handle this project as cyber law and other regulatory framework/compliances.
 Operation feasibility: Can we create operations which is expected by the client?
 Technical: Need to check whether the current computer system can support the software
 Schedule: Decide that the project can be completed within the given schedule or not.
DESIGNING

 Now, we have all the requirement that is clearly defined in SRS document. Its time to begin designing the
software.
 Remember that, Designing is the most crucial (“Nirnayak”) phase of the SDLC, in short one need to focus while
designing as a small change in design will affect in the each and every phase next.
 Designing involves, flowchart development, DFDs design, Algorithm design, Database design, ER-Diagram and
other designing related task etc.
 Hence, while designing keep reference of SRS document and concentrate on each requirement mentioned for
error free design.
 Once designing phase is complete next phase begins that is Coding phase.
CODING

 Once you have design ready, quick start to code according to the design provided by designing team.
 Coding is also known as programming phase or physical design, as it will be done according to the design and
make system functional.
 The implementation of software design starts in terms of writing program code in the suitable programming
language and developing error-free executable programs efficiently.
 Coders must follow the coding procedure defined by their organization and programming tools like compilers,
interpreters, debuggers, etc.
 Different high level programming languages like C, C++, Pascal, Java and PHP are used for coding.
TESTING

 This phase is usually a subset of all the phases as in the modern SDLC models, the testing activities are mostly
involved in all the phases of SDLC.
 However, this phase refers to the testing only phase of the product where product defects are reported, tracked,
fixed and retested, until the product reaches the quality standards defined in the SRS.
 There are different testing levels and method used test software product, developed in coding phase.
 These levels and methods of testing, will be discussed in later chapter in details.
IMPLEMENTATION OR DEPLOYMENT

 Once the software is certified, and no bugs or errors are stated, then it is deployed or given to the client for
actual implementation.
 After the software is deployed, client comes to know how actual system is working and if found something not
proper then its maintenance begins.

Once when the client starts using the developed systems, then the real issues come up and requirements to be
solved from time to time.
Client starts working with the actual developed system and found that something is not working or some
functionality is not working properly then demands for maintenance.
In this procedure, the care is taken for the developed product or system is known as maintenance.
In this phase main focus is on the remaining bugs or any functionality not implemented correctly will be taken
under maintenance and once again it goes for changes till the final acceptance.
SOFTWARE TESTING LIFE CYCLE (STLC)
 PHASES OF STLC

 1. Requirement Analysis:
 Requirement Analysis is the first step of the Software Testing Life Cycle (STLC). In this phase quality assurance
team understands the requirements like what is to be tested.

 If anything is missing or not understandable then the quality assurance team meets with the stakeholders to
better understand the detailed knowledge of requirements.

 Software requirement means requirement that is needed by software to increase quality of software product.

 These requirements are generally a type of expectation of user from software product that is important and need
to be fulfilled by software. Analysis means to examine something in an organized and specific manner to know
complete details about it.
PHASES OF STLC

 The activities that take place during the Requirement Analysis stage include:
• Reviewing the software requirements document (SRD) and other related documents
• Interviewing stakeholders to gather additional information
• Identifying any ambiguities or inconsistencies in the requirements
• Identifying any missing or incomplete requirements
• Identifying any potential risks or issues that may impact the testing process
PHASES OF STLC

 2. Test Planning:

 Test Planning is the most efficient phase of the software testing life cycle where all testing plans are defined.
 In this phase manager of the testing, team calculates the estimated effort and cost for the testing work.
 This phase gets started once the requirement-gathering phase is completed.

 The activities that take place during the Test Planning stage include:

 Identifying the testing objectives and scope

 Developing a test strategy: selecting the testing methods and techniques that will be used
 Identifying the testing environment and resources needed
 Identifying the test cases that will be executed and the test data that will be used
• Estimating the time and cost required for testing
• Identifying the test deliverables and milestones
• Assigning roles and responsibilities to the testing team
• Reviewing and approving the test plan
PHASES OF STLC

3. Test Case Development:

 The test case development phase gets started once the test planning phase is completed. In this phase testing
team notes down the detailed test cases.
 The testing team also prepares the required test data for the testing. When the test cases are prepared then
they are reviewed by the quality assurance team.

The activities that take place during the Test Case Development stage include:
•Identifying the test cases that will be developed
•Writing test cases that are clear, concise, and easy to understand
•Creating test data and test scenarios that will be used in the test cases
•Identifying the expected results for each test case
•Reviewing and validating the test cases.
PHASES OF STLC

 4.Test Environment Setup: Test environment setup is a vital part of the STLC. Basically, the test
environment decides the conditions on which software is tested.
 This is independent activity and can be started along with test case development. In this process, the testing
team is not involved. either the developer or the customer creates the testing environment.

5. Test Execution: After the test case development and test environment setup test execution phase gets started. In this
phase testing team starts executing test cases based on prepared test cases in the earlier step.

The activities that take place during the test execution stage of the Software Testing Life Cycle (STLC) include:
•Test execution: The test cases and scripts created in the test design stage are run against the software application to
identify any defects or issues.
•Defect logging: Any defects or issues that are found during test execution are logged in a defect tracking system, along
with details such as the severity, priority, and description of the issue.
•Test data preparation: Test data is prepared and loaded into the system for test execution
PHASES OF STLC

• Test environment setup: The necessary hardware, software, and network configurations are set up for test
execution
• Test execution: The test cases and scripts are run, and the results are collected and analyzed.
• Test result analysis: The results of the test execution are analyzed to determine the software’s performance and
identify any defects or issues.
• Defect retesting: Any defects that are identified during test execution are retested to ensure that they have been
fixed correctly.
• Test Reporting: Test results are documented and reported to the relevant stakeholders.
PHASES OF STLC

 6. Test Closure:
 Test closure is the final stage of the Software Testing Life Cycle (STLC) where all testing-related activities are
completed and documented.
 The main objective of the test closure stage is to ensure that all testing-related activities have been completed and
that the software is ready for release.
 At the end of the test closure stage, the testing team should have a clear understanding of the software’s quality
and reliability, and any defects or issues that were identified during testing should have been resolved.
 The test closure stage also includes documenting the testing process and any lessons learned so that they can be
used to improve future testing processes
 Test closure is the final stage of the Software Testing Life Cycle (STLC) where all testing-related activities are
completed and documented. The main activities that take place during the test closure stage include:
PHASES OF STLC

• Test summary report: A report is created that summarizes the overall testing process, including the number of
test cases executed, the number of defects found, and the overall pass/fail rate.
• Defect tracking: All defects that were identified during testing are tracked and managed until they are resolved.
• Test environment clean-up: The test environment is cleaned up, and all test data and test artifacts are archived.
• Test closure report: A report is created that documents all the testing-related activities that took place, including
the testing objectives, scope, schedule, and resources used.
• Knowledge transfer: Knowledge about the software and testing process is shared with the rest of the team and
any stakeholders who may need to maintain or support the software in the future.
• Feedback and improvements: Feedback from the testing process is collected and used to improve future testing
processes
DIFFERENCE BETWEEN SDLC AND STLC:

SDLC STLC

 SDLC is mainly related to software development.  STLC is mainly related to software testing.
 Besides development other phases like testing is  It focuses only on testing the software.
also included.
 STLC involves only six phases or steps.
 SDLC involves total seven phases or steps.
 In STLC, less number of members (testers) are
 In SDLC, more number of members (developers) needed.
are required for the whole process.
 In STLC, testing team(Test Lead or Test Architect)
 In SDLC, development team makes the plans and makes the plans and designs.
designs based on the requirements.
 Goal of STLC is to complete successful testing of
 Goal of SDLC is to complete successful software.
development of software.
 It helps in making the software defects free.
 It helps in developing good quality software.
DIFFERENCE BETWEEN SDLC AND STLC:

SDLC STLC

 SDLC phases are completed before the STLC  STLC phases are performed after SDLC phases.
phases.
 Regression tests are run by QA team to check
 Post deployment support , enhancement , and deployed maintenance code and maintains test
update are to be included if necessary. cases and automated scripts.
 It helps in developing good quality software  It helps in making the software defects free
TYPES OF SOFTWARE TESTING
AUTOMATION TESTING

 Automation Testing
 Automation testing is a process of changing any manual test case into the test scripts by using automation testing
tools, and scripting or programming language is called automation.
 Automation testing is used to increase the efficiency, effectiveness, and coverage of Software testing.
 Automation test engineer uses automation testing tools to automate the manual design test cases without any
human interference.
 And these testing tools can control the execution of tests, access the test data, and compares the actual result
against the expected result.
AUTOMATION TESTING

In other words, we can say that whenever we are testing an application by using some tools is known
as automation testing.
We will go for automation testing when various releases or several regression cycles goes on the
application or software. We cannot write the test script or perform the automation testing without
understanding the programming language.
MANUAL TESTING

 Testing any software or an application according to the client's needs without using any automation tool is
known as manual testing.
 Manual testing is testing, where the tester can test the application without any knowledge of any programming
language.
 In manual testing, the test engineer tests the application like a user to make it bug-free or stable.
 Manual test engineers always search for the fault or bugs in the product before the product released in the
market, yet delivered software still has defects.
 And there is a chance that the final software product still has a defect or does not meet the customer
requirement, even the manual test engineer do their best.
MANUAL TESTING

 We do not require any precise knowledge of any testing tool to execute the manual test cases. We can easily prepare
the test document while performing manual testing on any application.

In software testing, manual testing can be further classified into three different types
of testing, which are as follows:

White Box Testing

In white-box testing, the developer will inspect every line of code before handing it over to the testing
team or the concerned test engineers.
MANUAL TESTING

White box testing is also known as open box testing, glass box testing, structural testing, clear box
testing, and transparent box testing.
MANUAL TESTING

 Black Box Testing

 Another type of manual testing is black-box testing. In this testing, the test engineer will analyze the software against requirements, identify
the defects or bug, and sends it back to the development team.

Then, the developers will fix those defects, do one round of White box testing, and send it to the testing team.
Here, fixing the bugs means the defect is resolved, and the particular feature is working according to the given requirement.
MANUAL TESTING

 Grey Box Testing

 Another part of manual testing is Grey box testing. It is a collaboration of black box and white box testing.
 Since, the grey box testing includes access to internal coding for designing test cases. Grey box testing is
performed by a person who knows coding as well as testing.

In other words, we can say that if a single-person team done both white box and black-box testing, it is
considered grey box testing.
SOFTWARE TESTING PRINCIPLES

 Software testing is a procedure of implementing software or the application to identify the defects or bugs.
For testing an application or software, we need to follow some principles to make our product defects free,
and that also helps the test engineers to test the software with their effort and time. Here, in this section,
we are going to learn about the seven essential principles of software testing.

Let us see the seven different testing principles, one by one:

•Testing shows the presence of defects
•Exhaustive Testing is not possible
•Early Testing
•Defect Clustering
•Pesticide Paradox
•Testing is context-dependent
•Absence of errors fallacy
SOFTWARE TESTING PRINCIPLES
SOFTWARE TESTING PRINCIPLES
Testing shows the presence of defects
 The test engineer will test the application to make sure that the application is bug or defects free. While doing
testing, we can only identify that the application or software has any errors. The primary purpose of doing testing
is to identify the numbers of unknown bugs with the help of various methods and testing techniques because the
entire test should be traceable to the customer requirement, which means that to find any defects that might
cause the product failure to meet the client's needs.
 Exhaustive Testing is not possible
 Sometimes it seems to be very hard to test all the modules and their features with effective and non- effective
combinations of the inputs data throughout the actual testing process.
 Hence, instead of performing the exhaustive testing as it takes boundless determinations and most of the hard
work is unsuccessful. So we can complete this type of variations according to the importance of the modules
because the product timelines will not permit us to perform such type of testing scenarios.
SOFTWARE TESTING PRINCIPLES

 Defect clustering
 The defect clustering defined that throughout the testing process, we can detect the numbers of bugs which
are correlated to a small number of modules. We have various reasons for this, such as the modules could
be complicated; the coding part may be complex, and so on.
 These types of software or the application will follow the Pareto Principle, which states that we can identify
that approx. Eighty percent of the complication is present in 20 percent of the modules. With the help of
this, we can find the uncertain modules, but this method has its difficulties if the same tests are performing
regularly, hence the same test will not able to identify the new defects.
he defect clustering defined that throughout the testing process, we can detect the numbers of bugs which
are correlated to a small number of modules. We have various reasons for this, such as the modules could
be complicated; the coding part may be complex, and so on.
SOFTWARE TESTING PRINCIPLES

 These types of software or the application will follow the Pareto Principle, which states that we can identify that
approx. Eighty percent of the complication is present in 20 percent of the modules. With the help of this, we can
find the uncertain modules, but this method has its difficulties if the same tests are performing regularly, hence the
same test will not able to identify the new defects.

Pesticide paradox
This principle defined that if we are executing the same set of test cases again and again over a particular
time, then these kinds of the test will not be able to find the new bugs in the software or the application. To
get over these pesticide paradoxes, it is very significant to review all the test cases frequently. And the new
and different tests are necessary to be written for the implementation of multiple parts of the application or
the software, which helps us to find more bugs.
SOFTWARE TESTING PRINCIPLES

 Testing is context-dependent
 Testing is a context-dependent principle states that we have multiple fields such as e-commerce websites,
commercial websites, and so on are available in the market. There is a definite way to test the commercial site
as well as the e-commerce websites because every application has its own needs, features, and functionality.
To check this type of application, we will take the help of various kinds of testing, different technique,
approaches, and multiple methods. Therefore, the testing depends on the context of the application.

Absence of errors fallacy

Once the application is completely tested and there are no bugs identified before the release, so we can say
that the application is 99 percent bug-free. But there is the chance when the application is tested beside the
incorrect requirements, identified the flaws, and fixed them on a given period would not help as testing is
done on the wrong specification, which does not apply to the client's requirements. The absence of error
fallacy means identifying and fixing the bugs would not help if the application is impractical and not able to
accomplish the client's requirements and needs.