Functional testing is the testing of a given application’s function, that is, its relation to the user and (especially) to the rest of the system. Traditionally, functional testing is implemented by a team of testers, independent of the developers.
While unit testing tests both what an application segment does (how it meets a part of the application specs) and how it does it (how it behaves towards the rest of the application), functional testing tests only the what. A functional test is not concerned with an application’s internal details.
Another way of stating this is that functional testing is “the customer’s test”. But even this is misleading. Developers need a benchmark during all development stages -- a developer-independent benchmark -- to tell them what they have and have not achieved. Functional testing begins as soon as there is a function to test and continues through the application’s completion and first customer contact.
The expression, “the customer’s test”, can be misleading in another way. Some people think of functional testing as mimicking a user and checking for expected output. But the real customer is not just someone feeding commands to the application. They are running the application on a system, simultaneously with other applications, with constant fluctuations in user load, etc. The application, of course, should be crash-resistant in the face of these conditions.
More and more, the user interface of our applications is supplied by pre-tested components, which produce few surprises once they are integrated correctly. On the other hand, we are constantly asked to write custom applications for systems of ever-increasing complexity. Therefore, the central functions tested by a functional test are increasingly system-related rather than user-related.
An automated testing tool, namely, TestComplete, will support functional testing by automating its repetitive aspects and producing results in a flexible, filtered form. In addition, TestComplete enhances its functional testing feature by supporting:
- Continuity
- Application-grade tests
- Interfacing
- Orientation
To learn how to perform functional testing, see Functional Testing With TestComplete.
Continuity
As indicated above, functional testing is an ongoing process, from the beginning of an application’s creation. Functional testing’s benefits can only be realized through the maintenance of continuity. In other words, even the simplest functional test should be applicable throughout the life of a project, and it should be capable of automatically measuring results against an already-validated standard output. The TestComplete Test Log is designed to meet these criteria.
In fact, the test log supports Regression Testing, in which functional testing is integrated into general test work, and each new test cycle reuses the tests and results of previous cycles.
Application-grade tests
The typical approach to functional testing includes testing of application functionality via the user interface. TestComplete includes special means to simulate user actions over application’s windows and menus (see Simulating User Actions).
However, testing the user interface is only a minor part of functional testing’s work. Functional testing should be kept external to the application as much as possible. It is not external scripting that is obsolete, rather scripting, limited to recording, playback and screen capture.
A functional test can require the same programming power as application writing, especially if the test is to be automated (rather than evaluated by hand on each iteration). TestComplete provides this programming power in following ways:
- A choice of scripting languages, each of which has a full set of programming constructs.
- A sophisticated library of testing objects, which encapsulate needed functionality in easy, transparent methods and properties.
- More scripting objects that directly interface with the system (Win32) or with database servers (ADO). Thanks to these, TestComplete reveals “what” the application does in areas far more central to the application than its screen output.
But the script is not the only way of doing functional tests with TestComplete. Another powerful alternative is keyword tests. These tests consist of operations that perform various actions like simulating user actions on tested objects, performing various verification actions, calling methods or properties of the tested objects and so on. Keyword tests are created and edited visually with special editors, wizards and dialogs. They can also be recorded. All of these features make keyword tests a simple but powerful alternative to script code. By using them, even inexperienced users can quickly and easily create the desired testing functionality and automate your tests.
Interfacing
If functional testing is to be used as a starting point for daily development work, then it is important for back-end functionality (the essential object of functional testing in today’s environment) to be testable before the application has a user interface or other command mode.
TestComplete can supply its own interface to run even the most internal aspect of the application, without having to go through the application’s external interface. In a way, this is less than “pure” functional testing, but it is the only way to rely on functional testing as a starting point in early development stages, and especially in exploratory stages. See White-Box Testing.
Orientation
It is recommended that functional testing is not conducted randomly; it cannot be considered testing if you do not know what you are testing for. White-box testing centers on TestComplete Open Application facility, one of whose capabilities is to provide information on which functional tests to run, and how unexpected results occur. Beginning functional testing early during an application’s creation also gives hints as to which tests should be run. Functional tests must check the limits of an application’s specifications. Developers learn which aspects of the code are likely to raise problems, and which aspects are symptoms of other problems.
Developers who create functional tests could possibly code in the same errors, or even avoid the trouble spots they missed while developing the source code. If this possibility exists, the “interesting tests” should be coded externally. But, if they are external, we have a dilemma -- how do you know that the code areas developers find worrisome are really tested?
The Open Application facility offers a solution to this problem by giving TestComplete access to the application’s internal details. The application can be tested externally, but monitored internally -- both before designing the test, by viewing it in the Object Browser, and during the test, by adding code (external code) to see if the expected internal area is being exercised.
See Also
Functional Testing With TestComplete
Different Ways of Testing
Simulating User Actions
About Open Applications
Object
Browser