What is Black Box

Testing
▪ There are two basic approaches to testing:
functional and structural.

2
▪ Due to its nature, functional testing is often
called “black box testing.” In the structural
approach, test cases are generated based on the
actual code of the program or module to be
tested. This structural approach is sometimes
called “glass box testing”

3
Software Testing – What is
Software Testing?
Characteristics of Software
Test.
▪ Errors prevent software from producing outputs
according to user requirements. They occur if
some part of the developed system is found to
be incorrect, incomplete, or inconsistent. Errors
can broadly be classified into three types,
namely, requirements errors, design errors, and
programming errors.
5
▪ To avoid these errors, it is necessary that:
requirements are examined for conformance to user
needs, software design is consistent with the
requirements and notational convention, and the
source code is examined for conformance to the
requirements specification, design documentation
and user expectations. All this can be accomplished
through efficacious means of software testing.
6
▪ The activities involved in testing phase basically evaluate the
capability of the developed system and ensure that the system
meets the desired requirements. It should be noted that testing
is fruitful only if it is performed in the correct manner.
Through effective software testing, the software can be
examined for correctness, comprehensiveness, consistency and
adherence to standards. This helps in delivering high-quality
software products and lowering maintenance’ costs, thus
leading to more contented users.
7
Software Testing Basic

▪ Software testing determines the correctness,

completeness and quality of software being
developed. IEEE defines testing as ‘the process
of exercising or evaluating a system or system
component by manual or automated means to
verify that it satisfies specified requirements or
to identify differences between expected and
actual results.’ 8
Software testing is closely related to the terms
verification and validation. 
▪  Verification refers to the process of ensuring that the
software is developed according to its specifications. For
verification, techniques like reviews, analysis,
inspections and walkthroughs are commonly used. While
validation refers to the process of checking that the
developed software meets the requirements specified by
the user.
▪ Verification and validation can be summarized thus as
given here. 9
▪ Verification: Is the software being developed in
the right way?

▪ Validation: Is the right software being

developed?

10
▪ Software testing is performed either manually or
by using automated tools to make sure that the
software is functioning in accordance with the
user requirements.

11
advantages associated with testing are listed
below.
▪ It removes errors, which prevent software from producing
outputs according to user requirements.
▪ It removes errors that lead to software failure.
▪ It ensures that the software conforms to business as well as
user’s needs.
▪ It ensures that the software is developed according to user
requirements.
▪ It improves the quality of the software by removing maximum
possible errors from it.
12
Differentiate
Between Error,
Fault and Failure
▪ Fault is a condition that causes a system to fail
in performing its required function. A fault is the
basic reason for software malfunction and is
synonymous with the commonly used term bug.

14
▪ Failure is the inability of a system or component
to perform a required function according to its
specifications. A software failure occurs if the
behavior of the software is different from the
specified behavior.

15
▪ The term error is used in two different ways. It
refers to the discrepancy between a computed,
observed, or measured value and the true,
specified, or theoretically correct value. That is
error refers to the difference between the actual
output of software and the correct output.

16
Errors can be present in the software due to the
following reasons.

▪ Programming errors: Programmers can make

mistakes while developing the source code.

17
Errors can be present in the software due to the
following reasons.

▪ Unclear requirements: The user is not clear

about the desired requirements or the developers
are unable to understand the user requirements
in a clear and concise manner.

18
Errors can be present in the software due to the
following reasons.

▪ Software complexity: The greater the

complexity of the software, the more the scope
of committing an error (especially by an
inexperienced developer).

19
Errors can be present in the software due to the
following reasons.

▪ Changing requirements: The users usually

keep on changing their requirements, and it
becomes difficult to handle such changes in the
later stage of development process. Therefore,
there are chances of making mistakes while
incorporating these changes in the software.

20
Errors can be present in the software due to the
following reasons.

▪ Time pressures: Maintaining schedule of

software projects is difficult. When deadlines
are not met, the attempt to speed up the work
causes errors.

21
Errors can be present in the software due to the
following reasons.

▪ Poorly documented code: If the code is not

well documented or well written, then
maintaining and modifying it becomes difficult.
This causes errors to occur.

22
Guidelines of
Software Testing
Define the expected output: 

▪ When programs are executed during testing they

mayor may not produce the expected outputs
due to different types of errors present in the
software. To avoid this, it is necessary to define
the expected output before software testing
begins. Without knowledge of the expected
results, testers may fail to detect an erroneous
output. 24
Inspect output of each test completely

▪ Software testing should be performed once the

software is complete in order to check its
performance and functionality along with the
occurrence of errors in various phases of
software development.

25
Include test cases for invalid and unexpected
conditions:

▪ Generally, software produces correct outputs

when it is tested using accurate inputs.
However, if unexpected input is given to the
software, it may produce erroneous outputs.
Hence, test cases that detect errors even when
unexpected and incorrect inputs are specified
should be developed.
26
Test the modified program to check its expected
performance:

▪ Sometimes, when certain modifications are

made in the software (like adding of new
functions) it is possible that the software
produces unexpected outputs. Hence, it should
be tested to verify that it performs in the
expected manner even after modifications.

27
Testability
Testability

▪ The ease with which a program is tested is

known as testability. Testability should always
be considered while signing and implementing a
software system so that the errors (if any) in the
system can be detected with minimum effort.

29
CHARACTERISTICS OF TESTABILITY

▪ Easy to operate: High quality software can be

tested in a better manner. This is because if the
software is designed and implemented
considering quality, then comparatively fewer
errors will be detected during the execution of
tests.

30
CHARACTERISTICS OF TESTABILITY

▪ Stability: Software becomes stable when

changes made to the software are controlled and
when the existing tests can still be performed.

31
CHARACTERISTICS OF TESTABILITY

▪ Observability: Testers can easily identify

whether the output generated for certain input is
accurate simply by observing it.

32
CHARACTERISTICS OF TESTABILITY

▪ Easy to understand: Software that is easy to

understand can be tested in an efficient manner.
Software can be properly understood by gathering
maximum information about it. For example, to
have a proper knowledge of the software, its
documentation can be used, which provides
complete information of the software code thereby
increasing its clarity and making the testing easier.
33
CHARACTERISTICS OF TESTABILITY

▪ Decomposability: By breaking software into

independent modules, problems can be easily
isolated and the modules can be easily tested.

34
 Characteristics of
Software Test
There are several tests (such as unit and integration) used for testing the
software. Each test has its own characteristics. The following points,
however, should be noted.
Characteristics of Software Test

▪ High probability of detecting errors: To detect maximum

errors, the tester should understand the software thoroughly
and try to find the possible ways in which the software can
fail. For example, in a program to divide two numbers, the
possible way in which the program can fail is when 2 and 0 are
given as inputs and 2 is to be divided by 0. In this case, a set of
tests should be developed that can demonstrate an error in the
division operator.

36
Characteristics of Software Test

▪ No redundancy: Resources and testing time are

limited in software development process. Thus,
it is not beneficial to develop several tests,
which have the same intended purpose. Every
test should have a distinct purpose.

37
Characteristics of Software Test

▪ Choose the most appropriate test: There can

be different tests that have the same intent but
due to certain limitations such as time and
resource constraint, only few of them are used.
In such a case, the tests, which are likely to find
more number of errors, should be considered.

38
Characteristics of Software Test

▪ Moderate: A test is considered good if it is

neither too simp1e, nor too complex. Many tests
can be combined to form one test case. However
this can increase the complexity and leave many
errors undetected. Hence, all tests should be
performed separately.

39
Software Testing
Strategies
▪ A testing strategy is used to identify the levels
of testing which are to be applied along with the
methods, techniques, and tools to be used during
testing. This strategy also decides test cases, test
specifications, test case decisions, and puts them
together for execution.

41
▪ Developing a test strategy, which efficiently
meets the requirements of an organization, is
critical to the success of software development
in that organization. Therefore, a software
testing strategy should contain complete 
information about the procedure to perform
testing and the purpose and requirements of
testing. 42
▪ The choice of software testing strategy is highly
dependent on the nature of the developed
software.

43
Generally, all testing strategies have following
characteristics.
▪ Testing proceeds in an outward manner. It starts from testing
the individual units, progresses to integrating these units, and
finally, moves to system testing.
▪ Testing techniques used during different phases of software
development are different.
▪ Testing is conducted by the software developer and by an ITG.
▪ Testing and debugging should not be used synonymously.
However, any testing strategy must accommodate debugging
with itself.
44
Types of Testing
Types of Testing

▪ Inspection
▫ A testing technique in which participants examine program code
for predictable language-specific errors
▪ Walkthrough
▫ A peer group review of any product created during the systems
development process; also called a structured walkthrough
▫ review many systems development deliverables, including
logical and physical design specifications as well as code
Walkthrough scenerio
▪ Desk Checking
▫ A testing technique in which the program code is sequentially
executed manually by the reviewer

What the code does is important in desk checking, an informal process in which the
programmer or someone else who understands the logic of the program works
through the code with a paper and pencil. The programmer executes each
instruction,using test cases that may or may not be written down. In one
sense, the reviewer acts as the computer, mentally checking each step and its
results for the entire set of computer instructions.
Types of Testing

▪ Unit Testing
▫ Each module is tested alone in an attempt to discover any errors
in its code, also called module testing
▪ Integration Testing
▫ The process of bringing together all of the modules that a
program comprises for testing purposes. Modules are typically
integrated in a top-down, incremental fashion
▪ Current practice calls for a top-down approach to writing and testing
modules. Under a top-down approach, the coordinating module is
written first. Then the modules at the next level in the structure chart
are written, followed by the modules at the next level, and so on, until
all of the modules in the system are done. Each module is tested as it
is written. Because top-level modules contain many calls to
subordinate modules, you may wonder how they can be tested if the
lower-level modules haven’t been written yet.
Types of Testing

▪ Stub Testing
▫ A technique used in testing, especially where modules are
written and tested in a top-down fashion, where a few lines of
code are used to substitute for subordinate modules
▪ System Testing
▫ Requirements testing
▫ Usability testing
▫ Security testing
▫ Documentation testing
▪ System testing is more than simply expanded
integration testing where you are testing the
interfaces between programs in a system rather
than testing the interfaces between modules in a
program. System testing is also intended to
demonstrate whether a system meets its
objectives.
▪ To verify that a system meets its objectives,
system testing involves using nonlive test data
▪ Nonlive means that the data and situation are
artificial, developed specifically for testing
purposes, although both the data and the
environment are similar to what users would
encounter in everyday system use.
How to maintain
Information
Systems
Software maintenance prediction

▪ Organisations need to establish filing systems to accommodate the

different types of records they need to keep. These files must be
updated regularly and accurate to maintain the integrity of the files. A
business might establish a centralised filing system where all there
records are kept it one area or a non-centralised systems which are
seen in departments within organisations who have control of their
own records. These files can be paper-based (stored in cabinets),
electronic (computer systems), stored in fixed filing areas (filing
cabinets or compactus units) or in a portable filing system (can be
easily moved from one area to another).

55
How to organization's information is stored
depends on the following:

▪ The amount of information to be

stored: Large amounts of information are easier
to store in a computer database rather than a
paper-based storage system. This allows many
people to access the information easily,
especially if the organisation is spread
throughout various locations.
56
How to organization's information is stored
depends on the following:
▪ The size of the workplace/organisation: This refers to the size
of the organisation and also the number of employees. A large
workplace area has the ability to store paper-based information
in filing cabinets or compactus units, whereas a small workplace
area could store more information electronically or digitally. If
an organisation has a large number of employees, the method of
storing information depends on how many people need the
information and where these people are located within the
organisation.
57
How to organization's information is stored
depends on the following:

▪ How work is conducted: Some organisations are

more electronically up-to-date than others and
they tend to store information electronically
rather than paper-based. If there are a large
number of employees who operate outside the
organisation, electronic information are digital
communication are more suitable.
58
How to organization's information is stored
depends on the following:

▪ The amount of storage space available: If there

is limited storage space, less paper files can be
stored. Inactive or dead files would need to be
identified and disposed of so as the storage space
can be used most effectively.

59
How to organization's information is stored
depends on the following:

▪ How often records need to be

accessed: Records that are used most often would
need to be accessed easily. Paper-based files
would be stored centrally if the workplace area is
relatively small or stored non-centrally to give
access to the relevant department. Information
can also be stored electronically so as it could be
accessed by all employees. 60
How to organization's information is stored
depends on the following:

▪ Security required:Paper-based information can

be stored in a locked filing cabinet in a secure
area or a locked room. Keys can be given to
employees who have the authority to access these
information. For electronic information,
passwords would be required to restrict access
and regular backing-up information would be
needed in case of a power failure or a computer 61

virus.
How to organization's information is stored
depends on the following:

▪ Cost of storage equipment: Computers and

other electronic equipment are expensive and
must be updated and maintain regularly whereas
filing cabinets last for a long period of time and
are one-off expenses.

62
How to organization's information is stored
depends on the following:

▪ Protection for environmental effects: All files

must be protected at all times from fire, flood,
theft, etc.

63