Black box testing

Black box testing is a type of software testing in which the functionality of the software is not known.

Black box testing can be done in the following ways:

1. Syntax-Driven Testing –
⮚ This type of testing is applied to systems that can be syntactically represented by some
language.
⮚ For example- compilers, language that can be represented by a context-free grammar.
In this, the test cases are generated so that each grammar rule is used at least once.

2. Equivalence partitioning –
⮚ It is often seen that many types of inputs work similarly so instead of giving all of them
separately we can group them and test only one input of each group.
⮚ The idea is to partition the input domain of the system into several equivalence classes
such that each member of the class works similarly, i.e., if a test case in one class
results in some error, other members of the class would also result in the same error.
The technique involves two steps:

a. Identification of equivalence class – Partition any input domain into a

minimum of two sets: valid values and invalid values. For example, if the
valid range is 0 to 100 then select one valid input like 49 and one invalid like
104.

b. Generating test cases – (i) To each valid and invalid class of input assign
a unique identification number. (ii) Write a test case covering all valid and
invalid test cases considering that no two invalid inputs mask each other. To
calculate the square root of a number, the equivalence classes will be: (a)
Valid inputs:
1. The whole number which is a perfect square- output will be an integer.
2. The whole number which is not a perfect square- output will be a
decimal number.
3. Positive decimals
4. Negative numbers(integer or decimal).
5. Characters other than numbers like “a”,”!”,”;”, etc.
3. Boundary value analysis –
 Boundaries are very good places for errors to occur.
 Hence if test cases are designed for boundary values of the input domain
then the efficiency of testing improves and the probability of finding errors
also increases.
 For example – If the valid range is 10 to 100 then test for 10,100 also apart
from valid and invalid inputs.
4. Cause effect Graphing –
 This technique establishes a relationship between logical input called causes
with corresponding actions called the effect.
 The causes and effects are represented using Boolean graphs.
 The following steps are followed:
1.Identify inputs (causes) and outputs (effect).
2.Develop a cause-effect graph.
3.Transform the graph into a decision table.
4.Convert decision table rules to test cases.
5. Requirement-based testing –
 It includes validating the requirements given in the SRS of a software
system.

6. Compatibility testing –
 The test case result not only depends on the product but is also on the
infrastructure for delivering functionality.
 When the infrastructure parameters are changed it is still expected to work
properly.
 Some parameters that generally affect the compatibility of software are:

1.Processor (Pentium 3, Pentium 4) and several processors.

2.Architecture and characteristics of machine (32-bit or 64-bit).
3.Back-end components such as database servers.
4.Operating System (Windows, Linux, etc).
Black Box Testing Type

The following are the several categories of black box testing:

1.Functional Testing
2.Regression Testing
3.Nonfunctional Testing (NFT)
Functional Testing:
 It determines the system’s software functional requirements.

Regression Testing:
 It ensures that the newly added code is compatible with the existing code.
 In other words, a new software update has no impact on the functionality of
the software.
 This is carried out after a system maintenance operation and upgrades.

Nonfunctional Testing:
 Nonfunctional testing is also known as NFT.
 This testing is not functional testing of software.
 It focuses on the software’s performance, usability, and scalability.
Tools Used for Black Box Testing:
1.Appium
2.Selenium
3.Microsoft Coded UI
4.Applitools
5.HP QTP.
Advantages of Black Box Testing:

•The tester does not need to have more functional knowledge or

programming skills to implement the Black Box Testing.
•It is efficient for implementing the tests in the larger system.
•Tests are executed from the user’s or client’s point of view.
•Test cases are easily reproducible.
•It is used in finding the ambiguity and contradictions in the functional
specifications.
Disadvantages of Black Box Testing:

•There is a possibility of repeating the same tests while implementing the testing
process.
•Without clear functional specifications, test cases are difficult to implement.
•It is difficult to execute the test cases because of complex inputs at different
stages of testing.
•Sometimes, the reason for the test failure cannot be detected.
•Some programs in the application are not tested.
•It does not reveal the errors in the control structure.
•Working with a large sample space of inputs can be exhaustive and consumes a
lot of time.
 Integration Testing

 Integration testing is the process of testing the interface between two

software units or modules.
 It focuses on determining the correctness of the interface.
 The purpose of integration testing is to expose faults in the interaction
between integrated units.
 Once all the modules have been unit tested, integration testing is
performed.
 Integration testing can be done by picking module by module.
 This can be done so that there should be proper sequence to be followed.
 And also if you don’t want to miss out on any integration scenarios then
you have to follow the proper sequence.
 Exposing the defects is the major focus of the integration testing and the
time of interaction between the integrated units.
Integration test approaches – There are four types of integration testing
approaches. Those approaches are the following:

1. Big-Bang Integration Testing –

 It is the simplest integration testing approach, where all the modules are
combined and the functionality is verified after the completion of
individual module testing.
 In simple words, all the modules of the system are simply put together
and tested.
 This approach is practicable only for very small systems.
 If an error is found during the integration testing, it is very difficult to
localize the error as the error may potentially belong to any of the
modules being integrated.
 So, debugging errors reported during big bang integration testing is very
expensive to fix.
Advantages:

It is convenient for small systems.

Disadvantages:

 There will be quite a lot of delay because you would have to wait for all the modules
to be integrated.
 High risk critical modules are not isolated and tested on priority since all modules
are tested at once.
 Not Good for long Projects.
2. Bottom-Up Integration Testing –

 In bottom-up testing, each module at lower levels is tested with higher

modules until all modules are tested.
 The primary purpose of this integration testing is that each subsystem tests
the interfaces among various modules making up the subsystem.
 This integration testing uses test drivers to drive and pass appropriate data
to the lower level modules.
Advantages:
•In bottom-up testing, no stubs(called programs) are required.
•A principle advantage of this integration testing is that several disjoint
subsystems can be tested simultaneously.
•It is easy to create the test conditions.
•Best for the applications that uses bottom up design approach.
•It is Easy to observe the test results.
Disadvantages:
•Driver(calling program/dummy units) modules must be produced.
•In this testing, the complexity that occurs when the system is made up of a
large number of small subsystems.
•As Far modules have been created, there is no working model can be
represented.
3. Top-Down Integration Testing –
 Top-down integration testing technique is used in order to simulate the
behaviour of the lower-level modules that are not yet integrated.
 In this integration testing, testing takes place from top to bottom.
 First, high-level modules are tested and then low-level modules and
finally integrating the low-level modules to a high level to ensure the
system is working as intended.
Advantages:

•Separately debugged module.

•Few or no drivers needed.
•It is more stable and accurate at the aggregate level.
•Easier isolation of interface errors.
•In this, design defects can be found in the early stages.

Disadvantages:

•Needs many Stubs.

•Modules at lower level are tested inadequately.
•It is difficult to observe the test output.
•It is difficult to stub design.
4. Mixed Integration Testing –
 A mixed integration testing is also called sandwiched integration testing.
 A mixed integration testing follows a combination of top down and bottom-up
testing approaches.
 In top-down approach, testing can start only after the top-level module have
been coded and unit tested.
 In bottom-up approach, testing can start only after the bottom level modules
are ready.
 This sandwich or mixed approach overcomes this shortcoming of the top-
down and bottom-up approaches.
 It is also called the hybrid integration testing. also, stubs and drivers are used
in mixed integration testing.
Advantages:

•Mixed approach is useful for very large projects having several sub projects.
•This Sandwich approach overcomes this shortcoming of the top-down and
bottom-up approaches.
•Parallel test can be performed in top and bottom layer tests.

Disadvantages:

•For mixed integration testing, it requires very high cost because one part has
Top-down approach while another part has bottom-up approach.
•This integration testing cannot be used for smaller systems with huge
interdependence between different modules.
What is Integration Testing?
Integration Testing is a division of software testing that tests interfaces between
different software components. Any software module will work well individually, but
when it’s integrated with a different module, there are chances where the software
might not behave as intended. This is when integration testing is performed to
ensure that the software works smoothly without any issues.
Why Should You Do Integration Testing?
•It is extremely difficult to find and fix defects in integrated components. Performing
Integration tests can help you in such cases.
•With integration testing, you can find and fix the bugs at the very start of the
development.
•This test runs faster than the end to end tests.
•This test will help you to find system issues like cache integration, corrupted
database schema, etc.
•With Integration Testing, you’ll be able to reduce the possibilities of software failure.
•Performing this testing will help you to check the structural changes when a user
moves from one module to the next.
•You can reduce the overall number of bugs in a system by fixing issues in the
Integrated modules.
•By performing integrated testing, you can cover multiple modules, thus providing
broader testing capabilities.
Types of Integration Testing:
Incremental Integration Testing

 Incremental integration testing is performed by combining logically

related two or more modules.
 Every module will be added one by one in the testing unit until the
testers complete the whole system.
 With this approach, you can test the system for defects at an early
stage in a smaller unit when it is reasonably easy to identify the
cause.
 This type of testing intends to pass the feedback to the developers at
the very start to fix the bugs.
 Bugs found with this testing can be fixed without disturbing the other
modules.
 This method generally uses stubs and drivers to set up the
transmission.
 Stubs and drivers are duplicate programs used to establish
communication.
 You can perform this integration test in three different approaches.
1. Bottom-up Integration Testing

 Here the testing starts from the lowest module in the architecture.
 The testing control flow moves upwards from the bottom.
 This method will be executed whenever the top modules are under
development.
 This method will use the drivers to restore the working of modules
that are missing.
 This way of approach has a high success ratio and is an efficient way
to test and develop a product.
 It is faster than the other traditional methods of testing.
2. Top-down Integration Testing

 In this approach, testing is performed from the top-most module in

the architecture.
 The testing control flow moves to the bottom from the top.
 This method will use stubs as duplicate programs to restore the
working of modules that are missing.
 This method is comparatively easier than the bottom-up approach
as it uses stubs, which are generally easier to write than the
drivers.
 With this approach, you can find the interface errors with ease
because of its incremental nature.
3. Sandwich Integration Testing

 It is a combination of Bottom-up and Top-down Approaches.

 In this approach, bottom modules are tested with top modules, at the
same time, the top modules are tested with the lower modules.
 The goal here is to reach the mid module by testing both top and
bottom modules simultaneously.
 This approach uses both stubs and drivers.
Big Bang Integration Testing

 This type of testing is usually performed only after all the modules are
developed.
 Once developed, all modules will be coupled to form a single software
system, and then the testing will be performed.
 This sort of testing generally suits smaller systems.
 Though every module will be developed before even starting the
integration testing, the biggest disadvantage here is some of your
resources will be unproductive as they have to wait for all the modules
to be developed before starting the testing process thus, making it
costly and time-consuming.
Why Black Box Testing

• Black Box testing helps in the overall functionality verification of the

system under test.
• Black Box testing is done based on requirements.
• Black Box testing addresses the stated requirements as well as
implied requirements.
• Black box testing encompasses the end user perspectives.
• Black Box testing handles valid and invalid inputs.
When to do Black Box Testing?

• Black box testing activities require involvement of the testing

team from the beginning of the software project life cycle,
regardless of the software development life cycle model chosen for
the project.

• Testers can get involved right from the requirements gathering

and analysis phase for the system under test.

• Test scenarios and test data are prepared during the test
construction phase of the test life cycle, when the software is in the
design phase
HOW TO DO BLACK BOX TESTING?

Black box testing exploits specifications to generate test cases in a

methodical way to avoid redundancy and to provide better
coverage.
The Various techniques are
• Requirements based testing
• Positive and negative testing
• Boundary value analysis
• Decision tables
• Equivalence partitioning
• State based or Graph based testing
• Compatibility testing
• User documentation testing
• Domain testing
Integration Testing

• Integration Testing as a Type of Testing

• Integration Testing as a Phase of Testing

• Scenario Testing

• Defect Bash
Integration Testing as a Type of Testing

• Integration is both a phase and a type of testing.

• Integration testing is both a type of testing and a phase of testing.
• As integration is defined to be a set of interactions, all defined
interactions among the components need to be tested.
• Integration testing means testing of interfaces.
• They are internal interfaces and exported or external interfaces.
• Integration testing type focuses on testing interfaces that are
“implicit and explicit” and “internal and external.”

There are several methodologies available, to in decide the order for

integration testing.
These are as follows.
• Top-down integration
• Bottom-up integration
• Bi-directional integration
• System integration
INTEGRATION TESTING AS A PHASE OF TESTING
• Integration testing as a phase of testing starts from the point where two components
can be tested together, to the point where all the components work together as a
complete system delivering system/product functionality
• The integration testing phase focuses on finding defects which predominantly arise
because of combining various components for testing, and should not be focused on
for component or few components
• Integration testing as a type focuses on testing the interfaces.
• All testing activities that are conducted from the point where two components are
integrated to the point where all system components work together, are considered a
part of the integration testing phase.
• Integration testing as a phase involves different activities and different types of
testing have to be done in that phase.
• This is a testing phase that should ensure completeness and coverage of testing for
functionality.
• To achieve this, the focus should not only be on planned test case execution but also
on unplanned testing, which is termed as “ad hoc testing.”
• The integration testing phase involves developing and executing test cases that
cover multiple components and functionality
• When the functionality of different components are combined and tested together for
a sequence of related operations, they are called scenarios.
 Scenario Testing

 Scenario Testing is a Software Testing Technique that uses scenarios i.e.

speculative stories (guess rather than knowledge) to help the tester work
through a complicated problem or test system.
 The ideal scenario test is a reliable, complicated, convincing or motivating story
the outcome of which is easy to assess.
 Usually these tests are different from test cases as the test cases are single
steps whereas scenarios cover a number of steps.
 Scenario testing is performed to ensure that the end to end functioning of
software and all the process flow of the software are working properly.
 In scenario testing, the testers assume themselves to be the end users and find
the real world scenarios or use cases which can be carried out on the software by
the end user.
 In scenario testing, the testers take help from clients, stakeholders and
developers to create test scenarios.
 Scenario testing helps testers to know how the software will
exactly work when end user will use it.
 As the scenario testing tests the business process flow of the
software so it helps in figure out a lot of defects which cannot be
found with the help of other testing.
 Scenario testing is carried out by creating test scenarios which
copy the end users usage.
 A test scenario is a story which describes the usage of the
software by an end user.
Characteristics of Scenario Testing:

A scenario test has five key characteristics:

•Story
•Motivating
•Credible
•Complex
•Easy to evaluate
Scenario Testing Process:
Methods in Scenario Testing:

There are two methods in scenario testing:

1.System scenarios:

Scenario tests used in this method are only those sets of realistic,
user activities that cover various components in the system.

2. Use-case and role-based scenarios

In use-case and role-based scenario method the focus is specifically

on how the system is used by a user with different roles and
environment.
Risks of Scenario Testing:

•Scenario testing is complex involving many features.

•Scenario testing is not designed for coverage of the
program.
•Scenario testing is often heavily documented and used time
and again.
DEFECT BASH

 Defect bash is an ad hoc(created or done for particular purpose) testing where

people performing different roles in an organization test the product together at
the same time.
 Defect bash brings together plenty of good practices that are popular in testing
industry.
 They are as follows.
 • Enabling people “Cross boundaries and test beyond assigned areas”
 • Bringing different people performing different roles together in the organization
for testing—“Testing isn't for testers alone”
 • Letting everyone in the organization use the product before delivery—“Eat your
own dog food”
 • Bringing fresh pairs of eyes to uncover new defects—“Fresh eyes have less bias”
 • Bringing in people who have different levels of product understanding to test
the product together randomly—“Users of software are not same”
 • Let testing doesn't wait for lack of/time taken for documentation— “Does
testing wait till all documentation is done?”
 • Enabling people to say “system works” as well as enabling them to “break the
system” — “Testing isn't to conclude the system works or doesn't work
All the activities in the defect bash are planned activities, except for what
to be tested.

It involves several steps.

• Step 1 Choosing the frequency and duration of defect bash

• Step 2 Selecting the right product build
• Step 3 Communicating the objective of each defect bash to everyone
• Step 4 Setting up and monitoring the lab for defect bash
• Step 5 Taking actions and fixing issues
• Step 6 Optimizing the effort involved in defect bash