Archive

Archive for the ‘testing’ Category

The consequences of a bug fix

Take a good look at this guy. What, you didn’t know who he is? Of course: he’s pope Gregory XIII, who created the Gregorian calendar.

Here is some Wikipedia quotes about the calendar:

The Gregorian calendar is the internationally accepted civil calendar.[1][2][3] It was introduced by Pope Gregory XIII, after whom the calendar was named, by a decree signed on 24 February 1582, a papal bull known by its opening words Inter gravissimas.[4] The reformed calendar was adopted later that year by a handful of countries, with other countries adopting it over the following centuries. The need for the Gregorian reform stemmed from the fact that the Julian calendar system assumes a length for the mean tropical year of 365 days and 6 hours, when the correct value is 365 days 5 hours 48 minutes and 45 seconds. At the time of its introduction the actual date of the vernal equinox was imperfectly known. At the time of the reform the length of the mean tropical year was also imperfectly known. A 400 – year intercalary cycle was introduced which gives an average length for the calendar year which is 27 seconds too long. In the twentieth century Eastern European governments, on the advice of astronomers, introduced a version with a 900 – year intercalary cycle which gives an average length for the calendar year which is only two seconds too long.[5]

When implementing the calendar, 11 days were removed to get in line with the new calendar.

During Agila Sverige, Albin Rännar from Nordic Investor Services, besides from giving a very interesting speech on the death of the budget, explained some of the problems which evolved from the good pope’s new calendar.

If you just look at the description, it looks like a really good idea to reform the calendar. In other words, fix those bugs in the calendar.

But as Rännar pointed at: what about the short term effects? Let’s say that you had a contract with a contractor and according to this contract, you would deliver on July 14th. And then suddenly, there was no  July 14th. What then? And even if the actual date was not removed, you might loose 11 days during which you could complete the delivery.

Another person (sorry, but I don’t remember exactly who it was who told the story) then told us about another problem they had when they fixed bugs. Sometimes there was a bug which users used in their business and by fixing that bug, a business opportunity disappeared with the release and without any warning.

And this brings us back to the definition of a bug. For the poor contractor, the missing 11 days was a bug and for the customer losing his business opportunity removing that loop hole probably feels like a bug.

Sometimes fixing a bug feels like creating one, even if there are no regressions.

Advertisements
Categories: Business, testing

Are you consistently bad?

We need to be consistent! We need to be reliable!

Aren’t that nice?

But then consider Sanjiv Augustine’s wonderful statement from APLN:

image

(Source Jesse Fewell)

A team can be consistent and reliable and still deliver garbage. If you always deliver garbage, you’re pretty predictable, aren’t you? You can truly rely on them delivering garbage. Business as usual.

I have a childhood friend who works with a supplier who he really can count on. He can count on the system failing after each upgrade. He can rely on the support functionality not being able to fix his problems after the delivery and he can be sure to have a lot of angry users on his back. After each upgrade.

What bugs my friend the most is not the individual problems. It’s that no one seems to care that his company loses money every time they upgrade the system. He’s annoyed by that nothing gets better. He feels like the supplier sees the problems as normal. Well, they are since they are consistent, he laughs with panic in his voice when we talk after an upgrade.

I’ve told my friend that he should abandon the supplier, for his company’s sake but mostly for his own health’s sake. And this my recommendation: if you work with a supplier who sees garbage deliveries as the normal state, get out. And if the supplier thinks there are different problems each time and blames this and that, well that is no excuse. If the process consistently produces garbage, it does not matter if the garbage is of type A one day and B the other. It is obvious that the process allows the garbage.

If you instead work at that supplier, you should do something about it. The competition is hard out there and blaming this and that does not help. Look back at your latest deliveries and figure out how many critical errors your company has introduced to your users lately. And no, don’t blame the integrators or the installation guys or even the users. Look at the end product.

Are you proud or are you lining up arguments why you were not to blamed for these incidents?

Jesse Fewell have on his blog presented how Sanjiv Augustine has described his idea of an Agile PMO and how such a solution can fuel continuous improvement.

This is just one take on the problem and it’s handling. Because this is not a problem what can be solved, it’s something you need to work on all the time and on all levels. So what if you have 90% code coverage, work test driven, use scrum and have continuous integration? These are great tools among other tools but if you still work in the garbage spreading business what’s the use of you mixing the garbage with some fine wines?

Categories: Agile, Business, lean, scrum, testing Tags:

The non responsive UI – a nightmare for users and testers

If there is something I cannot tolerate as a computer, it’s a non responsive UI.

I’m currently updating my IPod music list and I’m so disappointed with Apple that they still haven’t fixed the responsiveness of the UI. If I click a song in the list, it takes seconds before ITunes starts playing the new song.

My least favorite program is in a class of itself, as always. When I select an e-mail in the Inbox it can take many long seconds before the right message is displayed in the preview. This has sometimes resulted in missed information and always a lot of frustration.

As a tester, the non responsive UI is also a big problem. I click something. Nothing happens. So, I click again. Something happens. Is that because I clicked once or twice?

When you’re buying new software for your staff, don’t be satisfied with a PowerPoint presentation, test the UI yourself. And that does not mean the salesperson showing what he wants to show with the data he wants to display. If you have a product list with 100.000 products, make sure you test the search functionality with that data. And make sure that you are handling the computer. Salespeople know their software, know where the loopholes are. But he won’t be there when the guys can’t complete their tasks because the software is malfunctioning.

We can all blame the software industry for sloppy work in this area but as long as the people buying the stuff does not demand this as much as they demand functions which they rarely use, why should things improve?

Categories: Business, testing, Usability

Business value of the boring stuff

2009/08/17 1 comment

This weekend, our vacuum cleaner broke down. We both looked devastated on the thing. Not so much for the money (which of course is boring to spend) but for the knowledge that we now would have to spend a lot of time buying a new one.

First, I tried to make an educated, good decision and scanned different communities and sites for the most recommended and best value. But I soon lost interest and found myself surfing on more interesting stuff. That is most things in the universe. I tried looking at one of those cleaning robots but realized that with two floors, one dog and a boy into Lego, this would probably cause more time spent than our gain.

So, I just gave up and went to the store. I went to one of those malls where are multiple stores to choose from, but realized when I got there that it wasn’t worth my time shopping around. So, I picked a store and went inside.

There are an silly amount of options out there, folks. One brand can have five or six different models in your average store. People went around there, testing the things. I just stared. How could I possibly choose?

And then I nearly fell into the trap that most product owners do when they prioritize. They think that something is boring so they go for the cheapest option out there. I almost picked the cheapest one when I realized, Hey, I hate cleaning. Why should I have the worst possible tool when I do the stuff I hate the most? Won’t that make me hate it even more?

The same goes for product owners. They probably don’t think upgrades, logging, error handling and installation features are the stuff of their dreams, so they try to get this as cheap as possible. And then they complain when bugs go unnoticed for months. When regression testing is a hassle, when upgrades takes forever and roll back is not possible.

I didn’t pick the most expensive vacuum cleaners. I took one in the upper level without a bag. I don’t like shopping those bags either. Since I don’t even know the model I’m using, I’m stuck trying to find that just to know that the specific bags are not available then. And they cost a lot of money. With a Golden Retriever you tend to spend a lot of bags.

Well at home, I found that the new thingy made it easier to clean at home. And having a remote in the handle is really a good thing. The dog hair is handled much better and one of the rugs are clean for the first time in five years. Well, I thought it was kind of clean before but now I know.

And one thing more, skipping the bag means that I can see all the stuff I vacuum. No more hiding of dirt. And that is also important in software development. Never hide your garbage for your in house staff. Better that they know about it and help with the cleaning.

Testing on other projects

2009/08/16 1 comment

One of my requirements for starting to work for TUI Nordic was that I was to be able to participate as a tester. For me as a project manager, testing enables me to get to learn the system and the users in a very easy and for filling way, but it also makes it possible to become a real team member. In TUI Nordic, the project manager fills the product owner role in scrum projects and since I’m a firm believer in product owners being a part of the scrum team, this is a easy way to do that. Stating that one is a team member is one thing, but if you don’t do any actual work and function as a chicken, you’re not a real team member, indifferent of how much coffee you bring the guys.

The passed week, I’ve tested a new experience with testing. We’re completing to projects at the same time and since we work with shared code, our projects are really integrated. So, I asked if I couldn’t participate as a tester of the other project. Really interesting. I can get a little bit of insight in the project manager skills of another project manager from an inside perspective, but I also learn more about being a tester. In all other projects I’ve been a tester in; I’ve known all the objectives and known the project in all details. Known what has been decided and which decisions are lacking.

The difference is huge. I’ve really learnt how important for testers to learn about all those decisions. But how? An extensive list? I don’t know. Do you?

Categories: Leadership, testing

Measuring productivity

You get what you measure

So true, so true. These famous words from Mary Poppendieck point at an important objective of anyone interested in their work.

But there is a risk to these words. Because you can be lead to believe that you can measure everything you want.

I want my son to love me. So, following Mary’s words I should probably measure his love. This should ensure me success in getting his love.

Sounds goofy? Well, to most sane people this sounds crazy. I cannot take out a chart and plot my son’s love for me.

But how about productivity? In the agile community I’ve read a couple of discussions about if you can use velocity to measure productivity. I don’t like this idea much. I use velocity for predictions and my priority. Story point estimates are in my world a relative value of size, and if I start measuring how many dots they complete every month, they are not sure to start making their estimates bigger. I still don’t measure productivity but I’ve also lost my chance of predicting my upcoming deliveries.

So, how do I measure productivity of the developers on my team? Well, I measure it by how happy my users and stakeholders Do they feel that the investment was worth it. But, but, you might say: that is too vague! And I say that just this is what matters. If the customer is happy about the investment. Can they make the money they hade anticipated or save the cost they were counting on.

And frankly, I have a hard time finding a good measurement of productivity. I can just look back at my role; project manager. What is a productive project manager? Is it the one who makes the most Gantt chart bars? Or holds the longest steering groups? How does a project manager know if he’s been productive a day? For me it’s a feeling. Some days I can have had this ten minutes meeting which clarified a lot of stuff which will save us a lot of coding time or make us reach our goals. But a numeric calculation, I don’t know.

It was perhaps easier when I was a test leader. And yet not. A productive tester does not find a lot of bugs, he prevents them from occurring in the first place. And how do you measure that? Yes, you can measure the decline in bugs, but how do you know if a specific tester was the reason.

So, to summarize; I wouldn’t feel productive as a project manager if I was asked to measure the productivity of team members.

Do you use the Spoilt Brat Pattern?

2009/06/15 2 comments

One of the reason for why I started working for TUI Nordic was the view of the customer. Not that the customer’s always right but the customer must feel like he’s right.

All too often do people think that their customer is wrong or should blame himself for not being satisfied. He made the wrong choice, picked the budget alternative and still he has the nerve to complain about it. And when he do complain how many strive at making the customer go away/stop complaining instead of making him content. Sometimes it does not cost you anything. More often than not simple words and explanations can make the customer feel that his issues has been noticed and validated. Yes, you feel that your hotel is too far from the beach and that is why you paid less than the others. Do you want me to check if we can upgrade your reservation? That’s an example of what I mean, instead of making the customer feel stupid you can recognize his problem and find solutions.

And the same goes for development teams. You have a feature developed and when you deliver you find that the customer is not satisfied. In some cases they tell you that you got it all wrong, load and clear. In other cases they don’t use the functions. In both cases there can be frustration that you didn’t understand them but I guess there is also a sense of guilt. Perhaps they helped during specification and testing but it wasn’t until production they realized the problem. So what do you do?

Many turn to the Spoilt Brat Pattern.

Before I got Peter, I used to hate spoilt children. I still hate it, but now I have a better understanding. So, what is a spoilt brat? That’s the kid who gets what he screams about and he’s still not happy. He complains, screams that you got him the wrong one or that he just want something new now.

If you as an adult apply the Spoilt Brat Pattern you turn to the child and say “Hey, you asked for that one. You got it now, so don’t be so spoiled and be happy about what you have. Think about the poor kids in X, they would be thrilled about that one. It’s no fun giving you stuff, because you’re never pleased.”

Spot on, isn’t it. Hm. In software development this would sound like “Hey, we built it like the specification and you did approve to this during testing. Now you have what you wanted. Think about the guys in finance, they have been waiting for their features for a month now. Why should we develop things for you, you’re never pleased with anything.”

Well, yesterday an incident got me thinking. My son Peter really wanted a scooter after testing one at his cousin and a month ago, we went out and got one. I went to a toy store and there it was, blue and Peter approved of it. It wasn’t quite like the one his cousin had but there were no others like that one in the store, so we got this blue one. It looked something like this:

At home, Peter started using the scooter but soon, I realized he wasn’t pleased with it. And he stopped using it. I couldn’t understand why. So, yesterday we started talking about in a store. He saw another scooter and he gloated. So, I asked why he didn’t use his own scooter. This one was just the same, or?

                

But, he finally confessed, you cannot slide with his. Stupid mom as I am I stated that they were the same. No, said Peter. Mine has three wheels, so I can’t slide it when I brake. If I were a better mom I would probably hinder my son from sliding at age four, but instead I realized our mistake. Peter hadn’t understood that the third wheel would hinder him from making that daring stuff he wanted to do and I hadn’t even bothered to learn the difference between the two types of scooters.

If I had played the Spoilt Brat Pattern on Peter, I would have just said that he should be happy about his scooter. But instead I got him the right one instead and gave the other one to another child, whose parents wouldn’t afford one and who won’t do any sliding. Both Peter and I made a mistake by picking out the three-wheeled scooter in the first place and forcing him to use it would be of no good to anyone of us. But, and this is a big but; hadn’t he acknowledged that he himself made the original choice, this story would have had another ending.

So, next time your users are not happy about the features you’ve built, think if you’ve built them the three-wheeled scooter they didn’t really have any use for and try to fix the problem.