The problem is/was that I was forced to run the docker with sudo (reasons are explained on both pages linked here, I’m not going to repeat them), and while both sites gave a solution, the docs.docker.com -instructions did not actually work. So I googled a bit more: https://developer.fedoraproject.org/tools/docker/docker-installation.html
According to developer.fedoraproject.org, you’ll have to run the following two commands in order to get docker executed without sudoing.
Basically you’ll add a docker -group and add yourself to it.
When after logging in to a service you get to see this:
It is not working. Well, or it is, but not as it should. Besides, the error message is not the most user friendly, either. Besides, for a hacker this type of error message reveals easily the system the service is built on, which is always a security risk.
After pressing refresh, though, the page is loaded.
BTW, WordPress has a bug in their category handling -field. In case you write a comma to the field (id=”newcategory”), the word before the comma is not listed at all after pressing enter. Like this:
Write “Errors, fails and bugs” to the id=”newcategory” -field
Press enter
Expected:
You get to see the string Errors, fails and bugs” in category list
Actual:
“fails and bugs” is listed. Word “Errors” is not listed anywhere
Now, the reason for this might be that the field on the same page (id=”new-tag-post_tag” ) handles the commas to store separate tags, and that works as specified. Perhaps the category -field handling just uses the same functionality. And looks like to me that it is a copy-paste accident. Perhaps not tested, or then again maybe tested, but results are neglected due to well known reasons: it’s not important, user won’t do that etc.Well, this user did đ
As you can see, it is sometimes crucial to select a right tool. Even to stick to it, regardless on how awkward and painful it might feel. I just had to open with this scene, it is anyhow from one of my all time favorite movies. The book it is based on, is definitely one of my top 5:s.
We’ve all been there. It’s late night, we’re out in the park, having fun and all we have left is bottle of wine. And of course the corkscrew is nowhere to be found. So you start using your imagination. You might have a normal screw and a screwdriver, maybe a pair of tongs, too, you might be carrying a multi-tool, for what I know. Or not. The cork stays in the bottle.
You go through your pockets again, ask your friends, someone says that all he’g got is a pen, other one offers you a rock.
You see where I’m going here? A pen is mightier than a rock? Well, at least now it is.
Now you could open the bottle by smashing the head to a rock. Or smashing the rock to the head of the bottle. That might work, too. In the other hand, there’s always risks of getting bottle broken so, that the glass gets inside the bottle. Besides, that will create a mess in the grass and I a devoted dog owner and animal lover hate when people break bottles or other glass and leave the stuff there. Besides, people can get hurt too, for real.
So that leaves you the pen, right. You could write a letter – I know, it’s old school, but it’s nice sometimes, for real – to someone with a corkscrew to drop by. What’s there to loose? You got the whole weekend ahead of you (Did I mention it is a Friday night?) Or you could rob a corkscrew store with it, not the world’s best idea, though, giving it to be late night and the stores are all closed.
You could also take the pen and push the cork inside the bottle. That actually does work. You might get to spill some, but then again, at least there isn’t going to be shattered glass anywhere for the paws of the two to four legged friends. Notice I left a place for three legged dogs or cats, even squirrels.
So, you take the pen and grab the bottle. Your hands are getting a bit sweaty so you what your sleeve around the bottle. It keeps it in its place. Not completely, but firm enough. You take a breath.
You push the pen against the cork and push. Nothing happens, except the veins in your temples seems to be exploding, your face turns to red and the pen hurts your palm. A lot. You let go for awhile, and try again. No change to the situation. Cork is till on and you seem to be screwed.
A friend of yours, the one that has taken one more than you, mumbles something and offers you the stone from his hand. You look at him and smile and are about to shake your head, but change your mind and take the stone.
It is smooth on the other side, the side agains your palms has some edges and it feels, if not cold, then at least cool. You take the stone, push the bottle against the ground and hold it between your feet and hold the pen on your other hand against the cork. Then you slowly but firmly hammer the pen inside the bottle with the stone and finally, you’re done. Everything’s fine again, you drink the wine, get in to the night and wake up next morning with a hangover and some blurry memories. You might even end up having fun, who knows.
What I mean here is that you should choose your tools, for real. First of all you need to know that you have a need for a tool, then you need to check what requirements you have for it, then you need to find it. Thanks to the interwebs, it is fairly easy nowadays. After finding the tools, take several, and use them for awhile in the situation needed. So to say, evaluate them.
If you run into problems with the tool (you should, for real, even a sledgehammer needs some maintenance), try to find out if anybody has had the same issues. Most likely you’re not alone.
Check the maintenance costs. If you use more time maintaining the tool than the flaky tests, you probably have the wrong tool. Regardless on how good it looks, sounds or feels.
And once and for all; don’t get stuck with the first evaluation, don’t get stuck with your evaluation choice, either. In case the tool loses its focus and usability, make sure you can move away from it.
I myself are at the moment in that kind of situation: using a multitool with a gentle learning curve, but the maintenance and the license is starting to feel bad. It was a tool I was familiar with, a tool I’ve used for years in the previous companies, and it used to be an open source tool. They ended the open source path last year (if I remember correctly) and otherwise turned the usability a bit more worse, too.
So I’m considering moving the tests to another multitool, an open source based tool with steeper learning curve, but a considerably larger user group. Actually, I’ve done my consideration, all I need to do now is to transfer and modify the current tests from the first tool to the second one.
I’ve been using XMind a lot for mindmapping. It has fulfilled my needs somewhat well, at least I cannot come up with anything to nag about from the top of my head.
Except that there is only *.deb -package available for Linux. For the love of <pick your favorite deity here>. Not all of us are using Ubuntu. Don’t get me wrong, Ubuntu is ok to use. I’m not using it due to our servers are running CentOS. To get to know the issues you might run into when dealing with production, you should be using same (or at least one that is based on the same architecture) operating system on your workstation. So i do have Fedora, which is not CentOS, but close enough. I do admit being lazy here, there is CentOS -desktop available, but to get the tools needed to work with that is so much harder than with Fedora, that I did not even try this time. I might do that in the future, though.
One thing first. WordPress app seems not to be able to send the image in case I press settings when it is uploading. Hence the rectangle below.
This was actually my message. They ought to do a movie out of this.
I know they’ve done Blade Runner (Which is brilliant) and they’re planning on a sequel, but there’s few angles in the book you could consider. One of them being the Voight-Kampff empathy test. Which also strikes me, as a tester.
Well, of course everything always goes as planned. Or then again, of course not. And when they don’t go the way you thought, planned or wanted, you might get a temptation to just let it go. But letting go would let you only quit, not finish. Determination or stubbornness – call it what you will – you need it. Especially when handling things that are voluntary and not always easy to squeeze in to your day.
That being said, I’ve been struggling. Anyhow, here’s a small report on things I’ve managed to accomplish so far.
Day 7: Find an accessibility bug.
I suppose it was this one that broke my flow. First of all, I came in a day late, dollar short. Second thing was that I’ve never done any accessibility testing. That, me being in the case, leads some  issues.
I have always been ‘try first, stumble and read the manual to get to know what did I do wrong’ -type of guy. This time was no exception. I ended up reading few short sentences on the  W3 accessibility testing wiki and rushed my way to turn on accessibility features on my notebook. After fooling around for awhile I got nowhere, if not to the land of frustration. The laptop is old and slow and it had difficulties to read the web pages in Finnish so that I would actually understand. That was due to the lack of memory (most likely) and bad/lacking support of the chipset. I’m running CloudReady/Chromebook OS on Asus EeePC with Intel Atom chipset. It fails to work on most of the OS I’ve tried.
So I gave up.
You see, testing is my profession and therefore it actually is my passion. But not on my spare time. I have divided my days between work and non-work, and it suits me fine. It just don’t help doing test related tasks (regardless how fun they are :D) on my spare time. It’s not that I wouldn’t like, but as I have my priorities at work, I also have them when I’m at home. And in that kind of issues, it actually is really easy to quit. Which I did.
But now I went and read a bit more on accessibility testing and noticed that there is few semi-automated tools listed on the page. I suppose I’ll give them a try at work on some of our interfaces. Semi automation is still partly automation (which I do like a lot) and I might also find something worthwhile. You never know where you end up when you start testing without a decent specification. And even with a spec you might find yourself in between rock and a weird place.
My plan was to write about the other tests I did (but did not write about), but this post starts to get long enough, I’ll have to fill the other blanks later on.
I know, every excuse is just an excuse on failing to prioritise, but sometimes the prioritising actually gets you nailed down to something where you just have to concentrate and work on. This week has been one of those.
So to say, releases flowing in from doors and windows and I find myself testing (or wanting to test) them all.
Which of course has meant that I haven’t been able to fulfil the 30 Days of Testing assignments. Currently I am lagging behind 1½ – 2 days. My plan is to get back on the track during this week, anyhow, meaning that I’ll do something during the weekend.
This is just to inform that I am aware of the situation.
Besides that, I ended up going through this tutorial yesterday and realised that this mochaJs-thing seems to be a neat way to learn JavaScript and some test development đ I might even give it a more thorough run later on. I also discussed with the author (Viktor Johansson) on collaborating and creating some neat tutorial with BDD & Robot Framework. Oh, and managed to install Skype on the Fedora, which is always an accomplishment đ
Last week I joined 30 Days Of Testing -challenge that was organized by Ministry of Testing. And I have to admit it has been fun. Besides that I have found myself doing things I should’ve been doing all the time, I’ve also done something new, too.
First of all the ‘Listen to a testing podcast‘ was very revealing as well as fruitful. I’ve been now listening to the Test Talks while riding bike to and from work and found out new ideas, new ways to think about testing. It is really refreshing to notice that, even though I’ve been working as a single tester (and I’ve done that on purpose, also)  quite a lot for the past years, there’s a community out there. People thinking, if not like me, but at least similar kind of issues and situations that I am facing in my profession. So to say, it has been a blast to notice that đ
Yesterday’s challenge was to do a ‘Crazy Test’. So, what I did was the following:
Use Siri to start music (‘Play music from artist Metallica‘)
Wait until Siri gives you a ping that it has received the command (but before it confirms what it is about to do)
Put on reverse gear
Now, my expected result would be that I could reverse in the car by watching the rear camera and listening to music (at this example, Metallica). Of course it didn’t do anything like that. I received the ping from Siri to indicate that it had received my message, but when the rear camera was switched on, the command was weirdly gone. I could reproduce the behavior even when making a phone call request.
Now one might thing it is a safety feature. But I can’t think it that way, for me it feels like a bug. Software is not working the way I expect it to do. If I turn on the phone and call manually and start to reverse, the call is connected. As well when it comes to music. I can pretty well listen to music (even Metallica) and reverse at the same time.
Now, is this a race condition, or something else? Where is the problem? In Siri/Apple CarPlay? In the API between car and carplay? Has this scenario been tested? Does not seem likely. Or if it has been tested, perhaps the results have been ignored in order to get the software out in time. Â Or the responsibility of the behavior has not been clear; should it be car that takes care of this, or the phone?
You might also say (and I wouldn’t argue against that) that this wasn’t particularly crazy test. More or less exploratory boundary/edge case. I was not driving my car sideways on the ice, or 110 Km/h on the highway. I don’t actually care. It was crazy enough for me. Plus that I noticed something new, learned something new, which I suppose should be the main point in life and work altogether. i mean, you can never be crazy enough, not unless you learn more and get crazier.
Yesterday’s challenge was to listen to a testing podcast. So I went to iTunes Store, which is the de facto standard when it come to podcasts, at least in my books. In fact, the sole reason for me using iPhone, to be honest. Otherwise I don’t care (not any more) which manufacturer or OS my phone has. After testing Symbian (Nokia & SonyEricsson used that OS in their phones) and using Android & iOS, I’m getting more and more aware that most of them have their good and bad downsides (yes, that’s what I meant).
I do have, sometimes irritating, tendency to get lost while babbling. And that is precisely what happened up there. Now I gather myself and get back to the track.
So, I found the podcast. It is Joe Colantonio’s Test Talk. A series of podcasts on testing and test automation. Since the subject is somewhat intriguing, I ended up subscribing to that, too. Seems to be long enough episodes to listen during the way to work, whether I ride my bike or the subway.
I ended up listening the episode where Rosie Sherry was attending as guest. And I was positively surprised. Not to mean that I was expecting something lousy, but the thing is that the episode made me think. Which is always a good thing. Regardless on what I said yesterday.
She was talking the importance of testing instead of testing tools, and I found myself agreeing. Even though this blog has been about the tools, I realised that my main focus has been telling that regardless of the tools, the skill of testing is what matters. Or at least that is what I should’ve been saying; for that is what I actually mean about the blunt instruments. They are just tools we use, tools in order to help us provide the knowledge about the behaviour (sometimes even vision of quality) of the software we’re testing. At least I think I should be pushing my writing to that one.
What I mean here is that subconsciously I have thought the same way (Now I hope I got it right, too), but not being completely aware of that. It’s not the tools, it’s the way you use them.
Funny thing is that the other day, few days ago, I got a question in Twitter from a former colleague about what SW test automation books he should be reading. And all I could say was ‘How Google Tests Software’, ‘ATDD by Example’ & ‘Lessons learned in Software Testing’. To be honest, I don’t know much more. I’ve been using the tools, not reading about them. And that has always been my approach in life, in general. Experiment, fix on the run, read when you need. I don’t read the manuals, not before I don’t know what to do. Sometimes I read them too late, maybe too shallowly, and skip some important stuff. I just don’t seem to get myself working the other way. I am an experimental tester, as it seems.
Besides the tools, Joe lifted up also the communities Rosie has been founding: The Ministry Of Testing, Testing Dojo & Software Testing Club. And immediately (after getting to work) I found myself browsing more information about the Dojo and the TestBash happenings etc. I was hooked, there’s a community of testers! Seems to be I’ve been living in my own man -cave for few years now. Let’s see what the communities and the future brings up. At least now I feel excited đ
So, thanks for Rosie & Joe for showing me one more door to the world of testing !