Ideally, your test system should be separate from the production one used for normal work. In particular, you should not mount any production file systems from within the test environment. This way you can avoid damaging or losing your production data if there is a serious bug, leading to data losses, in the tested kernel. Of course, if the tested kernel damages the test environment, you ought to notify the kernel developers of the problem.
Fortunately, you need not boot the test system in order to reconfigure it or
install a new kernel on it. Namely, you can mount the test system's root
filesystem using a temporary mount point (eg. /mnt) and go to it using
chroot. Then, you will be able to prepare the new kernel, compile it and
install it (that should better be done with the help of a script automating
the entire process), while using the computer for normal work. Next, when
you have some time, you can boot the test system and run some tests on it.
It is best to configure the test system with your convenience in mind, as it
should not require you to do very much additional work. For this reason, the
distribution installed on it should allow you to compile and test the kernel
easily. It should also allow you to test the new functionality of the kernel,
so it ought to contain contemporary versions of kernel-related tools and
libraries. The test branch of Debian is one of such distributions, because it
contains current versions of the most important utilities as well as older
versions of gcc, which are sometimes useful (unfortunately, some kernel
developers only check if their code is compiled correctly by the gcc
available in their favorite distribution). In turn, Fedora Core supports
SELinux very well and it allows one to try all of the new functionality
offered by the latest kernels.