A business-facing test is a test that's intended to be used as an
aid to communicating with the non-programming members of a
development team such as customers, users, business analysts and the
like. When automated, they describe the system in domain-oriented terms,
ignoring the component architecture of the system itself.
Business-facing tests are often used as acceptance criteria, having
such tests pass indicates the system provides the functionality that
the customer expects.

Automated business-facing tests are often represented in some form of
DomainSpecificLanguage, since this helps communication
with non-programmers and also helps give programmers a mechanism
that helps them step back from the details of the code. Tools like
Cucumber and Twist help design such DSLs and provide mechanisms to
bind them to the system under test.

Business-facing tests are commonly implemented as
BroadStackTests since their user-oriented expression
suggests treating the system under test as a black box. However
there are significant advantages to implementing business-facing
tests as ComponentTests since this often results in
easier maintenance and faster execution.

I'm a big fan of automated testing, but it's important to recognize
that manual tests play a significant role in business-facing
testing. Techniques such as exploratory testing and usability
testing are inherently manual activities and are essential parts of
a well-balanced test portfolio.