software

Hunt ‘em down

/ jankka / Leave a comment

Mankind has been practicing hunting, let’s say, for a few years now. we’ve been capable to get our daily rations of protein, carbs and fat by hunting, finding, gathering, looting whatever has been available. And I ‘d like to think we’ve been rather successful on that, too.

Just think about it ; we’re still here, few other species have gone extinct and most of the current ecology –system is more or less constantly threatened by our existence. So I’d like to make a conclusion that we’re are pretty well adjusted for hunting down whatever it is to be down hunted.

So how come it is so hard to do with requirements?

I mean come on, people. There will always be the written down requirements, those are the easy part. Regarding that they are available for all software project participants. Which they might be, and then again, they might not. So let’s not concentrate on them at the moment. Let’s make an ass out of u and me and assume that the written down requirements are available, and what is most important, their whereabouts are known in the whole project for all the participants.

So QA starts their work basing their testing on the requirements and information available. No big deal. Bugs will be found, they will be fixed, life goes on.

But what about the stuff everybody just magically know should work? The packaging standards of the applications, the delivery setups, the way the applications should react to other applications in the system? What if those are de-facto standards, written down ages ago, known to most of the people involved, but just in this particular project there’s a bunch of newcomers.

During the initiate phase such things should be brought up and delivered to them, ain’t it so? sure it is. Well, that is a nice picture, but honestly people, it does not always work as that.

The truth (You can’t handle the truth!) is that we do  live in a perfect world. Yes, you read it right. It is perfect and understandable unambiguous and messy and in the end, it is beautiful to see this multitude of failures, flaws and not working things among the everyday life’s working stuff and understand that it all is part of the process.

Now where I’m going with this? Here; all you need to do is to take your stand and adept to the situation.

As a QA –engineer, your responsibility is to plan and execute test cases with certain expected results. You cannot say that you can’t do them, that you don’t have the requirements. Not if you get to know that you should’ve known. And for the record it is more than OK not to know.Like I pointed out yesterday, it does not matter if you did mistakes, or if someone else did them by not providing the requirements to your lap. What matters that you take a leap towards the newly found information and hunt it down.

Now you might tell me that it is project responsibility to deliver all needed information considered and bring it to you. Hopefully on a silver plate. I’d like that, too. And while they’re at it they could also bring the coffee and take care of my laundry.

Now here’s the crucial part, at least for me; The world as we live is perfect. It is perfect for human beings who are capable to hunt down all the targets they aim to do. And that applies to requirements in software projects. You might not succeed all the time, none of the hunters do, either, but who cares. The point is that you can hunt and that you can catch your prey. Let the prey here be information. Actually, if you’re reading this, your brains have been capturing at least some information on this page. Same applies to requirements. Regardless if they are written down or not.

The next question is, of course, what to do with them? Well, depending of the structure, you’ll need to get to the best parts of them. You might need to skin, peel or mush them. And then split them to chewable pieces. Some of them are nutritionally really good, some of them are completely unusable. Pick what you can use and leave the rest. The ones you picked up, you’ll feed up to your Test Case –creating ogre, called Untar the Defector. And you’re done. For now. Tomorrow will come and bring the new challenges, and your ogre is forever hungry.

Soundtrack for the post:Queen – Live At The Rainbow

Advertisement

Running with the hammer

/ jankka / Leave a comment

 

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

/ jankka / Leave a comment

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.