Quote from Wikipedia:
“Functional testing is a quality assurance process that bases its test cases on the specifications of the software component under test. Functions are tested by feeding them input and examining the output, and internal program structure is rarely considered (unlike white-box testing). Functional testing is conducted to evaluate the compliance of a system or component with specified functional requirements. Functional testing usually describes what the system does.”
QF-Test supports the record-replay paradigm going way beyond it. This allows any person to create simple to very complex tests for the software. Software programming skills are not necessarily required although we know they help.
In step 1 those functions are traditionally described in external to QF-Test files. One can also use a Keyword-Driven-Development (KDD) or Behavior-Driven Testing (BDD). Both are very well supported by QF-Test. A special parser library for Gherkin (a language of Cucumber) is also available on demand.
The values required for steps 2 and 3 can be described via the usage of Data-Driver. The data can be fed via database, internal tables, external CSV or Excel files and more. This type of testing is often called Data-Driven testing, especially useful when multiple values need to be tested in similar tests and conditions.
Step 4 has a very special place within QF-Test. The QF-Test dependencies, a unique feature that takes care of setup, cleanup, error handling and recovery of the system under test (SUT).
Steps 5, 6 and 7 belong to the execution and reporting engine of QF-Test. Reporting, screenshots, re-run, and test documentation are only part of the features. Integration with all Continuous Integration tools, like Jenkins is also possible.
Normally step 8 wouldn't need an explication, since you and your colleagues want to work with the test results and your manager wants to be informed about them.