Tools for reading, writing and editing

Kuva

Cow Tools. (c) Gary Larson

What can be considered as a tool? Whatever that is filling the needs while used, ain’t it so? A stone is a tool of hammering (Ok, I admit I should myself drop the hammer now) and for keeping door not to be shut. But I wouldn’t go so far that even think of trying to use it as a screwdriver. Well, I actually did think about it. Gary Larson had a brilliant frame about stone age tools, btw.

According to Wikipedia “A tool is any physical item that can be used to achieve a goal, especially if the item is not consumed in the process. Informally the word is also used to describe a procedure or process with a specific purpose. Tool use by humans dates back millions of years, and other animals are also known to employ simple tools.”

So it seems a tool can be whatever we find to be fit.

So what is a test tool, then? For me it sounds to be a tool that is used for testing something, to prove that the object to be tested behaves according the expectations. And now, remember here, as a software tester, the expectations are that the tested object behaves somewhat faulty and weird. Developers live in a beautiful world where their programs work flawlessy day after day no matter the circumstances. And here comes the tester in and ruines it all with the help of his tools. Neat, ain’t it 😀

I’d start with pen and paper. Or a marker and a whiteboard. They are both brilliant tools for thought processing in order to get a grip what needs to be tested. At this point the review of the documentation plays a big role and can also lead to that some possible flaws in design process can be spotted, too. Yes I know, it’s a long shot that there is any, dear developers, we all know you don’t make mistakes. It’s the tester that plants the bug inside the program, ain’t it so?
Besides examining and writing down the test processes and needed test cases the pen and paper can afterwards be used for test journaling, too. So no surprise there; some of the simpliest tools are actually multitools.

Then there’s the native tools that are provided by every operating system. Notepad, TextEdit, Vi, Emacs, Wordpad and Gedit. Completely and highly usable tools for taking notes and reading test results.
I try to avoid Notepad as much as I can. It’s hard to read and edit text files that have no linebreaks. Plus that it lacks a descent way to search and replace. Same can be applied to Wordpad, too. In windows I’ve been using Notepad++ in all kind of editing, reading and writing. It is free, easy to use and comes with bunch of neat features.
To be honest TextEdit in OSX is not that good either. It is obvious for me to use TextWrangler on editing and watching the results of text files. Or to create HTML/XML -inputs, SQL -sentences etc. For writing in OSX, Writeroom is by far the best tool I can use when it comes to pure writing. I’m actually using it at the moment. It is a distraction free text editor. Unfortunately it is not free, but the price of 9,99 $ is not that big in order to get it working. By the way, should all the software we use be free? To be honest, I don’t think so, but that’s a different topic and a subject for a different blog entry as itself 😀
Since I’ve been working with linux quite a lot, vi or vim has been my main editor for years. Ever since I learned how to write changes to the file and quit (:wq or :x) I’ve been every now and then trying to do so when quitting a terminal connection. Besides the odd commands it does have a powerful way of manipulating big textfiles with several great options on replacing all or finding a certain string(s) inside the file. I know I’ve been just scratching the surface on this one, too, but it really has helped me a lot more than nano or pico ever did. yes, I’ve used them, too, but that was even more long ago 😀
Emacs I tried maybe two times, but it has been more or less too much for me. Now here’s the place for a flame -comments, then. Vim or Emacs?
Now just one question: do I really have to tell you the reason why I don’t use gedit at all? Or at least I try to avoid using it as much as I can. It is too heavy and clumsy when compared to vi/vim. Now I know there’s a GUI fo emacs, too, but as said I’ve never had a reason to use that one either. Vim has done the job I’ve needed to get done. And that’s the main reason (at least for me) to choose the tool in hand.

It seems also that this article is just a scratch on the surface: I really need to write a bit more on these tools.

BTW, this article was written with WriteRoom Big Grin :D

Soundtrack: Dire Straits – Brothers In Arms – 20th Anniversary Edition

Link

Top 10 Excuses Made by Programmers

Top 10 Excuses Made by Programmers

Ever since I took my first ISEB -certificate I found this list a fascinating one. Need to actually to get a poll somewhere here to measure the accuracy of the grades in that list in real qa-life. Which seems to be somewhat something else than the real life (the one we do live away from keyboard/touch screen).

I myself see the ‘Works on my machine’ and ‘That’s weird…’ as the funniest 😀

10. “I haven’t touched that module in weeks!”

9. “It must be a hardware problem.”

8. “Somebody must have changed my code.”

7. “Did you check for a virus on your system?”

6. “You must have the wrong version.”

5. “That’s weird…”

4. “There must be something wrong with your data”

3. “It’s never done that before.”

2. “It worked yesterday.”

1. “It works on my machine”

And it seems there’s even more thorough list in here:

http://vbcity.com/forums/t/44234.aspx

Running with the hammer

 

There's no hammer here.

There’s no hammer here.

Tools are tricky. Well not all of them and to be honest after a while any tool what so ever is easy to maintain and handle as the user experience has gained. The learning curve of course varies a lot.

Let’s take such as a hammer. A somewhat blunt instrument for hitting. Anyone can use it. Anyone can hit with it. Anyone can hurt themselves with it without any particular training. Nevertheless it is hard one to master. I’ve watched the master carpenters hammering down floor boards in such speed and accuracy that I doubt there’s no way of me getting there. Well not at least by watching. As a friend of mine used to say: You learn to run by running. The same applies to hammering. No, you don’t learn to hammer by running, even for some of it might sound tempting, but I doubt that’s the way it goes. What I ment – for those who still are running with the swinging hammer – is that you learn to hammer by hammering. A lot. They say it takes 10000 hours to master something. Or was it 10000 repetitions. Give and take a few. So as far as I see: there’s no way I can get hammering that much. I already have this writing and working to do.
And that’s the normal excuse on not mastering anything. The road is long, I don’t have time and besides the next guy does it already so well; the Polish (or Estonian, Mexican, you name it) do it cheaper and faster.
But consider this; the road ahead starts from the first step. That’s all you have to take. Once again, drop the hammers and stop running. I’m all metaphores here, the action comes later. Yes, I know, boring. But pay attention.

We here are proud owners of knowledge, gathered knowledge. We’ve done it at work, at customer premises, while killing time in between the assignments, on courses or in the evenings when you could do something else with your lives. You name it. We all have it.
Now let’s imagine that we could have a vault of combined knowledge. A stuff we could get into and read and contribute and flourish with our knowledge. Actually, you might kindly point out, there is. Some might call it the internet. The googlepedia, whatever. The truth is out there. And in here, too. It’s inside ourselves. And we do use it, don’t we.

So the trick on knowing more and spreading the already gathered knowledge is not that hard. Not at all. And that’s precisely what I’m trying to point out in here; don’t just take the first step. Take also the next. And the next. Keep on going. Hammer down the obstacles of your mind (there! You see, there was use of that hammer after all!) and walk on. But most of all spread the knowledge, don’t sit on it. The more you give the more you get. Really.

And that’s what this blog is about to be. A forum for me to boast myself (as always, I’m the most humble and modest guy of the world) and spread the word on the tools I’ve used and evaluating to get some order to them.

Soundtrack: Pink Floyd – The Wall

Blunt Instruments Of Testing

Welcome to my blog. This blog is attended to be a placeholder of thought concerning Software Testing and test tools particularly. Most likely – so far as I know which kind of writer I am – the blog posts will vary somewhere around the big topic.

As a professional tester and a wannabe writer I see writing as part of the thought process in order to organize my ideas. It’s kind of similar tool than discussion with colleagues or friends sometimes can be. So at least for me that’s one of the professional tools a software tester can use. For me writing a test journal is a crucial part of working, and it helps me to organize my memories on my work assignments, which sometimes can come and go and change rather rapidly.

I will be forming this blog every now and then and most likely to write as often as possible. We’ll see how far I get with this approach.