  In the context of decision making under explorable uncertainty, scheduling
with testing is a powerful technique used in the management of computer systems
to improve performance via better job-dispatching decisions. Upon job arrival,
a scheduler may run some \emph{testing algorithm} against the job to extract
some information about its structure, e.g., its size, and properly classify it.
The acquisition of such knowledge comes with a cost because the testing
algorithm delays the dispatching decisions, though this is under control. In
this paper, we analyze the impact of such extra cost in a load balancing
setting by investigating the following questions: does it really pay off to
test jobs? If so, under which conditions? Under mild assumptions connecting the
information extracted by the testing algorithm in relationship with its running
time, we show that whether scheduling with testing brings a performance
degradation or improvement strongly depends on the traffic conditions, system
size and the coefficient of variation of job sizes. Thus, the general answer to
the above questions is non-trivial and some care should be considered when
deploying a testing policy. Our results are achieved by proposing a load
balancing model for scheduling with testing that we analyze in two limiting
regimes. When the number of servers grows to infinity in proportion to the
network demand, we show that job-size testing actually degrades performance
unless short jobs can be predicted reliably almost instantaneously \emph{and}
the network load is sufficiently high. When the coefficient of variation of job
sizes grows to infinity, we construct testing policies inducing an arbitrarily
large performance gain with respect to running jobs untested.
