Arkisto: April 2011

A Tester is an Expert. Who Cares?

27. Aprilta, 2011 | Kirjoittaja: Antti Niittyviita

Ossi works as a head of human resources in a growing software business. He goes through several heaps of applications on a daily basis and tries to find new employees for the firm. Skilled people are required especially for development, but someone has made a passing comment that there is a project that needs a tester as well. Ossi is not terribly bothered by this, since from the business’s point of view, testing is only an useless expenditure.

Yet, a tester has to be found due to boss’s order, so Ossi gets cracking. When he has eliminate all but the three most fitting candidates, they are asked for an interview. All the people are experts of testing. They have enough experience from the field and their resumés are in order.

  1. Minna, 32 years old, is a longstanding tester with 12 years of experience. In the interview she tells about herself and her earlier career in detail. Minna also answers the challenges Ossi brings up in an expert manner.
  2. Jarkko, 34 years old, is also an experienced one with 9 years behind him. In the interview he opens up his educational background and can even tell a good success story from his career. He answers any questions with an immediate response.
  3. Heli, 26 years old, is the youngest of the three. She only has experience worth of five years. Her salary wishes are almost the same as the previous two, which Ossi also wonders about. In the interview Heli delivers robust facts about why testing done well is sure to save money for Ossi’s firm. It improves the firm’s reputation and also saves time for the developers. Heli does not talk about her career, nor does Ossi ask about it.

What do you think? Who does Ossi decide to hire?

The crux of the matter is that the first two applicants are engineers, body and soul. They are genuine professionals and know how to talk about their knowhow. Ossi, however, is not interested in their life story or career. He is interested in what use a candidate actually is to him and the firm.

The decision is easy and Ossi decides to hire Heli, because Heli told him clearly the main things:

a) Why testing is work worth the money and

b) What use is she for Ossi and his firm.

Dear tester. You are a professional and you know what good testing is. Unfortunately, that is not enough:

You need to learn to tell other people that!

* P.S. You can start by reading a few good blogs.

It is Easy to Trip over Your own Agility

19. Aprilta, 2011 | Kirjoittaja: Antti Niittyviita

Scrum! Agile! Speed and efficiency! They sound nice and practical. By adapting these virtues, nothing can go wrong! The motiviation is at its zenith and work starts with teeth aflutter. At some point, the road becomes rocky.

As a person who has went in for physical activities I can say that overconfidence in one’s own agility and speed does not get you very far. Running and doing cartwheels and flips might look stylish and confident, but it is also the most inefficient movement form for the performer.

When you walk you have more time to take a look at what goes around you, the danger of tripping is noticeably smaller and moving around is also more efficient. When walking, you have to time to check where you plant your foot next.

The smart ones might have deduced that this metaphor is leading to improving work methods. Slow and steady change under surveillance is always more efficient than running in blind. “Let’s see if this one will work, because it worked in neighbour’s organization”-mentality is sure to lead you into problems. Every organization is different. Every organization requires different work methods.

How does agility then show in practice in work life? In unfortunately many projects they do not have clear working methods in plain sight, which people could then follow. In unfortunately many projects the working methods are in a constant state of being designed and changed. They do not have the time to try any method well enough and experiences remain uncollected. The best practices remain unknown.

Unfortunately many firms have become blinded by the radiance of the word Scrum and stray further and further away from the path of efficient development. Finally they become estranged from the reality of product development. Workers, team leaders and bosses are seated in the same room in hopes that information would pass more smoothly. The tools chosen are massive and expensive multitoolhammerdrillrulerscrewdriver-tools, which should support Scrum principles. Is this agile software development?

Lare Lekman has listed in blog the most important bits of Scrum:

  1. Deliver regularly something
  2. Ensure that you deliver the things that are of the highest priority
  3. Strive for better in each iteration/release

Agility in software development is based on clear guidelines, which everyone strives to follow. It is not a continuously changing cacophony or fast-looking fumbling. It is a series of controlled steps taken with expertise. A continuous movement forward.

Urgent deadlines do not change the work method into stylish running steps. “Deliver regularly something” does not mean that you mark an unfinished task as being ready. Fumbled half-implemented done is sure to produce more additional expenses than a late well-implemented done. Testing ensures that.

Genuine agility is to take high quality, balanced, and short enough steps while keeping the goal clear in mind.

Testing Guru Improving the Process

5. Aprilta, 2011 | Kirjoittaja: Antti Niittyviita

Testing guru Esko worked in close collaboration with software developers in a project, whose method of work was continuous integration. It was Esko’s responsibility to ensure that the quality of the software was always good. In addition to testing, Esko took care that found defects were also fixed.

Continuous integration aims to an always functioning system. When a developer injects a change into the version control, then the system should have become improved at that point. Usually, the system releases a build right after the changes or every night after the work has ended. Traditionally, the tester works with these nightly builds.

Esko knew the problems of this method. When the tester is working on the nightly build, then the developer is already wrestling with new things. Even though the development is agile, the tester is working on an old piece of software. When the defect is discovered in it, it is already too late. The tester and developer have to jump into a time machine and return to the root of the problem.

This method approaches the traditional waterfall model without noticing it. It is a series of small waterfalls. Specsing-deving-testing. An amazing number of businesses work this way, and claim that their testing is a seamless part of agile development.

For testing to walk hand in hand with agile, the chasm described above has to be narrowed in all ways possible. Esko knew what he was doing, he took the bull by its horns and narrowed the chasm. Esko suggested the developers to further condense their collaboration. What did he suggest, then?

Developer delivers EACH addition ALWAYS first to the testing. After that, it goes to the version control.

Esko bravely took the responsibility of launching the change. He encouraged the developers to bring all of their fixes first to himself and then to the version control. As a result, they discovered a large quantity of bugs even before the nightly builds. The defects were discovered over one day earlier, which is actually a pretty significant time in two week sprints.

The number of regression defects in nightly builds dropped by 60% and the time spent with defects caused by them was almost halved.

When a testing guru improves a process, it is good for each player of the team.