Alternatively known as Periodic Testing,
this involves running the same tests on the same code periodically (for example,
nightly) to very that code involving an external or unstable system is still working.

"Bit rot" is a phenomenon where software gets new bugs or breaks entirely because of changes to the modules or operating system that the software runs on top of.

Rot Testing involves automatically retesting the same software package whenever a new version of one of it's dependencies is released,
so that failure due to other people's changes can be detected quickly.

When a software package like perl releases a new version that adds or changes features (or even fixes bugs) there can be thousands of packages and millions of lines of code that will be impacted by the changes.
And the more code impacted,
more higher chance of causing bugs.

Fallout Testing involves testing hundreds or thousands of software packages with a new version of a dependency to verify that changes will not cause damage down-stream.

Packages such as Test::More and Test::Builder have worked from the inside out,
starting with a single test and working towards more and more-varied types of testing.

PITA works from the outside-in.
Way outside.

The fundamental unit in PITA is an "Image",
a virtual hard drive that PITA puts inside a virtual computer with a virtual CPU (of various types) with virtual hardware (of various types).

On the Image you can install any operating system you like,
just like on real hardware,
and set the operating system up with any packages and any languages in any configuration you like,
and at the end,
install a small piece of software onto the Image that is setup to run at startup time.

And then you save the Image.

You can create a few or as many of these PITA Images as you like,
trade them with other developers or distribute them within your company (licenses permitting).

With a set of Images in place,
PITA can take a software package and inject it an Image where the image manager executes a testing scheme on the package,
captures the results,
and spits it out for collection as an XML file.

And this process can be repeated over,
and over,
and over again.
It gets repeated as many times as is needed,
as often as is needed,
on as many packages is necesary,
across a set of Images that provide a particular testing solution.

This method can distributed or clustered extremely easily,
and by introducing flexbility through the use of plugins,
PITA can be made to work with multiple emulators (such as VMWare or Qemu) and allow the testing of multiple types of packages (Perl 5,
Python,
Java,
C) or even allow you to define your own specialised testing schemes.

And further,
it lets you seperate the collection of the results from the analysis of the results.
With only enough analysis embedded inside the testing scheme for it to know if and when to abort the testing sequence,
a PITA installation will primarily just spit out a whole pile of XML reports.

These reports can then be stored and run through analysis routines seperately.
And if the analysis code is improved,
you can rerun the analysis over old results with minimal effort.