Windows

Sourcetree Update in Windows 10

/ jankka / Leave a comment
  1.  Update has hung for few months (i usually work in Linux anyhow)
  2. I choose to accept
  3. New update for version 1.9.0 is downloaded and installed, not more glitches than normal Windows installer brings
  4. After update I get a pop-up that this version will not be updated/maintained anymore and I can choose to ignore or get to the downloads page
  5. I get to downloads, I’m curious
  6. a new version 2.3.5.0 is downloaded, so I install it
  7. Installation is smooth, and I am bugged about the earlier version once again when I start the app.

Now, really? I have to update to a non-supported version first to get the latest, separate, completely new version? How smooth is this?

 

Advertisement

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.

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