Arkisto: April 2010



Tools Cost, Work Time Does Not

29. Aprilta, 2010 | Kirjoittaja: Antti Niittyviita

I talked with a test leader about testing and utilizing work time recently. Particularly our discussion about reporting woke our thoughts in regard to the currently used mindset. Unbelievable but true: Often the mindset is that tools cost, but work time does not.

During my talk with the test leader, I learned that he spends around 3-4 hours of work time every week for making reports. He collects results data in one excel file manually and sends the reports to stakeholders. 3-4 hours was little work time regarding a test leader’s duties.

3-4 hours a week linearly means 141-188 hours a year. That’s one man-month. Solely for manually making excel sheets. Of course, it does not feel that bad when you do it in little pieces at a time, but they add up to a pretty intense amounts considering how valuable a test leader’s work time is usually. It takes 6000 euro a year just for writing excel sheets.

Remember this: 3 hours of work time wasted a week means 141 hours wasted in a year.

Testers horribly often do work with the second best tools around – that is, the office programs. That is manual labor from the beginning to the end and that gets to be expensive where we are from.

In construction yards they have already noticed this. They prefer buying a good circular saw for an employee instead of putting the guys to work with frame saws.

Work, Meaning and Communication

20. Aprilta, 2010 | Kirjoittaja: Antti Niittyviita

About Giving Feedback and its comments told us a bit about the challenge in communication in software development. Developers get frustrated, when the testers give negative feedback in the form of error reports. Testers need to think a bit about how to relay the message in a way that does not aggravate the developer.

The problem does not lie in the communication between a developer and a tester and its form, but in following the roles set by the project management.

For the whole it is most efficient if the developers write code with the accuracy specified by the requirements. Testers, on their part, try to find the significant flaws in the code. They both are professionals in their own field. Would it not be the best for the whole if in the project stuff gets done by the people who have the best capability for doing them?

Should responsibilities and human relations not be entirely healthy, the developers can become averse towards flaws and the negative feedback they receive from them.

In these situations, the project management should be awake. The management need to actively communicate to the developers that they do not expect flawless code, since the testers find the flaw and problems faster than the developers. The product finishes faster, when the developers dare to leave their code for the testing without spending days or weeks rounding the edges.

Error reports are no longer negative feedback, but normal communication that aims to achieve a good outcome. A work done well is a reason to applaud, both the developers and the testers.

What is significant is not who find the flaw. What is significant is how quickly the flaw gets wound and fixed. Both are work for a professional.

About Giving Feedback

15. Aprilta, 2010 | Kirjoittaja: Antti Niittyviita
Comments: 1

A Finn knows how to give feedback!

During the dawn of my studies I worked at Telering, selling Sonera’s phones and telephone subscriptions. A typical workday consisted of a bunch of sold subscriptions and phones. It was entirely possible that we also solved important phone settings problems for the customers, that is to say we also functioned as a support service.

Each day included listening to the worries of the customers in addition to performing these routine operations. Customers came and vented about whatever subscription or whichever phone. Customer servicers’ role is to listen, understand and help if possible. One Saturday in the July did stick in my mind quite vividly. It was an exceptional day.

A customer stepped into the store. I remembered him having visited us last week with his problems. Gloomy clouds had begun to gather over my head, since I so would have not wanted to listen to his problems again. The customer surprised us all by slamming a bagful of sweet rolls on our counter and thanked us for the good service he had received! The positive feedback brought a smile to everyone’s lips and the team’s customer service spirit was in the zenith for the rest of the day. And you know what? The sweet rolls tasted good as well. It was that Dallaspulla stuff, which has vanilla cream in its centre.

After this experience I remained to think about the power that came from feedback. Why does a Finn primarily give feedback only when something is wrong? When everything goes well, a Finn is silent. I dare say that Finns are very bad at giving feedback! That’s something to learn.

What does this all have to do with testing, then?

Joel Spolsky wrote in his blog with a headline of Why testers? The text opened a new perspective to the necessity of testing. A coder in fact becomes better in his or her job through feedback. The faster a feedback is, the better it can be learned from. Mistakes are still in fresh memory when the feedback is imminent. When you compile the software and find it functional, the coder receives the first piece of feedback. The second piece remains for the tester to give.

So, a high quality tester is a one who gives feedback fast. The feedback has to be straight and accurate, BUT:

One of the tester’s most valuable attributes in development work is giving positive feedback. You read it right: positive feedback. Just like training a puppy, it is more sensible to encourage good behavior with compliments and treats, rather than always punish for bad behavior.

A coder’s , just like any other human being’s morale, motivation and level of happiness can be improved and the central piece of it all is positive feedback. The person get a warm fuzzy feeling when someone once in a while pats on the shoulder and says:

“You’ve done daaaamn good job today! You’re a good guy and you’ve certainly deserved a cookie!”

Travel, an Outstanding Software

7. Aprilta, 2010 | Kirjoittaja: Antti Niittyviita

A couple of my friends work in the University of Oulu. Like in many other institutions of public service, they also use Travel software for travel expenses reimbursement in the university. Due to usability problems, the software has been undergoing updates for months. A friend kept me up to date about the new update via IRC:

13:20 <@Anonymous> info: no exchange rate

13:21 <@Anonymous> this FYI when you change in euro for the currency

13:30 <@Anonymous> ahh ha! after taking a look at the intter.net, this is quite logical and again only an user error.

13:30 <@Anonymous> it so happens that “taxi, homeland” is so special a mode of expense among 300 others that it is a special case where you may not choose euro as the currency

13:30 <@Anonymous> because, you need to leave the field empty. OK.

 

13:32 <@Anonymous> and now that I learned that one, I might be able to finish the reimbursement claim by myself now

 

13:42 <@Anonymous> ERROR: mandatory extra text label is missing in expenses/km –row [-25]

13:42 <@Anonymous> I counted my chickens before they hatched

13:47 <@Anonymous> Yep. A dead end. Nothing is missing anything, or at least I can’t find anything and neither did XX.

13:47 <@Anonymous> Saving and sending receipts to the secretary and wishing good luck

13:54 <@Anonymous> Oh! Found it. Homeland expenses require a “text label “-field and in addition a “extra text label” which one has to input through another window :D

13:54 <@Anonymous> Because it makes sense that the taxi takes so many explanations that it needs more than one text label.

How bad was Travel before the update that took months?

After this outburst piqued my interest, I googled a bit at Travel. The most interesting discussion was found on a suomi24-forum, where the original post cited Helsingin Sanomat on 4th Jan 2009. HS article can be found on the digital paper, which one can read with HS web account.

In the article, they interview Technical High School’s professor of interactive digital media, who has investigated government’s software acquisitions. No kiddie gloves on. Good mister professor had contacted the person who had made the acquisition, and asked about stuff for a bit:

The reception was unfriendly. Takala learned, among other things, that in the testing of the software they wanted to leave out current users of Travel due to legal reasons.

The basis for this was, that since we had used the software’s earlier version, we can harbor a certain prejudice towards its supplier, which makes us unbiased.

Before you release a software, for God’s sake, at least get comments from the intended user.