Tools for reading, writing and editing

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 

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