RT is a system which at a high level takes in email, processes it into the database, provides access to the data various ways (primarily a web site) and sends email out. Along the way it can do a lot of neat things and can hopefully exactly model business processes and workflow. And that is what I'm working on, rather than on RT itself. I'm working on top of RT, on the RT platform if you will.
Modelling business logic is done in RT 3.x via the Scrip system. Scrips are RT's automation configuration, expressed in Perl, and can either be input through the web ui or added to the code as Perl extensions. I expect to do some of each, eventually. Most of the scrips I'm working up will be for the correct filing, labeling, and distribution of the requests generated by these incoming emails.
So to be able to to test automated filing and distribution, I want to be able to send RT mail, watch what happens, check the various bins, take notes, make changes to scrips and quickly try again. The faster I can cycle through these steps the quicker I can come up with working business logic that we can deploy, ..., step three profit.
A production install of RT uses apache2, mod_perl, some database, a lot more Perl, and mail in and out, running on some kind of Unix (probably Linux) server. This would not be a good test environment even if readily available (and safe) because it's far too complicated and has too many moving parts that don't have anything to do with the experiments I want to run. And I don't want to expose this fragile thing to live email even if I was allowed to by local custom.
Here's what I have going so far for this:
Although I've been testing and breaking software my whole life I am still quite new to the craft of software testing and the concepts behind professional QA. In particular there is no innovation (yet) in what I am doing, but the tools of Unix are proving quite helpful and I'm happy with my progress so far.
1: That configuration script is not from the excellent but dated book RT Essentials