Arkisto: December 2010

Is it Worth it to Fix a Bug?

23. Decemberta, 2010 | Kirjoittaja: Antti Niittyviita

As a person so engaged with the testing business, my automatic answer to this question is ‘Absolutely!’. The answer is good from a general point of view, but what about from the viewpoint of economics and reputation? From their perspective, the severity of a bug and how often it gets reproduced serve the main role. As an example, I offer these two scenarios:

  1. Conan the Barbarian’s new two-handed sword reveals itself to be dull. The production error is clear and reproduced with every swing. This is unlikely to affect Conan’s skills at arms, but in the hands of an average warrior the blade will likely spell doom.
  2. He-man’s freshly crafted one-handed sword is sharp and cuts flesh very poorly only in certain angles. He-man is also a swordsman of Conan’s peer, whose battle-tactical vision single bad cuts are unlikely to falter, but even one bad hit could change the tide of the battle to an unknown direction.

Conan’s and He-man’s shared sword maker faces a dilemma. Should the production be kept the same, or should the production errors be fixed? As a businessman, the sword maker ponders the severity of production errors and ends up fixing Conan’s dull blade, but continues to produce He-man’s shard sword as before. The sword maker concluded that the cost to fix are sometimes noticeably higher than the expenses caused by that one flaw.

A real life example of this choice is with Santa Claus’s Hiace-sleigh’s latest production error that reached the headlines: SUA (sudden unintended acceleration). Description of the flaw in short: Rudolf had been hitting the gym too often. The question is, has the sleigh maker been aware of that particular flaw when they had released the sleighs to the manufacturing? How often this flaw shows itself, that is, the reproduction is very small compared to the amount of sold sleighs. Therefore, the cost to fix these flaws are very likely to be higher than the expenses caused by them. However, the indirect expenses caused by the flaw are an entirely another matter. Flaws that lead to injuries and death always raise a storm in the media, the result of which is that people might not trust Santa Claus like they did before.

Would it then have been worth fixing that one insignificant bug?

Testing gurus wish you equally a bugless Christmas and a cost-efficient new year!

But That’s not Agile

20. Decemberta, 2010 | Kirjoittaja: Antti Niittyviita

David the developer is hammering code in a project with Carl the Coder. A Sprint of two weeks has been ongoing, the final days with lengthy overtimes. When the boys finish their work, the software and the recently finished feature pack get sent to Tina the Tester. Quite often this is called Agile.

Too often firms say that they develop new software with agility. Despite that, getting a closer look at the core of their software development reveals the aforementioned scenario. Often what is going on is an incremental or iterative (IID) way of creating software. In it, devs withdraw to work upon agreed upon pieces of software in that one cycle and the finished set is sent for testing. Suddenly, a work claimed to be Agile is quite like a series of small waterfalls.




This difference of interpretation induced discussions also at TestausOSY’s Agile-seminar at Oulu. Incremental software development is not automatically Agile. Agile, on the other hand, is incremental by nature.

The main differences come from the nature of teamwork and the significance of fast feedback. Feedback is not fast, if the work is done in cycles of development, then testing. In that scenario, the question is not about teamwork, but rather, the cooperation of two teams. Confusing, is it not?

I think that Agile’s differences to traditional incremental software development are summarized by the following points:

  1. The team is self-organized: no managers, no forced processes
  2. The feedback is always fast: from tester to developer, from client to the team
  3. The work adjusts to the needs that arise: no long increment plans
  4. The tools help reaching a goal: they do not dictate how it is reached

To turn incremental into genuine Agile, people need to learn to let go of the old mindscape ‘well planned is halfway there’. They need to give up on predicting success with metrics or specs. They need to accept uncertainty and unpredictability. Things do not always go as planned. But, one thing above all else: People must have the daring!

Tools and processes come and go. The main thing is that you get results and that the software works!

What Does a Certificate say about the Tester?

7. Decemberta, 2010 | Kirjoittaja: Antti Niittyviita

ISEB, ISTQB, CSQA, CSTE, CQIA, CTM, SSBB and CSTP. Phew, that’s a lot of acronyms I say!

There are several certificates in the testing business, but what do they actually teach?

Naturally, being certified leaves you with a certificate. The certificate tells us that a certain level of testing skills and basic terminology has been reached. It tells us that an exam has been passed and that the questions received the right answers.

Which of the following would you not use when choosing test techniques?

  1. Level and type of risk
  2. Time and budget
  3. Regulatory standards
  4. Recommendations from developers

Above is an example from ISEB certification exam question. If you have even a little bit of practical experience, answering this question will become difficult if not actually impossible(*). When choosing testing techniques it is important to think about risks, resources, laws and standards. It is equally important to discuss with the developers. No team functions if someone is going solo. The same kind of questions that rouse conflicting feelings fill the certification tests full.

Maybe that is why I have long felt that certificates do not simply fit modern testing. They cannot be used to measure how good testing is, since it tries to force the testers to the same mindscape and mold. Yet, the best results of testing are achieved always when the same thing is being looked at from several points of view. By different people from different views. There is less cover from being observed by many.

Certification trainings are usually quite proper. There is room for discussions, critique and practical experiences in them. Which is why I feel that certificates, despite everything, tell us what the tester could be expected to know, at the very least. The most important thing they still leave out.

A certificate leaves out what the tester actually knows.

(*) according to ISEB the only right answer to this question would have been option 4.