Blog posts in English

Based on evidence…

I’m very interested in shool education and I’m chairing the board of the local school. My particular field of interest is education for children with learning disabilities. This is because two of my boys have ADHD with reading disabilities.
We’re looking for new ways to educate children with special needs here in Denmark, and the trend is to include them in the normal educational environment – not put them in special schools. There are two reasons to do so: One is that it’s cheaper, the other that the effect of special education is statistically not very good.
I’m regularly discussing the dilemmas of special education with local politician and social sciences professor Bent Greve, and lately he and I had a short e-mail discussion about whether education should be evidence based. This is also a public debate, similar in nature to the debate taking place in the testing community.
Bent Greve explained me why he, as a politician, requires education to be evidence based: He needs to know that the practices which are being applied actually works. I suppose it is about supporting his descision making, but he pointed out that it is also in the interest of those they’re trying to help. It can be done in health care, so he beleives it can be done in other areas too. However, it should never be an excuse for the individual professionals’ responsibility for what he or she is doing – the evidence should support them in making the right decisions.
This point of view is sympathetic if you’re engaged in politics or managing a company: You want your workers to do work that works. Not work that doesn’t work. Right?
On the other hand is the point of view of the professional, who uses his talent and creativity to research for and find solutions. Teachers generally argue against the focus on evidence and find that it limits their freedom and makes them less good teachers. I also argued with Bent that, sometimes the “right descision” turns out to be the wrong descision. For example: If you base your teaching on evidence of what works in general, we can be certain that there will be between 5 and 20% of the pupils who will not learn anything. So what should we do for them?
Bent Greve responded intelligently: Evaluation and evidence cannot be left alone. Continous experimentation and development is needed, as nothing can be said to be final truths.
I agree.
As a tester craftsman I follow patterns in my work which work for me most of the time, but sometimes I find that they don’t. If I test and don’t find any bugs, I feel dissatisfied and confused. I think I may have used the wrong pattern, but I’m in jeopardy and I don’t know what to do since my pattern failed. Eventually I may have to give up, or I may discover a pattern that works within the time that I have to test.
Managers don’t find bugs, testers do. Politicians don’t educate pupils, teachers do. So who should we trust? I’m not going to answer this question since it’s absurd: There would not have been schools if there hadn’t been politicians and there would not have been any software companies if there were no managers. But I think everyone can agree that by the end of the day, the thing that really matters is that we find as many of those annoying bugs as possible before the product is released, and that the pupils learn the most from attending school. Right?
Correct. But sometimes we find that the patterns we’re following in our worklife (whether that’s teaching or testing) are not working. Then what? We have to stop and think. Something is wrong. How do we progress from here. This is where the most important rule is: Don’t apply the same pattern again – try something different!
PS: I was not at Eurostar 2010 today so did not hear Stuart Reid’s keynote. I did, however follow some of the noise it caused on Twitter!

Copyright (C) Anders Dinsen
6 year old Troels learning by playing

Blog posts in English

Usability testing is different

Usability testing is done for roughly the same reason as other kinds of testing: To discover new knowledge about the system under test. In this case knowledge about how users work with the system.
But Usability Testing is a very different discipline from ordinary system testing.
In my opinion, the one thing that makes usability testing different from system testing is, that it never discovers absolute facts about the system. 
Instead, a usability test will only say something about how the system works in relation to someone – and this someone is a person – or persons. And as you have probably experienced several times in your life, real persons aren’t absolute, predictable, or static – they’re quite dynamic and you never really know what to expect. Usability testing is a bit like integration testing against a remote system, which keeps changing, even while you test it!
Another aspect is that it’s much more important, yet also more difficult, to describe the context in which the system is to be used and the test is executed in.
I’ll illustrate that with a basic example: Many corporations implement systems for internal use which are not really user friendly, but since the employees get paid for using them, they don’t mind this – and once they’ve used the system for a few weeks, the system may have become an efficient work tool. An opposite example is most computer games, which are deliberately designed to be inefficient, but are usually easy to learn and use. These two systems or applications may be used on the same day by the same person, but in different situations, of course.
Setting the context is not always possible, though. For example is that most people will only respond to things which they understand: Chances are that if you had tested Facebook on users in 1995, they wouldn’t like it at all because they would not understand what it was to be useful for.
Essentially, I feel that the tester must be much more conscious about what he is doing and how it is affeting the test results. I actually believe that the description of the context itself and the way you describe it is as influential on the results you get, as the system and the users themselves.
Yes, testing usability can be very challenging!

Blog posts in English

Code is Poetry – But What About Testing?

WordPress used to have a tagline saying “code is poetry”, apparantly Microsft has used it too. I don’t know who came up with it first, but I agree. I wrote my first piece of BASIC code almost 30 years ago, my first machine code program more than 25 years ago, and learned C also about 25 years ago. Code can be as meaningful and meaningless as poetry, so the analogy is correct. To me at least.
Now, many years later, I’m a professional tester. I find problems with other peoples business processes, architecture, software designs, and implementations. I don’t write code any more (except when I’m using it to test something).
But where’s the poetry? Is testing essentially a non-poetic activity?
I don’t think so. Yet, it doesn’t make sense to say “tests are poetry”. They aren’t. Then, what are they?

Blog posts in English

Natural born tester

When I was still a child, I could not have a new toy without starting to find out how I could get inside and find out how it was built. It was often distracting me away from the intended use of the toy.
I was annoyingly courious! I don’t know when it started, but I know that I have never found a cure for it. I played with LEGO’s a lot – I think that satisfied my constructive instinct – but couriosity was always there: I dismantled mechanical and electronic toys, the old alarm clock, vacuum tube radios, loudspeakers, computers…
Couriosity can lead to new knowledge or to destruction – or both. I didn’t always find out how things worked. For example, a vacuum tube does not itself reveal how it works like a gear and a spring can do. So my couriosity was sometimes not really satisfied. That didn’t turn me down, however. I kept on taking things apart!
I’ve “sharpened my pencil” a lot since then and now have a much better understanding of product development and how to use my couriosity in a way that is not destructive at all, but usually very constructive. I am a professional tester and I’m able to quickly and effeciently discover facts about new things that nobody knew about (some of these facts are called “bugs”). My job is to pipe those facts back to the developers who can use them to improve the software they are responsible for.
That’s what a tester does. Whether you’re “natural born” or has discovered the techniques later in life isn’t important. Couriosity is important!

Blog posts in English

Technology versus Product focus

Software is based on technology and software engineers love it. The most popular subject of discussions between programmers is which platform to choose for the next project, what tools to use, and what development methodololgy to use.
New technologies and methods are heavily accompanied by marketing campaigns that promise many good things if we base our new product, project management, testing etc on this great new invention. They don’t even have to be commercial products: There are people in our industry who advocate common paradigms and free tools very firmly without any kind of focus on their limits.
During my career, I have found that technology fascination alone usually leads us nowhere in terms of business value and making a different to users.
In this series of blog posts, I’m going to point out why we have to pay specific attention to this pit-fall, and why we must repeatedly to evaluate the technology we’re using against its influence on the result of the project: The product.
I’m going to suggest a product focused software development paradigm.
Focusing on the end product (and knowing how to focus) in software development projects, will lead to better products.

Blog posts in English

Rapid Software Testing course by Michael Bolton

Even with years of experience, I always feel I have to look somewhere to become wiser. To learn. To develop.
In 2009, I spent one happy day at Agile Testing Days in Berlin. A wonderful venue, great conference. For personal reasons, I could only allocate that one single day, and I promised myself to return for the full conference this year.
Unfortunately something came in the way, and I started looking for something else. Something that could refresh me. And I came across Micahel Bolton and James Bach’s course on Rapid Software Testing and found that it was being held in London – and the time actually did fit in my calendar.
The course was excellent – just what I needed – and my tester brain has been re-fuelled.

Rapid Software Testing course by Michael Bolton
Michael Bolton running an exercise with us on the Rapid Software Testing course