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.
Chris
Comments
- Anonymous
April 21, 2004
Chris,
That's the best explanation of why specs are so crucially important that I've ever read. Fantastic! My organization has recently been bitten by this in a painful way. We started with good specs and a solid design for one product only to find out two years down the road that all the usage scenarios were wrong and the product wouldn't be used any where close to what we'd designed/spec'd. I say chalk one up to learning curves and human error.
Scott - Anonymous
April 21, 2004
"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."
This is something I make a fuss about all the time: I see things where I am absolutly sure people (= users) will feel uneasy about later.
They might not know why they feel uneasy because of this but they would/could feel a lot better if X would not be there.
Problem with the people I am talking such things: They ask 'But why do you care? You don't work this way." As if this would matter.
I always thought not only software should have test, but how work is planned also.
I really laughed at your description about this nitpicking mode. It's like the saying 'if all you have is a hammer, everything looks like a nail.'
And when you are all in this spec mode, everything will be nitpicked. What do your families say about you when you in this mode ;o) - Anonymous
April 21, 2004
;-)
I see a news headline:
"Today was a great day for US builders economy. Microsoft Office reached first beta.
Microsoft Visio developers and select group of customers visited today new Building NN.
Several complains was resolved as 'by-design' but builders promised that next version of Building NN+1 will suit user needs better" - Anonymous
April 21, 2004
It's like dtp. The fact, that you might have a great product which can do all these things does not mean you don't need to have enough expertise or experience to make it really good.
It's okay if Visio warns me that these two faxmachines are too near each other "Would you like to have it in the next room?" but it might not recognize 'yes they is not enough space between them but with the specs and the non-experience of the team I suggest 5 fax machines because they will have 100 fax a day and need proper redistribution of the received faxes also'
Okay, the point where the designer should have considered computer fax was perhaps 4 new faxes away.
But you get the point. It is false security to believe the programm can do anything. It can't. The moment I accept this, it can be a very valuable tool for me. - Anonymous
May 31, 2009
PingBack from http://outdoorceilingfansite.info/story.php?id=22204 - Anonymous
May 31, 2009
PingBack from http://outdoorceilingfansite.info/story.php?id=4568 - Anonymous
June 01, 2009
PingBack from http://woodtvstand.info/story.php?id=11117 - Anonymous
June 13, 2009
PingBack from http://homelightingconcept.info/story.php?id=588