Categories can help. Categories can help with some things. You might use categories to help indicate:
- Who will write or run the tests. For example, unit tests are generally written by developers (and are sometimes called developer tests). Acceptance tests might be executed by testers or product owners.
- The characteristics being tested--e.g. functional tests or load tests.
- The purposes for which you might run the tests. You run smoke tests to help decide whether it would be worthwhile to run a more comprehensive set of tests. You run acceptance tests to help decide whether to accept the system.
In general, a categorization scheme is useful if it helps someone decide whether and how to think about or interact with the things being categorized. The ways we interact with tests are to write, read, run, or respond to them (and maybe some other stuff I've neglected). If a test categorization scheme helps you do those things, it's useful. Otherwise, it's not so useful.
Multiple dimensions, so multiple categorizations. One day for fun I analyzed a bunch of test categories to identify the dimensions or variables at play. I quickly identified thirteen dimensions (and of course there are others, but I stopped there). Each categorization scheme places any given test somewhere along one dimension, or maybe two.
But every test falls somewhere along each of the dimensions. So every categorization scheme tells you some (potentially) useful things about tests, but none tells you everything you might want to know about a test. A given test might be both a smoke test (which indicates a reason for running it) and a function test (which indicates what characteristic is being tested).
In the end, the value of a categorization scheme arises from your purposes for interacting with the tests, and the extent to which the scheme helps you interact well.