Functional Testing

Why it matters

People use software to get a job done: pay a bill, book an appointment. When a function is missing, gives a wrong result or makes the job needlessly hard, users notice at once, and with money or personal data a wrong result does harm even when nothing crashes. A fast, secure checkout that shows the wrong total is still a failure.

For a tester, functional testing is the core of daily work. It also builds the habit everything else depends on: working out the expected result from the test basis before you look at what the system does.

A test type you apply at every test level

ISTQB groups tests by level and by type. Functional testing is a test type: it asks what the test object should do, while non-functional testing asks how well it behaves. Every test type can be applied at every test level, so each level from the previous lessons gets functional tests; only the test object grows.

• Component: the discount function returns 20.00 for a subtotal of 200.00 and the code WELCOME10.
• Integration: the cart service sends the discounted total, not the original one, to the payment service.
• System: at checkout in the browser, applying the code adds a discount line and a new total.
• Acceptance and end-to-end: a customer applies the code, pays and receives a confirmation that shows the discounted amount.

Completeness, correctness and appropriateness

These three are the sub-characteristics of functional suitability in ISO/IEC 25010, which you met in the lesson on software quality. They cover stated needs, written in the requirements, and implied needs that nobody wrote down. Each one gives you a different question to ask of the same feature:

• Functional completeness: do the functions cover all the specified tasks and user objectives? A promo-code feature with no way to remove an applied code is incomplete, however well the rest works.
• Functional correctness: do the functions give accurate results? Check calculations, stored data, state changes and messages against the rule. A 10% discount on 249.95 SAR must be rounded the way the business decided, not the way the code happens to round.
• Functional appropriateness: do the functions help users complete their tasks without unnecessary steps? If the code field exists only in the cart, a customer at the payment step must go back to use it: the function is present and correct, but not appropriate. How easy a supported task is to perform is usability (called interaction capability in ISO/IEC 25010:2023), a non-functional question.

The test basis: requirements and user stories

Functional tests are usually designed black-box: you derive them from documentation external to the test object, without reading its code. Some teams use "functional" and "black-box" as synonyms, but ISTQB keeps them apart: functional says what is checked, black-box says where the tests come from. A developer’s unit test of the discount function is functional even though it was written with the code open.

Typical test basis for functional tests:

• Requirements, specifications and business rules, such as "orders of 300.00 SAR or more ship free".
• User stories and their acceptance criteria, the main basis in agile teams.
• Use cases, for flows with alternatives and exceptions.
• API contracts, regulations, user manuals or a system being replaced, when the team agrees they apply.

Try it: Requirements → Test Cases Try it: Acceptance Criteria Generator

The anatomy of a functional check

Every functional check has the same parts: the state the system starts in, an input or action, the rule from the test basis, and the expected output that the rule predicts. Take a cart with items worth 200.00 SAR plus a 15.00 SAR delivery fee, and the criterion "WELCOME10 takes 10% off the item subtotal; the delivery fee is not discounted". For the input WELCOME10, the rule predicts a 20.00 SAR discount and a total of 195.00 SAR.

Part 1:1state     items 200.00 SAR + delivery fee 15.00 SAR
Part 2:2input     promo code WELCOME10, then Apply
Part 3:3rule      AC-1: 10% off the item subtotal; fee not discounted
Part 4:4expected  discount 20.00 SAR, total 195.00 SAR
Part 5:5actual    discount 20.00 SAR, total 195.00 SAR

Write the expected output down before the run. Afterwards it is easy to accept whatever the screen shows: 193.50 SAR looks plausible, but it means the fee was discounted too. That is a failure, and the report names the rule it breaks.

When the basis is silent, for example on how to round 24.995, the silence is itself a finding: ask the product owner and record the answer, or record the assumption you tested against.

Worked example: functional checks for a promo code

The story and its four acceptance criteria below are the test basis. The tester derives at least one check per criterion, works out every expected output in advance, then asks the three questions of the whole feature.

• Correctness: F1 and F2 test the calculation, F3 to F5 the rejection rules. F2 has no expected result yet because AC-1 gives no rounding rule, so the tester asks before testing.
• Completeness: F6 needs a remove function. If the build has none, that is a missing function, a functional defect.
• Appropriateness: the story says "at checkout", so the tester confirms that the code field is available on the payment step, not only in the cart.
• Not in the table: how fast the discount appears, or whether codes can be guessed. Those are non-functional questions.

Story PROMO-31
As a customer, I want to apply a promo code at checkout
so that I pay the discounted price.

AC-1  WELCOME10 takes 10% off the item subtotal. The delivery fee is not discounted.
AC-2  An expired or unknown code is rejected with a message; the total does not change.
AC-3  Only one code per order: a second code is rejected with a message.
AC-4  The customer can remove an applied code before paying.

Cart unless stated: items 200.00 SAR + delivery fee 15.00 SAR = 215.00 SAR

Check  Basis  Input or action                  Expected output
F1     AC-1   apply WELCOME10                  discount 20.00, total 195.00
F2     AC-1   items 249.95, apply WELCOME10    discount 24.995: 25.00 or 24.99? Ask.
F3     AC-2   apply SUMMER24 (expired)         rejected with a message, total 215.00
F4     AC-2   apply WELCOM10 (typo)            rejected with a message, total 215.00
F5     AC-3   WELCOME10 applied, apply VIP5    VIP5 rejected with a message, total 195.00
F6     AC-4   remove WELCOME10                 no discount line, total 215.00

Try it: User Story → Test Cases Try it: Percentage Calculator

Frequently asked questions

References

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality modelISO/IEC · 2023The product quality model: functional suitability, performance efficiency, compatibility, interaction capability, reliability, security, maintainability and flexibility.
• ISTQB GlossaryISTQBThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.