- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Email to a Friend
- Printer Friendly Page
- Report Inappropriate Content
You know what an automated regression system is, right? It’s a system that can automatically run a whole bunch of tests against your product or service to ensure that it is still working correctly.
A lot of testers and developers have come to think of the automated regression system as the enemy. For testers, it just creates work. “How am I supposed to get all of my testing done when I have to spend all of my time triaging failures in regression?” For developers, it is the source of a lot of bug reports. “How am I supposed to get my coding finished if I have to spend so much time fixing bugs on stuff I worked on a long time ago?”
Give some thought to the possibility of personal regression. This is the idea that you can now easily put together your own little mini-regression system that runs on your own computer. iTest makes it very easy to put together something that will let you choose your own sets of tests to run, and will run them and report results when you want it to. But why?
Well, if you’re a developer, the value is fairly clear. You know that if you check in a bug, it’s going to cost you a lot of time later – probably after you’ve already moved on to some other project. But if you have your own little regression system, you can do a bunch of testing before you commit your changes. Obviously, you probably won’t get coverage on all possible bugs that you might create. But you probably have a pretty good idea of which parts of your product are most vulnerable to the kinds of changes you are making. Wouldn’t it make sense to do some quick checks to see that they’re working with your changes before you check them in? Most likely, bug reports assigned to you are going to go down.
If you’re a tester, you might be wondering why you should think about personal regression. To answer that, let me ask you if you’ve ever spent several days testing a new build from development – only to find at that point that there is something really serious that is broken in the build. When they fix it, are you going to have to go back and start over again? Wouldn’t it be great if you had the ability to run your own set of sanity tests on a build you get from development before you start investing any time on it? Well, sure, you could wait around for some big centralized regression system to tell you whether the build is good. Do you really have the time to wait? Or perhaps you should trust development to give you a pretty good build every time? Yeah, right!
If you’re interested in personal regression, start small. Just pick a few tests that you think are useful to do a quick check of your system. Make sure you always leave your testbed in a state that is suitable for running these. (Or create a new test that puts your testbed into a certain initial state.) You can create a master test case to run these. (Or if you are running iTest 3.4, you can define a test suite that runs these. In that case, you’ll want to tag those tests with a unique parameter that you can use to identify them. Then you can add to your suite later by tagging other tests with the same parameter.) Once you have your master test or test suite defined, plan to run it regularly. One easy way to get started is to launch this before you leave at night. Or, if you use the Jobs support in 3.4, you can schedule it to run whenever you want. Then you can check the report(s) when you come in to see if everything is as you would expect.
Once you have a very simple personal regression system up and running, I predict that you’ll want to do more with it. Eventually you’ll find that you can get a lot done at the office, while you’re at home having fun doing something else!
![]() | Kingston Duffie is the founder and CTO of Fanfare. Learn more about Kingston >> |



You must be a registered user to add a comment on this article. If you've already registered, please log in. If you haven't registered yet, please register and log in.