Module 1- Introduction to software testing

Ariane 5
On June 4th, 1996, the very first Ariane 5 rocket ignited its engines and began speeding away from the coast of French
Guiana. 37 seconds later, the rocket flipped 90 degrees in the wrong direction, and less than two seconds later,
aerodynamic forces ripped the boosters apart from the main stage at a height of 4km. This caused the self-destruct
mechanism to trigger, and the spacecraft was consumed in a gigantic fireball of liquid hydrogen.
The disastrous launch cost approximately $370m, led to a public inquiry, and through the destruction of the rocket’s
payload, delayed scientific research into the workings of the Earth’s magnetosphere for almost 4 years. The Ariane 5
launch is widely acknowledged as one of the most expensive software failures in history.
The fault was quickly identified as a software bug in the rocket’s Inertial Reference System. The rocket used this system
to determine whether it was pointing up or down, which is formally known as the horizontal bias, or informally as a BH
value. This value was represented by a 64-bit floating variable, which was perfectly adequate.
However, problems began to occur when the software attempted to stuff this 64-bit variable, which can represent billions
of potential values, into a 16-bit integer, which can only represent 65,535 potential values. For the first few seconds of
flight, the rocket’s acceleration was low, so the conversion between these two values was successful. However, as the
rocket’s velocity increased, the 64-bit variable exceeded 65k, and became too large to fit in a 16-bit variable. It was at
this point that the processor encountered an operand error, and populated the BH variable with a diagnostic value.

Therac 25
The Therac-25 was a computerized radiation therapy machine produced by Atomic Energy of Canada Limited (AECL)
after the Therac-6 and Therac-20 units. The Therac-20, a predecessor of the Therac-25, employed independent protective
circuits and mechanical interlocks to protect against overdose. The Therac-25 relied more heavily on software. Before
release of Therac-25 on the US market, AECL obtained approval to market it from the FDA. This approval was obtained
by declaring what FDA called pre-market equivalence.
The accidents occurred when the high-power electron beam was activated instead of the intended low power beam, and
without the beam spreader plate rotated into place. The machine's software did not detect that this had occurred, and
therefore did not prevent the patient from receiving a potentially lethal dose of radiation. The machine massively
overdosed patients at least six times between June 1985 and January 1987. Each overdose was several times the normal
therapeutic dose and resulted in the patient's severe injury or even death.

Intel Pentium bug

The Pentium FDIV bug is the most famous (or infamous) of the Intel microprocessor bugs. It was caused by an error in
a lookup table that was a part of Intel's SRT algorithm that was to be faster and more accurate.
With a goal to boost the execution of floating-point scalar code by 3 times and vector code by 5 times, compared to the
486DX chip, Intel decided to use the SRT algorithm that can generate two quotient bits per clock cycle, while the
traditional 486 shift-and-subtract algorithm was generating only one quotient bit per cycle.
This SRT algorithm uses a lookup table to calculate the intermediate quotients necessary for floating-point division.
Intel's lookup table consists of 1066 table entries, of which, due to a programming error, five were not downloaded into
the programmable logic array (PLA). When any of these five cells is accessed by the floating-point unit (FPU), it fetches
zero instead of +2, which was supposed to be contained in the missing cells. This throws off the calculation and results
in a less precise number than the correct answer (Byte Magazine, March 1995).
At its worst, this error can occur as high as the fourth significant digit of a decimal number, but the possibilities of this
happening are 1 in 360 billion. It is most common that the error appears in the 9th or 10th decimal digit, which yields a
chance of this happening of 1 in 9 billion.
Intel has classified the bug (or the flaw, as they refer to it) with the following characteristics:
• On certain input data, the FPDI (Floating Point Divide Instructions) on the Pentium processor produce
inaccurate results.
• The error can occur in any of the three operating precisions, namely single, double, or extended, for the divide
instruction.
• The incidence of the problem is independent of the processor rounding modes.
• The occurrence of the problem is highly dependent on the input data.
• The degree of inaccuracy depends on the input data and upon the instruction involved.
• The problem does not occur on the specific use of the divide instruction to compute the reciprocal of the input
operand in single precision.

Software Testing
Software testing can be stated as the process of verifying and validating whether a software or application is bug-free,
meets the technical requirements as guided by its design and development, and meets the user requirements effectively
and efficiently by handling all the exceptional and boundary cases.
The process of software testing aims not only at finding faults in the existing software but also at finding measures to
improve the software in terms of efficiency, accuracy, and usability. It mainly aims at measuring the specification,
functionality, and performance of a software program or application.

Why should it be tested?

Software testing can be stated as the process of verifying and validating whether a software or application is bug-free,
meets the technical requirements as guided by its design and development, and meets the user requirements effectively
and efficiently by handling all the exceptional and boundary cases.
The process of software testing aims not only at finding faults in the existing software but also at finding measures to
improve the software in terms of efficiency, accuracy, and usability. It mainly aims at measuring the specification,
functionality, and performance of a software program or application.

Software Quality
Software quality product is defined in term of its fitness of purpose. That is, a quality product does precisely what the
users want it to do. For software products, the fitness of use is generally explained in terms of satisfaction of the
requirements laid down in the SRS document.
Example: Consider a functionally correct software product. That is, it performs all tasks as specified in the SRS
document. But, has an almost unusable user interface. Even though it may be functionally right, we cannot consider it
to be a quality product.
Portability
Usability
Reusability
Correctness
Maintainability
Example:
Consider a functionally correct software product. That is, it performs all tasks as specified in the SRS document. But,
has an almost unusable user interface. Even though it may be functionally right, we cannot consider it to be a quality
product.
The modern view of a quality associated with a software product several quality methods such as the following:
Portability:
A software device is said to be portable, if it can be freely made to work in various operating system environments, in
multiple machines, with other software products, etc.
Usability:
A software product has better usability if various categories of users can easily invoke the functions of the product.
Reusability:
A software product has excellent reusability if different modules of the product can quickly be reused to develop new
products.
Correctness:
A software product is correct if various requirements as specified in the SRS document have been correctly implemented.
Maintainability:
A software product is maintainable if bugs can be easily corrected as and when they show up, new tasks can be easily
added to the product, and the functionalities of the product can be easily modified, etc.

Role of Testing
A Software tester (software test engineer) should be capable of designing test suites and should have the ability to
understand usability issues. Such a tester is expected to have sound knowledge of software test design and test execution
methodologies. It is very important for a software tester to have great communication skills so that he can interact with
the development team efficiently.
The roles and responsibilities for a usability software tester are as follows:
1. A Software Tester is responsible for designing testing scenarios for usability testing.
2. He is responsible for conducting the testing, thereafter analyze the results and then submit his observations to
the development team.
3. He may have to interact with the clients to better understand the product requirements or in case the design
requires any kind of modifications.
4. Software Testers are often responsible for creating test-product documentation and also has to participate in
testing related walk through.
5. Prepare status report of testing activities
6. Required interactions with the customers
7. Updating project manager regularly about the progress of testing activities.

Testing Process
Level 0: There’s no difference between testing and debugging.
Level 1: The purpose of testing is to show that the software works.
Level 2: The purpose of testing is to show that the software doesn’t work.
Level 3: The purpose of testing is not to prove anything specific, but to reduce the risk of using the software.
Level 4: Testing is a mental discipline that helps all IT professionals develop higher-quality software.
Level 0 is the view that testing is the same as debugging. This is the view that is naturally adopted by many undergraduate
computer science majors. In most CS programming classes, the students get their programs to compile, then debug the
programs with a few inputs chosen either arbitrarily or provided by the professor. This model does not distinguish
between a program’s incorrect behavior and a mistake within the program, and does very little to help develop software
that is reliable or safe.
In Level 1 testing, the purpose is to show correctness. While a significant step up from the naive level 0, this has the
unfortunate problem that in any but the most trivial of programs, correctness is virtually impossible to either achieve or
demonstrate. Suppose we run a collection of tests and find no failures. What do we know? Should we assume that we
have good software or just bad tests? Since the goal of correctness is impossible, test engineers usually have no strict
goal, real stopping rule, or formal test technique. If a development manager asks how much testing remains to be done,
the test manager has no way to answer the question. In fact, test managers are in a powerless position because they have
no way to quantitatively express or evaluate their work.
In Level 2 testing, the purpose is to show failures. Although looking for failures is certainly a valid goal, it is also a
negative goal. Testers may enjoy finding the problem, but the developers never want to find problems – they want the
software to work (level 1 thinking is natural for the developers). Thus, level 2 testing puts testers and developers into an
adversarial relationship, which can be bad for team morale. Beyond that, when our primary goal is to look for failures,
we are still left wondering what to do if no failures are found. Is our work done? Is our software very good, or is the
testing weak?
The thinking that leads to Level 3 testing starts with the realization that testing can show the presence, but not the
absence, of failures. This lets us accept the fact that whenever we use software, we incur some risk. The risk may be
small and the consequences unimportant, or the risk may be great and the consequences catastrophic, but risk is always
there. This allows us to realize that the entire development team wants the same thing – to reduce the risk of using the
software.
In level 3 testing, both testers and developers work together to reduce risk. Once the testers and developers are on the
same “team,” an organization can progress to real Level 4 testing.
Level 4 thinking defines testing as a mental discipline that increases quality. Various ways exist to increase quality, of
which creating tests that cause the software to fail is only one. Adopting this mindset, testers can become the technical
leaders of the project. They have the primary responsibility of measuring and improving software quality, and their
expertise should help the developers.
An analogy that Beizer used is that of a spell checker. We often think that the purpose of a spell checker is to find
misspelled words, but in fact, the best purpose of a spell checker is to improve our ability to spell. Every time the spell
checker finds an incorrectly spelled word, we have the opportunity to learn how to spell the word correctly. The spell
checker is the “expert” on spelling quality. In the same way, level 4 testing means that the purpose of testing is to improve
the ability of the developers to produce high quality software. The testers should train your developers.

Verification and Validation

Verification is the process of checking that a software achieves its goal without any bugs. It is the process to ensure
whether the product that is developed is right or not. It verifies whether the developed product fulfills the requirements
that we have. Verification is static testing.

Verification means Are we building the product right?

Validation is the process of checking whether the software product is up to the mark or in other words product has
high level requirements. It is the process of checking the validation of product i.e. it checks what we are developing is
the right product. It is validation of actual and expected product. Validation is dynamic testing.

Verification vs Validation
Validation means: Are we building the right product?

Verification Validation

It includes checking documents, design, codes and It includes testing and validating the actual product.
programs.

Verification is the static testing. Validation is the dynamic testing.

It does not include the execution of the code. It includes the execution of the code.
 Methods used in verification are reviews, Methods used in validation are Black Box Testing, White
walkthroughs, inspections and desk-checking. Box Testing and non-functional testing.

It checks whether the software conforms to It checks whether the software meets the requirements and
specifications or not. expectations of a customer or not.

It can find the bugs in the early stage of the It can only find the bugs that could not be found by the
development. verification process.

The goal of verification is application and software The goal of validation is an actual product.
architecture and specification.

Quality assurance team does verification. Validation is executed on software code with the help of
testing team.

It comes before validation. It comes after verification.

It consists of checking of documents/files and is It consists of execution of program and is performed by
performed by human. computer.

Verification refers to the set of activities that ensure Validation refers to the set of activities that ensure that the
software correctly implements the specific function. software that has been built is traceable to customer
requirements.

After a valid and complete specification the Validation begins as soon as project starts.
verification starts.
Verification is for prevention of errors. Validation is for detection of errors.

Verification is also termed as white box testing or Validation can be termed as black box testing or dynamic
static testing as work product goes through reviews. testing as work product is executed.
Verification finds about 50 to 60% of the defects. Validation finds about 20 to 30% of the defects.

Verification is based on the opinion of reviewer and Validation is based on the fact and is often stable.
may change from person to person.

Verification is about process, standard and guideline. Validation is about the product.

BUG
In software testing, a bug is the informal name of defects, which means that software or application is not working as
per the requirement. When we have some coding error, it leads a program to its breakdown, which is known as a bug.
The test engineers use the terminology Bug.
If a QA (Quality Analyst) detect a bug, they can reproduce the bug and record it with the help of the bug report template.

Error
The problem in code leads to errors, which means that a mistake can occur due to the developer's coding error as the
developer misunderstood the requirement or the requirement was not defined correctly. The developers use the term
Error.

Fault
The fault may occur in software because it has not added the code for fault tolerance, making an application act up.
A fault may happen in a program because of the following reasons:
• Lack of resources
 • An invalid step
• Inappropriate data definition

Test Case
The test case is defined as a group of conditions under which a tester determines whether a software application is
working as per the customer's requirements or not. Test case designing includes preconditions, case name, input
conditions, and expected result. A test case is a first level action and derived from test scenarios.
Test case gives detailed information about testing strategy, testing process, preconditions, and expected output. These
are executed during the testing process to check whether the software application is performing the task for that it was
developed or not.
Test case helps the tester in defect reporting by linking defect with test case ID. Detailed test case documentation works
as a full-proof guard for the testing team because if developer missed something, then it can be caught during execution
of these full-proof test cases.
To write the test case, we must have the requirements to derive the inputs, and the test scenarios must be written so that
we do not miss out on any features for testing. Then we should have the test case template to maintain uniformity, or
every test engineer follows the same approach to prepare the test document.

When do we write a Test Case?

We will write the test case when we get the following:
• When the customer gives the business needs, then the developer starts developing and says that they need 3.5
months to build this product.
• In the meantime, the testing team will start writing the test cases.
• Once it is done, it will be sent to the Test Lead for the review process.
• When the developers finish developing the product, it is handed over to the testing team.
• The test engineers never look at the requirement while testing the product document because testing is constant
and does not depend on the mood of the person, rather than the quality of the test engineer.

Coverage Criteria
A coverage criterion is a rule or collection of rules that impose test requirements on a test set and measure how well the
program is exercised by a test suite. One or more coverage criteria are used. There are a number of coverage criteria.
The coverage criterion describes test requirements completely and unambiguously.
• Function Coverage – Has each function in the program been executed?
• Statement Coverage – Has each line of the source code been executed?
• Condition Coverage – Has each evaluation point (such as a true/false decision) been executed?
• Path Coverage – Has every possible route through a given part of the code been executed?
• Entry/Exit Coverage – Has every possible call and return of the function been executed?

Types of Testing
1. Unit Testing
Unit testing is a method of testing individual units or components of a software application. It is typically done by
developers and is used to ensure that the individual units of the software are working as intended. Unit tests are usually
automated and are designed to test specific parts of the code, such as a particular function or method.
Unit testing is done at the lowest level of the software development process, where individual units of code are tested
in isolation.
Advantages of Unit Testing:
1. It helps to identify bugs early in the development process, before they become more difficult and expensive to
fix.
2. It helps to ensure that changes to the code do not introduce new bugs.
3. It makes the code more modular and easier to understand and maintain.
4. It helps to improve the overall quality and reliability of the software.

Integration Testing
Integration testing is a method of testing how different units or components of a software application interact with each
other. It is used to identify and resolve any issues that may arise when different units of the software are combined.
Integration testing is typically done after unit testing and before functional testing. It verifies that the different units of
the software work together as intended.
Types of Integration Testing:
1. Top-down integration testing – It starts with the highest-level modules and integrates them with lower-level
modules.
2. Bottom-up integration testing – It starts with the lowest-level modules and integrates them with higher-level
modules.
3. Big-Bang integration testing – It combines all the modules and integrates them all at once.
4. Incremental integration testing – It integrates the modules in small groups, testing each group as it is added.

Regression Testing
Regression testing is a method of testing that is used to ensure that changes made to the software do not introduce new
bugs or cause existing functionality to break. It is typically done after changes have been made to the code, such as bug
fixes or new features.
Methods of Regression Testing:
1. Retesting – Testing the entire application or specific functionality affected by the changes.
2. Re-execution – Running a previously executed test suite to ensure that the changes did not break existing
functionality.
3. Comparison – Comparing the current version of the software with a previous version to ensure no functionality
is broken.
Advantages of Regression Testing:
1. It helps ensure that changes do not introduce new bugs.
2. It ensures the software continues to work as intended after changes.
3. It improves the overall reliability and stability of the software.
4. Regression testing is an ongoing process throughout the software development lifecycle.
 5. It should be automated as much as possible to save time and resources, and a well-defined regression test suite
should be maintained.

System Testing
In system testing, the software is tested to ensure it works properly across different operating systems. It comes under
black box testing.
Here, the focus is on required input and output without considering the internal working of the system.
It includes:
• Security testing
• Recovery testing
• Stress testing
• Performance testing
Example:
This includes functional as well as non-functional testing.

Performance Testing
Performance testing is designed to test the run-time performance of software within the context of an integrated system.
It is used to test the speed and effectiveness of the program and is also called load testing.
In this testing, we check the performance of the system under a given load.

Example:
Checking several processor cycles.
Acceptance Testing
Acceptance testing is formal testing based on user requirements and function processing. It determines whether the
software is conforming to specified requirements and user requirements or not.
It is conducted as a kind of Black Box testing, where the required users are involved in testing the acceptance level of
the system. It is the fourth and last level of software testing.
User Acceptance Testing (UAT) is a type of testing which is done by the customer before accepting the final product.
Generally, UAT is done by the customer (domain expert) for their satisfaction and to check whether the application is
working according to given business scenarios and real-time scenarios.
In this, we concentrate only on those features and scenarios which are regularly used by the customer or mostly user
scenarios for the business, or those scenarios which are used daily by the end-user or the customer.
However, the software has passed through three testing levels (Unit Testing, Integration Testing, System Testing), but
still there are some minor errors which can be identified when the system is used by the end-user in the actual scenario.

Beta Testing
Beta testing is performed by real users of the software application in a real environment. It is one of the types of User
Acceptance Testing.
A beta version of the software is released to a limited number of end-users to obtain feedback on product quality. Beta
testing helps in minimizing product failure risks and provides increased quality through customer validation.
It is the last test before shipping a product to customers. One of the major advantages of beta testing is direct feedback
from customers.
Different Types of Beta Testing
1. Traditional Beta Testing
The product is distributed to the target market and related data is gathered in all aspects. This data can be used
for product improvement.
2. Public Beta Testing
The product is released publicly to the world through online channels, and data can be collected from anyone.
Based on the feedback, product improvements can be done.
Example: Microsoft conducted one of the largest beta tests for its operating system Windows 8 before
officially releasing it.
3. Technical Beta Testing
The product is released to a group of employees of an organization, and feedback or data is collected from the
employees.
4. Focused Beta Testing
The software product is released to the market for collecting feedback on specific features of the program,
such as important functionality of the software.
5. Post-release Beta Testing
The software product is released to the market, and data is collected to make improvements for future releases
of the product.

Functional Testing
Functional testing is a type of software testing used to verify the functionality of a software application, whether the
functions are working according to the requirement specification.
In functional testing, each function is tested by providing input, determining the output, and verifying the actual output
with the expected value. Functional testing is performed as black-box testing, which confirms that the functionality of
an application or system behaves as expected. It is done to verify the functionality of the application.
Functional testing is also called black-box testing because it focuses on application specification rather than actual code.
The tester has to test only the program rather than the system.

Goal of Functional Testing

The purpose of functional testing is to check:
• The primary entry functions
• Necessarily usable functions
• The flow of screen GUI
Functional testing displays error messages so that users can easily navigate throughout the application.

Steps Followed in Functional Testing

• Tester verifies the requirement specification in the software application.
• After analysis, the tester prepares a test plan based on the requirement specification.
• After planning the tests, the tester designs the test cases.
• After designing the test cases, the tester prepares the traceability matrix document.
 • The tester executes the designed test cases.
• Analysis of coverage is done to examine the covered testing areas of the application.
• Defect management is carried out to manage defect resolution.

Stress Testing
Stress testing is a software testing technique that determines the robustness of software by testing beyond the limits of
normal operation. Stress testing is particularly important for critical software but is used for all types of software.
Stress testing emphasizes robustness, availability, and error handling under heavy load rather than correct behavior under
normal conditions. It verifies the stability and reliability of the system and determines how the system behaves under
extremely heavy load conditions.
Stress testing goes beyond the normal operating point and analyzes how the system works under extreme conditions. It
is performed to ensure that the system does not crash during crunch situations.

Stress testing is also known as Endurance Testing or Torture Testing.

Characteristics of Stress Testing
1. Stress testing analyzes the behavior of the system after a failure.
2. Stress testing makes sure that the system recovers after failure.
3. It checks whether the system works under abnormal conditions.
4. It ensures the display of appropriate error messages when the system is under stress.
5. It verifies that unexpected failures do not cause security issues.
6. It verifies whether the system has saved the data before crashing or not.

Performance Testing
Performance testing is a non-functional testing technique performed to determine system parameters in terms of
responsiveness and stability under various workloads.
Performance testing measures quality attributes of the system such as scalability, reliability, and resource usage.
Performance Testing Techniques
• Load Testing
It is the simplest form of testing conducted to understand the behavior of the system under a specific load.
Load testing measures important business-critical transactions, and monitors the load on the database,
application server, etc.
• Stress Testing
It is performed to find the upper limit capacity of the system and to determine how the system performs when
the current load exceeds the expected maximum.
• Soak Testing
Soak testing, also known as endurance testing, is performed to determine system parameters under continuous
expected load. During soak testing, parameters such as memory utilization are monitored to detect memory
leaks or other performance issues. The main aim is to discover system performance under sustained use.
• Spike Testing
Spike testing is performed by suddenly increasing the number of users by a very large amount and measuring
system performance. The main aim is to determine whether the system can sustain the workload.
Usability Testing
Usability testing is a significant type of software testing technique that comes under non-functional testing.
It is primarily used in user-centered interaction design to check the usability or ease of use of a software product. The
implementation of usability testing requires an understanding of the application, as it involves extensive testing.
Generally, usability testing is performed from an end-user viewpoint to verify whether the system is efficiently working
or not.
It ensures that the software is easy to use for the intended end-user while sustaining the client’s specified functional and
business requirements.
Usability testing ensures that the developed software is straightforward to use without facing problems, making the end-
user’s life easier.
In other words, usability testing identifies defects in end-user communication with the software product, which is why
it is also known as User Experience (UX) Testing.
It helps fix several usability problems in a website or application while ensuring excellence and functionality.

Testing Methods
There are different methods that can be used for software testing.

Black-Box Testing
Black-box testing is a testing technique performed without any knowledge of the internal workings of the application.
The tester does not know the system architecture and does not have access to the source code.
During black-box testing, the tester interacts with the system’s user interface by providing inputs and examining outputs
without knowing how the inputs are processed internally.
Advantages of Black-Box Testing
• Well suited and efficient for large code segments.
• Code access is not required.
• Clearly separates the user’s perspective from the developer’s perspective.
• Large numbers of moderately skilled testers can test the application without knowledge of implementation,
programming language, or operating systems.
Disadvantages of Black-Box Testing
• Limited coverage, since only a selected number of test scenarios are performed.
• Inefficient testing due to limited knowledge of the application.
• Blind coverage, as the tester cannot target specific code segments or error-prone areas.
• Test cases are difficult to design.

White-Box Testing
White-box testing is the detailed investigation of internal logic and structure of the code. White-box testing is also called
glass testing or open-box testing. In order to perform white-box testing on an application, a tester needs to know the
internal workings of the code.
The tester needs to have a look inside the source code and find out which unit/chunk of the code is behaving
inappropriately.
The following table lists the advantages and disadvantages of white-box testing.
Advantages
• As the tester has knowledge of the source code, it becomes very easy to find out which type of data can help in
testing the application effectively.
• It helps in optimizing the code.
• Extra lines of code can be removed which can bring in hidden defects.
• Due to the tester's knowledge about the code, maximum coverage is attained during test scenario writing.
Disadvantages
• Due to the fact that a skilled tester is needed to perform white-box testing, the costs are increased.
• Sometimes it is impossible to look into every nook and corner to find out hidden errors that may create problems,
as many paths will go untested.
• It is difficult to maintain white-box testing, as it requires specialized tools like code analyzers and debugging
tools.

Grey-Box Testing
Grey-box testing is a technique to test the application with having a limited knowledge of the internal workings of an
application. In software testing, the phrase the more you know, the better carries a lot of weight while testing an
application.
Mastering the domain of a system always gives the tester an edge over someone with limited domain knowledge. Unlike
black-box testing, where the tester only tests the application's user interface; in grey-box testing, the tester has access to
design documents and the database. Having this knowledge, a tester can prepare better test data and test scenarios while
making a test plan.
Advantages
• Offers combined benefits of black-box and white-box testing wherever possible.
• Grey box testers don't rely on the source code; instead, they rely on interface definition and functional
specifications.
• Based on the limited information available, a grey-box tester can design excellent test scenarios especially
around communication protocols and data type handling.
• The test is done from the point of view of the user and not the designer.
Disadvantages
• Since the access to source code is not available, the ability to go over the code and test coverage is limited.
• The tests can be redundant if the software designer has already run a test case.
• Testing every possible input stream is unrealistic because it would take an unreasonable amount of time;
therefore, many program paths will go untested.

A Comparison of Testing Methods

The following table lists the points that differentiate Black-box testing, Grey-box testing, and White-box testing.
Black-Box Testing Grey-Box Testing White-Box Testing

The internal workings of an The tester has limited knowledge of the Tester has full knowledge of the
application need not be known. internal workings of the application. internal workings of the
application.

Also known as closed-box testing, Also known as translucent testing, as the Also known as clear-box testing,
data-driven testing, or functional tester has limited knowledge of the structural testing, or code-based
testing. insides of the application. testing.

Performed by end-users and also by Performed by end-users and also by Normally done by testers and
testers and developers. testers and developers. developers.
Testing is based on external Testing is done on the basis of high-level Internal workings are fully known
expectations – internal behaviour of database diagrams and data flow and the tester can design test data
the application is unknown. diagrams. accordingly.

It is exhaustive and the least time- Partly time-consuming and exhaustive. The most exhaustive and time-
consuming. consuming type of testing.

Not suited for algorithm testing. Not suited for algorithm testing. Suited for algorithm testing.

This can only be done by trial-and- Data domains and internal boundaries Data domains and internal
error method. can be tested, if known. boundaries can be better tested.