  In this position paper, we would like to offer and defend a new template to
study equivalences between programs -- in the particular framework of process
algebras for concurrent computation.We believe that our layered model of
development will clarify the distinction that is too often left implicit
between the tasks and duties of the programmer and of the tester. It will also
enlighten pre-existing issues that have been running across process algebras as
diverse as the calculus of communicating systems, the $\pi$-calculus -- also in
its distributed version -- or mobile ambients.Our distinction starts by
subdividing the notion of process itself in three conceptually separated
entities, that we call \emph{Processes}, \emph{Systems} and \emph{Tests}. While
the role of what can be observed and the subtleties in the definitions of
congruences have been intensively studied, the fact that \emph{not every
process can be tested}, and that \emph{the tester should have access to a
different set of tools than the programmer} is curiously left out, or at least
not often formally discussed.We argue that this blind spot comes from the
under-specification of contexts -- environments in which comparisons takes
place -- that play multiple distinct roles but supposedly always \enquote{stay
the same}.We illustrate our statement with a simple Java example, the
\enquote{usual} concurrent languages, but also back it up with
$\lambda$-calculus and existing implementations of concurrent languages as
well.
