Month: June 2013

When all else fails, do it yourself?

/ jankka / Leave a comment

8_30_11_-_1In the real life – that’s the weird place outside, away from keyboard – there’s a saying “When all else fails, read the fucking manual”. At least I’ve been told that much. Actually that’s how I’m used to work. One could say I’m the local businessmen -dream.

Let’s say my bike needs the rear derailleur to be changed. Or at least adjusted. No big deal. I take my screwgie and start turning. I almost get it done. Almost. Then I readjust it. And finally look at the youtube -video where the guy puts it in order in like 15 seconds. So, how hard can it be? I continue minging around. Finally after few hours I got the rear derailleur so misplaced that I get max 4 gears changed on the 9 -gear shift and everytime I’m worried I’ll break the cable while changing the gear. So all I can do then is to take the bike to ‘The Guy’. Who then will fix it in approx 45 seconds and give me a bill of half an hours work. Nice.

That seems not to be, however, the case when you work with software. At least not for me. It is more or less limited knowledge plus tons of googling and other supporting tools that gets me around the problems I face in my everyday work. That’s at least how it works when dealing with open source applications. Don’t get me wrong here; I’m a big fan of the whole open software -movement.

With paid applications you get to have the support more or less easily available. With the free ones you get to be stuck for whatever tools and knowledge you have and can get all by yourself. Some of the open software vendors do actually provide the possibility to pay for the support, and that is more or less great.

But then that comes to the collision with my ego. I don’t know why it is so, but I still do have problems to swallow my pride and make the request for help. Unless I’ve been bangin my head to the wall for few days or so. And that is always few days of wasted time. Needless to say that it would be ok to do so at home, but at work it’s not only my time; it’s also company time I’m wasting.

So what should be done? Should I admit that I don’t know a bit earlier, swallow my pride and make the call? Or should I find the solution all by myself (Which is actually one of the best ways to learn.)? Or is there a ‘best of both worlds’ -solution available? What I mean is where’s the actual tipping point here? When should I realize I’ve gone too far? After 3 repetitions that leads to nowhere? Or after 10? I suppose that, as always, it depends.

I’ll have to admit here that I actually did not take the bike to the guy because of the rear derailleur, that’s something I got fixed together with manual, a video from youtube and few days practice at home. But as said, the time was spent, even though now I can adjust my gears without any problems at all. With the fork with suspension, however, I realized that the lack of knowledge together with lack of tools would’ve ruined my self confidence together with my economy, so that I took to the guy. Who did excellent job, by the way. And only charged me one third of the forks price for mounting it 😀

Advertisement

From Quality Assurance to Quality Assistance.

/ jankka / Leave a comment

From Quality Assurance to Quality Assistance.

Ran into this link while reading about the testing. From Quality Assurance to Quality Assistance. It actually rings a bell; I do like to think myself as a servant more than the guy being served. Ask not what a developer can do to you: Ask what you can do to help the developer 😀

Now there should be an embedded Prezi -presentation made by Yong Goo Yeo:

 

 

In case it does not show, here’s the link.

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

Â