OSX

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.

Advertisement

Building up the competence

/ jankka / Leave a comment

After being back from vacation has been neat. At least what came to the office atmosphere. The first week I worked almost completely from home, week after that there was almost nobody at the office, so I could really work easily by myself. Now I notice that the sounds of the keyboards rattling and mice buttons clicking keeps bugging me off. Not sure why, though. Usually I get the feeling when I’m tired. And now it’s monday and I won’t admit being tired after nice and refreshing weekend. Luckily there’s Spotify and earphones. 😀

During the holiday I was more or less online all the time, which can be seen as a good or bad. But as my friend has told me, everything has its good and bad drawbacks. I myself found the holiday really good and refreshing. Both on personal and professional level.

As you might know, I’m working as Test Engineer in QA/Test consultant company. The thing is that I got a phone call and an email during my first holiday week telling me I got an interview with a potential (and really interesting) client next monday, if it just suited my plans. Well, it did. I went to the interview and ended up having a test exam delivered to me the next day. Not completely unexpected, for they were looking for test developers.

I’ve been in  a similar situation before, last year at Spotify and that did not go too well. Or at least I found something I was not capable of doing. Regardless on the training I’ve taken and the education I have, my development capabilities were far from perfect. I did my best ( at the time) and came up with solution made with bash -scripts.

This time, though, I decided to really give it a shot with a decent language. I did have my Python -training   last year, for test automation purposes the language feels still to be really good one. Sadly I did not have any possibility to start using it at my previous work. Well, I might have could, but I never did even try. Besides that I did stick up with my old habits (and bash -scripts), which really rarely leads to anything new and exiting. 

So I went and jump into Python. Ended up doing some Python -related stuff few hours per day for around 10 days. With some breaks, for it still was my holiday 😉 It basically meant I did work around 3 days with Python and ended up with one solution. Then I got back at work and noticed I could make it a little bit better before delivering to the client. Which I did.

Now that the version is delivered I can see it’s not perfect. They rarely are. So at least I’ve got something to work with still.

This all has been really interesting. Getting inside the development, even for test purposes, has been an eye opener. More or less it seems that this has been the one tool missing from my case. So in that way I really do understand using my own time on learning and getting inside Python. For now on it will definitely be easier for me to adapt to that kind of situation. Besides that, now I can keep up learning myself more and more. I suppose that is the best way to do it. To build up and maintain the competence while I still can. My target is now to keep on developing something with Python daily. The same thing I’ve had my writing; I’ll need to create a new habit out of it. By that way I’ll keep up my touch to the language and hopefully will get my competence built up more and more every day. Well at least weekdays. Weekends are still worth to be used with family 😀

Now I’m not saying people should use their own time doing job -related stuff, and I myself don’t see I was doing it like that. I just used the work as an excuse for getting an uplift for my own competence. And (you might argue with this) my competence is not made only for work purposes, it is something I can use in my everyday life, somehow, too. Even if I won’t sit down and code I can learn myself how to get to know new stuff and that won’t hurt in the real life situations either.

Now, few tips:

  1. Eclipse & pyDev is a brilliant couple. I did myself use ADT Bundle for Eclipse for we need Android development environment for test automation purposes.
  2.  Stackoverflow has been a brilliant source of information when in need. And I’ve been using it a lot 😀
  3. In case you need to add plot graph on your web site (I need to) it seems matplotlib could do the trick.  Here’s how to get it installed in OS X Mountain Lion
$ ruby -e "$(curl -fsSkL raw.github.com/mxcl/homebrew/go)"
$ brew doctor
$ brew install python
$ export PATH=/usr/local/bin:/usr/local/share/python:$PATH
$ easy_install pip
$ brew install gfortran
$ pip install numpy
$ pip install scipy
$ brew install pkg-config
$ brew install freetype
$ brew install libpng
$ pip install matplotlib
$ python
>>> import numpy
>>> import scipy
>>> import matplotlib

  

What is a test tool?

/ jankka / Leave a comment

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.)

 

Tools for reading, writing and editing

/ jankka / 1 Comment
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