I have often found that regression testing is both important and boring, so I usually try to automate it as much as possible.

Unfortunatley there there is often little or no automation in place at all when you join a new team and there is often not enough time to get it working properly before the next release. 

In fact though, even when there is a lot of automated testing in place, I have sometimes been surprised how quickly a good business person will find a significant bug by simply sitting down and mucking around (playing) with a system for an hour.

Exploratory testing

So I think there is a place for “mucking around” testing every week on a project. This informal approach will test for the things the team never thought of and will often reveal surprises even if it is just a developer or random business person doing the testing.  And often, those surprises will be missed by consistent and formal testing even when it is properly automated.

Of course when a real tester does “mucking around” testing they like to call it “exploratory” testing to make it sound more legetimite and scientific.

Exploratory testing is, in fact, exactly the same thing as “mucking around with the system” to see if it breaks. But the exploratory testing done by a master tester, compared to a random business person, is like the difference between the work done by a master painter and that done by an enthusiastic child.

I will not attempt to cover the numerous techniques, heuristics and instincts that a master tester (or painter) needs to learn to master their craft, but I will say that regardless of whether you are an expert tester or a rank amatuer, exploratory testing can be fun and surprisingly effective (yes – even for IT Managers like me).

I will also say is that any effective approach to testing, including regression testing, involves an allocation of time to “just mucking around”. This often opens up problems you didn’t want to find, but that is better than going live with the same problems.

A good description of exploratory testing can be found in the following article if you want a better definition http://www.satisfice.com/articles/what_is_et.shtml.

Exploratory testing can be boring if you just press the same button all the time. But it can be more fun if you just muck around with the system and try to do “the stupidest possible thing a user can do”, or “see what would happen if you tried to enter Rupert Murdoch into system and see what the process will do with a salary of $120m or so per year”.

If you allow yourself time to be inventive and creative, then you will probably stumble on a surprising number of bugs … and potentially even requests for scope changes.  So this can be a pretty effective approach and failing anything else you will find some of the bugs AND you will find it will even be enjoyable if you do it properly.

But even then I think we can do better.  So there must be another option, somewhere between using robots to do your testing (ie automating testing) and mucking around having fun breaking the system (exploratory testing).

So my next quest is to find something beyond exploratory testing that will still add value when manually testing and will still not suck too much for those doing it.