When to shake things around

A) General Rule - After every release - switch Area Ownership

No tester should have the same area two releases in a row. If you have short releases, then it should be no more then a year or two.

Conditions before swapping areas:

• Make it clear to the testers, that before handing off their area, the feature must be stable and any deliverables must be completed, automation/test cases etc.

Why switch up ownership?

• Tester start to get desensitized.
• They start to make assumptions that certain areas work.
• Enthusiasm decreases - willingness to keep testing drops significantly.
• They will not touch the area again unless there was a code change - and testing the fix in an area that was considered stable is minimal at best. (One of the reasons fixing bugs later in the cycle is very high risk)
• Ignorance is Bliss - when an area owner finds a bad bug late in the cycle, there is a chance they might not enter it, in an attempt not to look like they suck. This is totally possible and chances of this increases if testers are questioned publicly on why a bug was not found earlier

What you get?

• Spreading knowledge. You don't want only one person to know everything about a feature.
• Increase number of eyes on an area. The new area owner has a different perspective on the product. The way they will start testing the new feature in how it relates to the old features they owned. As a result a whole new set of integration tests will be tested... which leads to new bugs. (assuming you encourage ad-hoc testing)
• Excitement. If you make it clear to the new area owners not to assume anything was tested, and they are supposed to break it. It will bring a bit of excitement back, especially when the product has started to stabilize.
• Surfaces problem testers - this is an awesome way to detect if a tester sucks. If the new owner starts to find a crap load of issues... you just covered your ass. You NOW know the old area owner needs a backup tester... which raises a RED FLAG! (time to give the old area owner a highly visible area which gets alot of traction by other testers.)
• Saving Face - ** if a tester knows in a couple of weeks they will be handing off the area, they are probably going to start testing just a little bit harder to find the issues before someone else does. All testers hate it when someone finds a bug in their area... and they will try just a little bit harder to look like they suck!
• Old feature owners never really let go. They will still be checking up on the feature every once in a while.

B) Other testers are finding bugs in another persons area

You really need to analyze the bugs being entered:

• Are they basic bugs?
• Are devs pissed off that the bug was not found earlier?(need to talk with them)
• How long has the bug been around for?
• Was the bug a regression? If so, how long has the regression been around for?

If you are frequently seeing bugs entered in a persons area - then something needs to be done. See if the tester is overwhelmed? Do they have too much on their plate? The features on their plate, is there a common integration link between them? Or do they own areas where if they are testing Feature A they are totally neglecting Feature B and both Features A and B are high risk?

If a tester has two high risk features, but there is no common integration point between them, you should assign one of the high risk features to another tester that has the bandwidth to look at it. (All testers do not have a high risk area)

C) Miscellaneous Reasons

I am just outlining some general rules in A) and B). Of course there are lots of other reasons to switch areas.

What you should get out of reading this blog post:

What I wanted to convey is switching area ownership is a good thing... and PLEASE don't be afraid of it. Testers LOVE it! Any if they don't like the idea... its because they are shitting their pants :) (NOTE: there are bad ways of switching areas... but doing A) is always good. And doing B) is for the quality of the product.... its stuff in C) which can cause problems.)