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?
Author: Anders Dinsen
Categories
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!
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.
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.
