UNIT-II

Software Test Plan:-

What is Test Plan:
A test plan is a document that consists of all future testing-related activities. It is prepared
at the project level and in general, it defines work products to be tested, how they will be
tested, and test type distribution among the testers. Before starting testing there will be a
test manager who will be preparing a test plan. In any company whenever a new project is
taken up before the tester is involved in the testing the test manager of the team would
prepare a test Plan.

➢ The test plan serves as the blueprint that changes according to the progressions in
the project and stays current at all times.
➢ It serves as a base for conducting testing activities and coordinating activities among
a QA team.
➢ It is shared with Business Analysts, Project Managers, and anyone associated with
the project.
Why are Test Plans Important:
The following are some of the key benefits of making a test plan:
➢ Quick guide for the testing process: The test plan serves as a quick guide for the
testing process as it offers a clear guide for QA engineers to conduct testing
activities.
➢ Helps to avoid out-of-scope functionalities: The test plan offers detailed aspects
such as test scope, test estimation, strategy, etc.
➢ Helps to determine the time, cost, and effort: The Test serves as the blueprint to
conduct testing activities thus it helps to deduce an estimate of time, cost, and effort
for the testing activities.
➢ Provide a schedule for testing activities: A test plan is like a rule book that needs
to be followed, it thus helps to schedule activities that can be followed by all the
team members.
 ➢ Test plan can be reused: The test plan documents important aspects like test
estimation, test scope, and test strategy which are reviewed by the Management
Team and thus can be reused for other projects.
Objectives of the Test Plan:
1. Overview of testing activities: The test plan provides an overview of the testing
activities and where to start and stop the work.
2. Provides timeline: The test plan helps to create the timeline for the testing
activities based on the number of hours and the workers needed.
3. Helps to estimate resources: The test plan helps to create an estimate of the
number of resources needed to finish the work.
4. Serves as a blueprint: The test plan serves as a blueprint for all the testing
activities, it has every detail from beginning to end.
5. Helps to identify solutions: A test plan helps the team members They consider
the project’s challenges and identify the solutions.
6. Serves as a rulebook: The test plan serves as a rulebook for following rules
when the project is completed phase by phase.
Types of Test Plans:
The following are the three types of test plans:
➢ Master Test Plan: In this type of test plan, includes multiple test strategies and has
multiple levels of testing. It goes into great depth on the planning and management
of testing at the various test levels and thus provides a bird’s eye view of the
important decisions made, tactics used, etc. It includes a list of tests that must be
executed, test coverage, the connection between various test levels, etc.
➢ Phase Test Plan: In this type of test plan, emphasis is on any one phase of testing. It
includes further information on the levels listed in the master testing plan.
Information like testing schedules, benchmarks, activities, templates, and other
information that is not included in the master test plan is included in the phase test
plan.
➢ Specific Test Plan: This type of test plan, is designed for specific types of testing
especially non-functional testing for example plans for conducting performance tests
or security tests.

Types of Technical Reviews:-

Software Technical Review :
A software technical review is examined by a team of qualified software engineers
for the suitability of the software product. This process can also be defined as a critical
evaluation of an object in the software. Through the software technical review process, we
can identify the errors or defects in the software product in the early phase itself.
Types of STRs :
The intent of this section is for the students to realize that the types of reviews that
must be performed on a project are dependent upon the specific intermediate deliverables
that are produced. Various application areas should also be described in the context of their
review processes. The types of developmental modes are as follows:
1. Development life cycle models –
a. Waterfall model
b. Rapid prototyping
c. Iterative enhancement
d. Maintenance activity modeling
2. Current Standards –
a. Military standards
 b. IEEE standards
c. NBS standards
Furthermore, the reviews are classified into two types: Formal and Informal reviews.
Informal reviews are meant to describe the type of review that typically occurs
spontaneously among peers and in which the reviewers have any work and also not create a
review report.
Formal reviews are characterized by carefully planned meetings in which reviewers are
held accountable for their participation in the review and in which a review report
containing action items is generated and acted upon.
Importance of STRs :
Some of the reasons behind the importance of STRs are as follows:
➢ It also impacts employee morale. For some employees, such as maintenance
personnel, the reviews may provide an opportunity to gain visibility of their work
and, thus, will be viewed positively.
➢ It helps in software maintainability as it improves the developer’s general
understanding of the whole system, which further facilitates error diagnosis during
maintenance.
➢ It helps in the tracking of a project for both project management and customers.
With this, we can track management, customers, and also developers’ projects.
➢ They provide feedback about the software and its development process. Examples
of how review processes can impact the existing software development such as by
identifying weaknesses in the software that will require additional validation effort
in the future must also be provided.
Review Methodologies :
There are many variations to performing technical reviews. Most of these approaches
involve a group meeting to assess a work product; however, variations of reviews exist that
do not require a review group meeting. The three major approaches for performing the
software technical review are given as follows:
1. Walk-through –
Walk-throughs are a formal and very systematic type of verification method as
compared to peer review. In a walkthrough, the author of the software document
presents the document to other persons which can range from 2 to 7.
2. Inspections –
Inspections are the most structured and formal type of verification method and
are commonly known as inspections. It requires detailed preparation for the
reviewing team members and it includes a very high systematic review of the
software product.
3. Audits –
It can also be described as an external type of review process as it serves to
ensure that the software is correctly verified and working as per the requirement.

Static and Dynamic Testing:-

Static Testing is a type of a Software Testing method which is performed to check
the defects in software without actually executing the code of the software application.
Whereas in Dynamic Testing checks, the code is executed to detect the defects. Static
testing is performed in early stage of development to avoid errors as it is easier to find
sources of failures and it can be fixed easily. The errors that cannot be found using
Dynamic Testing, can be easily found by Static Testing. Static Testing Techniques: There
are mainly two type techniques used in Static Testing:
 Dynamic Testing is a type of Software Testing which is performed to analyze the
dynamic behavior of the code. It includes the testing of the software for the input values
and output values that are analyzed. Dynamic Testing is basically performed to describe the
dynamic behavior of code. It refers to the observation of the physical response from the
system to variables that are not constant and change with time. To perform dynamic testing
the software should be compiled and run. It includes working with the software by giving
input values and checking if the output is as expected by executing particular test cases
which can be done with either manually or with automation process. In 2 V’s i.e.,
Verification and Validation, Validation is Dynamic Testing.
Levels of Dynamic Testing
There are various levels of Dynamic Testing. They are:
➢ Unit Testing
➢ Integration Testing
➢ System Testing
➢ Acceptance Testing
Static Testing Dynamic Testing
It is performed in the early stage of It is performed at the later stage of the
the software development. software development.
In static testing whole code is not In dynamic testing whole code is
executed. executed.
Static testing prevents the defects. Dynamic testing finds and fixes the
defects.
Static testing is performed before Dynamic testing is performed after code
code deployment. deployment.
Static testing is less costly. Dynamic testing is highly costly.
Static Testing involves checklist for Dynamic Testing involves test cases for
testing process. testing process.
It includes walkthroughs, code It involves functional and nonfunctional
review, inspection etc. testing.
It generally takes shorter time. It usually takes longer time as it involves
running several test cases.
 It can discover variety of bugs. It expose the bugs that are explorable
through execution hence discover only
limited type of bugs.
Static Testing may complete 100% While dynamic testing only achieves less
statement coverage in comparably than 50% statement coverage.
less time.
Example: Example:
Verification Validation

Software Testing in Spiral Manner:-

The Spiral Model is one of the most important Software Development Life Cycle
models, which provides support for Risk Handling. In its diagrammatic representation, it
looks like a spiral with many loops. The exact number of loops of the spiral is unknown and
can vary from project to project. Each loop of the spiral is called a Phase of the software
development process.
The exact number of phases needed to develop the product can be varied by the project
manager depending upon the project risks. As the project manager dynamically determines
the number of phases, the project manager has an important role to develop a product using
the spiral model.
The Spiral Model is a Software Development Life Cycle (SDLC) model that provides a
systematic and iterative approach to software development. It is based on the idea of a spiral,
with each iteration of the spiral representing a complete software development cycle,
from requirements gathering and analysis to design, implementation, testing, and
maintenance.
What Are the Phases of Spiral Model?
The Spiral Model is a risk-driven model, meaning that the focus is on managing risk through
multiple iterations of the software development process. It consists of the following phases:
➢ Planning: The first phase of the Spiral Model is the planning phase, where the
scope of the project is determined and a plan is created for the next iteration of the
spiral.
➢ Risk Analysis: In the risk analysis phase, the risks associated with the project are
identified and evaluated.
➢ Engineering: In the engineering phase, the software is developed based on the
requirements gathered in the previous iteration.
➢ Evaluation: In the evaluation phase, the software is evaluated to determine if it
meets the customer’s requirements and if it is of high quality.
➢ Planning: The next iteration of the spiral begins with a new planning phase, based
on the results of the evaluation.
➢ The Spiral Model is often used for complex and large software development
projects, as it allows for a more flexible and adaptable approach to software
development. It is also well-suited to projects with significant uncertainty or high
levels of risk.
The Radius of the spiral at any point represents the expenses(cost) of the project so far, and
the angular dimension represents the progress made so far in the current phase.
Advantages of the Spiral Model
Below are some advantages of the Spiral Model.
➢ Risk Handling: The projects with many unknown risks that occur as the
development proceeds, in that case, Spiral Model is the best development model to
follow due to the risk analysis and risk handling at every phase.
➢ Good for large projects: It is recommended to use the Spiral Model in large and
complex projects.
➢ Flexibility in Requirements: Change requests in the Requirements at a later phase
can be incorporated accurately by using this model.
➢ Customer Satisfaction: Customers can see the development of the product at the
early phase of the software development and thus, they habituated with the system
by using it before completion of the total product.
➢ Iterative and Incremental Approach: The Spiral Model provides an iterative and
incremental approach to software development, allowing for flexibility and
adaptability in response to changing requirements or unexpected events.
➢ Emphasis on Risk Management: The Spiral Model places a strong emphasis on
risk management, which helps to minimize the impact of uncertainty and risk on the
software development process.
➢ Improved Communication: The Spiral Model provides for regular evaluations and
reviews, which can improve communication between the customer and the
development team.
➢ Improved Quality: The Spiral Model allows for multiple iterations of the software
development process, which can result in improved software quality and reliability.
Disadvantages of the Spiral Model
Below are some main disadvantages of the spiral model.
➢ Complex: The Spiral Model is much more complex than other SDLC models.
➢ Expensive: Spiral Model is not suitable for small projects as it is expensive.
➢ Too much dependability on Risk Analysis: The successful completion of the
project is very much dependent on Risk Analysis. Without very highly experienced
experts, it is going to be a failure to develop a project using this model.
➢ Difficulty in time management: As the number of phases is unknown at the start of
the project, time estimation is very difficult.
➢ Complexity: The Spiral Model can be complex, as it involves multiple iterations of
the software development process.
➢ Time-Consuming: The Spiral Model can be time-consuming, as it requires multiple
evaluations and reviews.
➢ Resource Intensive: The Spiral Model can be resource-intensive, as it requires a
significant investment in planning, risk analysis, and evaluations.

Test Coverage:-
Test coverage is the degree to which a test or set of tests exercises a particular
program or system. The more code that is covered by a test, the more confidence
developers have that the code is free of bugs. Measuring test coverage can be
difficult because it is often hard to determine what percentage of the code is actually
being executed by a test. In general, however, the more code that is covered by a
test, the better.
There are many different types of test coverage, but in general, test coverage
is a measure of how much of the code or functionality of a system is being tested by
a particular set of tests. For example, if a set of tests only covers 50% of the code,
then it has 50% coverage. There are many different ways to measure test coverage,
and the level of coverage that is considered acceptable varies from organization to
organization. In some cases, 100% test coverage may be required, while in others,
80% may be considered adequate.
One way to think of test coverage is as a spectrum, with lower levels of
coverage being less effective and higher levels being more effective. However, it is
important to remember that no single level of coverage is right for all situations, and
the level of coverage that is appropriate will depend on the specific system under test
and the risks involved.
Purpose of Test Coverage
The purpose of test coverage is to ensure that all code paths in a program are
executed at least once during testing. This helps to ensure that all bugs and potential
problems are found and fixed before the program is released. Test coverage can be
measured in a number of ways, but the most common metric is line coverage, which
simply measures the percentage of lines of code that are executed during testing.
➢ Cover all possible code paths: All code paths should be covered in a test in
order to ensure that all parts of the code are executed at least once. This will
help to find potential bugs that may be present in the code.
➢ Important functionality should be covered: All important functionality
should be covered in a test in order to ensure that it is working correctly. This
 includes ensuring that all inputs are handled correctly and that all outputs are
as expected.
➢ Potential bugs should be fixed before release: All potential bugs should be
covered in a test in order to ensure that they are found and fixed before the
code is released.
➢ All potential edge cases should be covered: All potential edge cases should
be covered in a test in order to ensure that the code behaves as expected in all
situations.
➢ All potential error conditions should be considered: All potential error
conditions should be covered in a test in order to ensure that the code behaves
as expected in all situations.
➢ Executed all tests at least once: All tests should be executed at least once in
order to ensure that they are actually being run and that they are working as
expected.
➢ Covered all possible input values: All possible input values should be
covered in a test in order to ensure that the software can handle them
correctly.
➢ Considered all possible combinations of input values: All possible
combinations of input values should be covered in a test in order to ensure
that the software can handle all potential combinations correctly.
Test Coverage Metrics
There are many different ways to measure test coverage, but some common metrics
include:
➢ Lines of code covered: This metric simply measures the number of lines of
code that are covered by tests. This is a good starting point, but it doesn’t give
the whole picture, since some lines of code are more important than others.
➢ Blocks covered: This metric measures the number of blocks of code (e.g., if-
statements, for-loops, etc.) that are covered by tests. This is a more granular
metric than lines of code, but it still doesn’t give the whole picture.
➢ Functions/methods covered: This metric measures the number of functions
or methods that are covered by tests. This is a more granular metric than
blocks, but it still doesn’t give the whole picture.
➢ Statements covered: This metric measures the number of statements that are
covered by tests. This is the most granular metric, but it still doesn’t give the
whole picture.
➢ Conditions covered: This metric measures the number of conditions (e.g., if-
statements, boolean expressions, etc.) that are covered by tests.
Types of Test Coverage
1. Statement Coverage: A test suite is said to achieve statement coverage if
every statement in the software has been executed at least once during
testing. This type of test design coverage ensures that every statement in
the software has been executed at least once. This is the most basic form
of test design coverage and is often used as a starting point for more
comprehensive testing.
2. Decision Coverage: A test suite is said to achieve decision coverage if
every decision (e.g. if-then-else) in the software has been taken both true
 and false during testing. This type of test design coverage ensures that
every decision (i.e. every ‘if’ or ‘case’) in the software has been executed
with all possible outcomes. This is a more comprehensive form of testing
than statement coverage and can help to uncover errors that may not be
obvious from simply executing every statement.
3. Condition Coverage: A test suite is said to achieve condition coverage if
every condition in the software has been evaluated as both true and false
during testing. This type of test design coverage ensures that all the
conditions within a decision have been executed with all possible
outcomes. This is a more comprehensive form of testing than decision
coverage and can help to uncover errors that may not be obvious from
simply executing every decision.
4. Multi-Condition Coverage: A test suite is said to achieve multi-condition
coverage if all combinations of conditions in the software have been
evaluated during testing. This type of test design coverage extends
condition coverage by testing all the conditions within a decision with all
possible combinations of values. This is a more comprehensive form of
testing than condition coverage and can help to uncover errors that may
not be obvious from simply executing every condition.
5. Modified Condition: A test suite is said to achieve modified conditions if
all modified conditions and decisions in the software have been evaluated
during testing. This type of test design coverage extends decision coverage
by testing all the conditions within a decision with all possible outcomes,
taking into account the effect of modifying the conditions. This is a more
comprehensive form of testing than decision coverage and can help to
uncover errors that may not be obvious from simply executing every
decision.
6. Data Flow Coverage: A test suite is said to achieve data flow coverage if
all executable paths through the software have been executed during
testing. This type of test design coverage ensures that all the possible paths
through the software have been executed. This is a more comprehensive
form of testing than all the other types of coverage and can help to
uncover errors that may not be obvious from simply executing the
software.
Benefits of Test Coverage
➢ Reduced bugs: Test coverage can help reduce the number of bugs in your
code. By testing your code, you can find and fix bugs before your users do.
➢ More reliable code: Code that has been tested is more reliable than code that
has not been tested. By testing your code, you can find and fix bugs before
your users do.
➢ Easier to find bugs: Test coverage can help you find bugs in your code. By
testing your code, you can find and fix bugs before your users do.
➢ Faster debugging: By testing your code, you can find and fix bugs before
your users do. This can save you time when debugging your code.
 ➢ Better code quality: Code that has been tested is typical of higher quality
than code that has not been tested. By testing your code, you can find and fix
bugs before your users do.
➢ Reduced time to market: By testing your code, you can find and fix bugs
before your users do. This can save you time when releasing your code to the
public.
➢ Ensure that all parts of the code are executed at least once: This is
important because it helps to find bugs that might otherwise go unnoticed.
➢ Prevent regressions: This is important because it helps to ensure that new
code does not break old code.
➢ Ensure that new code doesn’t break old code: This is important because it
helps to maintain the stability of the codebase.
Limitations of Test Coverage
➢ Time-consuming and expensive to set up and maintain: In order to get
reliable test coverage, a lot of time and effort must be put into setting up the
tests and making sure they are effective. This can be costly, both in terms of
money and time.
➢ Difficult to interpret: The results of test coverage can be difficult to
understand and interpret. This can make it difficult to know how effective the
tests are and what needs to be improved.
➢ False sense of security: Having high test coverage can give a false sense of
security, as it can make it seem like the system is more robust than it actually
is. This can lead to complacency and a lack of vigilance, which can ultimately
lead to problems.
➢ Can miss edge cases: No matter how good the test coverage is, there is
always the possibility that it will miss some edge cases. This can lead to
problems that only occur in rare circumstances, which can be difficult to find
and fix.
➢ Expensive to calculate and maintain: Test coverage can be expensive to
calculate and maintain because it requires running tests and then analyzing
the results. This can be time-consuming and may require special tools.
Additionally, if the test coverage changes frequently, it can be difficult to
keep up with the changes.
➢ Hard to interpret: Test coverage can be hard to interpret because it is a
measure of how many tests were run and how many lines of code were
covered. It does not necessarily indicate how effective the tests were at
finding bugs.
➢ Hide problems: Test coverage can be used to hide problems because it can
make it seem like the code is better tested than it actually is. This can lead to
problems if the tests are not effective at finding bugs.
➢ Make things seem better than they are: Test coverage can be used to make
things seem better than they are because it can make it seem like the code is
better tested than it actually is. This can lead to problems if the tests are not
effective at finding bugs.

Test Evaluation:-
Test Evaluation Report (TER) is a document that contains a summary of all the testing
activities, methods used for testing, and a summary of the final test results of a Software
project. TER is prepared after the completion of testing and the Test Summary Report and
provides all the necessary information regarding software testing to the developers and the
key stakeholders. These stakeholders can then evaluate the quality of the tested product and
make a decision on the software release.

Features of Test Evaluation Report

➢ Conducts analysis and assessment of Test Summary Report (TSR), source codes, test
results, and the measures used for product testing.
➢ Enables objective evaluation and assessment of product quality.
➢ Consists of corresponding recommendations that may be required for the next testing
efforts.
➢ Validates that no bug or error was missed by the tester.
➢ Reviews important change requests and issue details.
➢ Assess the product quality before it moves ahead in the development process.
➢ Allows the team members to effectively monitor each and every testing phase of the
development process.

Why is important to create Test Evaluation Report?

➢ Test Evaluation Reports are essential for making sure that the product under
development is achieving an acceptable level of quality before it is released to the
market.
➢ Stakeholders and customers can take corrective actions if needed for future
development processes.
➢ Done right; this can add true value to your development lifecycle by providing the
right feedback at the right time.

How to create a Test Evaluation Report?

An effective Test Evaluation Report should contain the following components:

1. Project Information
All the information regarding the project and the customer, such as Project Name, Customer
Name, and Project No. etc., is mentioned under this section. For a Change Request (CR), the
CR number can be mentioned as well.
2. Introduction
The introduction section can consists of the following:

➢ Purpose: This describes the purpose of the Test Evaluation in terms of test coverage
and defect analysis.
➢ Scope: This describes the scope of this document; associated project(s), and other
items of interest to the test team.
➢ Definitions: This can contain definitions, abbreviations, and acronyms required to
interpret the Test Evaluation document.
➢ References: This identifies the documents referenced in the Test Evaluation
Summary by title, report number, date, and author.
➢ Overview: This describes the rest of the Test Evaluation document and how the
document is organized.
3. Test Results
Test Results are summarized in this section. Test Results are generally the outcome of the
whole process of the Software Testing Life Cycle. The produced results offer an insight into
the deliverables of a software project which represents the project status to its stakeholders.
4. Test Coverage
Test Coverage is covered in this section which includes both the Requirements-based Test
Coverage and the Code-based Test Coverage. Test Results of both the coverages are
mentioned here and are compared with the previous test results.
5. Recommendations
This section identifies any suggested actions that need to be made based on the evaluation of
the test results. These recommendations help the developers/stakeholders to understand and
work accordingly for the next phase in the development life cycle.
6. Diagrams and Graphs
Under this section, diagrams, charts, graphs, or other data visualization of the test results can
be added. This helps in better debugging and root cause analysis
Example:

Best Practices to create a Test Evaluation Report

A Test Evaluation Report is a kind of communication tool between the Test Team and the
stakeholders. Through this test report, the stakeholder can understand the project situation,
the product quality, and other things. Hence, there is a need to develop good Test Reports.
A good Test Evaluation report should be:

➢ Concise and Clear: The information captured in the test report should be short, clear,
and easy to understand.
➢ Detailed: The report should provide detailed information about the testing activities
whenever and wherever necessary. The information provided should not be abstract as
it won’t help the stakeholders in drawing a clear picture of it.
➢ Standard: The report should follow a standard template as it is easy for stakeholders
to review and understand.
➢ Specific: The report should describe and summarize the test result specification and
focus on the main point only.

Acceptance Test:-
Acceptance Testing is a method of software testing where a system is tested for
acceptability. The major aim of this test is to evaluate the compliance of the system with the
business requirements and assess whether it is acceptable for delivery or not. Standard
Definition of Acceptance Testing:
Acceptance Testing is the last phase of software testing performed after System Testing and
before making the system available for actual use.

Types of Acceptance Testing:

1. User Acceptance Testing (UAT): User acceptance testing is used to determine
whether the product is working for the user correctly. Specific requirements
which are quite often used by the customers are primarily picked for the testing
purpose. This is also termed as End-User Testing.
2. Business Acceptance Testing (BAT): BAT is used to determine whether the
product meets the business goals and purposes or not. BAT mainly focuses on
business profits which are quite challenging due to the changing market
conditions and new technologies so the current implementation may have to
being changed which results in extra budgets.
3. Contract Acceptance Testing (CAT): CAT is a contract that specifies that once
the product goes live, within a predetermined period, the acceptance test must be
performed and it should pass all the acceptance use cases. Here is a contract
termed a Service Level Agreement (SLA), which includes the terms where the
payment will be made only if the Product services are in-line with all the
requirements, which means the contract is fulfilled. Sometimes, this contract
happens before the product goes live. There should be a well-defined contract in
terms of the period of testing, areas of testing, conditions on issues encountered
at later stages, payments, etc.
 4. Regulations Acceptance Testing (RAT): RAT is used to determine whether the
product violates the rules and regulations that are defined by the government of
the country where it is being released. This may be unintentional but will impact
negatively on the business. Generally, the product or application that is to be
released in the market, has to go under RAT, as different countries or regions
have different rules and regulations defined by its governing bodies. If any rules
and regulations are violated for any country then that country or the specific
region then the product will not be released in that country or region. If the
product is released even though there is a violation then only the vendors of the
product will be directly responsible.
5. Operational Acceptance Testing (OAT): OAT is used to determine the
operational readiness of the product and is non-functional testing. It mainly
includes testing of recovery, compatibility, maintainability, reliability, etc. OAT
assures the stability of the product before it is released to production.
6. Alpha Testing: Alpha testing is used to determine the product in the
development testing environment by a specialized testers team usually called
alpha testers.
7. Beta Testing: Beta testing is used to assess the product by exposing it to the real
end-users, usually called beta testers in their environment. Feedback is collected
from the users and the defects are fixed. Also, this helps in enhancing the
product to give a rich user experience.
Use of Acceptance Testing:
➢ To find the defects missed during the functional testing phase.
➢ How well the product is developed.
➢ A product is what actually the customers need.
➢ Feedback help in improving the product performance and user experience.
➢ Minimize or eliminate the issues arising from the production.
Advantages of Acceptance Testing :
➢ This testing helps the project team to know the further requirements from the users
directly as it involves the users for testing.
➢ Automated test execution.
➢ It brings confidence and satisfaction to the clients as they are directly involved in
the testing process.
➢ It is easier for the user to describe their requirement.
➢ It covers only the Black-Box testing process and hence the entire functionality of
the product will be tested.
Disadvantages of Acceptance Testing :
➢ Users should have basic knowledge about the product or application.
➢ Sometimes, users don’t want to participate in the testing process.
➢ The feedback for the testing takes long time as it involves many users and the
opinions may differ from one user to another user.
➢ Development team is not participated in this testing process.

Summarize Testing Results:-

Reporting test execution results is an essential part of Testing; whenever the test
execution cycle is complete, the tester should make a full test results report, including the test
cycle’s Test Pass/Fail status.
If manual Testing is done, the test pass/fail result should be captured in an Excel sheet. If
automation testing uses an automation tool, the HTML or XML reports should be provided to
stakeholders as test deliverables.
Test results are the outcome of the whole software testing life cycle process. The results thus
produced offer an insight into the deliverables of a software project, significant in
representing the project’s status to the stakeholders.

Few concepts:

Testing: Identifying whether a bug/error hides within a project and assessing the
observation’s impact. It forms an essential activity of Quality Assurance.
Debugging: This method involves identification and then correction of bugs/errors. When
developers encounter an error in the code, they debug. Debugging is thus a part of unit
testing.
Test Case: A test case is a document that consists of test data, preconditions, postconditions,
and expected results that are developed for a specific kind of test scenario intended for
serving a particular purpose.
Test Suite: It is a collection of test cases aimed at testing a software application to detect that
the application adheres to the requirement specifications. It consists of a detailed set of
instructions to attain a common goal.
Two broad categories/types of Testing help to obtain the test results most appropriately. They
are as follows :

Manual Testing is the process of Testing comprising a group of testers who examine the
code for the presence of a bug. The Testing is performed without the use of any tool. The
tester tests the application just as an end-user would do to find defects, if any.
Automation Testing- Automating the test process is done with the help of a script or tool. A
piece of code is used to detect a bug/error.