Background:
Testing non-functional aspects emerged when it became clear that even perfectly functioning features can be inconvenient, slow, or inaccessible to some users. Such defects are difficult to detect automatically, so manual testers play a key role.
Problem:
Testers often focus solely on functionality, ignoring performance, usability, and accessibility. Non-functional defects are difficult to formalize and explain; their subjectivity hampers obtaining a clear assessment.
Solution:
When testing, consciously allocate time for non-functional checks. For performance, record response time (e.g., with a stopwatch); for usability, describe inconveniences and provide examples; for accessibility, use checklists or tools (e.g., enabling a screen reader).
Key features:
Should all non-functional defects be documented by testers in a bug report?
Not always. If the problem is subjective, sometimes it’s enough to discuss it with the team and document it as an improvement (feature request).
Should the tester set performance metrics themselves?
Only if they are not specified in the requirements or specifications; otherwise, rely on them.
Is it mandatory to have special software or tools for non-functional testing?
No, basic checks are quite possible manually (e.g., manually measuring time, analyzing accessibility through a checklist).
A tester noticed that the catalog page loads in more than 10 seconds but did not log a bug, thinking, "It’s probably the same for everyone."
Pros:
Cons:
The tester detailed that the catalog page loads in 12 seconds on the first access, attached a stopwatch screenshot, and suggested possible optimization options.
Pros:
Cons: