Functional Testing - Software Testing: Testing Across the Entire Software Development Life Cycle - page 119

The tester has the challenge of identifying input and output fi elds that are data
type sensitive and design execution tests to validate their correctness and robustness
(will not fail). The primary source for this test planning is the user guide that is sup-
posed to spell out all input fi eld data type restrictions.
7.6.4.3 Dates
We discussed the complexities of date formats and date calculations in white box
testing. Dates reappear in the black box discussion because there is date behavior
that a user can observe and a tester can test without having the code available. These
dates typically appear on data entry screens, in information search criteria, and on
reports. The user guide is the best source of expected behavior for dates that the user
directly controls and sees. This is also the situation in which the tester discovers date
formatting choices in some kind of user profi le, for example, the formats mm/dd/
yyyy or dd/mm/yyyy or Month, yyyyy. So, the tester is challenged to test the default
date format wherever it is used in the software, as well as all the other formatting
choices in the same software locations.
7.7 SUMMARY
The objective of functional testing is to validate the software behavior against the
business functionality documented in the software requirements and specifi ca-
tions. Business functionality is generally defi ned as those activities that support routine
daily business. Functional testing is achieved by a series of tests that exercise increasingly
more of the software that directly enables users to accomplish this routine daily business.
There is a relatively new development scoping technique called a use case that
software developers employ to capture user-functional requirements of a system for
the purpose of scoping the project. The technique became popular in the mid-1990s
fi rst as an object-oriented design technique and later broadened in appeal for other
types of software development. Consider drafting a test case for each use case happy
path and each use case alternate path, bringing the use case sequence of actions into
the test case steps almost one-for-one.
As the design phase of the software development project continues, details
become available that spell out how each actor can accomplish the use case activi-
ties—menus, data entry web pages, data search web pages, report web pages, print-
outs, databases for purchases, and so forth. As these details emerge from the design
work, the tester can identify the pieces that need testing individually before they can
be tested together, implying more test cases. Use cases are a powerful basis to develop
business path test cases. Use cases contain the business functionality to be verifi ed.
As each use case is refi ned by additional requirements and design detail, the tester can
leverage the more detailed use cases to develop detailed test cases for the individual
application pieces. Execution of the test cases then proceeds in reverse order, that is,
the test cases for the individual application pieces are executed fi rst. When all of the
pieces are validated, the test cases for the different business paths are executed.