Pepelen
Software Testing (QA) from Scratch

Lesson

Functional vs non-functional; black, white and grey box

Learner can classify a test as functional or non-functional and choose a black-, white- or grey-box perspective for a goal.

1 / 6

What the system does vs how well it does it

What the system does vs how well it does it

Functional testing answers the question: does the system do what the specification says it should do? Examples: can the user log in? Does the search return relevant results? Is a product added to the cart correctly? Functional tests are tied directly to requirements and user stories. Non-functional testing asks a different question: how well does the system do it? The four main non-functional areas from ISTQB are: performance (is it fast enough under load?), usability (is it easy to use?), security (is it protected from attacks?), and compatibility (does it work across different browsers, devices, or operating systems?). Black-box testing: the tester has no knowledge of the internal code or structure. Tests are designed entirely from requirements and expected behavior. Most system and acceptance tests are black-box. It models how a real user experiences the product. White-box testing: the tester has full access to the source code and designs tests to exercise specific code paths, branches, or conditions. Developers often use this approach for unit and integration tests to ensure code coverage. Grey-box testing: a combination — the tester has partial knowledge (e.g., knows the API structure or database schema but not the full source code). This is common in API testing and security testing. A critical habit: do not test only the happy path. Positive testing checks that valid inputs produce correct outputs. Negative testing checks that the system handles invalid inputs, unexpected data, and error conditions gracefully — for example, submitting an empty password or an overly long username.
Lesson notes
What the system does vs how well it does it
Functional testing answers the question: does the system do what the specification says it should do? Examples: can the user log in? Does the search return relevant results? Is a product added to the cart correctly? Functional tests are tied directly to requirements and user stories. Non-functional testing asks a different question: how well does the system do it? The four main non-functional areas from ISTQB are: performance (is it fast enough under load?), usability (is it easy to use?), security (is it protected from attacks?), and compatibility (does it work across different browsers, devices, or operating systems?). Black-box testing: the tester has no knowledge of the internal code or structure. Tests are designed entirely from requirements and expected behavior. Most system and acceptance tests are black-box. It models how a real user experiences the product. White-box testing: the tester has full access to the source code and designs tests to exercise specific code paths, branches, or conditions. Developers often use this approach for unit and integration tests to ensure code coverage. Grey-box testing: a combination — the tester has partial knowledge (e.g., knows the API structure or database schema but not the full source code). This is common in API testing and security testing. A critical habit: do not test only the happy path. Positive testing checks that valid inputs produce correct outputs. Negative testing checks that the system handles invalid inputs, unexpected data, and error conditions gracefully — for example, submitting an empty password or an overly long username.
Functional vs non-functional; black, white and grey box — Software Testing (QA) from Scratch