Avainsanat: ‘End user’

Forcing is the Shit!

11. Septemberta, 2014 | Kirjoittaja: Antti Niittyviita

Is your business being bothered by too many users? There’s an antidote for that. Forcing is the best way to manage irresponsibly booming userbase growth! Facebook has managed this quite successfully. With both its own chat, as well as the chat that they just recently bought.

Facebook –app remembers to shove its own Messages app every time in your face every time you open the chat.

After you have replied with “Not now” a few times, they become more generous with the options they offer you.

When you finally surrender under the vast world of options and make the mistake of installing the new app, guess what? That’s not still enough for them! The imposing continues. Turn on notifications or we will remind you about them every single time whenever you open the app!

Then came WhatsApp. It collected a nice amount of users, until it was sold. Guess just what kind of world of options was thrown in front of the users once the new owner took over?

You’ve got that so right. Same broken record every time you make the mistake of opening the application. I am not interested in your damn notifications!

At least Apple knows its stuff. One can even post negative reviews about apps, but of course they remain to be unpublished.

You can avoid, for example, stress tests’ need quite easily: Ruin your users’ experience with absolutely insane solutions. Worry not about feedback! No users, no problems!

Clock Towards the Summer

2. Aprilta, 2014 | Kirjoittaja: Antti Niittyviita
Comments: 1

On Sunday morning I woke up at a usual time. Or actually, I did not. The time was one hour more than it was the day before at the same time. According to a rule of thumb I have learned, you adjust clocks always towards the summer. In the spring forwards and during the autumn backwards. Towards the summer, it is.

I opened WhatsApp first thing in the morning and the flood of complaints in the group chat was quite reassuring. My good friend Mark (name changed) complained along the lines:

So, what the f*ck is the brain damage that resulted in meeting times changing when daylight savings time comes over? I mean, really! Where would one even need such a ‘feature’ for?

That complaint was not the only one. It was the same song evenly from the Android, iOS and Windows Phone –users. The problems did not visit everyone, but the loudest ones were the ones whose calendars had got messed up. The origin of the problem is still unknown, but it seems to be linked to calendar server’s and the phone’s co-operative functions.

Phone developer passes the blame over to the server’s developer.

The server’s developer passes the blame over to the phone’s developer.

In road traffic, one can easily find oneself blaming the car in front of you for bad driving. It is, after all, his car right in front of your very eyes. For traffic jams, the original fault for is usually further away, at the distance of a few cars ahead. It is a rare driver that thinks so far. The same rings true for the world of software development.

End users usually blame the problematic part for the entire problem. Passing over the blame at the developer’s side is for naught. The one who takes care of the repairs is the one who paying customer would primarily point at.

Avoiding Responsibility, or Ignorance?

30. Januaryta, 2013 | Kirjoittaja: Antti Niittyviita

Web services are made to be cooler and cooler. They successfully respond to the increasing variety of terminals. Top products are launched onto the market on a daily basis. Each one has links to social media, and a user interface that is sheer deliciousness. Be it for either business or consumer clients, people make efforts to produce good functionality in web services and for good user experiences.

Quite often the product owners order works from the experts of software development and they are also taking care of testing. They are whistling past the graveyard.

Despite all that, there remains nearly always a black hole in building web services. Behind its event horizon there is something, which no one knows inkling about.

The non-functional areas of web services, such as information security and performance have a central role to play in building a successful web service. Despite this, the responsibility of taking care of them almost always remains in a grey zone. The question remains awkwardly hanging in the air like a dark rain cloud whenever a third party testing partner sits at a meeting and opens his or her mouth.

The client is responsible for the new product’s ability to fill in the criteria of the business. The developer is responsible for making sure that these criteria are met. The service provider running behind the scenes is the same which they have always used. Everyone thinks they are satisfied.

Yet, for example, the response times of a service has been noted to be a key factor for the money streams in a web business:

It is in everyone’s best interest, without an exception, that the provided service works. Regardless of what role you are in, be it the service provider, client, supplier or the tester, remember to bring this up: Who is responsible?! Answer it!

Detach the Battery!

23. Januaryta, 2012 | Kirjoittaja: Antti Niittyviita

Detach it indeed. The best advice that should be followed first when a software error takes place. How many times during the life span of modern phones have you had to detach and reattach the battery? How many times have you rebooted your computer when a single app is slowing down the machine? Have you ever had to turn off your car due to the bugs of the driving computer? What is best, in some car models there are quick handles for the battery’s wires for the sole purpose, that in the event of a software error, you can detach/reattach the battery.

Why is it so, that in these modern times we have accepted some things that used to be negative, as common day routines? When I buy a new mobile phone from the shop I want to imagine that it would work without any magical battery detaching or 8 second power button rituals. I would prefer not to dirty my hands by the highway loosening my battery wires or hit my laptop’s reset button, when MS Office starts to get rowdy with me. (An Apple man would say to this that “buy a Mac.”. I will not.)

After meditating for a while, I deduced that all of this is due to the fact that because it has always been so. The phenomenon is the same as with normal cigarettes. If cigarettes would hit the market now as a new product, it would be likely that it would be banned as a severe health risk. But, because cigarettes have been on the market for around as long as humans have been using fire, it has been accepted as common day, although deemed as a negative thing. When we have been detaching the battery for who knows how long, we accept it, but with the same negative feeling.

The same acceptance has seeped so deep that a large number of phone manufacturer’s testers no longer keep the back lid in place when testing a phone. Solely due to the fact that the battery is easier to detach when problems arise, and since it is easier to observe technically with certain tools when you can detach the battery quickly. This method is probably not end user testing. Who was that great tester genius, who first discovered that you can fix a defect by detaching the battery…

Modern society is based on energy consumption. Why is it then, that we need to cut off the power in a single machine to get it working again?

Detach the battery! As the saying still echoes from the darkest corners from years ago, back when a group of guys discovered a glimmer of positivity for a single time in the history of man in the saying, after a downhill skiing weekend…

Illusion of Uniqueness

19. Decemberta, 2011 | Kirjoittaja: Antti Niittyviita

I discuss a lot with people who make their living from product development. Some make complex design systems. Others do difficult web applications. The third firm does stuff with production control systems. All these sound quite different. It has been most interesting to notice that in all the discussions there is one common factor. Which is, that all of them speak in unison that:

Our product and industry is so unique that breaking in new friends takes years

A bunch of hogwash I say. Your industry and business might be unique, but your products are just software among software. It runs the same programming languages, interfaces, servers and clients as all the others. Your methods of software development is just the same as hundreds of other software firms. The same kinds of bugs repeat from one system to the other, regardless of if it handles customer web services or industrial control software.

Industry-based knowhow is useful, granted, but do you know what the people in other firms are by trade? They belong to software development teams. They are your run of the mill coders, testers, specsers and managers. They all have a very common background. In the end, they know their trade pretty damn well.

Functional code is born, bugs found, and design is not a problem. Understanding your industry accumulates over the years, but at the same pace, people get railroaded and form social bubbles. People want to zealously believe in their own uniqueness. Ultimately, this leads to there being fewer and fewer fresh ideas and stuff gets done stubbornly the same way as “we have always done before”.

I claim that your industry’s uniqueness is an illusion that is born when you and your friends sit around the same sandbox for too long. It is worth going out for a breath of fresh air once in a while. To keep an open mind, to watch how the others do just the same things as you do.

P.S. Is your product unique? Can it not be tested without years of experience? Tell me about it, and I will send in a fully layman tester. I say that in two weeks, the person will become a useful member of the testing team. If not, you get your money back and I will humbly treat you to a supper.

Not Some Useless Expense

28. Marchta, 2011 | Kirjoittaja: Antti Niittyviita

Have you ever made a reclamation about a product or service you received? Have you ever taken the product to warranty service? This is how it looks like from the other side of the counter.

  1. Customer service listens to your complaint and tries to help you: 10 min
  2. Technical customer service tries to fix the error with you: 10 min
  3. Finally, the technical customer service writes an error report: 10 min
  4. Support representative checks the report, tests and sends it to the product development team: 1 hour
  5. Product development team investigates, fixes and tests: 10 worker days (70 hours)
  6. The fix is delivered to the current customers, if possible. 2 worker days (15 hours)
  7. Send feedback to the customer who made the complaint, through the entire chain: 30 min

When one customer complains, that is not when people get around to making repairs. When 100 customers complain, the cause of the complaint must be quite obvious. Entire complaint cluster takes around 2 hours per one complaint. When there are 100 people with complaints, it takes 200 hours. Fixing and delivering the fix eat another 85 hours.

So, a total of 285 hours! In worker days, that makes 38. With a very modest 250 euro per day, the entire show adds up to 13300 euro! And that sum does not even contain the loss of image and bad user experiences caused in the customer base by the flawed product! In addition, delivering the fix can in reality take over 100 times more time, if it requires the product to be pulled back.

The mission of the testing is to eliminate these expenses already during the product development, before the product has yet made its way to its first customer.

It is entirely useless to try and convince that testing is only a useless expense.

Straight Jacket or Hawaiian Shirt?

10. Marchta, 2011 | Kirjoittaja: Antti Niittyviita

A huge responsibility was given to Teppo the Tester (name changed). Teppo had to prepare a test report of the most recent test cycle. Having done it plenty of times, beads of sweat start emerging on Teppo’s brow even before reaching the end of the cycle. Finally, the time for reporting comes. With shaking hands, Teppo executes the painfully long and frustrating process:

  1. Teppo exports the accurate data of the test cycle from the very expensively acquired test control system by making use of an Excel-macro (which he had made himself with blood and tears)
  2. From the mess produced by the Excel-macro, Teppo isolates the essential information – pictures and diagrams – and pastes them to the e-mail he will eventually send. Most of the pictures and diagrams require precise re-scaling after being pasted so that the e-mail would stay readable.
  3. Managers also want to see an accurate listing of test cases, so Teppo has to return to Excel-tables. Because it never works as intended when it comes to pasting Excel-rows to the mailer program, Teppo needs to open a notepad, through which he cycles the rows to the mailer program, so that they stay readable.
  4. Sweating profusely, Teppo adds a short description of the test cycle’s events, issues and their solutions to the beginning of the e-mail.
  5. Finally, Teppo pastes the Excel-table hell exported from the very expensively acquired test control system as a whole. The Excel-table hell contains all the same information that Teppo had just now compiled to a more readable form with great painstaking effort. Teppo does his best to understand that opening an Excel-file and reading information from it can be very difficult for many manager-level people.
  6. Teppo adds to the recipient line of the e-mail a varying number of addresses and a couple of e-mail lists as well.
  7. Frustrated and on the brink of tears, Teppo, who is a big man and once upon a time, a proud professional Tester, presses the Send-button. Will anyone end up reading this report? The e-mail gets only answered by Testmanager Urpo, who announces that the next report has to have a bit more of this and that and it has to be in a powerpoint slideshow format! At the end of his answer there looms a question, which drops the base of all that is ethically right with testing: Why does this report have so much red!? As if Teppo is being blamed for it…
  8. Totally spent, Teppo prepares himself mentally for the next test cycle.

Does this sound familiar? The end result is not enough for making a good test report in a modern cost efficient business world, but equally important is also the way the report is made. Frustratingly many of the tools are still not born for the need of the end user, that is, the testing expert’s needs. The user is the one who has to adapt inside the straight jacket tightened by the tool.

Is it too much to ask that the tool offers a direct way of compiling such a report that it includes all the demanded bits by an individual user? Is it too much to ask, that at all times, no matter who it is that uses the tool, they can see the phases of the project’s advancement and the most significant things associated with its development? Would it not be a darn utopia when all that mentioned above could happen with a single click of a mouse!

Easy to use, simple and time-saving tool is the tool of the future. People, who have no knowledge of better, have become set deep in their tracks and fail to see the advantages of newer tools. If you have used a chastity belt and a straight jacket for your entire life then Hawaiian shirt and cool shorts (commando-style) might feel weird.

Yet, after short familiarization period, the constraining gear gets stomped deep into the swamp. It is only a matter of time when the rigid tools created by large firms for other large firms give room to the actually useful tools.

Are you content at sitting in a soft room wearing a straight jacket, drinking through a straw magical drinks offered to you by men in white, or would you rather sit in a sunny beach wearing a Hawaiian shirt drinking piña colada while engaged in a dialogue with nice friends?

PS. We recommend familiarizing yourself with a Finnish-based group tool called FlowDock. It has been made with the right kind of attitude while remembering who the end user is.

How to Turn a Bug into a Butterfly

23. Julyta, 2010 | Kirjoittaja: Antti Niittyviita

Summer greetings, dear readers. Now that the heat waves have passed, it is a good time to return momentarily to the amazing world of software testing and defect control.

This summer I have followed the heated discussion around the antenna problems of the smart phone frontier. To be more exact, iPhone 4’s problem and its solution. As it happens, touching iPhone’s bottom right edge drops the bandwidth to non-existing levels, as you can see from the following video.



This is clearly a bug, which seems to have crept past several quality assurance levels, all the way from hw-testing to end user tests. A professionally handled testing process would not permit a bug such as this to pass. Not at Apple, not at elsewhere.

I declare that this particular bug was caught at exactly the right place in the product development life cycle. The bug reached markets because of defect control process. I have seen far too often when clear bugs get assessed and filed as “works as designed”.

People say that a bug is a feature. This is how it was meant to work!

Apple knows its marketing, though. Product demos are bursting with superlatives. The products are amazing and wonderful. In iPhone 4’s case, Apple has decided to fix the problem by handing free covers to all the people who reported the bug. When the cover is between the hand and the phone, the hand won’t be able to press down on the critical spot in the phone. By acting this way, one can read between the lines that:

We have acknowledged the bug, but we don’t know how to fix it. The bug is in the hardware.

Yet, the marketing message is more powerful:

We are human and we can make mistakes. We love our users and want to compensate our error by giving out free phone covers.

This is a good way to kindle sympathy and compassion in the end user. This is how a bug turned into a butterfly.

Yet, most of the time addressing a bug as a feature is a dangerous gamble. A gamble, which can endanger both your product’s reputation, and your company’s.

If your marketing does not function like they have it at Apple, think twice before you even attempt it.

They Fit the Specifications, so What?

16. Juneta, 2010 | Kirjoittaja: Antti Niittyviita
Comments: 1

Some time ago, we made two test cycles with an Asia-based team, just for the hell of it. The first test cycle was given a very clearly written test specs based on the product’s specifications.

The testing was conducted in India and the results were as expected. 18 defects were found among 40 test cases – As many as had been found in the design phase already (*). The next test cycle’s mission briefing was clearly different. They had as much time for the testing as they had had the previous time.

For this assignment, they were only sent the product to be tested, and a list of things that are worth checking during the testing. That is to say, no specifications, nor test cases.

Test this product to your best knowledge and report all issues in a way you find best suited

As a result, we received 25 reports. To report the defects, the test team got creative and used video capturing to show them, so everyone could see what they were and how they happened. The software developers also gave thumbs up!

Of the time spend in executing testing work, the result received was 38% higher when the testers’ hands were not tied with having to closely follow specifications or test cases. The tester put on the end user hat and reported defects to the best of their experience.

The chasm in specifications between functional and genuinely functional in this case was pretty intense. The underlying problem in this case is that requirements engineering is conducted with almost no exceptions before building the product. The specifications are an abstract entity inside the designer’s head, formed prior to tell how the end product should function. Keep this in mind when you design the testing.

Remember that a functional product according to specifications might not be a genuinely functional product. Only when the testing has been done with an open mind can you tell how it really is!

(*) During the design phase of the testing we had to familiarize ourselves with both functional requirements and investigate the product itself, in other words: To conduct investigative testing. This design phase therefore took a lot of time.

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.