Skip to content

Archive for August, 2007


J-RAT in GUI Centric Testing

So the question is, can we apply J-RAT to GUI Centric Testing? By now we all agree that having all different functional area in the same room during testing increases productivity big time when testing process centric code. Can the same be done for GUI Centric testing? The problem is that during GUI testing, a lot of time is spend in ‘clicking’ through the app and finding bugs. The argument is that having Business Analysts and Developers in the same room doesn’t help this type of testing.

Well, of course that’s not true. J-RAT applies here and J-RAT still rocks.

See my pervious post about the 4 stages in System Test. J-RAT should be apply during the end of stage 1 onward.

What we are doing now is once the tester feels like their bug finding rate is slowing down (meaning they are getting into stage 2), they will start pairing up with developers. One tester and one developer becomes a bug fixing team. They start addressing issues together. There will be multiple ‘bug fixing units’ to address different part of the system.


What is Code-Review?

Found this in my email and fee like I should repost to my blog


I’ve been an Architect for many years and code review is always
something that is difficult to do right. I have tried from formal code
review meetings to reviewing CVS check-ins daily, to my latest ‘pair
and monitor’ approach. Basically as many have pointed out, this is a
necessary process to ensure the right design, coding partice are in
place. Code reveiw is supposed to make the team more aware of what one
another is doing and improve code quality as a whole.

Anyway, I’m always for light process. And that is what right now I’m
heavily relying on ‘pair and montior’. By pairing developers, you have
a higher chance of having better documented code. We then have one of
two team members who’s sole responsibility is to monitor everything
that goes into CVS and flag anything that disagree with our
development handbook. So far this is a low impact approach that seem
to be working.

Sze Wong
Zerion Consulting
See my blog at:


4 Stages of Software System Testing

During system test, it’s usually very hard to gauge progress. Most teams are still using the percent complete (how much have you tested) to report progress. While that’s easy, that usually does not tell you correctly where you are. 

Today I am starting to use the 4 stage system to tell the team where we are in System Testing.

The basic idea is that as you test, you will start by finding a lot of bugs, and as developers keep fixing these top level bugs, you will find more as you get deeper into the system. The bug list will grow on a daily basis. This is stage 1.

Then you getting to a point where you are finding less bugs, but the bug list is still big because the developers are working on high-level bugs and usually takes longer to fix. The bug list is slowly shrinking. This is stage 2.

As developers catch up, you finally get to a point when the bug list is empty and the developers starts to fix at a faster pace than the testers can find bugs. This is stage 3. The onset of stage 3 is when the rate of bug fixing finally go beyond the rate of bug finding. In real-life is not aways easy to spot to onset of stage 3 but if the bug list stays empty for a few days (assuming daily test cycle), the the proejct is in stage 3.

And finally, the testers will have a hard time finding bugs. And the bug fix rate is starting to drop as there are not enough bugs to be fix. Then, of course, at the end, the testers cannot find any more bugs for bug found and bug fixed are both zero at the end. Stage 4 starts when the rate of bug fixing slows down.

4 Stages of Software System Testing