Why separating functional/non-functional aspects of a system is important for me as a tester
I make such a distinction at the very beginning of a project (either during drafting the strategy or implementing it). It helps in making non-functional or 'implicit' (another word for overlooked, forgotten, or ignored completely) requirements sufficiently 'explicit' to everyone involved. This enables me to ascertain and communicate about where (and how much) we are focussing immediately and how we plan to cater to the critical non functional aspects of the system over a period of time (why I say over a period is in the elaboration of non-functional requirements).
This is certainly good; since as "headlights" of a project you want to illuminate everything that lies ahead.
Few examples/benefits of making such distinction and then including it in your plan could be
- As a tester I do not write unit tests (written by devs as a part of
TDD) but since unit tests cater to non-functional requirements like
testability,maintainability or extensibility; I can always make it a
part of my strategy and point to the correct reference or to its lack
- Similarly, I am not a security expert but I might highlight security
or vulnerability as legitimate concerns and let experts handle that.
Some elaboration on non-functional requirements
Non-functional requirements are largely cross cutting and implicit, and once we pay heed to them; it has to be a continuous effort through the project lifetime. Mike Cohn calls these
"constraints" and says these are similar to taxes which we have to pay in every agile sprint in this blog.
I largely derive the functional/non-functional distinction from Brian Marick's testing quadrants which has been elaborated in the book Agile Testing by Lisa Crispin and Janet Gregory as well.
For me business facing tests are mostly functional and technology facing tests make up for the non-functional requirements.