UNIT-4

Software Testing
➢Strategic Approach to Software Testing,
➢ Testing Fundamentals Test Plan,
➢ Test Design,
➢Test Execution,
➢ Reviews,
➢ Inspection Auditing,
➢Alpha and Beta Testing of Products.

Strategic Approach to Software Testing

Testing is the process of executing a program with the intent of finding errors.

Software testing is the process of evaluating a software application to

identify if it meets specified requirements and to identify any defects.
The following are common testing strategies:
1. Black box testing – Tests the functionality of the software
without looking at the internal code structure.
2. White box testing – Tests the internal code structure and logic
of the software.
3. Unit testing – Tests individual units or components of the
software to ensure they are functioning as intended.
4. Integration testing – Tests the integration of different
components of the software to ensure they work together as a
system.
5. Functional testing – Tests the functional requirements of the
software to ensure they are met.
6. System testing – Tests the complete software system to ensure
it meets the specified requirements.
 7. Acceptance testing – Tests the software to ensure it meets the
customer’s or end-user’s expectations.
8. Regression testing – Tests the software after changes or
modifications have been made to ensure the changes have not
introduced new defects.
9. Performance testing – Tests the software to determine its
performance characteristics such as speed, scalability, and
stability.
10. Security testing – Tests the software to identify
vulnerabilities and ensure it meets security requirements.
Software Testing is a type of investigation to find out if there is
any default or error present in the software so that the errors can be
reduced or removed to increase the quality of the software and to
check whether it fulfills the specified requirements or not.
According to Glen Myers, software testing has the following
objectives:
• The process of investigating and checking a program to find
whether there is an error or not and does it fulfill the
requirements or not is called testing.
• When the number of errors found during the testing is high, it
indicates that the testing was good and is a sign of a good test
case.
• Finding an unknown error that wasn’t discovered yet is a sign
of a successful and good test case.
The main objective of software testing is to design the tests in such a
way that it systematically finds different types of errors without
taking much time and effort so that less time is required for the
development of the software. The overall strategy for testing software
includes:
Advantages of software testing:

1. Improves software quality and reliability – Testing helps to identify

and fix defects early in the development process, reducing the risk
of failure or unexpected behaviour in the final product.
2. Enhances user experience – Testing helps to identify usability
issues and improve the overall user experience.
3. Increases confidence – By testing the software, developers, and
stakeholders can have confidence that the software meets the
requirements and works as intended.
 4. Facilitates maintenance – By identifying and fixing defects early,
testing makes it easier to maintain and update the software.
5. Reduces costs – Finding and fixing defects early in the
development process is less expensive than fixing them later in
the life cycle.

Disadvantages of software testing:

1. Time-consuming – Testing can take a significant amount of time,

particularly if thorough testing is performed.
2. Resource-intensive – Testing requires specialized skills and
resources, which can be expensive.
3. Limited coverage – Testing can only reveal defects that are present
in the test cases, and it is possible for defects to be missed.
4. Unpredictable results – The outcome of testing is not always
predictable, and defects can be hard to replicate and fix.
5. Delays in delivery – Testing can delay the delivery of the software
if testing takes longer than expected or if significant defects are
identified.
For successful testing, a test plan (documentation) plays a very important
role. Here, we will discuss the following points:
1. Introduction to Test Plan
2. Importance of Test Plan
3. Test Plan Guidelines
4. Types of Test Plans
5. Test Plan Attributes
6. What If There is No Test Plan?
1. Test Plan

“Test Plan is A document describing the scope, approach, resources,

and schedule of intended test activities.”

➢ A Test Plan is a detailed document that describes the test strategy,

objectives, schedule, estimation, deliverables, and resources required
to perform testing for a software product.
➢ Test Plan helps us determine the effort needed to validate the quality
of the application under test.
➢ The test plan serves as a blueprint for conducting software testing.
 Test Case ID
Section-I Section-II

(Before Execution) (After Execution)

Purpose : Execution History:
Pre condition: (If any) Result:
Inputs: If fails, any possible reason (Optional);

Expected Outputs: Any other observation:

Post conditions: Any suggestion:
Written by: Run by:
Date: Date:

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 involves in the testing the test manager of the
team would prepare a test Plan.
2. Importance of Test Plan
The following are some of the key benefits of making a test plan:
• It acts as a quick guide for the testing process.
• It helps to avoid out-of-scope functionalities.
• It determines the time, cost, and effort.
• Provide a schedule for testing activities.
• Resource requirement and equipment.
• Test Plan Document can be used for similar projects.
• It helps to understand the test details.
• It helps in determining the quality of software applications.
3. Test Plan Guidelines
• Avoid Overlapping and repetition.
• Avoid Lengthy Paragraph.
• Use lists and tables.
• Update plan.
 • Don’t use outdated documents.
4. Type of Test Plan
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.
• Phase Test Plan- In this type of test plan, emphasis on any one
phase of testing.
• Specific Test Plan- In this type of test plan, it is designed for
specific types of testing especially non-functional testing.
5. Test Plan Attributes
There is no hard and fast rule of preparing a test plan but it has
some standard 15 attributes that companies follow:

A. Objective: It describes the aim of the test plan, whatever the good
process and procedure they are going to follow in order to give quality
software to customers. The overall objective of the test is to find as many
defects as possible and to make software bug free. The test objective must
be broken into components and sub-components. In every component
following activities should be performed.
• List all the functionality, performance to be tested.
• Make goals and targets based on the application feature.
B. Test Strategy: It is a crucial document that is to be performed and
usually designed by the Test Manager. It helps to determine Test Effort and
Test cost. Test strategy helps to determine the features that are going to be
tested and the features that will not be tested. The scope can be divided
into two parts:
• In-Scope: The modules that are to be tested rigorously.
• Out Scope: The modules that are not to be tested rigorously.
Example: In an application A, B, C, D features have to be developed, but the
B feature has already been designed by other companies. So the
development team will purchase B from that company and perform only
integrated testing with A, B, C.
C. Testing Methodology: The methods that are going to be used for testing
depend on application to application. The testing methodology is decided
based on the feature and application requirements.
Since the testing terms are not standard, one should define what kind of
testing will be used in the testing methodology. So that everyone can
understand it.
D. Approach: The approach of testing different software is different. It deals
with the flow of applications for future references. It has two aspects:
• High-Level Scenarios: For testing critical features high-level
scenarios are written. For Example, login to a website, booking
from a website.
• The Flow Graph: It is used when one wants to make benefits such
as converging and merging easy.
E. Assumptions: In this phase, certain assumptions will be made.
Example:
• The testing team will get proper support from the development
team.
• The tester will get proper knowledge transfer from the
development team.
• Proper resource allocation will be given by the company to the
testing department.
F. Risk: All the risks that can happen if the assumption is breaking. For
Example, in the case of wrong budget estimation, the cost may overrun.
Some reason that may lead to risk is:
• Test Manager has poor management skills.
• Hard to complete the project on time.
• Lack of cooperation.
G. Backup/Mitigation Plan- If any risk is involved then the company must
have a backup plan, the purpose is to avoid errors. Some points to
resolve/avoid risk:
 • Test priority is to be set for each test activity.
• Managers should have leadership skills.
• Training course for the testers.
H. Roles and Responsibilities: All the responsibilities and role of every
member in a particular testing team has to be recorded.
Example:
• Test Manager: Manages the project, takes an appropriate resource
and gives project direction.
• Tester: Identify the testing technique, verify the test approach, and
save project cost.
I. Scheduling: Under this, it will record the start and the end date of each
and every testing-related activity. For Example, writing test case date and
ending test case date.
J. Defect Tracking: It is an important process in software engineering as lots
of issue arises when you develop a critical system for business. If there is
any defect found while testing and that defect must be given to the
developer team. There are the following methods for the process of defect
tracking:
• Information Capture: In this, we take basic information to begin
the process.
• Prioritize: The task is prioritized based on severity and importance.
• Communicate: Communication between the identifier of bug and
fixer of bug.
• Environment: Test the application based on hardware and
software.
Example: The bug can be identified using bug tracking tools such as Jira,
Mantis, Trac.
K. Test Environment- It is the environment which the testing team will use
i.e. the list of hardware and software, while testing the application, the
things which are said to be tested will be written under this section. The
installation of software is also checked under this.
Example:
• Software configuration on different operating systems, such as
Windows, Linux, Mac, etc.
• Hardware Configuration depends on RAM, ROM, etc.
L. Entry and Exit Criteria: The set of conditions that should be met in order
to start any new type of testing or to end any kind of testing.
Entry Condition:
• Necessary resources must be ready.
 • The application must be prepared.
• Test data should be ready.
Exit Condition:
• There should not be any major bug.
• Most test cases should be passed.
• When all test cases are executed.
Example: If the team member report 45% of the test cases failed, then
testing will be suspended until the developer team fixes all defects.

Flow chart showing entry and exit condition

M. Test Automation: It consists of the features that are to be automated

and which features are not to be automated.
• If the feature has lots of bugs then it is categorized as Manual
Testing.
• If the feature is frequently tested then it can be automated.
N. Deliverables- It is the outcome from the testing team and that is to be
given to the customers at the end of the project.
Before testing phase:
• Test plan document.
• Test case document.
• Test design specification.
During testing phase:
• Test scripts.
• Test data.
• Error logs.
After testing phase:
 • Test Reports.
• Defect Report.
• Installation Report.
It contains a test plan, defect report, automation report, assumption report,
tools, and other components that have been used for developing and
maintaining the testing effort.
O. Templated: It is followed by every kind of report that is going to be
prepared by the testing team.
6. What If There is No Test Plan?
Below are some of the situations that may occur if there is no test plan in
place:
• Misunderstanding roles and responsibilities.
• The test team will have no clear objective.
• No surety when the process ends.
• Undefined test scope may confuse testers.

TEST DESIGN

Test design is the process of creating a plan

or strategy to test a software application,
including its features and functions. It involves
identifying test conditions, test cases, test data, and test techniques. The
purpose of test design is to detect software defects early and to cover
the requirements with minimum effort. Test design answers the
question "How to test?

Software Testing Life Cycle (STLC) is a sequence of specific

activities conducted during the testing process to ensure software
quality goals are met. STLC involves both verification and validation
activities. Contrary to popular belief, Software Testing is not just a
single/isolated activity, i.e. testing. It consists of a series of activities
carried out methodologically to help certify your software product.
STLC stands for Software Testing Life Cycle.
 STLC Phases
There are following six major phases in every Software Testing Life
Cycle Model (STLC Model):

STLC Model Phases

Requirement Analysis

Test Planning

Test case development

Test Environment setup

Test Execution

Test Cycle closure

What is Entry and Exit Criteria in STLC?

• Entry Criteria: Entry Criteria gives the prerequisite items that must be
completed before testing can begin.
• Exit Criteria: Exit Criteria defines the items that must be completed
before testing can be concluded

What is Test Execution?

Test Execution is the process of executing the tests written by the tester to
check whether the developed code or functions or modules are providing
the expected result as per the client requirement or business requirement.
Test Execution comes under one of the phases of the Software Testing Life
Cycle (STLC).
Importance of Test Execution:
• The project runs efficiently: Test execution ensures that the
project runs smoothly and efficiently.
• Application competency: It also helps to make sure the
application’s competency in the global market.
• Requirements are correctly collected: Test executions make sure
that the requirements are collected correctly and incorporated
correctly in design and architecture.
• Application built in accordance with requirements: It also checks
whether the software application is built in accordance with the
requirements or not.

Activities for Test Execution

The following are the 5 main activities that should be carried out during the
test execution.
1. Defect Finding and Reporting: Defect finding is the process of
identifying the bugs or errors raised while executing the test cases
on the developed code or modules. If any error appears or any of
the test cases failed then it will be recorded and the same will be
reported to the respective development team. Sometimes, during
the user acceptance testing also end users may find the error and
report it to the team. All the recorded details will be reported to
the respective team and they will work on the recorded errors or
bugs.
2. Defect Mapping: After the error has been detected and reported to
the development team, the development team will work on those
errors and fix them as per the requirement. Once the development
team has done its job, the tester team will again map the test
cases or test scripts to that developed module or code to run the
entire tests to ensure the correct output.
3. Re-Testing: From the name itself, we can easily understand that
Re-Testing is the process of testing the modules or entire product
again to ensure the smooth release of the module or product. In
some cases, the new module or functionality will be developed
after the product release. In this case, all the modules will be re-
 tested for a smooth release. So that it cannot cause any other
defects after the release of the product or application.
4. Regression Testing: Regression Testing is software testing that
ensures that the newly made changes to the code or newly
developed modules or functions should not affect the normal
processing of the application or product.
5. System Integration Testing: System Integration Testing is a type
of testing technique that will be used to check the entire
component or modules of the system in a single run. It ensures
that the whole system will be checked in a single test environment
instead of checking each module or function separately.

Test Execution Process

The test Execution technique consists of three different phases which will
be carried out to process the test result and ensure the correctness of the
required results. In each phase, various activities or work will be carried out
by various team members. The three main phases of test execution are the
creation of test cases, test case execution, and validation of test results. Let
us discuss each phase.
1. Creation of Test Cases: The first phase is to create suitable test cases for
each module or function. Here, the tester with good domain knowledge
must be required to create suitable test cases. It is always preferable to
create simple test cases and the creation of test cases should not be
delayed else it will cause excess time to release the product. The created
test cases should not be repeated again. It should cover all the possible
scenarios raised in the application.
2. Test Cases Execution: After test cases have been created, execution of
test cases will take place. Here, the Quality Analyst team will either do
automated or manual testing depending upon the test case scenario. It is
always preferable to do both automated as well as manual testing to have
100% assurance of correctness. The selection of testing tools is also
important to execute the test cases.
3. Validating Test Results: After executing the test cases, note down the
results of each test case in a separate file or report. Check whether the
executed test cases achieved the expected result and record the time
required to complete each test case i.e., measure the performance of each
test case. If any of the test cases is failed or not satisfied the condition then
report it to the development team for validating the code.

Ways to Perform Test Execution

Testers can choose from the below list of preferred methods to carry out
test execution:
1. Run test cases: It is a simple and easiest approach to run test
cases on the local machine and it can be coupled with other
artifacts like test plans, test suites, test environments, etc.
2. Run test suites: A test suite is a collection of manual and
automated test cases and the test cases can be executed
sequentially or in parallel. Sequential execution is useful in cases
where the result of the last test case depends on the success of
the current test case.
3. Run test case execution and test suite execution
records: Recording test case execution and test suite execution is a
key activity in the test process and helps to reduce errors, making
the testing process more efficient.
4. Generate test results without execution: Generating test results
from non-executed test cases can be helpful in achieving
comprehensive test coverage.
5. Modify execution variables: Execution variables can be modified in
the test scripts for particular test runs.
6. Run automated and manual tests: Test execution can be done
manually or can be automated.
7. Schedule test artifacts: Test artifacts include video, screenshots,
data reports, etc. These are very helpful as they document the
results of the past test execution and provide information about
what needs to be done in future test execution.
8. Defect tracking: Without defect tracking test execution is not
possible, as during testing one should be able to track the defects
and identify what when wrong and where.

Test Execution Priorities

Test Execution Priorities are nothing but prioritizing the test cases
depending upon several factors. It means that it executes the test cases
with high efficient first than the other test cases. It depends upon various
factors. Let us discuss some of the factors to be considered while prioritizing
the test cases.
• Complexity: The complexity of the test cases can be determined
by including several factors such as boundary values of test cases,
features or components of test cases, data entry of test cases, and
how much the test cases cover the given business problem.
• Risk Covered: How much risk that a certain test case may undergo
to achieve the result. Risk in the form of time required to complete
the test case process, space complexity whether it is executed in
the given memory space, etc.,
• Platforms Covered: It simply tells that in which platform or
operating system the test cases have been executed i.e., test cases
executed in the Windows OS, Mac OS, Mobile OS, etc.,
• Depth: It covers how depth the given test cases cover each
functionality or module in the application i.e., how much a given
test procedure covers all the possible conditions in a single
functionality or module.
• Breadth: It covers how the breadth of the given test cases covers
the entire functionality or modules in the application i.e., how much
a given test procedure covers all the possible conditions in the
entire functionality or modules in the product or application.

Test Execution States

The tester or the Quality Analyst team reports or notices the result of each
test case and records it in their documentation or file. There are various
results raised when executing the test cases. They are
• Pass: It tells that the test cases executed for the module or
function are successful.
• Fail: It tells that the test cases executed for the module or function
are not successful and resulted in different outputs.
• Not Run: It tells that the test cases are yet to be executed.
• Partially Executed: It tells that only a certain number of test cases
are passed and others aren’t met the given requirement.
• Inconclusive: It tells that the test cases are executed but it requires
further analysis before the final submission.
• In Progress: It tells that the test cases are currently executed.
 • Unexpected Result: It tells that all the test cases are executed
successfully but provide different unexpected results.

Test Execution Cycle

A test execution cycle is an iterative approach that will be helpful in

detecting errors. The test execution cycle includes various processes. These
are:
1. Requirement Analysis: In which, the QA team will gather all the
necessary requirements needed for test execution. For example,
how many testers are needed, what automation test tools are
needed, what testing covers under the given budget, etc., the QA
team will also plan depending upon the client or business
requirement.
2. Test Planning: In this phase, the QA team will plan when to start
and complete the testing. Choosing of correct automation test tool,
and testers needed for executing the test plan. They further plan
who should develop the test cases for which module/function, who
should execute the test cases, how many test cases needed to be
executed, etc.,
3. Test Cases Development: This is the phase in which the QA team
assigned a group of testers to write or generate the test cases for
each module. A tester with good domain knowledge will easily
write the best test cases or test scripts. Prioritizing the developed
test cases is also the main factor.
4. Test Environment Setup: Test Environment Setup usually differs
from project to project. In some cases, it is created by the team
itself and it is also created by clients or customers. Test
Environment Setup is nothing but testing the entire developed
product with suitable software or hardware components or with
both by executing all the tests on it. It is essential and it is
sometimes carried out along with the test case development
process.
5. Test Execution: This stage involves test execution by the team and
all the detected bugs are recorded and reported for remediation
and rectification.
6. Test Closure: This is the final stage and here it records the entire
details of the test execution process. It also contains the end-users
 testing details. It again modifies the testing process if any defects
are found during the testing. Hence, it is a repetitive process.

Test Execution Report

The Test Execution Report is nothing but a document that contains all the
information about the test execution process. It is documentation that will
be recorded and updated by the QA team. In that, they just record all the
processes happening in the day-to-day test execution activities. The test
execution activities are nothing but executing the task related to testing.
The documentation or the report contains various information. They are:
• Who all are going to execute the test cases?
• Who is doing the unit testing, integration testing, system testing,
etc.,
• Who is going to write test cases?
• The number of test cases executed successfully.
• The number of test cases failed during the testing.
• The number of test cases executed today.
• The number of test cases yet to be executed.
• What are the automation test tools used for today’s test
execution?
• What are the modules/functions testing today?
• Recording the issues while executing the test cases.
• What is today’s testing plan?
• What is tomorrow’s testing plan?
• Recording the pending plans.
• Overall success rate.
• Overall failure rate.
These are the headings in the Test Execution Report:
• Test Summary Report Identifier.
• Summary.
• Variances.
• Comprehensive Assessment.
• Summary of Results.
• Evaluation.
• Summary of Activities.
• Approval.
Guidelines for Test Execution

• Write the suitable test cases for each module of the function.
• Assign suitable test cases to respective modules or functions.
• Execute both manual testing as well as automated testing for
successful results.
• Choose a suitable automated tool for testing the application.
• Choose the correct test environment setup.
• Note down the execution status of each test case and note down
the time taken by the system to complete the test cases.
• Report all the success status and the failure status to the
development team or to the respective team regularly.
• Track the test status again for the already failed test cases and
report it to the team.
• Highly Skilled Testers are required to perform the testing with less
or zero failures/defects.
• Continuous testing is required until success test report is
achieved.
Software Review
Software Review isa systematic inspection of
software by one or more individuals who work
together to find and resolve errors and defects in the
software during the early stages of the Software Development Life Cycle
(SDLC).
A software review is an essential part of the Software Development Life Cycle
(SDLC) that helps software engineers in validating the quality, functionality,
and other vital features and components of the software. It is a whole process
that includes testing the software product and it makes sure that it meets the
requirements stated by the client.
Usually performed manually, software review is used to verify various
documents like requirements, system designs, codes, test plans and test cases.

Objectives of Software Review:

The objective of software review is:

1. To improve the productivity of the development team.

 2. To make the testing process time and cost effective.

3. To make the final software with fewer defects.

4. To eliminate the inadequacies.

Process of Software Review:

Types of Software Reviews:

There are mainly 3 types of software reviews:

1. Software Peer Review:

Peer review is the process of assessing the technical content and
quality of the product and it is usually conducted by the author of the
 work product along with some other developers.
Peer review is performed in order to examine or resolve the defects in
the software, whose quality is also checked by other members of the
team.
Peer Review has following types:
• (i) Code Review:
Computer source code is examined in a systematic way.

• (ii) Pair Programming:

It is a code review where two developers develop code
together at the same platform.

• (iii) Walkthrough:
Members of the development team is guided by author and
other interested parties and the participants ask questions
and make comments about defects.

• (iv) Technical Review:

A team of highly qualified individuals examines the software
product for its client’s use and identifies technical defects
from specifications and standards.

• (v) Inspection:
In inspection the reviewers follow a well-defined process to
find defects.

2. Software Management Review:

Software Management Review evaluates the work status. In this section
decisions regarding downstream activities are taken.

3. Software Audit Review:

Software Audit Review is a type of external review in which one or
more critics, who are not a part of the development team, organize an
independent inspection of the software product and its processes to
assess their compliance with stated specifications and standards. This
is done by managerial level people.

Advantages of Software Review:

• Defects can be identified earlier stage of development (especially in

formal review).

• Earlier inspection also reduces the maintenance cost of software.

 • It can be used to train technical authors.

• It can be used to remove process inadequacies that encourage defects.

Inspection
The term software inspection was developed by IBM in the early 1970s
when it was noticed that the testing was not enough sufficient to attain
high-quality software for large applications.

Software inspection is a process in which other developers or

team members review the code written by a developer to
identify potential errors or areas for improvement .
This process can help improve the overall quality of the software by
identifying and resolving faults early in the development process.

There are several ways that software inspection can improve software
quality:

1. Identifying and resolving defects early: By identifying and

resolving defects early in the development process, inspection
can prevent costly rework and delays later in the project.
2. Enhancing code readability: Inspection can help improve the
readability of the code, making it easier for other developers to
understand and maintain.
3. Improving team collaboration: Inspection can help improve
team collaboration by encouraging developers to share their
ideas and knowledge.
4. Enhancing code maintainability: Inspection can help identify
areas where code is difficult to maintain and suggest
improvements to make it more maintainable.
5. Improving code efficiency: Inspection can help identify areas
where code is inefficient and suggest improvements to make it
more efficient.
6. Enhancing security: Inspection can help identify security
vulnerabilities in the code and suggest improvements to make
the software more secure.
 7. Improving the overall quality of the software: By identifying
and resolving defects early in the development process,
inspection can help improve the overall quality of the software
and ensure that it meets the needs of its users.

Software Inspection Process : The inspection process was developed in

the mid 1970s, later extended and revised. The process must have an
entry criterion that determines whether the inspection process is ready to
begin. this prevents incomplete products from entering the inspection
process. Entry criteria can be interstitial with items such as “The Spell-
Document Check”.
There are some of the stages in the software inspection process such as-
• Planning : The moderator plan the inspection.
• Overview Meeting: The background of the work product is
described by the author.
• Preparation: The examination of the work product is done by
inspector to identify the possible defects.
• Inspection Meeting: The reader reads the work product part by
part during this meeting and the inspectors the faults of each
part.
• Rework: After the inspection meeting, the writer changes the
work product according to the work plans.
 • Follow Up: The changes done by the author are checked to
make sure that everything is correct.

Advantages of Software Inspection:

• Helps in the Early removal of major defects.
• This inspection enables a numeric quality assessment of any
technical document.
• Software inspection helps in process improvement.
• It helps in staff training on the job.
• Software inspection helps in gradual productivity improvement.
• Early identification and resolution of defects: Software
inspection allows developers to identify and resolve defects
early in the development process, which can save time and
resources by preventing costly rework or delays later in the
project.
• Improved code quality: Software inspection can help improve
the overall quality of the code by identifying areas for
improvement and suggesting changes to make the code more
readable, maintainable, and efficient.
• Enhanced team collaboration: Software inspection can
encourage developers to share their ideas and knowledge, and
can help improve team collaboration and communication.
• Increased code maintainability: Software inspection can help
identify areas where code is difficult to maintain and suggest
improvements to make it more maintainable.
• Enhanced security: Software inspection can help identify
security vulnerabilities in the code and suggest improvements to
make the software more secure.
• Cost-effective: Software inspection is relatively low cost and
time-efficient, as it can be done by the team members
themselves.
• Increased accountability: Software inspection can help hold
developers and teams accountable for the quality of their code,
by providing metrics and feedback.
• Provides a comprehensive view of the code: Software inspection
can provide an in-depth view of the code, which can help to
 identify both functional and non-functional requirements of the
software.

Software Audit
➢ A software audit is a thorough review of a software
product to check its quality, progress, standards,
and regulations.
➢ It checks the health of a product and ensures that everything is going as
planned.
➢ It can be done by an internal team or any external independent auditors.
➢ If the audit is performed by an external auditor, it can add some financial
strain to the company and disrupt development to accommodate such audits.
➢ It is recommended to perform regular internal audits on the software to ensure
that proper regulations are followed and all licenses are up-to-date as it can
also save the company from unnecessary legal issues.

Benefits of Audit in Software Testing

• Helps in validating the testing process and identifies ways to optimize the existing
process
• It checks for any mismatches between the requirements and the delivered features.
There can be miscommunication between business and technical teams which can
cause such mismatches. Audits helps in capturing such issues
• Ensures the development progress is as expected with compliance to regulations and
best practices. It can also catch any potential risks to the product and help mitigate it
• Incase any issues are noticed, proper suggestions are gives to improve upon the process
or the product

Types of Audit in Software Testing

There are different types of audits based on what goals are needed to be achieved
for the product
 • Internal audit: These audits are done within the organization

• External audit: These are done by independent contractors or external agencies

• Compliance audit: This audit checks if the process is within the given standards. If the
testing process has certain standards to adhere to, this audit ensures that it’s followed

• Process improvement: If there are any changes needed for the existing process, this
audit helps in identifying them. This is done by evaluating the various steps in the
process and identifying any problems, and eliminating them.

• Root cause analysis: This audit helps to find the root cause for a problem using
different testing processes. It is done for specific problems that require some attention
and need to be resolved.
Key differences between inspections and audits:
1. Purpose and Focus:
o Inspections primarily focus on identifying safety hazards in the
workplace. They revolve around people, places, and things.
o Audits, on the other hand, concentrate on evaluating
the processes adopted by an organization to prevent identified hazards
and address worker safety issues. Audits center on operations,
processes, and programs.
2. Frequency and Duration:
o Inspections usually occur monthly or at regular intervals. They are
relatively quick and might only take five or ten minutes at the start of
each shift.
o Audits are more in-depth and frequent. They can take several days to
complete, ensuring a thorough evaluation of compliance obligations.
3. Compliance Obligations:
o Inspections are typically something that a site is required to do by
a compliance obligation.
o Audits involve checking whether compliance obligations have been
met, including verifying that the required inspections have been
conducted.
o Inspections are the “do” part, while audits are the “check” part. Both are
essential tools for ensuring organizations operate in a manner that
complies with applicable laws and regulations.

Alpha Testing
Alpha Testing is a type of software testing performed to identify bugs
before releasing the product to real users or to the public. Alpha Testing
is one of the user acceptance tests. It is the first stage of software
testing, during which the internal development team tests the program
before making it available to clients or people outside the company.
Key points to remember:
• Work Done by Developers: The internal development team,
which consists of developers and testers, usually conducts
alpha testing in a controlled setting.
• Goal: Finding and fixing bugs, flaws, and usability issues is the
main goal before releasing the product for external users or
wider testing.
• Little User Engagement: Alpha testers are few in number and
frequently comprise members of the development team or those
intimately connected to the project.
• Environment: Alpha testing is typically carried out in a
development environment or laboratory that resembles actual
settings.
Beta Testing
Beta Testing is performed by real users of the software application in a real
environment. Beta testing is one type of User Acceptance Testing. A pre-
release version of the product is made available for testing to a chosen
set of external users or customers during the second phase of software
testing.
Key Points to remember:
• Actions Taken by Users: Customers or other users outside the
development team participate in beta testing. The software is
available to these users prior to its official release.
• Goal: The primary objective is to get input from actual users in
order to find any bugs, usability difficulties, or areas that need to
be improved before the product is formally released.
• Greater User Participation: In order to capture a variety of
viewpoints, a larger number of users—including a varied range,
can serve as beta testers.
• Environment: Real-world settings are used for beta testing to
simulate how users will interact with the program while
performing daily duties.
 Difference between Alpha and Beta Testing
The difference between Alpha and Beta Testing is as follows:
Alpha Testing Beta Testing
Parameters

Alpha testing involves

Beta testing commonly
both the white box and
uses black-box testing.
black box testing.
Involvment

Alpha testing is
Beta testing is
performed by testers
performed by clients
who are usually
who are not part of the
internal employees of
organization.
the organization.
Performed by

Alpha testing is Beta testing is

performed at the performed at the end-
developer’s site. user of the product.
Performed at

Reliability and security Reliability, security and

testing are not checked robustness are checked
Reliability and in alpha testing. during beta testing.
Security

Beta testing also

Alpha testing ensures
concentrates on the
the quality of the
quality of the product
product before
but collects users input
forwarding to beta
on the product and
testing.
Ensures ensures that the
 Alpha Testing Beta Testing
Parameters

product is ready for

real time users.

Alpha testing requires Beta testing doesn’t

a testing environment require a testing
or a lab. environment or lab.
Requirement

Alpha testing may Beta testing requires

require a long only a few weeks of
execution cycle. execution.
Execution

Most of the issues or

Developers can feedback collected
immediately address from the beta testing
the critical issues or will be implemented in
fixes in alpha testing. future versions of the
product.
Issues

Multiple test cycles are Only one or two test

organized in alpha cycles are there in beta
testing. testing.
Test Cycles

Alpha testing is an internal testing process carried out by

developers to identify bugs early, while beta testing involves
external users to obtain real-world feedback prior to the official
release. For a software product to be successful in the market and
of high quality, both stages are essential.
1. Review:
 o A review is a collaborative process where team members examine
software artifacts to identify defects, improve quality, and ensure
adherence to standards.
o It involves static analysis of documents, code, or other deliverables
without executing the software.
o Common types of reviews include:
▪ Peer Reviews: Colleagues review each other’s work to catch
errors, improve clarity, and share knowledge.
▪ Management Reviews: Higher-level management assesses
project progress and quality.
▪ Code Reviews: Developers scrutinize code for correctness,
maintainability, and adherence to coding standards.
o Reviews help identify issues early, promote knowledge sharing, and
enhance overall quality.
2. Inspection:
o Inspection is a formal review process with specific guidelines and
predefined roles.
o It aims to find defects systematically by analyzing artifacts such as
requirements, design documents, or code.
o Key characteristics of inspections:
▪ Structured Process: Follows a well-defined procedure.
▪ Roles: Includes roles like moderator, author, and reviewers.
▪ Checklists: Reviewers use checklists to identify common issues.
▪ Focused on Defect Detection: Primarily seeks defects rather
than broader quality aspects.
o Inspections are rigorous and methodical, making them effective for
defect prevention.
3. Audit:
o A software audit is a comprehensive examination of a software
product to assess its quality, adherence to standards, and compliance
with regulations.
o Key points about software audits:
▪ Purpose: To verify the health of the product, progress, and
adherence to best practices.
▪ Internal vs. External Audits:
▪ Internal Audit: Conducted within the organization by an
internal team.
▪ External Audit: Performed by independent auditors
(external agencies).
▪ Benefits of Software Audits:
▪ Validates testing processes and identifies optimization
opportunities.
▪ Ensures alignment with requirements and delivered
features.
▪ Verifies compliance with regulations and best practices.
▪ Mitigates potential risks.
▪ Provides actionable suggestions for improvement.
▪ Types of Software Audits:
 ▪ Project Metrics: Assess project progress and
performance.
▪ Product Metrics: Evaluate the quality and health of the
software product.
▪ People Metrics: Analyze team performance and
collaboration.

In summary, reviews, inspections, and audits play crucial roles in maintaining

software quality, preventing defects, and ensuring compliance. Each method serves
specific purposes and contributes to overall software excellence