Arkisto: April 2013



One Can Crash Web Pages With a Giant Penis

30. Aprilta, 2013 | Kirjoittaja: Antti Niittyviita

If brave enough, the professionals of marketing can make miracles happen with the help of modern Internet. Success stories can be born with a big budget and thought. Or sometimes one just lucks out. The success story is without an exception beneficial for business, but only when stuff works.

Last week NASA had one such luck when the Mars rover had become artistic.

NASA got to accidentally try the lime light of publicity, but they had not prepared well enough for a sudden rush of visitors. The potential produced by all those visitors scattered to the four winds, just like in many planned marketing campaigns.

May Day question for you, dear reader: What happens when a giant penis hits your web service and you get to be the center of attention on Reddit, Pinterest, Twitter, Pheed and Chan4?

How Fast is Fast Enough?

29. Aprilta, 2013 | Kirjoittaja: Antti Niittyviita

When one is optimizing a web page or a web service, one often hast to think about what is the adequate threshold for response times. If one’s targeted users are people, one has to keep those intended response times in relation to how you or I experience them as a part of the service’s usability.

Usability guru Jakob Nielsen has discussed the effects of response times and delays to user experience and defined three time thresholds in his article.

0.1 s is the time taken by functionalities that are experienced as immediate and natural. After one second passes, one notices the response delay, but is not yet agitated by it. When an event takes between 1 – 10 seconds, the delay will very well have to be called for depending on the nature of the feature, or the user needs to receive a feedback that his or her action has been noticed.

When the delay is longer than 10 seconds, it leads to complete dismissal of the function, so if something, such as compiling a database report, takes this long one needs to magically make it into a less delayed operation. For example, by telling the user that he or she will receive an email and a download link when the operation is finished.

And in order to turn this into a blatant sales speech, you should order Prove’s Knockout at once! With it you can magically conjure more speed and endurance into all functionalities.

Comedians in a Testing Seminar?

23. Aprilta, 2013 | Kirjoittaja: Antti Niittyviita

Tieturi’s Testaus 2013 –event was a success. Our reader Laura Selonen made important observations regarding Antti’s presentation and wanted to visit this blog as a guest writer. Laura also writes her own blog at the address: qaljs.blogspot.fi.

Antti Niittyviita brought up in his Testaus 2013 seminar presentation a perspective that a tester should have an inclination towards stand-up comedy and the ability to discuss with business people with fluency and charm. Well, not all of us are up to it, for one reason or another. Especially, if the business person is big enough a boss, who might not have the time to listen should the point not be brought up quickly and succinctly.

What to do if you do not have fluent dialogue in the language of business people and you feel kinship with the hapless ones who chose technology as their calling, since they find it more natural to talk to machines rather than to people?

One option is to talk through test reports. Mark Fewster, who spoke first in the same event, talked about risk-based reporting and the thoughts inspired by his presentation inspired me to answer to Antti and claim that a tester need not be a comedian, if it does not feel natural. Reports can indeed speak for the less verbal professional. I gladly ask my boss what he expects from reporting the testing.

Many product managers do not know what to expect, and that is when one has to tell them what testing can report on. Instead of the usual “this many tests were run and this many bugs were found” –style report you can talk about properties that have been tested and found functioning as opposed to the properties that have not been tested for one reason or another. Alternatively, you can talk about risks that were possible to minimize through testing as opposed to risks that have been found likely to happen (in the form of discovered and unfixed bugs), but which are not yet known about (because they are not tested).

I now challenge test managers to write an “executive summary” to their test reports, which shortly and succinctly tell the business chief where the product testing is currently at when evaluating the product’s quality.