Spec Reviews

After Greg's last two posts I can see this is going to work out great. While Greg's product (Encarta) is getting close to shipping and he's going through all the things you go through to get a product out the door, my product (Office) is just about to start serious development for the next version. So as we talk about what we're dealing with in our jobs you'll get some insight into two radically different places in the product cycle.

As you might expect, before we can start serious development we have to write specs. Those aren't my job (that's what Program Managers do) but developers and testers are actively involved in critiquing the specs. Technically my purpose in those meetings is to flag any design issues that would make the product untestable, but in reality I'm there to provide my input on what the product should do. Remember when Greg said that testers are advocates for our end users? That attitude continues with the spec reviews, I spend a lot of time trying to change things that I think are, for lack of a better word, dumb.

This is an important process because Software Engineering 101 teaches us that finding problems in the specs is orders of magnitude cheaper then finding them later. We take these spec reviews seriously, and passions sometimes run strong in the meetings. This is important stuff, and the time to speak up if you think we're headed down the wrong path.

Since we're doing all this spec review right now my whole test team is kind of in that nit-picky, griping mode (this is a mode we as testers naturally gravitate toward, when our job encourages it it can be ugly.) But something non-software related happened two weeks ago. Office started moving into a brand new building on campus, and let me tell you that the new building paired with everyone in spec review mode hasn't been pretty.

The first few days the majority of our meetings devolved into not reviewing our future software designs, but reviewing the building design. Complaints range all over the place, and being the technically oriented people we are most of them are functional complaints: the bathrooms and kitchens are too far away (108 and 132 yards from my office - I love Visio), the cafeteria is too small, there is just one small paper towel dispenser in the large bathrooms, the high tech light switches don't work right, traffic in the parking garage doesn't flow well, and more. Others in my team known more for their design taste complain of the boxy feeling, the long straight unbroken hallways, the exposed concrete. It's been an interesting time and it's kind of funny to me how a much of software nerds feel like we're qualified to be experts on building design.

But we are experts, because we're the users for the building. We may not be able to effectively design or build it, but we certainly can spot problems in the finished product. Your users will be like this with your software, they may not know what a better way to do it is, but they'll know if they don't like the way it works. Bring your customers in early (when you can still change things) and really listen to what they complain about.

But it's hard to bring customers in too early. Spotting problems like this in the design phase is hard. Most of the time you have to see the finished product in action to spot the problems. I know the parking garage is screwed up, but I'm not sure I could have looked at the design plan for it and spotted all the things I see now that I'm actually using it every day. Software is the same way, this is why beta tests are such a big deal - release the software out to users when it's a mostly finished product. It would have been like bringing us into the building when the structure solidly in place but the finishing wasn't quite done. Once again though, major problems can't really be fixed at this point, it's hard to put a new bathroom in when all the walls and plumbing are done. Preferably we'd like to find these issues in the design phase. With experience those of us in the industry can sometimes do this, but the users, the people that really matter, have almost no hope of it.

There are lots of methods of dealing with this problem and there are whole college courses about them (I took one.) I'm not going to delve into these methods, except to say it's to your organizations advantage to employ a couple of them. So when you're in a spec review, if you don't hear any talk about trying to get the opinions of some end users make a fuss (if you're not invited to spec reviews make an even bigger fuss.) Since after all, making a fuss is what us testers are best at.