Functional tests
Black-box testing of what the specification promises: test cases, decision table, traceability matrix, acceptance test plan and acceptance testing.
- 25 cards
- 4 topics
- Free
The outline, topic by topic
Each topic is weighted the way the exam weighs it.
- Concepts
- Questions
- Sort and link
- Scenarios
A few cards from the deck
Functional test: what is it?
Show the answer
A test that checks that a function of the application does what the specification promises, seen from the outside.
It starts from the requirement (“a blocked customer can no longer log in”), not from the structure of the code. So it can be written before the code.
Rule: discount if the customer is loyal and the basket exceeds €100. How many columns does the complete decision table have?
- 4
- 2
- 3
- 8
Show the answer
4
Two true-or-false conditions give 2 × 2 = 4 combinations: loyal and big basket, loyal and small basket, not loyal and big basket, neither. All four are tested.
A test case specifies a …, steps with their …, and an … result written before execution.
Show the answer
A test case specifies a precondition, steps with their data, and an expected result written before execution.
The precondition sets the starting state (active account, empty basket). The data make the steps replayable. The expected result lets you conclude.
Black-box test: what is it?
Show the answer
A test designed from the specification alone, without looking at the code or its internal structure.
It picks inputs and an expected result from the requirements. It does not depend on how the code is written, so it survives a refactoring.
At acceptance, the customer rejects a function that all of the team's green tests covered. What is the most likely cause?
- The customer refused for no reason, since green tests are enough to prove compliance
- The tests followed the team's understanding, not the customer's specification
- Unit tests were missing: just add some up to 100% coverage
- The tests were too slow and the customer had no time to reread them
Show the answer
The tests followed the team's understanding, not the customer's specification
Tests written from the code or from the team's interpretation validate that interpretation. Only cases derived from the specification, traceable requirement by requirement and validated with the customer, avoid the gap.