SOFTWARE

TESTING
(FUNCTIONAL
TESTING)
Rizwan Khalid
 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 usually describes what the system does.
 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