CST458 SOFTWARE TESTING

CST458 SOFTWARE TESTING

MODULE I

Some Popular Errors – Ariane 5, Therac 25, Intel Pentium Bug.

Ariane 5:- The Ariane 5 rocket, launched by the European Space Agency, was controlled by
software. This was the error in European space agency rocket. It occurred exactly 21 years
ago and the important thing to note that this error is because of a software [Link] error can
be described as follows: it was trying to squeeze in data corresponding to a 64-bit floating
point number into a memory space that is allotted for a 16-bit integer. So obviously it is not
going to be able to succeed in doing that. And because such rockets have safety critical
systems they always have backup software, but in this case the problem was ,the backup
software also had exactly the same error. So, this resulted in transmission of incorrect altitude
data to the aircraft and this rocket Ariane 5, went and plunged into the Atlantic Ocean within
36 seconds after it was launched. So, that is about 15 years of total effort and millions of
Euros had lost.

Therac 25:- The error in this case occurred due to a race condition in the software of a
radiation therapy machine, leading to a tragic miscalculation of radiation doses. The machine,
designed to administer controlled radiation for cancer treatment, delivered an overdose due to
the software flaw, resulting in the deaths of six patients. A race condition arises when the
behavior of a program depends on the timing or sequence of events in concurrent processes,
leading to unpredictable outcomes if not properly managed. This incident highlights the
critical importance of rigorous software testing, particularly in life-critical systems, to detect
and address concurrency issues. It also emphasizes the need for robust design practices,
adherence to regulatory standards, and continuous monitoring to ensure the safety and
reliability of such systems. The tragedy serves as a reminder of the ethical and professional
responsibility of software engineers to prioritize safety and thoroughly validate software
before deployment.

Intel Pentium Bug:- A U.S. mathematician, during research on prime numbers, identified
that the processor was performing floating-point division incorrectly. Upon investigation,
Intel discovered that the issue was present in all Pentium 4 processors already released. This
led to a large-scale product recall, resulting in significant financial losses for the company.

Prepared by, Neetha Alex, AP,CSE,TKMIT 1

 CST458 SOFTWARE TESTING

Software Testing
Testing is the execution of programs with the intent of finding defects. Software Testing is a
technical investigation of product ie an empirical search for quality related information of
value to a project‘s stakeholders. Software testing is the process of evaluating a software
application or system to identify defects, errors, or gaps in the requirements and ensure that it
functions as intended. The primary goal of software testing is to verify that the software
meets the specified requirements, operates reliably, and provides a high-quality user
experience.

Objectives of Testing
The stakeholders in a test process are the programmers, the test engineers, the project
managers, and the customers. A stakeholder is a person or an organization who influences a
system‘s behaviors or who is impacted by that system . Different stakeholders view a test
process from different perspectives as explained below

 It does work: While implementing a program unit, the programmer may want to test
whether or not the unit works in normal circumstances. The programmer gets much
confidence if the unit works to his or her satisfaction. The same idea applies to an
entire system as well—once a system has been integrated, the developers may want to
test whether or not the system performs the basic functions. Here, for the
psychological reason, the objective of testing is to show that the system works, rather
than it does not work.
 It does not work: Once the programmer (or the development team) is satisfied that a
unit (or the system) works to a certain degree, more tests are conducted with the
objective of finding faults in the unit (or the system). Here, the idea is to try to make
the unit (or the system) fail
 Reduce the risk of failure: Most of the complex software systems contain faults,
which cause the system to fail from time to time. This concept of ―failing from time to
time‖ gives rise to the notion of failure rate. As faults are discovered and fixed while
performing more and more tests, the failure rate of a system generally decreases.
Thus, a higher level objective of performing tests is to bring down the risk of failing
to an acceptable level
 Reduce the cost of testing: The different kinds of costs associated with a test process
include
o the cost of designing, maintaining, and executing test cases,
o the cost of analyzing the result of executing each test case,
o the cost of documenting the test cases, and
o the cost of actually executing the system and documenting it.

Therefore, the less the number of test cases designed, the less will be the associated cost of
testing. However, producing a small number of arbitrary test cases is not a good way of
saving cost. The highest level of objective of performing tests is to produce low-risk software

Prepared by, Neetha Alex, AP,CSE,TKMIT 2

 CST458 SOFTWARE TESTING

with fewer number of test cases. This idea leads us to the concept of effectiveness of test
cases. Test engineers must therefore judiciously select fewer, effective test cases

Software Quality
Quality is a complex concept—it means different things to different people, and it is highly
context dependent.

Kitchenham and Pfleeger‘s article on software quality gives a succinct exposition of software
quality. They discuss five views of quality in a comprehensive manner as follows:

1. Transcendental View:
Quality is subjective and hard to define, akin to recognizing it instinctively without a
precise explanation. For example, Justice Potter Stewart's famous "I know it when I
see it" remark reflects this view.
2. UsernView:
Quality is defined as the product's ability to meet user needs and expectations. It
focuses on fitness for purpose.
3. Manufacturing View:
Quality equates to conformance to specifications. A product's quality is determined by
how closely it adheres to predefined standards.
4. Product View:
Quality is rooted in the inherent characteristics of the product, where internal
attributes influence its external qualities.
5. Value-Based View:
Quality depends on the value customers place on it, influenced by how much they are
willing to pay for it.

McCall, Richards, and Walters were the first to study software quality in terms of quality
factors and quality criteria. A quality factor represents a behavioral characteristic of a
system. Some examples of high-level quality factors are correctness, reliability,
efficiency, testability, maintainability, and reusability. A quality criterion is an attribute of
a quality factor that is related to software development. For example, modularity is an
attribute of the architecture of a software system. A highly modular software allows
designers to put cohesive components in one module, thereby improving the
maintainability of the system
Various software quality models have been proposed to define quality and its related
attributes. The most influential ones are the ISO 9126 and the CMM . The ISO 9126
quality model was developed by an expert group under the aegis of the International
Organization for Standardization (ISO). The document ISO 9126 defines six broad,
independent categories of quality characteristics: functionality, reliability, usability,
efficiency, maintainability, and portability. The CMM was developed by the Software
Engineering Institute (SEI) at Carnegie Mellon University. In the CMM framework, a
development process is evaluated on a scale of 1–5, commonly known as level 1 through
level 5. For example, level 1 is called the initial level, whereas level 5—optimized—is the
highest level of process maturity

In the field of software testing, there are two well-known process models, namely, the test
process improvement (TPI) model and the test maturity Model (TMM) . These two
models allow an organization to assess the current state of their software testing

Prepared by, Neetha Alex, AP,CSE,TKMIT 3

 CST458 SOFTWARE TESTING

processes, identify the next logical area for improvement, and recommend an action plan
for test process improvement.

Role of Testing
Testing plays an important role in achieving and assessing the quality of a software
product . On the one hand, we improve the quality of the products as we repeat a test–find
defects–fix cycle during development. On the other hand, we assess how good our system
is when we perform system-level tests before releasing a product. Thus, as Friedman and
Voas have described, software testing as a verification process for software quality
assessment and improvement. Generally speaking, the activities for software quality
assessment can be divided into two broad categories, namely, static analysis and dynamic
analysis

• Static Analysis: As the term ―static‖ suggests, it is based on the examination of a

number of documents, namely requirements documents, software models, design
documents, and source code. Traditional static analysis includes code review,
inspection, walk-through, algorithm analysis, and proof of correctness. It does not
involve actual execution of the code under development. Instead, it examines code
and reasons over all possible behaviors that might arise during run time. Compiler
optimizations are standard static analysis.

• Dynamic Analysis: Dynamic analysis of a software system involves actual program

execution in order to expose possible program failures. The behavioral and
performance properties of the program are also observed. Programs are executed with
both typical and carefully chosen input values. Often, the input set of a program can
be impractically large. However, for practical considerations, a finite subset of the
input set can be selected. Therefore, in testing, we observe some representative
program behaviors and reach a conclusion about the quality of the system. Careful
selection of a finite test set is crucial to reaching a reliable conclusion

By performing static and dynamic analyses, practitioners want to identify as many faults as
possible so that those faults are fixed at an early stage of the software development. Static
analysis and dynamic analysis are complementary in nature, and for better effectiveness, both
must be performed repeatedly and alternated

Testing Process - Level 0 thinking, Level 1 thinking, Level 2 thinking, Level

3 thinking, Level 4 thinking

Broadly there are 5 levels for testing process , beginning from 0 and going all the way till 4.

Level 0 tells you that there is basically nothing called testing. Developers write their code,
they debug their code they ensure that it is correct and that is it, they go ahead and release it
right. So, it is clear that this does not really help to develop software that is considered to be
fully safe and [Link] this level testing is same as [Link] does not hep to develop a
software that is reliable and safe

Level one thinking a developer thinks that he or she has written a piece of code and their goal
to test is to be able to show that the code is correct. let us see a particular piece of code has an

Prepared by, Neetha Alex, AP,CSE,TKMIT 4

 CST458 SOFTWARE TESTING

integer variable. To be able to exhaustively tested on the 32 bit processor I need to be able to
give every value which is 2 power minus 32 to 2 power 32 plus or minus 1, and even when an
extra fast PC this is going to be able to take several years to do. So, unless I test it for every
value I cannot say that the testing is correct. So, here there is nothing like test engineers and
they even if there are they do not have goals and they just show that the software is not failed,
but the underlined listen it is not failed because it is correct or it is not failed because you
have designed the test cases wrongly, that is never clear.

The next level is level 2 thinking when you begin to believe that the goal of testing is to be
able to identify failures or errors in the software. This is the beginning of positively using
testing, but it organizations that are typically at this level there is lot of tiff between
developers and testers, they belong to different teams and then one does not want to help the
other, and there is confusion even though the goal of testing is fully realized.

In level 3 where they not only realize that the goal of testing is to find errors, but they also
work together and say that we will not only find errors, we will make sure that we reduce
errors to the extent possible in the software. And that is also conscious understanding that
when I release the software there is a bit of risk involved. The risk could be high or the risk
could be low and my goal is to make the risk as low as possible.

Level 4 thinking is where large organizations strive to be in, here testing becomes a mental
discipline. So, there is positive thought and efforts in the organization level to make sure that
testing teams' efforts are taken into consideration to develop software that is as error free as
possible. An organization like Microsoft which try to achieve excellence in level 4 thinking
and this is what is the desired level that we would like to achieve in testing.

Software Testing Terminologies - Verification, Validation and Testing,

Faults, Error and Bug, Test cases, Coverage Criteria

Verification

• The process of evaluating software to determine whether the products of a given

development phase satisfy the conditions imposed at the start of that phase.
• Verification is a static practice of verifying documents, design, code and program. It
includes all the activities associated with producing high quality software: inspection,
design analysis and specification analysis. It is a relatively objective process.
• Verification will help to determine whether the software is of high quality, but it will
not ensure that the system is useful. Verification is concerned with whether the system
is well-engineered and error-free.
• Verification activities are performed on interim products by applying mostly static
analysis techniques, such as inspection, walkthrough, and reviews, and using
standards and checklists.

Validation

• The process of evaluating software during or at the end of the development process to
determine whether it satisfies specified requirements.
• Validation is the process of evaluating the final product to check whether the software
meets the customer expectations and requirements. It is a dynamic mechanism of
validating and testing the actual product.

Prepared by, Neetha Alex, AP,CSE,TKMIT 5

 CST458 SOFTWARE TESTING

• Methods of Validation : Dynamic Testing

• Validation is performed on the entire system by actually running the system in its real
environment and using a variety of tests
• Validation is performed toward the end of system development to determine if the
entire system meets the customer‘s needs and expectations

Failure

A failure is said to occur whenever the external behavior of a system does not conform to
that prescribed in the system specification.

Error

An error is a state of the system. In the absence of any corrective action by the system, an
error state could lead to a failure which would not be attributed to any event subsequent to the
error

Fault

State of software caused by an error.

Bug

The presence of error at the time of execution of the software

Prepared by, Neetha Alex, AP,CSE,TKMIT 6

 CST458 SOFTWARE TESTING

Characteristic Fault Error Bug

Cause Defect in the Mistake by user or Specific instance of

software developer a fault or error

Effect Software fails to Software behaves in Software produces

meet its an unexpected way incorrect or
requirements unexpected results

Identification Found by developer Found by user or Found by developer

or tester tester or tester

Resolution Fixed by developer Corrected by user or Corrected by

tester developer

Defect

A defect is an error or a bug, in the application which is created. A programmer while

designing and building the software can make mistakes or error. These mistakes or errors
mean that there are flaws in the software. These are called defects.

Testcase

In its most basic form, a test case is a simple pair of < input, expected outcome >. If a
program under test is expected to compute the square root of nonnegative numbers, then four
examples of test cases are as shown

In stateless systems, where the outcome depends solely on the current input, test cases are
very simple in structure. A program to compute the square root of nonnegative numbers is an
example of a stateless system. A compiler for the C programming language is another
example of a stateless system. A compiler is a stateless system because to compile a program
it does not need to know about the programs it compiled previously. In state-oriented
systems, where the program outcome depends both on the current state of the system and the
current input, a test case may consist of a sequence of < input, expected outcome > pairs. A
telephone switching system and an automated teller machine (ATM) are examples of state-
oriented systems. For an ATM machine, a test case for testing the withdraw function is
shown below

Prepared by, Neetha Alex, AP,CSE,TKMIT 7

 CST458 SOFTWARE TESTING

Here, we assume that the user has already entered validated inputs, such as the cash card and
the personal identification number (PIN). In the test case TS1, ―check balance‖ and
―withdraw‖ in the first, second, and fourth tuples represent the pressing of the appropriate
keys on the ATM keypad. It is assumed that the user account has $500.00 on it, and the user
wants to withdraw an amount of $200.00. The expected outcome ―$200.00‖ in the third tuple
represents the cash dispensed by the ATM. After the withdrawal operation, the user makes
sure that the remaining balance is $300.00.

For state-oriented systems, most of the test cases include some form of decision and timing in
providing input to the system. A test case may include loops and timers.

Coverage Criteria

 Coverage criteria in software testing refer to the specific aspects or items of a

software system that are targeted for testing.
 These criteria help ensure that testing efforts are systematic, comprehensive, and
adequately cover the functionality and code of the software.
 Coverage criteria are adequacy measures to qualify if a test objective is satisfied
when executing test cases on a system under test.
 Coverage criteria are established to estimate the quality of test cases, and criteria
combinations are considered in software testing.

Types of Testing

Unit Testing

• Unit Testing is a level of software testing where individual units/ components of a

software are tested. The purpose is to validate that each unit of the software performs
as designed.
• Unit Testing is the first level of testing and is performed prior to Integration Testing.
• A unit is the smallest testable part of software. It usually has one or a few inputs and
usually a single output.
• It is executed by the Developer.
• Unit Testing is performed by using the White Box Testing method
• Example: - A function, method, Loop or statement in program is working fine.

Prepared by, Neetha Alex, AP,CSE,TKMIT 8

 CST458 SOFTWARE TESTING

Drivers

• Drivers are used in bottom-up integration testing approach.

• It can simulate the behavior of upper-level module that is not integrated yet.
• Drivers modules act as the temporary replacement of module and act as the actual
products.
• Drivers are also used for interact with external system and usually complex than
stubs.
• Driver: Calls the Module to be tested.
• Now suppose you have modules B and C ready but module A which calls functions
from module B and C is not ready so developer will write a dummy piece of code for
module A which will return values to module B and C. This dummy piece of code is
known as driver.

Stubs

• Stubs are used in top down integration testing.

• It can simulate the behavior of lower-level module that are not integrated.
• They are act as a temporary replacement of module and provide same output as actual
product.
• When needs to intact with external system then also stubs are used.
• Stub: Is called by the Module under Test.
• Assume you have 3 modules, Module A, Module B and module C. Module A is ready
and we need to test it, but module A calls functions from Module B and C which are
not ready, so developer will write a dummy module which simulates B and C and
returns values to module A. This dummy module code is known as stub.

Prepared by, Neetha Alex, AP,CSE,TKMIT 9

 CST458 SOFTWARE TESTING

Benefits

• Unit testing increases confidence in changing/ maintaining code. If good unit tests are
written and if they are run every time any code is changed, we will be able
to promptly catch any defects introduced due to the change.
• Codes are more reusable.
• Development is faster.
• The cost of fixing a defect detected during unit testing is lesser in comparison to that
of defects detected at higher levels.
• Debugging is easy.

Integration Testing

• Integration Testing is a level of software testing where individual units are combined
and tested as a group.
• In integration Testing, individual software modules are integrated logically and tested
as a group.
• Integration testing tests integration or interfaces between components, interactions to
different parts of the system such as an operating system, file system and hardware or
interfaces between systems.
• As displayed in the image below when two different modules ‗Module A‘ and
‗Module B‘ are integrated then the integration testing is done.

Integration Testing Approaches

Prepared by, Neetha Alex, AP,CSE,TKMIT 10

 CST458 SOFTWARE TESTING

Big Bang integration testing

In Big Bang integration testing all components or modules are integrated simultaneously,
after which everything is tested as a whole. As per the below image all the modules from
‗Module 1‘ to ‗Module 6‘ are integrated simultaneously then the testing is carried out.

Pros And Cons

• Convenient for small systems.

• Fault Localization is difficult.
• Since all modules are tested at once, high risk critical modules are not isolated and
tested on priority.
• Since the integration testing can commence only after "all" the modules are designed,
testing team will have less time for execution in the testing phase.

Top down Integration:

• In Top to down approach, testing takes place from top to down following the control
flow of the software system.
• Takes help of stubs for testing.

Prepared by, Neetha Alex, AP,CSE,TKMIT 11

 CST458 SOFTWARE TESTING

Advantages:

• Fault Localization is easier.

• Possibility to obtain an early prototype.
• Critical Modules are tested on priority; major design flaws could be found and fixed
first.

Disadvantages:

• Needs many Stubs.

• Modules at lower level are tested inadequately.

Bottom up Integration

• In the bottom up strategy, each module at lower levels is tested with higher modules
until all modules are tested.
• It takes help of Drivers for testing

Advantages:

• Fault localization is easier.

• No time is wasted waiting for all modules to be developed unlike Big-bang approach

Disadvantages:

• Critical modules (at the top level of software architecture) which control the flow of
application are tested last and may be prone to defects.
• Early prototype is not possible

Prepared by, Neetha Alex, AP,CSE,TKMIT 12

 CST458 SOFTWARE TESTING

System Testing

• The process of testing of an integrated hardware and software system to verify that the
system meets its specified requirements.
• It is performed when integration testing is completed.
• It is mainly a black box type testing. This testing evaluates working of the system
from a user point of view, with the help of specification document. It does not require
any internal knowledge of system like design or structure of the code.
• It contains functional and non-functional areas of application/product.
• System testing is performed in the context of a System Requirement Specification
(SRS) and/or a Functional Requirement Specifications (FRS). It is the final test to
verify that the product to be delivered meets the specifications mentioned in the
requirement document. It should investigate both functional and non-functional
requirements.
• It mainly focuses on following:
• External interfaces
• complex functionalities
• Security
• Recovery
• Performance
• Operator and user’s smooth interaction with system
• Documentation
• Usability
• Load / Stress

Performance Testing

• Performance Testing is a type of testing to ensure software applications will perform

well under their expected workload.
• A software application's performance like its response time, reliability, resource
usage and scalability do matter.

Prepared by, Neetha Alex, AP,CSE,TKMIT 13

 CST458 SOFTWARE TESTING

• The goal of Performance Testing is not to find bugs but to eliminate performance
bottlenecks.
• The focus of Performance Testing is checking a software program's

 Speed - Determines whether the application responds quickly

 Scalability - Determines maximum user load the software application can handle.
 Stability - Determines if the application is stable under varying loads

1) Identify your testing environment –

Do proper requirement study & analyzing test goals and its objectives. Also determine
the testing scope along with test Initiation Checklist. Identify the logical and physical
production architecture for performance testing, identify the software, hardware and
networks configurations required for kick off the performance testing. Compare the
both test and production environments while identifying the testing environment. Get
resolve the environment-related concerns if any, analyze that whether additional tools
are required for performance testing. This step also helps to identify the probable
challenges tester may face while performance testing.

2) Identify the performance acceptance criteria –

Identify the desired performance characteristics of the application like Response time,
Throughput and Resource utilization.

3) Plan & design performance tests –

Planning and designing performance tests involves identifying key usage scenarios,
determining appropriate variability across users, identifying and generating test data,
and specifying the metrics to be collected. Ultimately, these items will provide the
foundation for workloads and workload profiles. The output of this stage is

Prepared by, Neetha Alex, AP,CSE,TKMIT 14

 CST458 SOFTWARE TESTING

prerequisites for Test execution are ready, all required resources, tools & test data are
ready.

4) Configuring the test environment –

Prepare with conceptual strategy, available tools, designed tests along with testing
environment before execution. The output of this stage is configured load-generation
environment and resource-monitoring tools.

5) Implement test design –

According to test planning and design create your performance tests.

6) Execute the tests –

Collect and analyze the data.

Problem Investigation like bottlenecks (memory, disk, processor, process, cache,

network, etc.) resource usage like (memory, CPU, network, etc.,)

Generate the Performance analysis reports containing all performance attributes of the
application.

Based on the analysis prepare recommendation report.

Repeat the above test for the new build received from client after fixing the bugs and
implementing the recommendations

7) Analyze Results, Report, and Retest

Consolidate, analyze and share test results.

Based on the test report re-prioritize the test & re-execute the same. If any specific
test result within the specified metric limit & all results are between the thresholds
limits then testing of same scenario on particular configuration is completed.

Test objectives frequently include the following:

• Response time. For example, the product catalog must be displayed in less than
3 seconds.
• Throughput. For example, the system must support 100 transactions per second.
• Resource utilization. A frequently overlooked aspect is the amount of resources
your application is consuming, in terms of processor, memory, disk input output
(I/O), and network I/O.

Types of Performance Testing

• Load test
• Stress test
• Data Volume Testing

Prepared by, Neetha Alex, AP,CSE,TKMIT 15

 CST458 SOFTWARE TESTING

• Storage Testing

Stress Testing

• Stress Testing is performance testing type to check the stability of software when
hardware resources are not sufficient like CPU, memory, disk space etc.
• It is performed to find the upper limit capacity of the system and also to determine
how the system performs if the current load goes well above the expected maximum.
• Main parameters to focus during Stress testing are ―Response Time‖ and
―Throughput‖.
• Stress testing is Negative testing where we load the software with large number of
concurrent users/processes which cannot be handled by the systems hardware
resources. This testing is also known as Fatigue testing

Usability Testing

• In usability testing basically the testers tests the ease with which the user interfaces
can be used.
• It tests that whether the application or the product built is user-friendly or not.
• Usability Testing is a black box testing technique.
• Usability testing also reveals whether users feel comfortable with your application or
Web site according to different parameters – the flow, navigation and layout, speed
and content – especially in comparison to prior or similar applications.
• Usability Testing tests the following features of the software.
• How easy it is to use the software.
• How easy it is to learn the software.
• How convenient is the software to end user.

Usability testing includes the following five components:

• Learnability: How easy is it for users to accomplish basic tasks the first time they
encounter the design?
• Efficiency: How fast can experienced users accomplish tasks?
• Memorability: When users return to the design after a period of not using it, does the
user remember enough to use it effectively the next time, or does the user have to start
over again learning everything?
• Errors: How many errors do users make, how severe are these errors and how easily
can they recover from the errors?
• Satisfaction: How much does the user like using the system?

Benefits of usability testing to the end user or the customer:

• Better quality software

• Software is easier to use
• Software is more readily accepted by users
• Shortens the learning curve for new users

Acceptance Testing

Prepared by, Neetha Alex, AP,CSE,TKMIT 16

 CST458 SOFTWARE TESTING

• Acceptance Testing is a level of the software testing where a system is tested for
acceptability.
• The purpose of this test is to evaluate the system‘s compliance with the business
requirements and assess whether it is acceptable for delivery.
• Usually, Black Box Testing method is used in Acceptance Testing.
• Acceptance Testing is performed after System Testing and before making the system
available for actual use.
• The acceptance test cases are executed against the test data or using an acceptance test
script and then the results are compared with the expected ones.
• The goal of acceptance testing is to establish confidence in the system.
• Acceptance testing is most often focused on a validation type testing.

Acceptance Criteria

Acceptance criteria are defined on the basis of the following attributes

• Functional Correctness and Completeness

• Data Integrity
• Data Conversion
• Usability
• Performance
• Timeliness
• Confidentiality and Availability
• Installability and Upgradability
• Scalability
• Documentation

Types Of Acceptance Testing

• User Acceptance test

• Operational Acceptance test
• Contract Acceptance testing
• Compliance acceptance testing

• User Acceptance test

It focuses mainly on the functionality thereby validating the fitness-for-use of the

system by the business user. The user acceptance test is performed by the users and
application managers.

• Operational Acceptance test

Also known as Production acceptance test validates whether the system meets the
requirements for operation. In most of the organization the operational acceptance test
is performed by the system administration before the system is released. The
operational acceptance test may include testing of backup/restore, disaster recovery,
maintenance tasks and periodic check of security vulnerabilities.

• Contract Acceptance testing

Prepared by, Neetha Alex, AP,CSE,TKMIT 17

 CST458 SOFTWARE TESTING

It is performed against the contract‘s acceptance criteria for producing custom

developed software. Acceptance should be formally defined when the contract is
agreed.

• Compliance acceptance testing

It is also known as regulation acceptance testing is performed against the regulations

which must be adhered to, such as governmental, legal or safety regulations.

Advantages Of Acceptance Testing

• The functions and features to be tested are known.

• The details of the tests are known and can be measured.
• The tests can be automated, which permits regression testing.
• The progress of the tests can be measured and monitored.
• The acceptability criteria are known.

Disadvantages Of Acceptance Testing

• Requires significant resources and planning.

• The tests may be a re-implementation of system tests.
• It may not uncover subjective defects in the software, since you are only looking for
defects you expect to find.

Beta Testing

• Beta Testing is also known as field testing. It takes place at customer’s site. It sends
the system/software to users who install it and use it under real-world working
conditions.
• A beta test is the second phase of software testing in which a sampling of the
intended audience tries the product out
• The goal of beta testing is to place your application in the hands of real users outside
of your own engineering team to discover any flaws or issues from the user‘s
perspective that you would not want to have in your final, released version of the
application.
• Beta testing can be considered ―pre-release testing.

Advantages of beta testing

• You have the opportunity to get your application into the hands of users prior to
releasing it to the general public.
• Users can install, test your application, and send feedback to you during this beta
testing period.
• Your beta testers can discover issues with your application that you may have not
noticed, such as confusing application flow, and even crashes.
• Using the feedback you get from these users, you can fix problems before it is
released to the general public.
• The more issues you fix that solve real user problems, the higher the quality of your
application when you release it to the general public.

Prepared by, Neetha Alex, AP,CSE,TKMIT 18

 CST458 SOFTWARE TESTING

• Having a higher-quality application when you release to the general public will
increase customer satisfaction.
• These users, who are early adopters of your application, will generate excitement
about your application.

Regression Testing

• Regression Testing is defined as a type of software testing to confirm that a recent

program or code change has not adversely affected existing features.
• Regression Testing is nothing but full or partial selection of already executed test
cases which are re-executed to ensure existing functionalities work fine.
• This testing is done to make sure that new code changes should not have side effects
on the existing functionalities. It ensures that old code still works once the new code
changes are done.
• Regression Testing is required when there is a

 Change in requirements and code is modified according to the requirement

 New feature is added to the software
 Defect fixing
 Performance issue fix

Regression Testing Techniques :

Retest All

This is one of the methods for Regression Testing in which all the tests in the existing test
bucket or suite should be re-executed. This is very expensive as it requires huge time and
resources.

Regression Test Selection

Instead of re-executing the entire test suite, it is better to select part of test suite to be run

Test cases selected can be categorized as 1) Reusable Test Cases 2) Obsolete Test Cases.

Prepared by, Neetha Alex, AP,CSE,TKMIT 19

 CST458 SOFTWARE TESTING

Re-usable Test cases can be used in succeeding regression cycles.

Obsolete Test Cases can't be used in succeeding cycles.

Prioritization of Test Cases

Prioritize the test cases depending on business impact, critical & frequently used
functionalities. Selection of test cases based on priority will greatly reduce the regression test
suite.

Selecting test cases for regression testing

It was found from industry data that good number of the defects reported by customers were
due to last minute bug fixes creating side effects and hence selecting the Test Case for
regression testing is an art and not that easy.

Effective Regression Tests can be done by selecting following test cases –

 Test cases which have frequent defects

 Functionalities which are more visible to the users
 Test cases which verify core features of the product
 Test cases of Functionalities which has undergone more and recent changes
 All Integration Test Cases
 All Complex Test Cases
 Boundary value test cases
 Sample of Successful test cases
 Sample of Failure test cases

Regression Testing Tools

If your software undergoes frequent changes, regression testing costs will [Link]
such cases, Manual execution of test cases increases test execution time as well
as costs.

Following are most important tools used for both functional and regression testing:

Selenium: This is an open source tool used for automating web applications.
Selenium can be used for browser based regression testing.

Quick Test Professional (QTP): HP Quick Test Professional is automated software

designed to automate functional and regression test cases. It uses VBScript language
for automation. It is a Data driven, Keyword based tool.

Prepared by, Neetha Alex, AP,CSE,TKMIT 20

 CST458 SOFTWARE TESTING

Rational Functional Tester (RFT): IBM's rational functional tester is a Java tool
used to automate the test cases of software applications. This is primarily used for
automating regression test cases and it also integrates with Rational Test Manager.

Functional Testing

Functional testing is a type of software testing that focuses on the functionality of the
software. It is used to verify that the software meets the requirements that were
specified during the development process.

The important steps in functional testing are:

1. Identify the functionality to be tested. The first step is to identify the

functionality that needs to be tested. This can be done by reviewing the software
requirements specification (SRS).

2. Create test cases. Once the functionality to be tested has been identified, test
cases need to be created. Test cases are documents that describe the steps that need to
be taken to test a particular piece of functionality.

3. Execute the test cases. Once the test cases have been created, they need to be
executed. This involves running the software and following the steps that are
specified in the test cases.

4. Analyze the results. Once the test cases have been executed, the results need to
be analyzed. This involves looking for any errors or defects in the software.

5. Report the results. The results of the functional testing need to be reported to
the development team. This report should include a list of any errors or defects that
were found.

Functional testing is an important part of the software development process. It helps

to ensure that the software meets the requirements that were specified during the
development process. By following the steps outlined above, you can help to ensure
that your software is functional and free of errors.

Here are some additional tips for conducting effective functional testing:

● Use a variety of testing techniques. There are many different types of

functional testing techniques, such as black-box testing, white-box testing, and
boundary-value testing. Using a variety of techniques can help you to find a wider
range of errors.

● Test the software under different conditions. The software should be tested
under a variety of conditions, such as different operating systems, different hardware

Prepared by, Neetha Alex, AP,CSE,TKMIT 21

 CST458 SOFTWARE TESTING

configurations, and different data sets. Testing the software under different conditions
can help you to find errors that are only triggered by certain conditions.

●Get feedback from users. Once the functional testing is complete, you should get
feedback from users. This feedback can help you to identify any usability issues with
the software.

Acceptance Testing

Acceptance testing is a critical phase in the software testing lifecycle, primarily aimed at
determining whether a software application meets the business requirements and is ready for
deployment. This testing is typically performed by the end-users or stakeholders to validate
that the system behaves as expected in real-world scenarios.

The main objective of acceptance testing is to ensure that the software satisfies the
acceptance criteria and is functional enough for release to production.

Key Characteristics of Acceptance Testing:

1. Verification Against Business Requirements: The primary purpose of acceptance

testing is to confirm that the system works in line with business requirements and the
intended use cases.
2. End-User Involvement: Unlike functional or system testing, acceptance testing often
involves actual end-users or representatives from the business who verify the
software's capabilities and usability.
3. Real-World Scenarios: Acceptance tests are designed to simulate the real-world
environment in which the software will be used, focusing on how the application
performs under actual business conditions.
4. Final Testing Before Release: It serves as the final validation step before a product is
released to the customer or deployed in production.

Types of Acceptance Testing:

1. User Acceptance Testing (UAT):

o Definition: The process where end-users validate whether the software meets
the business requirements and is ready for use in a real-world setting.
o Who Performs It: End-users, clients, or business stakeholders.
o Key Focus: Ensures that the software performs the necessary tasks as
described in the requirements, and it often involves testing from the user‘s
perspective.
o Example: A customer service team using a new CRM system to check if it
allows them to track customer interactions properly.
2. Business Acceptance Testing (BAT):
o Definition: A variant of UAT that focuses more on verifying the software‘s
alignment with business processes rather than technical features.
o Who Performs It: Business analysts or business stakeholders.

Prepared by, Neetha Alex, AP,CSE,TKMIT 22

 CST458 SOFTWARE TESTING

oKey Focus: Ensures that the software‘s features are in alignment with the
business goals and objectives.
o Example: Verifying that a new inventory management system integrates well
with existing business operations.
3. Contract Acceptance Testing:
o Definition: Conducted to ensure that the software meets the terms and
conditions outlined in the contract, often with legal implications.
o Who Performs It: A combination of testers and stakeholders, including
representatives from both the vendor and the client.
o Key Focus: Ensures that the software meets all the contractual obligations
regarding functionality, performance, and other technical specifications.
o Example: Verifying that the delivered software meets the service level
agreement (SLA) regarding response times.
4. Alpha and Beta Testing:
o Alpha Testing: This is the initial phase of acceptance testing, often conducted
by internal staff, to ensure the system is functioning properly before releasing
it to a limited audience.
o Beta Testing: A limited version of the product is released to a small group of
external users to gather feedback and identify bugs before the final release.

Process of Acceptance Testing:

1. Requirement Review: The first step is to review the business requirements and
acceptance criteria, ensuring that they are clearly defined and understood.
2. Test Plan Creation: A detailed test plan is created, which outlines the test scenarios,
test cases, timelines, and resource requirements for performing the acceptance tests.
3. Test Case Design: Test cases are designed to cover real-world scenarios, edge cases,
and specific user flows based on the business requirements.
4. Test Execution: The test cases are executed by end-users or business stakeholders.
This can be done manually or using automated tools, depending on the complexity of
the test and the nature of the application.
5. Defect Reporting and Fixing: If issues or defects are found during acceptance
testing, they are reported to the development team for resolution.
6. Final Decision: After all tests are successfully completed and defects are resolved,
the stakeholders decide whether the software is ready for deployment based on the
acceptance testing results.

Advantages of Acceptance Testing:

1. Validation Against Business Needs: Ensures that the software meets the actual
business requirements and user expectations before being released.
2. Reduces Risk: Helps to identify potential issues early, preventing costly post-release
problems.
3. Stakeholder Confidence: Involvement of end-users and stakeholders provides
confidence that the software will meet their needs and is fit for its intended purpose.
4. Improves Quality: By performing UAT and other acceptance tests, the quality of the
software is improved as real-world conditions are taken into account.

Prepared by, Neetha Alex, AP,CSE,TKMIT 23

 CST458 SOFTWARE TESTING

Challenges in Acceptance Testing:

1. Ambiguous Requirements: If the business requirements are unclear or incomplete,

acceptance testing can be difficult to perform effectively.
2. Stakeholder Availability: Coordinating with stakeholders or end-users for
acceptance testing can be challenging, especially if they have limited availability.
3. Complex Test Environments: Setting up a real-world test environment that
accurately reflects user conditions can be complex and time-consuming.
4. Resistance to Change: End-users may be resistant to new systems or features,
making UAT a challenging and time-consuming process.

Best Practices for Acceptance Testing:

1. Clear Acceptance Criteria: Ensure that the acceptance criteria are well-defined and
understood by all stakeholders before starting the testing process.
2. Involve the Right Stakeholders: Involve actual end-users and business
representatives in the testing process to ensure real-world relevance.
3. Test Early and Often: Conduct acceptance testing early in the development cycle
(e.g., in the alpha or beta phase) to identify issues early.
4. Prepare Realistic Test Scenarios: Develop test cases that accurately reflect how the
system will be used in production.
5. Document Feedback and Results: Properly document the results of acceptance
testing and ensure that all feedback is communicated to the development team for
improvement.

Testing Methods

White Box Testing

White box testing, also known as clear box testing, structural testing, or glass box testing,
is a software testing technique where the internal structure, design, and implementation of the
application are known to the tester. Unlike black-box testing, which focuses on checking the
software's functionality without knowledge of its internal workings, white-box testing focuses
on testing the internal logic, code structure, and flow of the application.

In white-box testing, the tester has access to the code, architecture, and design documentation
and uses this knowledge to plan and execute test cases. The aim is to ensure that the system
behaves as expected from the inside, and that all internal components and paths are working
correctly.

Key Characteristics of White Box Testing:

1. Code Coverage: White box testing involves evaluating the code by checking the
paths, conditions, branches, and loops. It ensures that all parts of the code are tested
for correctness.

Prepared by, Neetha Alex, AP,CSE,TKMIT 24

 CST458 SOFTWARE TESTING

2. Internal Perspective: The tester has knowledge of the software‘s source code,
architecture, and logic, allowing them to create detailed test cases that cover all
internal aspects.
3. Test Case Design: Test cases are designed to evaluate specific code components,
such as functions, loops, and conditionals. The goal is to check the flow of the
program.
4. Automation: White box testing is often automated since it involves repeating specific
code paths that need frequent verification, making it ideal for unit testing, integration
testing, and continuous integration.

White Box Testing Techniques:

1. Statement Coverage:
o Definition: Ensures that every statement in the code is executed at least once
during testing.
o Goal: To test each line of code to ensure it works as expected.
o Example: If a code has multiple if statements, statement coverage ensures
each statement is executed at least once during testing.
2. Branch Coverage:
o Definition: Ensures that each decision (branch) in the code, such as if-else
statements or switch cases, is evaluated to both true and false outcomes at least
once.
o Goal: To test the decision points in the code and verify that all possible
branches are covered.
o Example: For an if-else condition, the test should cover both the true and false
paths.
3. Path Coverage:
o Definition: Ensures that all possible paths through the code (combinations of
statements and branches) are tested.
o Goal: To test every possible route through the program‘s code, including all
branches and loops.
o Example: For a loop that can iterate multiple times, path coverage would
ensure every possible number of iterations is tested.
4. Condition Coverage:
o Definition: Ensures that every boolean expression is evaluated to both true
and false at least once.
o Goal: To verify that all conditions within logical expressions are tested for
both true and false outcomes.
o Example: In a compound condition if (a && b), condition coverage would
test both cases where a is true/false and b is true/false.
5. Loop Coverage:
o Definition: Ensures that loops in the code are tested for both zero iterations,
one iteration, and multiple iterations.
o Goal: To check whether loops handle different iteration counts correctly.
o Example: For a for loop, loop coverage would test when the loop executes
zero times, one time, and more than one time.
6. Mutation Testing:
o Definition: Involves modifying the code in small ways (mutations) to check
whether the test cases can detect these changes.

Prepared by, Neetha Alex, AP,CSE,TKMIT 25

 CST458 SOFTWARE TESTING

o Goal: To assess the effectiveness of the test cases by verifying if they catch
the mutations.
o Example: Changing a + to a - in a mathematical expression and checking if
the test case detects the error.

Advantages of White Box Testing:

1. Thorough Testing: Since testers have access to the internal code, they can test every
part of the application, ensuring no part of the code is left untested.
2. Early Detection of Errors: White box testing helps detect errors in the code early in
the development cycle, improving the software‘s reliability.
3. Optimizes Code Efficiency: White box testing can help identify redundant code,
unnecessary loops, and inefficient logic, leading to optimized code.
4. Good for Unit and Integration Testing: It is highly effective for unit testing and
integration testing, where the internal workings of the system need to be verified.

Challenges of White Box Testing:

1. Requires Expertise: White box testing requires knowledge of the programming

language and the application‘s internal logic, making it difficult for non-technical
testers.
2. Time-Consuming: Designing detailed test cases based on the code structure can be
time-consuming, especially for large and complex applications.
3. Limited Coverage for External Factors: It focuses primarily on the internal
structure and logic, meaning it does not test the system's behavior from the end-user
perspective or cover external system interactions.
4. Difficulty in Testing Large Systems: In large applications with complex codebases,
ensuring full coverage of all code paths can be difficult and resource-intensive.

When to Use White Box Testing:

 Unit Testing: When testing individual components or functions of the system.

 Integration Testing: When verifying how multiple components or modules interact
with each other internally.
 Security Testing: To examine vulnerabilities in the code, such as checking for
unprotected APIs or improper handling of sensitive data.
 Performance Optimization: When aiming to identify inefficiencies in code logic,
such as redundant code, excessive loops, or memory leaks.
 Regression Testing: To ensure that the internal logic is not broken by new changes to
the codebase.

Black Box Testing

Black box testing is a software testing technique in which the internal structure, design, and
implementation of the system being tested are not known to the tester. The focus of black box

Prepared by, Neetha Alex, AP,CSE,TKMIT 26

 CST458 SOFTWARE TESTING

testing is on evaluating the functionality of the software from the user's perspective, ensuring
that it meets the specified requirements and behaves as expected.

In black box testing, the tester is only concerned with the input provided to the system and
the output generated, without any knowledge of how the system processes that input
internally.

Key Characteristics of Black Box Testing:

1. Input-Output Focus: The primary goal is to test the system‘s functionality by

providing inputs and checking if the output matches the expected results. The tester
does not need to know how the system arrives at that output.
2. No Knowledge of Internal Code: Black box testers do not have access to the source
code, database schema, or any other details of the internal workings of the software.
The testing is purely based on functional specifications.
3. End-User Perspective: Black box testing mimics how end-users interact with the
system, ensuring that it meets the business requirements and functions correctly in a
real-world scenario.
4. Test Cases Based on Requirements: Test cases are derived from the software‘s
functional requirements and user stories, which focus on the expected behavior and
user interface.

Types of Black Box Testing:

1. Functional Testing:
o Definition: This testing ensures that the software performs the required
functions as per the specifications.
o Objective: Verifies the application‘s functionality, including features like
login, form submission, data retrieval, and error handling.
o Example: Testing if a user can log in with valid credentials and access their
account.
2. Non-Functional Testing:
o Definition: Focuses on the non-functional aspects of the system, such as
performance, security, usability, and scalability.
o Objective: Ensures that the system not only works as intended but also meets
specific non-functional criteria.
o Example: Load testing to verify that a website can handle 1,000 simultaneous
users.
3. Regression Testing:
o Definition: Ensures that recent changes, such as bug fixes or new features,
have not introduced new defects into the existing system.
o Objective: Validates that the new changes do not negatively impact the
previous functionality.
o Example: Verifying that the "Add to Cart" feature still works after
implementing a payment gateway.
4. User Acceptance Testing (UAT):

Prepared by, Neetha Alex, AP,CSE,TKMIT 27

 CST458 SOFTWARE TESTING

o Definition: A form of black box testing where end-users or business

stakeholders test the system to verify if it meets their requirements and
expectations.
o Objective: Confirms that the system is ready for deployment and satisfies
business needs.
o Example: Business users testing a CRM system to check if it meets customer
data management requirements.
5. Smoke Testing:
o Definition: A preliminary test to check the basic functionality of the system
after a new build or update.
o Objective: Quickly checks if the system is stable enough to proceed with
more detailed testing.
o Example: Verifying if the application starts up and basic navigation is
functional after a new release.
6. Sanity Testing:
o Definition: Performed after receiving a software build, sanity testing checks
whether a specific part of the application functions correctly after changes
have been made.
o Objective: Verifies that the changes made (e.g., bug fixes) work as expected.
o Example: Testing if the issue with the "Save" button functionality is fixed
after a patch is applied.
7. Boundary Value Testing:
o Definition: Tests the system by focusing on the boundary values of input
ranges, as errors often occur at the edges of input domains.
o Objective: Validates that the system handles boundary conditions correctly.
o Example: Testing an age input field by entering values like 0, 18, 65, and 100
(upper and lower limits).

Advantages of Black Box Testing:

1. No Need for Code Knowledge: Since black box testing does not require knowledge
of the source code, it can be performed by testers who are not developers or do not
have programming expertise.
2. Realistic Testing: Black box testing simulates how end-users will interact with the
software, providing a more accurate representation of its usability and functionality.
3. Focus on Requirements: Test cases are derived from functional specifications, so
black box testing directly validates the system's compliance with business
requirements.
4. Effective for Large Systems: Black box testing is well-suited for testing large
systems or complex software applications, as it focuses on functionality rather than
internal complexity.
5. Helps in Identifying Missing Features: It helps identify missing functionality or
features that were not initially considered, ensuring the system meets user needs.

Challenges of Black Box Testing:

Prepared by, Neetha Alex, AP,CSE,TKMIT 28

 CST458 SOFTWARE TESTING

1. Limited Coverage: Since testers don‘t have access to the internal code, it‘s difficult
to know whether every part of the application has been tested, potentially leaving
some code paths untested.
2. Difficulty in Identifying Root Causes: Black box testing only identifies functional
issues but doesn‘t provide insight into the cause of the issues, which may make
debugging difficult.
3. Redundancy: Test cases may overlap or duplicate, especially if the requirements are
not well-defined, leading to inefficient testing.
4. Inability to Test Internal Functionality: It cannot test the internal working of the
system, such as the underlying logic, algorithm efficiency, or code quality.

Grey Box Testing

Grey box testing is a hybrid testing technique that combines elements of both black box and
white box testing. In grey box testing, the tester has partial knowledge of the internal
workings of the application but not full access to the code. This enables testers to design
more effective test cases by combining the advantages of both black box and white box
testing.

Grey box testing is commonly used to identify issues that may arise from the interaction
between the software's external functionality and its internal architecture. It is often applied
when the tester has access to the system architecture, database schemas, or other high-level
design documents but does not have full access to the source code.

Prepared by, Neetha Alex, AP,CSE,TKMIT 29

 CST458 SOFTWARE TESTING

Key Characteristics of Grey Box Testing:

1. Partial Knowledge of Internal Structures: In grey box testing, testers have access
to certain parts of the internal system, such as system architecture, database designs,
or API documentation, but not the full code. This partial knowledge allows testers to
design more focused and efficient test cases.
2. Combination of Black and White Box Testing: Grey box testing uses the
advantages of both black box and white box testing:
o Black Box: Testers focus on the system‘s functionality and user requirements
without delving deeply into the code.
o White Box: Testers use their knowledge of the system‘s architecture, code
flow, or underlying processes to create more effective tests.
3. Focus on Functional and Security Testing: Grey box testing often focuses on
security aspects and critical functionality, including areas where the system‘s internal
architecture may impact how data is processed or managed.
4. Limited Access to Source Code: Testers typically do not have access to the entire
source code, but they may have access to detailed technical documentation such as
API specifications or database schemas, which allows them to design more effective
tests.

Types of Grey Box Testing:

1. Functional Grey Box Testing:

o Definition: Tests the functionality of the software from an end-user
perspective, similar to black box testing, but with the advantage of partial
knowledge about the internal architecture.
o Objective: Validate that the software meets the specified requirements, but
with more informed test cases based on knowledge of the software's design.
o Example: Testing an application that interacts with an external API, where the
tester knows the API endpoints and can check if they are being called
correctly.
2. Security Testing:
o Definition: Focuses on identifying vulnerabilities and security flaws within
the system by leveraging knowledge of the system‘s design and architecture.
o Objective: Test the application for potential security issues such as SQL
injection, authentication flaws, or unauthorized access.
o Example: Testing how the system handles input validation in login forms,
where the tester understands how the authentication mechanism works.
3. Integration Testing:
o Definition: Verifies the correct interaction between different components or
systems by testing interfaces and data flow.
o Objective: Ensure that data flows correctly between the different modules and
that the system components interact properly.
o Example: Testing the integration between a web front-end and a back-end
database, where the tester has knowledge of the database schema and API
calls but does not need access to the source code.
4. Regression Testing:

Prepared by, Neetha Alex, AP,CSE,TKMIT 30

 CST458 SOFTWARE TESTING

o Definition: Verifies that new code changes have not introduced new issues or
broken existing functionality, especially in complex systems where
interactions between different modules are critical.
o Objective: Ensure that previously tested parts of the application continue to
function after changes or updates.
o Example: Testing if an update to one module affects other interconnected
modules, using knowledge of the system's structure to target areas likely to be
impacted.

Advantages of Grey Box Testing:

1. Better Test Coverage: Grey box testing allows for a more thorough exploration of
the application by combining functional testing with an understanding of the internal
system architecture, leading to better coverage of both functional and technical
aspects.
2. Effective Security Testing: Since testers have access to some internal details, they
can better evaluate security vulnerabilities, data flow issues, or improper access to
sensitive information, which might be missed in pure black box testing.
3. Faster Testing: Compared to white box testing, grey box testing can be faster as
testers are not reviewing the entire source code, but still have enough knowledge to
understand where the risks are and to focus on key areas.
4. Combination of Strengths: Grey box testing strikes a balance between the in-depth
testing of white box testing and the user-oriented approach of black box testing,
allowing testers to identify problems that might be overlooked in either approach
alone.

Challenges of Grey Box Testing:

1. Limited Knowledge: While testers have some insight into the internal workings, they
do not have full access to the code. This can limit their ability to conduct exhaustive
testing, especially when complex logic or algorithms are involved.
2. Requires Expertise: Testers need to have both functional knowledge (black box
skills) and some technical knowledge (white box skills). This may require testers to
have a higher skill level compared to black box testers.
3. Difficult to Maintain: Since the tester‘s understanding of the system is partial,
maintaining or updating test cases when the system undergoes significant changes can
be challenging.
4. Not Ideal for All Systems: Grey box testing may not be suitable for all applications,
especially those where security, performance, or other non-functional testing is not a
priority. For purely functional systems, black box testing may be more appropriate.

Prepared by, Neetha Alex, AP,CSE,TKMIT 31

 CST458 SOFTWARE TESTING

***************

Prepared by, Neetha Alex, AP,CSE,TKMIT 32