What do you test?
The latest releases have been quite hectic, and I've not had time participating in the acceptance testing but the release for tomorrow was up for some manual cranking by the mrs Product Owner today.
I don't know if I'm a good tester. I believe I'm not. But I always get our applications to crash. It's amazing. Give me five minutes and I have a crash. This time the errors were not in this product increment but has hanged on for a couple of sprints. Non of the users has complained either. So, how come? There is one simple solution to the question - I know where the possible loop holes are. I know my developers so I know what they overlook. So, I know what to test. This is one of my strengths (I think) as a product owner. Knowing the guys and knowing the application.
But it makes me a lousy tester. A good tester prevents these bugs from making it into the product in the first place. If I was a good tester I would do something to make this not happen again. Because if I know where to look, how come I don't share this information on the sprint planning meeting?
Mainly because I then participate with the product owner hat on my head and even if I'm dedicated to quality, I'm simply not wearing the tester's hat. Interesting. I have to do something about this but I'm not quite sure what and how.
What I also find is that I discover those small annoying bugs, usability wise, which makes the application unpredictable. And the funny thing is that when I ask the users if they don't find X annoying, they do, But they just take it for granted. That is sad. We develop for the users and they are so used to systems being a pain in the ass.
This is not because we have a lousy product. I think our product is wonderful. But more that users are so used to systems not being predictable and that they have to have this strange routines to go around the obsticles. The worst example was a lady whos computer had so low memory she had to turn of her screen to be able to complete a print out. And she never complained.
Well, it's pushing Friday and that is release day. Hurrey.
posted by Anna Forss @ 11:47 PM
2 Comments:
Your description of users seem classical to me. They need to get their job done so if they have to stand on their head to do it, they do. They also tend to take mistakes as their own fault. One horrible example was an application that had different meaning of the Return and Enter keys. And the users blamed themself for not coping.
To get great usability, you have to observe the users in action, somehow. If you can measure the mistakes directly in the product, fine. Or video tape the users.
Airplane controls were developed with the outspoken goal to never blame the pilot for being inadquate. It is the system that should prevent mistakes. Often the system is also the easiest to fix.
As a product owner, bad usability should be converted into money lost. So the stories that describe that quality of the system has a clear business value.
I couldn't agree more. It is important to value the completeness of a solution. And a solution is not complete if it does not work as the user expect it.
I prefer watching users in action. People tend to react to a camera and even watching users can be hard if you don't take the time to make them used to you.
Very good points! And they say developers don't care about users.
Post a Comment
Subscribe to Post Comments [Atom]
<< Home