Victory!

I fixed it!

It seems like the first installation of PC Suite failed but when I run remove program, the program was not removed. So when I reinstalled it, the error remained. But when I removed all the files manually and restarted the computer, I could complete the installation.

But the installation function of PC Suite is a shame for the industry and for Sony Ericsson. But I fixed it and that is what is most important right now.

Back to Sony Ericsson

When buying a new private phone, I was leaving Windows Mobile behind. I've not used Sony Ericsson for about ten years and I was really wondering how fast I could come in to the different UI. Despite me trying to tap the screen, it went smoothly. Except two things: recurring calender events (I cannot understand how they've let those bugs get out in production) and the PC Suite, which I've not yet gotten to work. I'm now trying to reinstall the program, since the support hasen't gotten back to me with any kind of help. And the connectivity to the computer was something I really wanted. So, I'm not very satisfied with Sony Ericsson right now.

Gladly enough, I'm really happy with the actual phone after two not so lucky sessions with HTC Touch Dual and HTC Touch Cruise.

A good idea

Why make life complicated? Why choose the difficult solution?

We can laugh at the advice in the add but professionally, how often do we choose to swim in alligator infested water when we don't have to?

Sometimes when we choose between two options, one can be the alligator infested water. It can be obvious from start but there are also water which becomes alligator infested if you continue swimming for a while. Unmaintainable or untestable code are examples of this. The hardest choice is of course when you have to choose between the alligators and the sharks. And then you just have to pick your fight.

Patterns and practices Acceptance testing

Got a tip from Richard Fennell that a beta on Patterns and practices for acceptance testing is to be released on Codeplex.

Sure read for yours truly! According to Fennell it will include several methods for acceptance testing, both working agile and waterfall. The download includes a table of content for you interested folks

You get what you measure - so how to create key values on bugs

Bugs are elusive. Not only that they occur, but that it seems that most key values which measures bugs is contraproductive but reading about Yahoo and their transition to agile, I've found a new interesting metric: number of critical bugs found in X within Y days after placed in Test/Production/etc. For example if you have the metric "The number of critical bugs found in production within 5 days of production".

Why is this interesting? Well, if it took the users less than five days to find the problem, the software development team should have found it as well.

The same type of metrics should be applicable in the different stages of a sprint, for example number of critical bugs found the first day of acceptance testing.

There is probably a downside to this metric but so far I like it

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.

Testing or trying

Tomorrow, we're starting the more structured acceptance testing before our release candidate on Monday. And we're including Testers and Tryers. So, what is the difference? Well, when you have a tester on a team, he works like a doctor with a sickly patient. He goes in a structured way through all the symptoms to find out what works and what doesn't work. He's an expert at finding software related bugs and will report a splendid bug report which my developers will love to work with.

But is the tester a normal user? Well, no! He doesn't work like a normal user and can never say "well, this will work with the user of type two." For this, we need the tryers. They try everything possible and impossible which a user can do in an very unstructured way. This works very well combined with with personas - the tryers should act like a user of a specific kind. Like the mad lady Vera at Customer C, who always double clicks Cancel when ever that button is visible. The tryer is not good at identifying actual software bugs and will never give a report which a developer can work with (other than saying cannot reproduce). But trying as as valid a test method if you use it properly. If the tryers think the customers will benefit from the new version, this is just what we need to know to go ahead with the deployment.

Why I'd love having House on my team

I have for some time tried explaining to folks at work what constitutes a good tester. That it's a mind set, and it takes a problem seeking mind, patience and a capability to express yourself. Well, the excellent blog I'm Testy gives some more insight into the issue and compares the tester to a physician. Well, I wouldn't mind having dr House of the TV series on my show. Here are some treats which makes him an excellent tester:

• Knowledge
• Working with a team
• Selects which problems to focus on: interesting and life threatening problems
• Capability to see outside the box
• Drilling into the problem
• Discusses open the different options and their dire consequences with the patient himself.

Well, you might say he's arrogant and evil, but that is perhaps the consequence of being a good tester.

Bugs...

One of the guys is staying late this evening. And my mail box is suddenly filled with bug reports. Should I be worried? No, this is awesome! We're one week away from code stop and we've identified a lot of critical bugs that we don't want to find next week. So, I have a hero in my team.

Asking why why why why

The famous Toyota four whys are a good rule. Take for example the critical bug we had in the latest release.

1. Why?
Well, it wasn't tested

2. Why wasn't it tested?
We tested it manually at the beginning of the last week, but not after the final critical check-ins.

3. Why manual test?
There are no automatic tests on that feature.

4. Why???


And here we come to the core of the problem. The problem is that we lack automatic tests on critical functions. And even if we fixed the bug now, we're open for the same bug next month. So, we didn't fix the problem. We fixed the acute bug. And that is the problem...

Released is awsome, but tests are better

Just before lunch, we moved the last item from our Stable list to Released list. In other words, we released! Nice and cozy. We all went for our lunch. Well back, the spiders are not running properly. The scrum master says it's because we're releasing an empty database. And I said, 'Hey, isn't that the problem we had last sprint. And the sprint before. And when I come to think about it: the sprint before.'
'No', says the scrum master. It's another problem but it manifests itself in the same manor. So, how come we don't have an automated test for this? The errors might differ between sprints but the test must always work.

Test the right stuff

As always, the few precious hour before release were hectic last week. Actually, yesterday it was a week ago. Terrible: the developers were fixing critical bugs the last minutes. And then we made a stupid mistake. Not testing the most crucial stuff: does it work to install the goodies?
Yesterday, our Operations team tried installing. It didn´t work. The last minute fixes worked on our development environment, but when setting up a test installation, it simply didn't work. And if you can't install it, you can't use it. Then you can discuss test driven development and code coverage to it's end. But you still might not have tested the most crucial stuff.
In cycling, the mountains are divided into categories, 5, 4, 3, 2 and 1, where 1 is the most difficult category. Then there is HC, that's beyond categorization. The mountains cars have trouble conquering. The mountains it would take us days to climb on a bike. If we'd make it at all.
In our team, we've introduced a HC category on our priority list. Beyond priority. If we don't complete those tasks, nothing else matters. And testing an installation is definitely a HC task.

A real user in the room

Today we've borrowed one of our consultants to test our new applications. He´s a really funny guy with a real user perspective, having been a real user in the past. It's fun and interesting to watch. And a little scary too...

Code analysis

I just read an interesting blog post. We're reinstalling our Team System server and since we'd have had many discussions on ca-warnings I checked which warning Microsoft uses, as a minimum.

If you're interested, here is a link to the Blog in question.

Then I realized that this is as boring as it can be. They have infected me with geekiness here at work.