This Letter is For You

October 11, 2016 | Author: Antti Niittyviita

Dear Guru,

I am writing to you, because what I have is so important. In the upcoming years, I want to witness wonderful success stories, which start from you.

Businesses never buy your help. People might sometimes. There are no exceptions.

People may buy your help should two reasons come to pass. If they know you exist, and if they feel like they trust you.

You cannot birth trust, if you are not known.

First, you need to become familiar. What needs to be done is to offer strangers the opportunity to discover you and what you can do.

Sometimes we say that the first impression is important. We say that it is difficult to change later on. Getting attached to that notion is dangerous, since uncertainty gets a foothold in what you do. You easily start to feel afraid.

The entire equation of specialist work falls short before it even starts. Because, most people do not provide an impression at all when they are afraid. Not even their name lingers behind.

First impression is the first necessity for professional reputation, but the game becomes even more unfair. Your professional reputation is built on other people’s silent expectations and polarized thinking way before you even arrive.

Despite that, there are no options, because people buy your help for two reasons only.

As an artisan of expertise you stand for yourself first and mainly. Your customer’s most valuable business secrets are always in your hands and not in the hands of the firm you stand for.

It is useful, should your firm have a good reputation. Yet, the most important question is whose responsibility is it to make use of your own or employer’s name to open new doors and to produce new trust?

The entire story always returns to one single person. That is you, dear guru. What could you do today to strive for trust and professional reputation?

P.S. I invite you to forge new success stories. If you became inspired by our blog’s ideas, it might just be that the Tester 3.0 training will permanently change your life and the flight altitude of your career.

What are We Talking About when We Talk about Quality?

October 6, 2016 | Author: Antti Niittyviita

Quality is an erroneously created concept! Attempts to define quality will only produce more suffering to the world. When we talk about it, we try to offer each other our own opinions. When we measure it, we actually measure the metrics we have built ourselves, because we do find them important. When we define its criteria, in reality we define something that cannot be defined by words or numbers. It is mathematics, which models in its entire useless beauty only its own rules or physics, which stubbornly presumes stuff for so long that it finally finds them.

WHAT? Why did yours truly suddenly make shameless claims such as these, which preach open war against every life bettering (read: things that make things more difficult) standard or even natural laws? This is sacrilege! We need tar and feathers here! The writer ought to be put into stocks!

In human intercourse the tragedy begins,

not when there is a misunderstanding about words,

but when silence is not understood.

This idea by H.D. Thoreau (1817-1862) contains deep wisdom. I don’t dare claim that I’d perfectly understand that wisdom, but I dare bring up an opinion regarding it. The kind which might change immediately after this text has been written. Life is wonderful, when you get to turn your coat whenever you feel like it!

The most brightest core is found,

 where we never talk about.

It emerges from there, which we never define. The more we define, the more we fall in love, and we all know that love is blind. We cannot see the forest, because it is so full of trees! We cannot see what the pieces really look like, because the world is so damn full of light! We cannot hear the silence, because we are so in love with our own voice! Talking is actually their fun, who know not how to listen. Maybe the real love is overcoming the blindness of your own love…

What are we actually talking about when we talk among ourselves? What are our opinions in reality? What do we leave without attention, when our own fear state brought about by our uncertainty drives us to decide that our opinions are facts? What do we protect, when we fight for those facts?

An opinion is an experience of value for someone,

who matters.

P.S. When all experience has to do with framework, the readers of this test marketing blog have a quiet duty to replace the parts of the text they want with the word quality, which I use as a hobbyhorse to produce a lovely framework for our shared illusion.

Who Brings the Food to the Professional’s Table?

October 3, 2016 | Author: Antti Niittyviita

A few weeks ago I ran across the following kind of notion in a newspaper article:

“…children’s clothing firm’s woolen hats have just come on sale and the web store broke down. Many were left without the things they wanted. Far-sighted people didn’t rely on the web store’s functionality – since they tend to crash when everyone logs on at the same time. They were queuing in the actual shop…”

This got me thinking… are we, the ambassadors of testing, failed in our calling, when people are already changing their behavior models when presented with an ‘opening day spike’, instead of demanding for a functioning web store?!

People have always known how to go around obstacles and function for their own gain, and the IT-era has not changed that. But, for the children’s clothing firm, it is very worrying that customers remain without merchandise through the web store.

The growth, even the survival, of young firms can be up to the web store staying functional during peak times. It might be turn out to be that the people responsible for producing that web store for the firm might be left without a customer, for one reason or another. The same fate might face the business who offered to handle the server capacity for that web store.

What is the solution to this problem? If you believe that the customer’s part is to know how to explicitly demand beforehand what they will end up needing from their supplier, then you are a part of the problem. You cannot pile the entire burden of responsibility onto the shoulders of the testers either, because smaller projects might not even have a professional tester in them, and even in the bigger ones, the tester might not be yet around in the beginning of the project.

A guideline for a good tester is to observe the system, with the customer’s business’s functionality being a priority, but I think that the entire supply chain ought to incorporate this guideline as a part of theirs. That is nothing new. It is a matter of professional pride.

The customers buy from us, not only a system, but also the expertise. We can implement the system they order from us, the system they actually need, and also tell them what they might need in the future and help prepare them for it.

At the end of any supply chain is a paying customer, in one way or another, and that customer’s satisfaction and existence is what ultimately brings the food to the table of all software business professionals.

Beware of the Workload Estimates of Testing

September 28, 2016 | Author: Antti Niittyviita

I often get asked to give an estimate about the amount of work that needs to be done. How much testing is needed to test the product? Or, how much time might the testing of the project take?

The question about workload estimates leads astray.

Testing fills the space that is planned for it. Always and without exceptions. The purpose of testing is to produce new information that is relevant and important for the business.

What is left to be decided is when we feel like we know enough. In actuality, the most important question is how much would it be wise to budget for testing?

The answer depends mainly on how much the person responsible for testing feels like having a basis to ask for, and how much the money man ultimately gives, as constrained by the structural margins.

Finally, what remains is to come up with the most wise and efficient method of producing the results within the constraints provided.

In actuality, a workload estimate stands for an agreement in allocating resources.

In Which League do You Play at?

September 16, 2016 | Author: Antti Niittyviita

“A real master makes repetition a heaven”, said Jari Sarasvuo once. He has said a bunch of other things as well, but this came to resonate for long for myself. Testing is repeating the same old same old. Monkey testing. All too often I hear such words from a tester’s mouth. I admit, that the notion has sometimes found a home in my own mind as well.

I have been taken to various kinds of sporting events since I was a wee lad. Football. Iceball. Baseball. Ball. I’ve also followed ice hockey. What has especially stuck in my mind since childhood was Teemu Selänne dropping Oulun Kärpät team to the first division. I was present on that important fifth match. Teemu scored 69 points in his 35 matches that season and came to be acknowledged as the most efficient player in the play offs. Teemu was already playing at such a level, which most will never in their lives reach.

“This week I practiced 15 times for a total of 25 hours. It almost gets too rough, but I have to do it. My desires, my goals and the stakes are so high that if you ever want to become someone, you need to practice. And achievements are only born from hard work.”

Teemu continued to play in the league for three more seasons. In every season more efficient than in the previous one. He wasn’t satisfied with his level, but kept on practicing more. Everyone surely knows Teemu’s show stopping newcomer records in NHL. In Winnipeg Jets he pounded 76 goals in the league and 132 points. This was both an all-time goal and point record for a new comer. Both records were in a league of their own, compared to the previous ones, and they are widely accepted to be unbreakable. I guess he had practiced even more, still.

“In April 1990 Teemu travelled as a guest of Winnipeg to watch NHL playoffs. Teemu understood how much he still had to work for, to reach his goal.”

Teemu Selänne finally won the Stanley Cup in the spring of 2007 at the age of 36. That was also when he finally stopped practicing. Because… what was there left to achieve? Why practice? Teemu continued his career until the spring of 2014, which is to say seven years past the time he stopped practicing. During that time, he did go and win one Olympic bronze and a world cup bronze. Maybe he didn’t stop practicing, after all?

“In autumn 2004 knee surgery started the last period of my career. Then I woke up to realize that I cannot keep on with normal methods, but that I need to really start working hard.”

In spring this year I was glad to spend time in a group which included several people who had been sporting at a high national level. An athlete, if someone, knows about practicing the same things day after day. I asked them how they did it. In addition to simple perseverance they brought up their love to their own sport and how it felt like playing to them. You can not only set a specific number of repetitions to yourself every night before going to bed, but you can have fun and variance in your methods. As it happens, professional athletes do well in the working life even after their sporting careers. Or is it merely a coincidence?

What is your level? What is the level you and your clients aim for? How do you reach this level?

Quotes from Ari Mennander’s book: Teemu. Otava, 2014, page 320.

How Did that Person become So Amazing and Skilled?

September 14, 2016 | Author: Antti Niittyviita

Have you ever met a person who has a very sharp situation awareness and judgment? The kind who can rise to the occasion and beyond, who can not only discover new perspective to problems, but to also solve them?

While we follow that breath taking situation awareness and judgment we come to think that, well, that person just happens to be that kind. Sigh. I wish I could be, too.

Naturally cutting edge situational awareness and judgment follow from good attributes inherited from one’s parents. Others might find better luck when it comes to inherited attributes, but that is merely a small slice of the entire story.

Across the life time, the significance of other factors lessens. Sharp situational awareness and judgment start to obey the most important of the factors. We call it experience. An experienced fellow is sufficiently sure to rely on the competence provided by that person’s background. At the same time, that person starts to become self-confident in another critical way.

That person permits new ideas to find fertile ground in his or her garden.

Cutting edge situational awareness and judgment are of course among the most important tools for a genuine expert. And they are products of achieved experience. But have you ever thought where that experience, which produces so many great results, is brought by? The kind of experience, which is qualitatively of the highest order and also offers the fastest experience curve?

Experience is born from practicing bad situational awareness and judgment.

Quality Assurance is a Lie that Keeps Destroying Projects

September 8, 2016 | Author: Antti Niittyviita

Have you ever given thought as to why does it seem to be so easy to drive software projects off the road? We are constantly hearing on the news how especially the bigger projects tend to crash and burn quite expensively. Typically, the project’s budget explodes because of impossible scheduling, or the end product is so bad that no one wishes to use it.

A functioning quality assurance is common in all the failed projects, as well. They put money towards quality and the sums of investment are high, too. But what is it that fails?

The answer is a human. Or more accurately put, the hidden longing in a human to feel assured and in control. The professionals of software business have their own term to depict the kind of work which strives to produce these feelings in others. It is called quality assurance.

The French root ‘assurer’ references insurances, promises, safety and certainty. What is interesting is how the term has started to pick up negative vibes, which are associated with assumptions and arrogance.

Producing assurance does happen to be one end result among the others. In quality assurance, they produce assurance that the product still works just like it did before. It is a medium for the sense of control, because the goal is to produce evidence of the software’s functionality.

There is an opposite force for quality assurance. Its purpose is to negate the sense of control by pointing out which specifications of the system, or architecture, or implementation do not yet work. It is especially good at destroying false senses of control.

This opposite force has a name. It is called testing.

In especially public sector’s information system projects it is easy to totally forget this. Specifications, architecture or implementation go unchallenged towards the quality assurance. Failure is set in stone from day one, when the action strives towards false senses of control.

Actual testing significantly improves the chance of success for software projects. Yet, it becomes impossible to do that vital work of testing, if we strive to keep testing as a part of quality assurance term.

Which is why I suggest the following, keeping in mind the future Finnish information system projects.

Plan quality assurance and testing as separate fields of work. Spectacular successes might be closer than you think.

A Tester ain’t a Star

September 5, 2016 | Author: Antti Niittyviita

What happens, if a software project becomes a play field for pride and power? When everyone starts camping solely at their own coffee table, and other people are only watched from the corner of one’s eye. And when going for a lunch, it takes place only within one’s own group of either testers or developers, and most certainly not with the big bosses.

When you are working in a project like that, you don’t feel like getting up and to work in the morning. And, oh man, is that my throat that is feeling very sore, and my shoulders are also beginning to ache… hey, wait a minute, isn’t that a sick leave I smell coming up?

The feel in the meetings nears claustrophobic. The coders feel as if the testers are fighting against them. The testers feel that the coders are fighting against them as well. The managers keep tripping everyone else in their work, seemingly whenever they just can. Gosh darn it!

Common sense has no foothold in the decision making process. Or in matters financial, unless the project is facing a total crisis already.

Such is a project that has become a playing field for pride and power.

But what can you actually do about it, should you find yourself stuck in the middle of such a field?

The first and the only step I to combine all the strength to accomplish one single task.

The mission is to make the developer team a star. To let them know, one person at a time, along with showing them just how.

Randomness Generates Order

September 1, 2016 | Author: Antti Niittyviita

Nature does not play its game by planning or giving reasons for its actions. It already has a strong tendency to form one after another of fascinating structures, all the way from snowflakes to galactic super clusters. Structures, which undisputedly work!

We humans, on the other hand, have a special tendency to unknowingly reject that complexity of nature. We build as straight a street as possible, our houses look like gigantic Lego-pieces, we draw lines between the stars shown on the night sky and if our life is not in “order”, we feel a deep offence.

Do we reject the complexity of nature’s randomness because we cannot understand it? Do we create models of its workings only to be able to discover something which we wanted to discover? Perhaps our simple creations are meaningful, however, because they are all a part of the grand multidimensional play of nature…

Let’s return to the surface! A software is also a model on a practical level, which we have built in our frenzy for creating something. Its functions are accurately pre-determined. Test specifying produces another model – the check model – which might match the software’s model. In our creation frenzy we are easily prone to mistakenly take these models for perfect.

How do we, who are at least imperfect in our mind possibly define something that is perfect? Check models do not generate apparitions, nor can thusly ever lead to perfection. Only as a part of some greater, undefined play prone to randomness can it serve the whole meaningfully.

Reject your human temptation to charge towards the world of models and formalities. Do not seek basis for your actions, nor demand other people to give any for theirs, because the reasons always end up in a restricted, imperfect, model.

Ninja Skills make a Tester

August 29, 2016 | Author: Antti Niittyviita

Overnight baked, fresh-from-the-oven software version is on your desk.  The tester is doing the tester’s work conscientiously when sitting in the tester’s own pen mouth foaming and going through the test cases. A good tester will get through 100 cases today as well, maintaining the pace until reaching the goal. That tester doesn’t talk much, nor ask troublesome questions. That’s a good tester.

Or is it?

  1. In reality, a skilled tester challenges the software product’s concept in the get go. The tester is interested in where the money is coming from and why. Who will be the first to buy this and how? The tester tests the product already in the first conversation with the product’s owner, or with the end user.
  2. Next, the skilled tester challenges the architecture of the product. The tester is interested in how many users are expected on the first day of launch and what kind of load balancer is the service using. The tester is testing the product already in the first conversation with the main architect and developers.
  3. Finally, the tester challenges the implementation. The tester is not interested in pointing out that the product is working like intended. In reality, the tester is interested in where the product hasn’t yet become broken. How would the next serious defect emerge?

A tester keen about professionality does trip horribly should the the tester first go and challenge the concept or architecture.

No one wants to talk to, or work with an annoying smart ass. The work is challenging enough as it is.

It has nothing to do with rationality. Despite the benefits, the emotion steers. That is why a genuine Guru is a nice and smart fellow. The Guru gets taken along because it feels like a good idea.

The entire trinity is only possible to be put into use in a team filled with masochists, or by delicately sneaking around.

Challenging the concept and architecture are ninja skills, which are not talked about, nor do you see them being used.