Arkisto: December 2009



Slightly Over To The Business Logic

18. Decemberta, 2009 | Kirjoittaja: Antti Niittyviita

New blog address, old tricks.

Still upset.

For the test control tool the big deal was almost closed. We promised to lower our (potential) client’s quality assurance expenses by 15%. They believed it.

Then, we were given the hand. Why so?

We were marketing more efficient test control to our (potential) client, that is to say, making the same job with less hours required. Unfortunately, we did not realize that our client’s client will still rather pay by the hour, rather by the quality. We did not understand our place in the value chain. Our (potential) client had no reason to improve their quality assurance process.

The model of thought was more or less the following:

  • We will pay 100 moneys for each of 100 time units spent testing
  • We expect you to find one bug for each time unit
  • We won’t pay a nickel more, even if you found 2 bugs for each time unit, because we price our subcontractor work by the hour. It’s easier to compare them that way!

Making the process more efficient would have meant 15% less money billed. Who would want that?

These days, we talk a lot about improving the productivity. In my understanding, a rise in productivity means that one gets more work done in the same time as before. Or the same amount of work done in less time than before. Improving productivity is primarily influenced by skill. It is through skill that during a working day one makes more commodities, more services.

A professional company would change the tires for your car in half an hour. How much more would you be willing to pay if the change would take an hour instead? Would you pay double? Hardly. I, too, am more interested in the agreed time for the work, and its final price rather than paying by the hour.

Big boats turn around slowly. Our (potential) client has started negotiating with its own client about taking a larger responsibility for the quality assurance. This way each partner can concentrate in increasing the total productivity.

Then, there will be a demand for improving the quality assurance process. We are good doing just that.

Common Interest And Burden Of Proof

4. Decemberta, 2009 | Kirjoittaja: Antti Niittyviita

‘Moose!’ yells the passenger. The driver does not hit the brake, but first asks: ‘where?’ Of course the animal must first be seen by your own eyes before you hit the brake. Naturally, this is not how it always goes when driving, but in product development this is common.

There are two kinds of bugs. The ones that systematically generate, and the kind which happen occasionally. The latter ones are the kind which requires certain circumstances and timing to coincide exceptionally well before the bug shows itself.

Reporting these kind of bugs is arduous, and fixing them even more so. These kind of bugs often linger for long periods of time before someone gets around to fixing them. Bug reports get tossed back and forth between product development and testing.

Developer: Could not reproduce, please retest on build 5

Test engineer: Still happens on 1 out of 10 tries

Developer: Could not reproduce, please retest on build 6, please provide a screenshot

Test engineer: Still happens… Did you even investigate?

Precious time is wasted on arguing instead of investigating the real reason. This problem escalates in multi-site projects, where the development is done in two time zones. Arguing can take weeks without actual solutions.

Why does a tester so often have a heavy burden of proving that a bug actually happens? One must provide screenshots, or even videos of the bug before developers take it seriously. They must see the bug with their own eyes. Sometimes the tester has to dig up the specs and from them show that the report is actually a bug and not a feature. Ultimately, figuring out bugs this way escalates upwards in the organization and the costs of solutions accumulate.

Situations such as these are often derived from the way how testing and product development experience a rivalry. There is no dialogue, communication has not worked, and what is good for the product has become secondary in their minds.

Assign product development teams to work together for the end product instead of competing with each other. Do this by waking up the entire project to think things through from the perspective of the end user.