Motivation
A good test describes a certain aspect of your system on a functional level. In this sense, a test is not much different from a specification. While traditionally specifications have been written up-front and tests afterwards, this trend has changed.
A specification written at the beginning of a project needs to be continuously maintained to stay relevant in rapidly-changing environments - and today, all environments change rapidly. As such, the specification has become a living part of the product, just like production code and tests.
Conversely, with software being developed and deployed iteratively, tests are written earlier in the process, sometimes before the actual features are implemented. This is a good thing.
Due to these trends the distinction between functional tests and specifications is quickly disappearing: it often helps to think of tests as specifications and specifications as tests.
Applicability
Tests that don't look like specifications are not very good tests: often they test how a feature is implemented, not that.
Specifications that don't look like tests are not very good specifications: often they are too vague, sometimes giving a false sense of consensus on the feature.
Consequences
Your process probably no longer has separate 'waterfall' phases for specification (up-front) and testing (afterwards). However, in many organizations, specification and testing are still the responsibilities of disparate roles or even teams. When you consider tests are specifications, the consequence is that specification and testing should be the joint responsibility of a multidisciplinary team consisting of both people with a background in specification/requirements engineering and people with a background in testing/test automation.