Arkisto: June 2011



Right Time to Reef

29. Juneta, 2011 | Kirjoittaja: Antti Niittyviita

Midsummer came and went. I started the Midsummer holidays by sitting on the beach rocks at my beloved cottage. The moment was perfect for daydreaming, since a gentle wave met the shore and a pleasant sea wind kept the mosquitoes away. The wind must have been just right, since even the holiday sailors had come out.

As the wind gets stronger and stronger, so does the sailing become harder. The speed does get higher, but so do the skipper’s skills get tested. When sailing, strong winds incline the boat a lot. In addition, the forces at work at separate parts of the boat, such as the mast and the rigging get stronger. The sail might get stretched, or in worst case even get damaged, unless an aware skipper understands the situation.

The purpose of reefing is to lower the area of the sail. You manage this by, for example, lowering the main sail or by fastening it to a bar lower. By making the area of the sail smaller you can avoid the aforementioned problems and make the voyage safer. Furthermore, the speed increases when you tack.

But when does a skipper know when to reef?

The people who have read the previous post might already guess the answer. It is about feel. You might very well have meters for inclination or for the real wind velocity behind the rudder, but the right decisions are made with experience and with the feel.

I warmly recommend a small moment of reflection for everyone on the software business. It is easiest at the beach or at a campfire.

When was the last time you documented requirements for your holiday or hobby? Have you ever made a detailed holiday plan? Have you made quality criteria or test cases for your free time? Do you measure your successes in some way?

At least I get anxious by a mere thought of these. Hobbies and holidays usually go very well without any of the above. The summer reflection’s place is to consider if any of the methods you use during your free time could be of use during work time?

Have a good and relaxing summer holiday everyone. Softwaretesting.fi shall return onto the waves come August.

The Tester Sits on the Seat of the Co-driver

16. Juneta, 2011 | Kirjoittaja: Antti Niittyviita

You cannot steer with the horror handle. You hold on to it with knuckles white from the extertion when the road suddenly gets rocky.

I sat in the co-driver’s seat in the beginning of the week on our way to lunch. My duty was to inform the driver which turns to take on our way to the Chinese restaurant. I seldom sit in any other place in a car than right behind the steering wheel, so the trip was quite insightful. It taught me a lot about tester’s life in software projects.

In the shoes of the co-driver I of course had a continuous field of vision to where we were going and how the traffic was. I could continuously feel if the speed would have been high or maybe too slow. I could of course feel too if the road was rocky and how steep the speed bumps were. The driver’s braking and accelerating were clear to me. I could have noticed them even with my eyes closed. I could also constantly see if the car behind us was getting too close. I could also estimate whether or not the surface of the road seemed dangerous after the rain. And that is not even the end of my sightings. The list could go on forever.

I could gather all this information from merely observing the situation and feeling with my body. It must have been how the driver did it. Getting to where we were headed had nothing to do with the meters in the car. Just think about how it would have been if we had both been staring at the speed-o-meter, the engine cycles, fuel consumption or the distance meter, just like they do in software projects. Pretty soon we would have found ourselves off the road.

Tester, just like a co-driver, cannot directly influence where they are going. The right kind of communication is where it is at.

This trip was a happy one, since I could actually influence our driving. The driver was a smart one and understood my directions well. We also shared a common goal that we had agreed upon earlier. The communication was excellent both ways.

As a co-driver I tried to give the directions constructively and ahead of time. Apparently, I even succeeded in it, since we had our Chinese lunch with both of us having ended up in the same place. But what would have happened, if I had only been a smart ass and given critique such as “We should have taken that turn earlier.”? My guess is that my trip would have continued on foot.

I think that the meters are an excellent aid for the trip. Yet, the main weight on making the right calls can never rest on them and them alone. The question is almost always about a gut feeling and the right communication. It is about a feeling. Some call it intuition, some call it experience. It holds true for both driving and software development.

Facts, meters and numbers are an excellent aid, but actual solutions and successes are always based on feelings. Having no trust in your feelings is the worst enemy of decisions.

P.S. I did not need to grasp the horror handle on this trip. The going was smooth and the team worked!

Testing and Quality Assurance Arguing

9. Juneta, 2011 | Kirjoittaja: Antti Niittyviita

Quality Assurance. QA. Sounds grand and looks pretty intense on a business card. Too bad that it has little to do with testing.

Some time ago I worked as a tester in a project in a large scale project. I hunted for bugs. The title us professionals of testing carried was “QA engineer”. We discussed QA-related things with the client and there was a lot of incoming QA from each possible direction.

When the project had been running for one year it started to become clear that it would never finish. We understood it after working for nine months and we even dared to say it out loud. The owner of the product realized it after wasting funding for another 8 months more. That last 8 months was maybe the most insightful time of my career. We mercilessly went through issues and tried to find solutions. Too bad that solving the issues was attempted from the opposite side that it should. Everything in fact started from testing, that is, in our project from quality assurance.

Your mission is to assure of the quality. You are quality assurance! Why does everything in this project go offroad?

Yep. Amazingly many testers face their everyday problems from this setting of things. They imagine that the tester is responsible for quality, even though the reality is entirely different.

  1. Tester has no power over making changes in the code
  2. Tester has no power over releases
  3. Tester has no power over making decisions regarding project management
  4. Tester has no power over time tables

The very same questions was brought up by Michael Bolton on his Rapid Software Testing course.

Why on earth would you call it quality assurance, when people doing it have no control over the quality?

Quality assurance is a grand word, but often full of it. At least it bring up in my mind that now the tester has to assure for the product’s quality. This way we can toss the actually useful goals of tester’s work into the garbage bin. The term ‘quality assurance’ sets the mindscape to the wrong tracks right from the start, before any work has even been done.

The actual mission of the tester is not to build confidence regarding the product’s workability. The actual mission of the tester is to destroy confidence built on false basis. Then it is not about quality assurance, then it is about testing.

PS. From now on the texts marked with “Bolton” are packed lunch, which I took note of during Michael Bolton’s Rapid Software Testing course in Helsinki.