qa

Some days of testing

/ jankka / Leave a comment

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.

Advertisement

Crazy Testing

/ jankka / Leave a comment

 

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:

  1. Connect iPhone to the car with Apple CarPlay
  2. Use Siri to start music (‘Play music from artist Metallica‘)
  3. Wait until Siri gives you a ping that it has received the command (but before it confirms what it is about to do)
  4. 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.

And I’d like to automate that test. For real 😀

 

 

Testing in popular culture

/ jankka / 1 Comment

This morning, while browsing for a podcast for this 30 Days Of testing -challenge, I found myself thinking. Yes I know, it’s a harsh condition and I try to avoid it regularly, but one can’t help oneself. Not when you’re born this way, you know, with brains and all.

Anyhow, I started thinking, who was the test engineer in Starfleet Academy that tested Kobayashi Maru? Clearly, for it being a computer scenario, it should’ve been tested. How otherwise could’ve James T. Kirk beaten it, even by cheating? And furthermore, in the ship, there’s only operators available, mainly. Someone must have been done a hell of a coding in order to get the USS Enterprise to get around the orbit in the first place. And, as we all know, when there’s a developer there should be a tester available.

Which brings me to this: Is there testing involved in popular culture? In the ‘Saving Matt Damon’ – movie, The Martian (which by the way is a great book, not as good movie, Ridley Scott blew it), NASA does skip the tests, based on risk assessment, apparently,  in order to send the supplies to the Mars a bit more earlier, even the length of the tests is slightly discussed. That’s most likely due to that the author of the book is, if I recall correctly, a SW engineer.

But is there more QA/Test references in popular culture? If not, why not? We’re working on a field of SW (Well, HW needs to be tested, too, but that’s another story) and the field gets bigger and bigger all the time. It is clearly so, nowadays, that hackers and developers can actually tell people what their profession is and people in general have some sort of clue what they are doing for living.

Me, in the other hand, if I tell my profession to my relatives, am faced with a puzzled smile and slightly confused glare. Which I can buy, nobody seems to know what this testing is and what it is all about. Getting more testing stories in popular culture would actually help a bit.

It would be interesting to know, if I’m wrong here. What I know, is the narrow field of popular culture I’ve been following. I might be completely wrong, which is always all so human.

By the way, did you know that the Chernobyl disaster  was caused by running tests? Some experiments, as it seems. Sounds slightly like exploratory testing to me. It’s always a refreshing thought when someone bashes around the nuclear plant systems.

Just one more: Who was the guy, who tested the Death Star particle exhaust vents security? And who approved the solution?

Note: And the answer comes from the  deeps of Twitter:

Thanks, @Marcel_Gehlen

PS. I did find the podcast, too.

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

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.

Top 10 Excuses Made by Programmers

/ jankka / Leave a comment

Top 10 Excuses Made by Programmers

Ever since I took my first ISEB -certificate I found this list a fascinating one. Need to actually to get a poll somewhere here to measure the accuracy of the grades in that list in real qa-life. Which seems to be somewhat something else than the real life (the one we do live away from keyboard/touch screen).

I myself see the ‘Works on my machine’ and ‘That’s weird…’ as the funniest 😀

10. “I haven’t touched that module in weeks!”

9. “It must be a hardware problem.”

8. “Somebody must have changed my code.”

7. “Did you check for a virus on your system?”

6. “You must have the wrong version.”

5. “That’s weird…”

4. “There must be something wrong with your data”

3. “It’s never done that before.”

2. “It worked yesterday.”

1. “It works on my machine”

And it seems there’s even more thorough list in here:

http://vbcity.com/forums/t/44234.aspx

Blunt Instruments Of Testing

/ jankka / Leave a comment

Welcome to my blog. This blog is attended to be a placeholder of thought concerning Software Testing and test tools particularly. Most likely – so far as I know which kind of writer I am – the blog posts will vary somewhere around the big topic.

As a professional tester and a wannabe writer I see writing as part of the thought process in order to organize my ideas. It’s kind of similar tool than discussion with colleagues or friends sometimes can be. So at least for me that’s one of the professional tools a software tester can use. For me writing a test journal is a crucial part of working, and it helps me to organize my memories on my work assignments, which sometimes can come and go and change rather rapidly.

I will be forming this blog every now and then and most likely to write as often as possible. We’ll see how far I get with this approach.