Lecture 25-30

Software Engineering I
COMSATS INSTITUTE OF INFORMATION AND TECHNOLOGY
In the last lecture

Requirement Engineering

2
In today’s lecture

Software Testing
White Box Testing
Black Box Testing

3
Software Testing

A process of analyzing a software item to detect the

differences between existing and required conditions (that
is bugs) and to evaluate the features of the software items
ANSI/IEEE

4
Software Testing Activity

Software testing is one of the “verification and validation,”

or V&V, software practices

5
Verification Vs. Validation

Verification:
◦Building the product right
◦Software should confirm to its specifications
Validation:
◦Building the right product
◦Software should do what the user really requires
6
7
Verification (Example)
There are supposed to be three switches and two
buttons on this wall.
The switches are supposed to be equi-distant apart
and 48 inches off the floor
The buttons are supposed to be on either side of the
switches
The left button is supposed to be labeled "Left“
The right button is supposed to be labeled "Right“
8
Validation (Example)
If I click the left button on, does it disable the far right
switch?
If I click the left button off, does it enable the far right
switch?
If I click the right button on, does it disable the far left
switch?
If I click the right button off, does it enable the far left
switch?
If I click both buttons on, does only the middle switch work

9
Economics of Testing
Related to the costs associated with testing our programs
- writing test plans and test cases
- set up proper equipment
- systematically execute the test cases
- follow up on problems that are identified
- need to remove most of the faults we find

10
Costs of Fixing the faults

Monitory costs
Intangible Costs
Low-Priority faults
◦ If too expensive to fix, remain latent in the product
High-Priority faults
◦ If not fixed, customers can lose faith

11
Goal of Testing

In order to minimize the cost, uncover as many defects as

possible with as little testing as possible

12
Methods of Testing

Manual Testing
Automated Testing

13
Manual Vs. Automated Testing
It is done manually
Manual Testing is a start of
Testing, without this testing we
can’t start Automation Testing
In Manual Testing testers are
allowed to do random testing to
find the Bugs
It is done by the help of
automated tools like Selenium, J
meter, QTP, Load Runner, Win
Runner and so on
Automation Testing is a
continuous part of Manual
Testing
In Automation Testing we always
test through Running Scripts
14
Manual Vs. Automated Testing
Manual Testing would be run
sequentially
It is not expensive
More testers are required in
Manual Testing because in this
testing test cases need to be
executed manually
Automation Testing is done on
different machines at same time
It is expensive
Few testers are required in
Automation Testing because in
this testing test cases need to be
executed by using Automation
Tools
15
Manual Vs. Automated Testing
It gives low accuracy result
It takes lot of time
It is considered as less reliable
No need of programming in
Manual Testing
It gives high accuracy result
It takes less time
It is considered as more reliable
Need of programming is must in
Automation Testing
16
Code written for Testing

Scaffolding Code
Computer programs and data files built to support
software development and testing but not intended to be
included in the final product

Involves stubs and Test Drivers

17
Basics of Software Testing

White Box Testing

Black Box Testing

18
White Box Testing

Structural Testing
Glass Box Testing
Focuses on the internal mechanism of a system or
component

19
Focus of White Box Testing
Focus of test execution during WBT is
◦To observe the program behavior related to different
(program statements, data structures, etc., and relations
among them)units
◦If a problem is detected, it is also located
◦Typically performed by the programmers themselves
because of their intimate knowledge of the specific
program unit under testing

20
Black Box Testing Example

In-circuit testing

21
White Box Testing Pros and Cons

 Tester can be non-  Chances of having repetition of

technical. tests that are already done by
programmer.
 This testing is most likely
to find those bugs as the  It is difficult to identify all
user would find. possible inputs in limited testing
time.
 Test cases can be designed
as soon as the functional
specifications are complete.

22
Black Box Testing

Functional Testing
Testing that ignores the internal mechanism of a system or
component and focuses solely on the outputs generated in
response to selected inputs and execution conditions

23
Focus of Black Box Testing

Focus of test execution during BBT is

◦ to observe the external behavior,
◦to ensure orderly execution of all the test cases
◦to record execution information for analysis and follow-up
activities

24
Black Box Testing Example

Compiler
Search Engine

25
Black Box Testing Pros and Cons

 Tester can be non-  Chances of having repetition of

technical. tests that are already done by
programmer.
 This testing is most likely
to find those bugs as the  It is difficult to identify all
user would find. possible inputs in limited testing
time.
 Test cases can be designed
as soon as the functional
specifications are complete.

26
Issues to think while Testing

Opacity
◦ Tester’s view of the code (White Box or Black Box)
Scale
◦ A small bit of code or whole system is analyzed

27
Types of Testing
Unit Testing
Integration Testing
Functional and system testing
Acceptance Testing
Regression Testing
Beta Testing

28
Unit Testing

Opacity: White Box Testing

Specification: Low level design and/or code structure
Unit testing is the testing of individual hardware or software
units or groups of related units
Usually done within a class or component

29
Integration Testing

Opacity: Black and White Box

Specification: Low and High Level Design
Integration test is testing in which software components,
hardware components, or both are combined and tested to
evaluate the interaction between them

30
Functional and System Testing

Opacity: Black-box testing

Specification: high-level design, requirements specification
Functional testing involves ensuring that the functionality
specified in the requirement specification works
System testing is testing conducted on a complete, integrated
system to evaluate the system compliance with its specified
requirements

31
Acceptance Testing

Opacity: Black-box testing

Specification: requirements specification
Acceptance testing is formal testing conducted to determine
whether or not a system satisfies its acceptance criteria (the
criteria the system must satisfy to be accepted by a
customer) and to enable the customer to determine whether
or not to accept the system

32
Regression Testing
Opacity: Black- and white-box testing
Specification: Any changed documentation, high-level
design
Regression testing is selective retesting of a system or
component to verify that modifications have not caused
unintended effects and that the system or component still
complies with its specified requirements

33
Beta Testing
Opacity: Black box testing
Specification: None
When an advanced partial or full version of a software package
is available, the development organization can offer it free to
one or more (and sometimes thousands) potential users or beta
testers

34