Month: September 2014

Cross platform rant

/ jankka / Leave a comment

I just can’t get it; How come it seems to be too difficult for developers provide a cross platform functionality that actually works? I mean come on you there. I’ve been learning to use this Robot Framework as the starting point for my own private ATDD -project (Called Marvin, due to Hitchhikers Guide to Galaxy, of course). This morning I started to create more test cases in order to start (later on) the development of the new log in -features. And I thought it would be a good use for my work laptop. Really, it has 16 GB of RAM, a processor and a hard drive. The only unfortunate thing about it is that it uses Windows 7. Due to reasons not quite clear to me, to be honest. It seems to have something to do with the IT -departments capabilities on monitoring and updating the end -users laptops and most likely the ability to remote -reset the hard drive in case the laptop is stolen. Or lost. Apparently the solution used there, in the wide America, is not flexible enough to be used in the real world. Well, now I’m just being nasty here, but still, we do develop stuff that runs above Linux and the development is done on windows. This of course applies to testing, too. Sigh.

Anyhow, everything worked just fine in the beginning. I did install the RobotFramework -eclipse -plugin and all. Ended up installing Robot Framework and its Selenium2Webdriver -library, too. Like I did last week on the Linux- & OSX- laptops. Like said, everything was fine. Until I had to actually execute the tests I had created.

I just can’t get the ancient profile -thinking Firefox keeps having on windows. Really. There’s no point of that. At the moment it actually really just slows down the development. And of course gains my frustration and gets me writing this blog -entry (which is not that bad thin, though). I tried to follow the instructions, too. Really guys, you who develop the Robot Framework, you could create a decent entry on how to configure Firefox and webdriver in Windows in order to get the test cases executed. All I found was Python Webdriver -instructions, which I have been using previously myself. Those do work. But there was no single entry anywhere that pointed to a working version of the setup.

So here I am; Browsing the web on my Firefox running on my ancient laptop that runs Ubuntu 14.04 LTS (With encrypted HardDrive, by the way) and getting ready to install the RobotFramework Eclipse -plugin to LiClipse pulling the latest changes from GitHub and executing the actual tests. In windows that was impossible (well ok, just NOT worth the effort), in Linux, it should not take more than 30 minutes for me to get a decent FAIL on the first test cases.

Learning curves

/ jankka / Leave a comment

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.

Sidekick

/ jankka / Leave a comment

Apparently it never is enough. Nothing is. Man born a hoarder is a hoarder, even during the nights or weekends. The last 2-3 weeks have been kind of challenging mayhem at work. I have to admit that my capability in adopting to varying situations has been tested. Several times. Long days, tough days. No time to reset, besides in the evenings at home or at the gym. Mostly both. Luckily training the unknown when following the CrossFit helps me mentally to get used to attacking the unknown. That’s a blessing. But even though it has been rough, it surely seems I haven’t been capable to do enough on the creative side.

I’ve been bouncing this idea of web -service that could help me as a tester. And since nobody is going to do it for me – partly due to my lack of capability to describe it properly and inthusiastically enough, partly due to the fact that every single other one at the work is evenly loaded – I’ll need to do it myself.

What I have planned is to do the whole stuff with Open Source SW, using Python, Django and git. Cucumber has been fetched and installed, as well as RobotFrameWork. Those are the tools for me to use.

Developing is a creative process and I’m pretty sure I’ll learn a lot on the way. I’m going to tackle this from the ATDD (Acceptance Test Driven Development) point of view. Hopefully I learn new stuff for testing as well as the crucial stuff for automating my tests and using development skills as tools for my work as a tester.

Now, since this is going to be part of my work, it is going to be a system test support tool, I cannot release anything (at least as it is) on my GitHub. I do have plans, though, to put something there, but as stripped version.

So far the project has been setting up stuff: Yesterday, a fresh install of Ubuntu 14.04 to my Dell Latitude, today getting the tools installed and reading the first introduction chapter for Git -usage. Tomorrow I should be good to go.

And for the record, I don’t except things being too ready too soon. This is going to be done for my education and amusement only. Status updates might follow every now and then anyhow 😀

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

It’s only human

/ jankka / Leave a comment

Now what is only human, you might ask? Errors are. Among the other things. Making them is really easy to human kind. It is of course easy to every single creature in the world. Even our dog seems to learn from its mistakes. Well, to be honest, I’m not quite sure about that, but at least I’ve got an impression that it is capable to learn at least something. In a matter of trial and error, what do you think that matters?

I really am a strong believer of trial, not error. As a test engineer I’m urged to try out things; to try out to do the errors and thereby to find out if the software I’m testing has them. I might also try to find the errors by other means, mainly by doing things I’m supposed to do. But that one should be more rare case to find errors, regarding that me and the developer have been handed the same pack of requirements. Which is not always the case. And even when it is, the understanding of the requirements might as well differ from one to another. And that’s the way you find the errors in the process.

But what is important here is how we handle the errors. As a tester, I’d like the developers see the found bugs and defects as an opportunity to make better products. Not being ashamed even for the stupidest mistakes. I’m not there to point out who has been stupid or idiotic. No. I’m there to point out that the application is not acting the way it should. The guilt comes within the person who receives the bug report. Well, in a case that I’m not being that stupid and making an ass of myself and blaming someone for making stupid mistakes. Which I rarely do. Come to think of that, I don’t recall when that happened last time. Maybe yesterday while being stupid, but hey, that’s like ages ago.

The same applies to slip-throughs. They do happen. The fact is that a test engineer can never test everything. We should be testing everything that is important and needed. But then again, we’re also only humans. It’s not a good thing that such things happen, but it is normal. What cane we do about it?

We can of course start the blame game. Which is one of the errors I’d like to be capable of avoiding. But as I’ve said before, it’s only human to do even so. Even though that is really stupid. Regardless who you are blaming, whether it being yourself or whoever else, you’re pointing your finger strongly and firmly to a place where the error does not exist; it is only the symptom or manifestation of error you in that case are pointing to. And this one here is the thing:

1) When making mistakes, learn from it, don’t try to stop doing them.

2) Don’t blame yourself – even though that is human, too – well, don’t do that too much.

3) Guilt and shame prevent you from seeing the actual problem. Sometimes they lead you to make same errors again.

4) Don’t be ashamed of missing the first one, second one, and the third one.

By trial and error we learn to get the banana from the tree. Or the tree and the banana. Or strained hands. or as in this case a list of things instead of the thing. Open-mouthed smile

“Never give up your right to be wrong, and be sure to give others that right too.”
― Tim Fargo

“You never know what worse luck your bad luck has saved you from.”
― Cormac McCarthy, No Country for Old Men