Wednesday, February 22, 2006
Better Testing Presentation
Here's a brief presentation I gave for the Toronto chapter of the Software Process Improvement Network ("SPIN").
Download "Better Testing" (584Kb, PowerPoint).
It emphasizes principles rather than giving specific tips, how-tos, or examples. This was written for the cerebral QA or development manager who is seeking some insight into why some things work well and others don't, rather than a prescription for an inexperienced manager looking for specific direction.
I started developing the presentation with a completely different plan for what it would contain and communicate. I really wanted to talk about burn-down charts and talk about various metrics I have personally found to be useful.
I imagined a kind of diagnosis model where the presentation would list specific project problems and talk about what you can empirically measure to confirm the problem. However, as I wrote out explanations for each metric, I noticed a problem.
Every time I'd explain a metric, I found myself writing out various caveats and disclaimers. The trouble is that metrics can be completely misused, causing teams to chase the numbers rather than develop software. So with each metric there are good things you can discover with measurement, but there are also pathological problems you can experience if you focus on the metric to the exclusion of the underlying principle.
After a while, I realized that this problem seemed more interesting to me than the metrics themselves. This is a cliché for programmers. We start developing a to-do list application and end up with an entire web development framework because we find the underlying common problem more interesting than the application.
So, this presentation is really about what makes some tests better than others, rather than specific tests. I'd appreciate any and all feedback, especially suggestions for improvement.
Download "Better Testing" (584Kb, PowerPoint).
It emphasizes principles rather than giving specific tips, how-tos, or examples. This was written for the cerebral QA or development manager who is seeking some insight into why some things work well and others don't, rather than a prescription for an inexperienced manager looking for specific direction.
I started developing the presentation with a completely different plan for what it would contain and communicate. I really wanted to talk about burn-down charts and talk about various metrics I have personally found to be useful.
I imagined a kind of diagnosis model where the presentation would list specific project problems and talk about what you can empirically measure to confirm the problem. However, as I wrote out explanations for each metric, I noticed a problem.
Every time I'd explain a metric, I found myself writing out various caveats and disclaimers. The trouble is that metrics can be completely misused, causing teams to chase the numbers rather than develop software. So with each metric there are good things you can discover with measurement, but there are also pathological problems you can experience if you focus on the metric to the exclusion of the underlying principle.
After a while, I realized that this problem seemed more interesting to me than the metrics themselves. This is a cliché for programmers. We start developing a to-do list application and end up with an entire web development framework because we find the underlying common problem more interesting than the application.
So, this presentation is really about what makes some tests better than others, rather than specific tests. I'd appreciate any and all feedback, especially suggestions for improvement.
Labels: agile
Monday, February 06, 2006
Three Email Courtesies
The following are courtesies: they help the people who read your emails save time. That makes them more productive and, hopefully, a little bit grateful to you :-)
How and when to mark emails "important:"
Use the low and high importance flags to mean urgent and not urgent. Specifically, high priority should mean "read this the moment you see it in your in box." Low priority means "you don't need to read this if you don't want to." Anything else means "use your own judgment, but please read this in the fullness of time."
What I do with the high priority flag is this: I use it whenever I would feel justified in interrupting someone else's meeting to tell them something. If it isn't that urgent, I do not mark it high importance.
Edit the subject line freely:
Edit the subject line for replies and forwards. Your reader is scanning their in box. What does "RE: RE: RE: FW: RE: the meeting" mean? Help them scan your subject at a glance. I suggest you almost never use the default "RE:" Instead, do this:
Make up a new subject line that describes your answer to an email and then prepend it to the old line. For example, instead of : "RE: the meeting", use "Some suggested topics | RE: the meeting."
This saves your reader a lot of time. Isn't that a tremendous gift?
Put short replies in the subject:
Does your reader need to open your email just to read the word "thanks"? I know Outlook has a preview pane. But it's still extra work to click on each message to see its preview. And if your reader has to set things up to preview every message in their inbox, they can see fewer messages.
Try this instead: put short replies right in the subject line with an indicator that there is no body. I use <eom/> because it's XML-ish and I happen to hate XML, so it feels like an inside joke. But everyone understands it. So try: "I'll bring the bagels! <eom/> | RE: the meeting."
That saves your reader even more time. The gift that keeps on giving!
I did not invent these ideas. I don't remember where I heard of them, but I wouldn't be surprised if at some time in the recent past I read a post just like this with these ideas in it. If someone can point out a source for these ideas, please comment and I'll give the proper attribution.
How and when to mark emails "important:"
Use the low and high importance flags to mean urgent and not urgent. Specifically, high priority should mean "read this the moment you see it in your in box." Low priority means "you don't need to read this if you don't want to." Anything else means "use your own judgment, but please read this in the fullness of time."
What I do with the high priority flag is this: I use it whenever I would feel justified in interrupting someone else's meeting to tell them something. If it isn't that urgent, I do not mark it high importance.
Edit the subject line freely:
Edit the subject line for replies and forwards. Your reader is scanning their in box. What does "RE: RE: RE: FW: RE: the meeting" mean? Help them scan your subject at a glance. I suggest you almost never use the default "RE:" Instead, do this:
Make up a new subject line that describes your answer to an email and then prepend it to the old line. For example, instead of : "RE: the meeting", use "Some suggested topics | RE: the meeting."
This saves your reader a lot of time. Isn't that a tremendous gift?
Put short replies in the subject:
Does your reader need to open your email just to read the word "thanks"? I know Outlook has a preview pane. But it's still extra work to click on each message to see its preview. And if your reader has to set things up to preview every message in their inbox, they can see fewer messages.
Try this instead: put short replies right in the subject line with an indicator that there is no body. I use <eom/> because it's XML-ish and I happen to hate XML, so it feels like an inside joke. But everyone understands it. So try: "I'll bring the bagels! <eom/> | RE: the meeting."
That saves your reader even more time. The gift that keeps on giving!
I did not invent these ideas. I don't remember where I heard of them, but I wouldn't be surprised if at some time in the recent past I read a post just like this with these ideas in it. If someone can point out a source for these ideas, please comment and I'll give the proper attribution.
