Functional Tests

The second of eight (8) Test Types looks at the validation of individual Solution functions.

Functional Testing

Building upon the previously covered Unit Tests which validate individual objects, all changes introduced into the Solution undergo testing to validate that the related function operates as desired.

Overview

A Functional Test validates that a group of objects operate properly, in a coordinated fashion, to enable a given function to work as designed. Functional Testing is built upon activities defined within Acceptance Criteria, Fit/Gap Analysis and other artifacts (e.g., Features, Stories) that have been used to define the functions that the application or technology are to support. A function represents a single task or activity (e.g., 'Create an Opportunity', 'Close an Order').

The purpose of Functional Tests are to:

  • Ensure that the application to technology configuration is correct as structured;
  • Validate that any RICE elements that have been added or modified correctly support the given function;
  • Validate that the functions and features are properly enabled to support the User Story and Acceptance Criteria specified; and
  • Validate that the application conceptual design has been appropriately implemented.

Additionally, Functional Test Cases will reference back to specific requirements and/or customizations to ensure that these items are not overlooked. To ensure that appropriate conditions are covered, these cases will include Test Data designed to fail, to trigger warnings and errors, and to emulate production-representative values. The IDs of the Test Cases themselves should be added to the definition of the Acceptance Criteria and Fit/Gap results to provide easy cross-reference that all items are addressed by testing activities.

On This Page
    Add a header to begin generating the table of contents

    Objective

    The objective of Functional Tests is primarily to validateapplication or technology configuration. However, RICE elements that have passed Unit Testing should also be incorporated into the cycle to ensure a fit between the modified objects and the related Solution functions. Functional Tests may also validate non-configuration components, such as Operating Procedures.  Most Functional Testing seeks to find errors or weaknesses in the configuration choices made or in changes made to delivered components. That is, most Functional Tests should be "negative" tests (i.e., designed to 'fail'). For example, If not already covered by Unit Tests, tests should validate that:

    • invalid data cannot be entered;
    • that selections can be made only of valid values; or
    • that business rules process correctly.

    This focus on negative testing enables a later focus on positive testing during Integration and System Testing.

    Scope

    Functional Tests are limited to individual modules or extensions thereof.

    Timing & Responsibility

    The members of the Delivery Team will execute these tests during Story Build, specifically during activities IT4 - Step 2 of 8: Work in Progress and IT4 - Step 3 of 8: Technical Review.  That implies that the Test Cases themselves were created prior to, or in parallel with, development / configuration change.

    The Security Administrator, or DevSecOps, in coordination with the Delivery Team, should also perform any desired Security Testing during these activities.

    A.K.A.

    Functional Testing is also known as:

    • Component Testing; or
    • Module Testing.

    Dependencies with Other Test Types

    to migrate

    Automation

    to migrate

    Solution Types

    to migrate

    Test Conditions

    to migrate

    Test Data

    to migrate

    Test Scripts

    For each function (i.e., process activity or task), a corresponding Test Script is created to ensure that testing of the function validates the expected capabilities and boundaries of the given function.  Initial testing will rely upon pre-defined, controlled data and values to validate that the function is operating as expected. These values need not represent full production. It is preferred to use a smaller set of controlled data – for example: perhaps 20 sample Employees; or Product A, Product B to Product N; etc.– in the DEV and TST environments rather than trying to complete a production level configuration. Later, actual production-ready values will be defined within these Test Scripts for use in the System Test.

    Test Cases

    to migrate

    Test Scenarios

    to migrate

    The next type of testing to review is Integration Testing.

    Scroll to Top