Why seperating functional/non-functional aspects of a system is important for me as an tester
I make such an distinction at the very begining 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 'explict' 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 an 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 an 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,maintainbility or extensibilty; I can always make it a
part of my strategy and point to the correct reference or to its lack
- Similarly I am not an security expert but I might highlight security
or vulnerability as legitimate concerns and let experts handle that.
Some eloboration on non-functional requirements
Non-functioanl 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 call 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 eloborated 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.