You pick the right tool

 

As you can see, it is sometimes crucial to select a right tool. Even to stick to it, regardless on how awkward and painful it might feel. I just had to open with this scene, it is anyhow from one of my all time favorite movies. The book it is based on, is definitely one of my top 5:s.

We’ve all been there. It’s late night, we’re out in the park, having fun and all we have left is bottle of wine. And of course the corkscrew is nowhere to be found. So you start using your imagination. You might have a normal screw and a screwdriver, maybe a pair of tongs, too, you might be carrying a multi-tool, for what I know. Or not. The cork stays in the bottle.

You go through your pockets again, ask your friends, someone says that all he’g got is a pen, other one offers you a rock.

You see where I’m going here? A pen is mightier than a rock? Well, at least now it is.

Now you could open the bottle by smashing the head to a rock. Or smashing the rock to the head of the bottle. That might work, too. In the other hand, there’s always risks of getting bottle broken so, that the glass gets inside the bottle. Besides, that will create a mess in the grass and I a devoted dog owner and animal lover hate when people break bottles or other glass and leave the stuff there. Besides, people can get hurt too, for real.

So that leaves you the pen, right. You could write a letter – I know, it’s old school, but it’s nice sometimes, for real – to someone with a corkscrew to drop by. What’s there to loose? You got the whole weekend ahead of you (Did I mention it is a Friday night?) Or you could rob a corkscrew store with it, not the world’s best idea, though, giving it to be late night and the stores are all closed.

You could also take the pen and push the cork inside the bottle. That actually does work. You might get to spill some, but then again, at least there isn’t going to be shattered glass anywhere for the paws of the two to four legged friends. Notice I left a place for three legged dogs or cats, even squirrels.

So, you take the pen and grab the bottle. Your hands are getting a bit sweaty so you what your sleeve around the bottle. It keeps it in its place. Not completely, but firm enough. You take a breath.

You push the pen against the cork and push. Nothing happens, except the veins in your temples seems to be exploding, your face turns to red and the pen hurts your palm. A lot. You let go for awhile, and try again. No change to the situation. Cork is till on and you seem to be screwed.

A friend of yours, the one that has taken one more than you, mumbles something and offers you the stone from his hand. You look at him and smile and are about to shake your head, but change your mind and take the stone.

It is smooth on the other side, the side agains your palms has some edges and it feels, if not cold, then at least cool. You take the stone, push the bottle against the ground and hold it between your feet and hold the pen on your other hand against the cork. Then you slowly but firmly hammer the pen inside the bottle with the stone and finally, you’re done. Everything’s fine again, you drink the wine, get in to the night and wake up next morning with a hangover and some blurry memories. You might even end up having fun, who knows.

What I mean here is that you should choose your tools, for real. First of all you need to know that you have a need for a tool, then you need to check what requirements you have for it, then you need to find it. Thanks to the interwebs, it is fairly easy nowadays. After finding the tools, take several, and use them for awhile in the situation needed. So to say, evaluate them.

If you run into problems with the tool (you should, for real, even a sledgehammer needs some maintenance), try to find out if anybody has had the same issues. Most likely you’re not alone.

Check the maintenance costs. If you use more time maintaining the tool than the flaky tests, you probably have the wrong tool. Regardless on how good it looks, sounds or feels.

And once and for all; don’t get stuck with the first evaluation, don’t get stuck with your evaluation choice, either. In case the tool loses its focus and usability, make sure you can move away from it.

I myself are at the moment in that kind of situation: using a multitool with a gentle learning curve, but the maintenance and the license is starting to feel bad. It was a tool I was familiar with, a tool I’ve used for years in the previous companies, and it used to be an open source tool. They ended the open source path last year (if I remember correctly) and otherwise turned the usability a bit more worse, too.

So I’m considering moving the tests to another multitool, an open source based tool with steeper learning curve, but a considerably larger user group. Actually, I’ve done my consideration, all I need to do now is to transfer and modify the current tests from the first tool to the second one.

Excuses get in the way

I know, every excuse is just an excuse on failing to prioritise, but sometimes the prioritising actually gets you nailed down to something where you just have to concentrate and work on.  This week has been one of those.

So to say, releases flowing in from doors and windows and I find myself testing (or wanting to test) them all.

Which of course has meant that I haven’t been able to fulfil the 30 Days of Testing assignments. Currently I am lagging behind 1½ – 2 days. My plan is to get back on the track during this week, anyhow, meaning that I’ll do something during the weekend.

This is just to inform that I am aware of the situation.

Besides that, I ended up going through this tutorial yesterday and realised that this mochaJs-thing seems to be a neat way to learn JavaScript and some test development 😀 I might even give it a more thorough run later on. I also discussed with the author (Viktor Johansson) on collaborating and creating some neat tutorial with BDD & Robot Framework. Oh, and managed to install Skype on the Fedora, which is always an accomplishment 😉

We’ll see what tomorrow brings.

Learning curves

It seems I have a road ahead. Not sure what is going to happen, but at least I know that I’ll enjoy the ride. The ride will be long and it will be hard at times, but all I have to do is to remember that I have all the time in the world for this and the target is not to create a perfect application, but to learn how to automate tests and develop with Python and Robot Framework. Both skills I see as needed in the future.

First of all, after everything was installed yesterday, I sat down and went through some tutorials. Both git & Robot Framework are getting more familiar now. Far from being perfect, but at least I’ve been using both. Git is, by the way, a lot more intuitive with the commands than CVS. And it really neat to use a service like GitHub to store my stuff in. At the moment the solution I started to lab with is stored as private in GitHub. In the future I plan to create a public variant on that in order to get it shared properly.

I also managed to start the Algorithms -project and created the first excercise. It is a simple insertion sort I managed to get together by help from stackoverflow (a really good site to search for information;)) and a slight use of my brain. I actually needed the stackoverflow -solution more or less as interpreter to the algorithm -books pseudo -code.

And last, but not least, I actually have now done my first time ever ATDD -approach on developing. The test case was created and it failed in the beginning. After some coding I managed to get it also go through and got a PASS as result. And the test case is of course using selenium webdriver -library to verify that the web -page is up and running.

As a bonus I actually got an idea about a solution on how to parse some input strings properly with groovy -script in SoapUI. A thing I will need to do at work next week anyhow.

So to say, it has been a proper weekend.

What is a test tool?

KuvaIn order to really discuss something worthwhile at this blog, I’d need to know what actually is a test tool? To gather information and thoughts about the test tools will be way easier if I know what to investigate.

As I mentioned before there is bunch of text editors, as well as internal/external blogs (such as this?) that could be used as test journals, test data editors and for interpreting test data. As an addition to that post I’d really like to see a tool that combines the journaling possibility seamlessly and easily to the test tools used.

Which brings us to the variety of the tools. There is scripting tools for running and automating test cases. Formost you can use the OS -native tools to automate some part of the test process.

For example there’s shell -scripting possibilities in Windows -machines. You can easily edit the scripts that can be used in command prompt by using the notepad or whatever editor there is. The problem that I see nowadays is more or less the fact that there’s not much you can do from Windows -shell. The command variety is limited and as stated, most of the stuff you want to get done requires the actual GUI. You can, however, automate some tool -usage, e.g. java-, ant-, cvs/svn/git -commands in order to proceed with the normal, and boring, repetitious steps on testing process. You could also use Perl and Python from the prompt. 

That is much less than what linux -shell can do. Bash -scripting (ok, there’s other command line interpreters than just the bash, I know ;)) with whatever linux/unix -distribution is more simple to get done and is way much effective due to the fact that the interpreters can execute a huge variety of their own functions plus call system applications, perl– & python -interpreters etc.

I will return to both of these interfaces later on as separate blog entries (one or more per interface). They certainly deserve it. The question still remains: Can the command prompts and their interpreters be referred as test tools?

I myself think so. The thing that remains to figure out is how much we can rely on the software and tool provided by the vendor of the OS (or a GNU -cult for that matter) and how much we need to take in consideration that they have their limits and defects, too. And last, but not least, when should we start using some other test tool as the ones provided by the OS we are using when testing. And yes, there’s a slight difference if you’re testing  the software and using it’s OS provided client interface on the test target than on your workstation. Depending on how heavy processes you use on test scripting you need to consider the effect to the test target and taken measurements (CPU & memory usage, thread usage on linux etc.)

 

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.