SOFTWARE

TESTING
(FUNCTIONAL
TESTING)
Engr. Sajid Saleem
 OUTLINE
 Functional testing
 Steps
 Pros and Cons
 Random testing
 Systematic testing
 Functional Testing Techniques
 Smoke Testing
 User Acceptance Testing
 Alpha
 Beta
 Regression Testing
2
 GUI Testing
FUNCTIONAL TESTING

What we see the system as ??

IF its not the program/code we are looking at
then what will be the base for testing??
TESTING TACTICS
WHY FUNCTIONAL
WHY FUNCTIONAL
WHY FUNCTIONAL TESTING
 Functional testing is best for missing logic faults
 A common problem: Some program logic was simply
forgotten
 Structural (code-based) testing will never focus on code that
isn’t there!
 Type of black box testing
 Bases its test cases on the specifications of the software
component under test
 Functions are tested by feeding them input and examining the
output
 Internal program structure is rarely considered
 FUNCTIONAL TESTING
 It is performed to verify that a software application performs and
functions correctly according to design specifications or functional
requirements
 During functional testing we check the core application functions,
text input, menu functions and installation and setup on localized
machines, etc.
 Functions (or features) are tested by feeding them input and
examining the output.
 Functional testing ensures that the requirements are properly
satisfied by the application.
 This type of testing is not concerned with how processing occurs, but
rather, with the results of processing.
STEPS OF FUNCTIONAL
TESTING
 Functional testing typically involves six steps
 Identify functions that the software is expected to perform.
 Create input data based on the function’s specifications.
 Determine the output based on the function’s specifications.
 Execute the test case.
 Compare the actual and expected outputs.
FUNCTIONAL TESTING
 ADVANTAGES
 It simulates actual system usage.
 It does not make any system structure assumptions.

 DISADVANTAGES
 It has a potential of missing logical errors in software.
 It has a high possibility of redundant testing.
FUNCTIONAL TESTING
 Systematic or random ??
RANDOM TESTING
WHY NOT RANDOM
 NEEDLES IN A HAYSTACK
 To find needles and remove them from
hay, look systematically for needles

 Unless there are a lot of needles in

the haystack, a random sample will
not be effective at finding them

 We need to use everything we know

about needles, e.g., are they heavier
than hay? Do they sift to the bottom?
SYSTEMATIC AND
FUNCTIONAL TESTING
SIMPLE EXAMPLE: POSTAL CODE LOOKUP
IN SHORT

Focus on What not How

FUNCTIONAL VS STRUCTURAL
TEST: GRANULARITY LEVELS
 Functional test applies at all granularity levels:
 Unit (from module interface spec)
 Integration (from API or subsystem spec)
 System (from system requirements spec)
 Regression (from system requirements + bug history)
 Structural (code-based) test design applies to relatively small
parts of a system:
 Unit
 Integration
FUNCTIONAL TESTING
TECHNIQUES
 Smoke Testing
 User Acceptance Testing
 Alpha
 Beta
 Regression Testing
SMOKE TESTING
Smoke testing approach activities
 Software components that have been translated into code are
integrated into a “build.”
 A build includes all data files, libraries, reusable modules,
and engineered components that are required to implement
one or more product functions.
 A series of tests is designed to expose errors that will keep the build
from properly performing its function.
 The intent should be to uncover “show stopper” errors that
have the highest likelihood of throwing the software project behind
schedule.
 The build is integrated with other builds and the entire product is
smoke tested.
REGRESSION TESTING
 Each time a new module is added as part of integration testing
 New data flow paths are established
 New I/O may occur
 Due to these changes, may cause problems with functions that
previously worked flawlessly.
 Regression testing is the re-execution of some subset of tests
that have already been conducted to ensure that changes have not
propagated unintended side effects.
 CONTD.
 Regression testing contains 3 diff. classes of test cases:
 A representative sample of tests that will exercise all software
functions
 Additional tests that focus on software functions that are
likely to be affected by the change.
 Tests that focus on the software components that have been
changed.

CONTD.
As integration testing proceeds, the number of regression tests
can grow quite large.
 Regression test suite should be designed to include only those
tests that address one or more classes of errors in each of
the major program functions.
 It is impractical and inefficient to re-execute every test for
every program function once a change has occurred.
 ALPHA AND BETA TESTING
 When custom software is built for a customer, a series of
acceptance tests are conducted to enable the customer to validate
all requirements.
 Conducted by the end-user rather than software engineers, an
acceptance test can range from an informal "test drive" to a
planned and systematically executed series of tests.
 Most software product builders use a process called alpha
and beta testing to uncover errors that only the end-user seems
able to find.
ALPHA TESTING
 The alpha test is conducted at the developer's site by a
customer.
 The software is used in a natural setting with the developer
"looking over the shoulder" of the user and recording errors
and usage problems.
 Alpha tests are conducted in a controlled environment.
BETA TESTING
 The beta test is conducted at one or more customer sites
by the end-user of the software.
 beta test is a "live" application of the software in an
environment that cannot be controlled by the developer.
 The customer records all problems (real or imagined) that
are encountered during beta testing and reports these to the
developer at regular intervals.
 As a result of problems reported during beta tests, software
engineers make modifications and then prepare for release of
the software.
GUI TESTING
 User interface testing, a testing technique used to identify the
presence of defects in a product/software under test by using
Graphical user interface [GUI].

 Exercise GUI events

 Provide inputs to GUI objects
PROBLEMS…
 A relatively small program such as Microsoft WordPad has 325
possible GUI operations.

 The second problem is the sequencing problem

 Regression testing becomes a problem

 These issues have driven the GUI testing problem domain

towards automation
GUI TESTING CHECKLIST
 Check Screen Validations
 Verify All Navigations
 Check usability
 Verify Data Integrity
 Verify the date Field and Numeric Field Formats
THANK YOU