Arkisto: May 2011

All the Weapons You Need

30. Mayta, 2011 | Kirjoittaja: Antti Niittyviita

Sucker Punch was a good movie. I dare say that, even though there is a downpour of differing opinions. First and foremost from the experience I remember the unbelievably fitting quote:

You have all the weapons you need… now fight!

That scene made me skip a beat. It did so, because I caught myself having the most stupid mindscape. I had always believed that in order to get results, you will need tools. Weapons, with which the job gets taken care of with efficiency and with no problems.

When a Finnish man is faced with a problem: the yard light has burned out, or the toilet seat at the office is broken, the man goes to pay the hardware store a visit. On that trip the man finds himself picking up a plethora of new and useful tools without which there is no way of living. Sometimes in the midst of it all, the man may even forget the main thing itself: that light, or that toilet seat.

The same problem causes inconveniences to numerous software projects around the world every day. Instead of painstaking creative work and getting started, the people look for tools on the Internet, each tool finer than the one before. They configure them to work and may even pay hefty prices for them. Yet, without an exception, these tool acquisitions are the main obstacle for getting results.

Test control system is one of these gadgets. Most of the time, they get implemented with great oomph and people get working to fill them up with documentation. Simply said, with test cases, requirements and new iterations of tests run. In actuality, the same results of testing could have been achieved by making a sensible use of only 10% of the system’s properties. Or entirely without!

From Tieturi’s Testaus 2011 seminar the most vivid memory I took home with me was Elisa Puoskari’s speech regarding Sulake’s working methods. At Sulake, the sprints are one day long. They have done away with defect database systems. There is a bunch of post-it notes hanging on the wall of the project room, one per error. They don’t waste time hanging around in the hardware store, configuring, updating servers, information management or user access levels.

Instead of fretting about tools Sulake has understood that which Sucker Punch tried to say.

Stop looking for scapegoat obstacles, problems or guilty parties from the outside and stop to think for a moment. You have all the tools which you will ever need to succeed. Do not be afraid to use them!

How Difficult can you Make a Warranty?

17. Mayta, 2011 | Kirjoittaja: Antti Niittyviita

Very difficult, is the right answer. I had an impetus to write about it after experiencing a case of customer service. The beginning of it all was like this:

I went and bought a new Samsung DVD-player from Anttila for personal everyday use. In the player, there was a clear user-independent defect: When playing a DVD (or a CD) the tracks had a chance to skip over to the next track while playing.

This small and randomly occurring defect made me take the player back to Anttila demanding the warranty service. In a belittling manner the salesperson of the technical department tried to continuously argue that the defect was brought about by scratches on the played CD. After a surprisingly hard metaphorical armwrestle I pulled out my last trump card and told the salesperson: “I am a diploma engineer of Information Technology and a software tester by profession. I am certain that the defect is in the player.” This changed things and the player was taken for repairs. Was this the first time when there has been concrete benefit from having an engineering diploma? ;)

After over a month later I had almost forgotten that I was an owner of a dvd-player, but then my Nokia phone received an SMS message from Anttila. “Your product has arrived from the service and is ready to be picked up.” I went and collected the player and when I reached home I read the list of operations that had been made to it: “Firmware updated” OK, I thought to myself, it could very well be that the defect in question could be solved with updating the firmware. I immediately took the player for a spin, but again after a few tracks of Pink Floyd the player skipped the to the next track right in the middle of good riffs! I seriously doubt that Infocare’s boys (Oulu’s Anttila outsources their product services to them, apparently) in southern Finland even bothered to try and reproduce the defect. And back to Anttila with the player. This time around, they took it in without arguing.

After a few weeks my Nokia phone received another SMS, which informed their dear customer to send the example CD to Infocare, so that they could reproduce the defect. The message had no information regarding their postal address, e-mail address or any contact information for the person in charge of the service. At the end of the message there was an ultimatum: Unless the customer sends the example CD within 7 days, the player will be sent back and the customer will have to pay a cost evaluation fee and the shipping. Some customer service there!

How this turns out is still open, the day the message arrived.

Immediately some questions pop into my mind. How thorough have Infocare’s boys been in southern Finland with verifying the actuality of the defect? With what logic is it cheaper to send the device from Oulu to Helsinki for one month for the servicing, if the thing they only do is a five minute firmware update? Is it really the benefit of manufacturer, seller or the service firm if the customer is threatened with shipping fees, when everyone could have had an easier time by giving a new device instead of the defecting one?

When I think about it from the point of view of the manufacturer, Samsung, I feel bad. The cost of the defect gets multiplied manyfold through this mindless and inefficient warranty service. To get rid of expenses, two options come into my mind. To either catch the bugs in the product development stage or start to improve the warranty service pipe.

This entire story serves as a tip for the manufacturer:

An user cannot be with your product 24/7. You cannot presume that a single fixer can notice a randomly occurring defect within a few minutes (or even an hour). It is not worth slapping the defect in an ignored-state after a short evaluation if it reproduces only at random. Apathy costs dearly.

One Step at a Time Towards Functioning Testing

5. Mayta, 2011 | Kirjoittaja: Antti Niittyviita

When testing is missing or does not work, admitting the problem is pain. It usually gets revealed after stuff has hit the fan. Still to this day, too often a phone rings at our office after there has been an accident.

We are missing functioning testing. What should we do?

Because uncertainty so often bothers the builder of a functioning testing, the first steps remain untaken. Only a necessity gets thing going. By that time, the client is breathing on the back of the neck, and the software developer’s time is surprisingly spent fixing the errors.

We decided to offer a free lesson on how functioning testing can be built out of sufficiently small blocks.

  1. Develop: Build a steady life rhythm with the software developers. Something worth testing should come out ever so often. Without this, there is no sense in investing in testing.
  2. Allocate resources: Hire a tester experienced enough, or buy the service from a partner. The main thing is, that the person is actually a tester and not just a bad developer.
  3. Test: Kick things off with the exploratory testing method. To discover the defects that have an impact on your client’s life is the thing that is immediately worth investing for!
  4. Build: Bring in new tools. Improve test- and defect control. Build a systematic method of acting, for example, with checklists. You can also think about automation.
  5. Condense: Condense the chasm between development and testing. In testing, aim from large waterfalls to small ones or Agile.
  6. Measure: Build at most three easy to use measures to evaluate the software’s quality. Our measures are based on all defect data.
  7. Optimize: Tune the amount of testing step by step until you have reached the optimal level.

By taking care of one step at a time you can already reach far in software development. With these steps it is possible to build a wholly new and high quality point of view towards building software under a month.

You can build a functioning testing out of small partial goals. You only need to grab the bull by its horn and get to work!

P.S. If getting started feels difficult despite these tips, you can order a Kick-off from us. We take care of parts 1 through 4 out of your way in only two weeks! You need not take part in anything but in the beginning meeting and in the end evaluation.