Fail is for the Winners Part One: Neglected Bugs

“Ever tried. Ever failed. No matter. Try again. Fail again. Fail better” – Samuel Beckett

Sometimes software testing is like a roller-coaster ride: fails (bugs) make you happy, but at the same time sad, and… to make matters worse: sometimes you may fail by reporting something that is not actually a bug.

At the very start of my work, I was scared to file a bug in order to avoid a… failure. How would I feel like if it actually figures out to be not a bug, but a feature? Maybe I’m just not aware of how the software must work.

Later on, I got braver and braver…

I have filed more than 100 bugs in past 3 months. In this new project we just started, I’m the tester who has filed the biggest amount of bugs. Does it make me the best tester? No.

The best tester is the one who gets the most bugs fixed.

Of course, filing a lot of important bugs gives you a bigger chance of actually getting a lot fixed, but… another side of this is that there will be a lot of Closed bugs which will be neglected and it makes you feel a little bit stupid for filing them after developer’s responses like “it works as designed”, or, “cannot reproduce”.

It takes time and practice to learn how to deal with them, but…

Don’t get down because your bugs were neglected. If there is a chance – file it as a task or enhancement. Even if bugs sometimes get closed for various reasons, it is always very useful to put attention on them. What you are doing is great and maybe first 2 times that bug will roughly be marked as Works as Designed, but in future releases someone will take it as an amazing suggestion to improve the software.

And, remember, don’t let failures bring you down. Don’t be scared of being laughed at. It would be way worse not to do anything and sit silent.

There is only one way to become a professional at what you do: Fail.
Fail a lot and never stop moving forward. Only leaving your comfort zone, you will reach some of the most amazing things in the world…

How to Attract Interesting Bugs: Use your Talents and Be a Software Terrorist

The release was supposed to be tomorrow, and, today I found a really interesting bug. I think it is the bug that I’m the most proud of so far… or at least today. (: 

I will tell what that bug was like in this post, but before that I must say how my colleagues reacted after getting an e-mail with developer’s commit and bug’s description: “What? Why did you do that? How did you manage to find that bug?”. And the answer is pretty simple: I try to make my testing nice and not monotonous…

Collect the best pictures: art, photography, travel, whatever you like and use it when you need to test something with Insert Picture, or, with image files in general. 

This seems so unimportant, right? Who cares what kind of picture you insert while testing. But, hey! You get tired of those default Windows pictures with tulips or penguins. And, let me tell you a secret – a picture which you like looking at can do wonders. Your imagination strikes with all this creativity/nice view in the image file. You suddenly feel happier and testing is more fun. To make it even more interesting, you could save quite many images you love with random names, so each time inserting an image you wouldn’t know what you are inserting exactly and get a bit surprised. 

Practice your foreign language while testing. 

Modifying a file (usually it’s a text modification) may seem such a boring task – just type in ‘Aaaaa’ or any other ‘asafsfjdsf’. So dull, repetitive and what a mess it creates when you try to save a lot of files with random file names like that and you are never sure whether this random name is unique. Then again you need to change it, oh, boy, so annoying. 
One way could be to think of interesting words, people to name your files, but…
Why not to practice your foreign language skills? Try to use testing as a chance to repeat newly learned words and just have fun while doing so. 🙂 It will definitely be more fun to write a funny word in a language you are studying instead of ‘Aaaa’. 🙂

Take inspiration from music.

If you lack of words in a foreign language, why not to listen to a radio of that language you are learning while testing? Then when cannot think of any word – just write down the one you hear in the song. In general, music can help to create a good vibe and mood for testing. However, this is not for everyone (for example, I cannot listen to it all the time, I need to get silence, but sometimes it really helps to refresh my mind). 

Be a Software Terrorist. 

A what? It’s time to tell about my lovely bug which made our release shift even more and a developer send me a message saying “You’re a terrorist” (I am not a terrorist, just a software terrorist…). 🙂
Try things out, have fun and you will find bugs like these… 


I turned on the software, inserted a lovely travel photo as a background picture, and, thought of a song I just heard on a Swedish radio (I am just a beginner, and, they say it’s really good to hear the language constantly, so I try to listen even if I understand only a few words). It had lyrics like: “wherever i turn in the world i’m standing here with empty hands”, so, I thought that this time my modification will be “empty hands”, but in Swedish. I wrote: “tomma hander” (without Swedish characters). Then I wanted to check some shortcuts and pressed Ctrl and got surprised. We test integration of products like that with a file system product of ours. And, there showed up the login to our file system. This is weird, I thought. Ctrl itself should not make any dialogs open. After log in there came integrated Open dialog… So, basically, it meant that if a user wants to save the new document with “tomma hander” and presses Ctrl+S he won’t be suggested to Save the file, but Open it from that file system product. This may be very annoying for a user working with large files and using shortcuts. 
I would have never found it if I typed in ‘asdajdaskdj’… The bug itself was as follows:
every time typing the letter o in the document (either it alone, or, in the text) and then pressing Ctrl key would work as Ctrl+O and give log in to our software and integrated Open dialog. 

A secret of a happy and productive tester: be not only passionate about testing, but fuel it with other passions you have in life. 


Software Release: False Alarms, Stress before the Deadline, and, Prospering Bugs

I did my first false alarm! 

We are working on this integration project for way longer than we thought to work. Bugs kept appearing, or, coming back to life. Finally, on our _4th_ final testing cycle (all cycles before failed), we got a build with a good feeling that it may be the release candidate build. Maybe it was the historical day with test plans actually passing! 

After a delayed release all the team is tired: developers lose hope to fix bugs and leave them for further releases, testers want to start testing something new as it gets a bit repetitious, and, everyone in general feels a bit low. Every new bug is way more painful if the deadline for release is coming up. Here comes the psychological crisis: developers feel like their coding is still not working after all this time and are a bit bitter on that, while testers…. Testers don’t get any support for finding bugs at this stage, a new bug is like a curse that nobody wants to have (even if it is silently valued: having in mind that the issue won’t be there after the release after the fix). But as I talked in previous post – being a software tester can give you a lot of psychology lessons, too! 

Also, when release is nearby every bug matters. If there comes a serious bug to be fixed in this release – you must react as soon as possible, let all the development and test team know about it. 

So, I did. I was testing a so called 0 bugs build today, and, well… one bug which had to be fixed in this build seemed to reproduce. It was weird that one case of it was fixed and another wasn’t, but I was trying to be very quick and inform the team about recurring issue. I sent an e-mail saying ‘BAD NEWS. This bug reproduces. I’m sorry!’. 

After I sent it and I reopened a bug (which was very painful as it was our release candidate and it was not anymore a real release candidate), I got concerned. How come it was fixed for one case, but not for the other… I ended up re-checking, re-installing everything and making my machine as fresh as possible. For my biggest horror: it actually was fixed, and, before my machine was not clean enough (had some left influence from previous builds). I wanted to bury my head into the ground: I just wrote a response to that e-mail I sent ‘Nevermind, False Alarm, I’m so sorry’. Dev lead replied that ‘It feels that release is coming… ‘. 

However, I actually found a real issue later on. This time I first checked a few times before filing it. And, well, it’s horrible, but, I destroyed the dream that this build was a release candidate. But it’s my job and it’s better to find it now than after the release. 

So, some bugs must be fixed, but… there are loads of bugs that are ‘pushed’ to the further releases as at the stage before the release date it’s too risky to fix them: may ruin something else and cause harm. That’s how we get those bugs that are always there, everyone is aware of them, and… they keep getting pushed for the further releases. 


Psychology of a Software Tester: Expectations and Moral Lessons

Even if at the very start my colleagues laughed at me when I felt bad that our software is ‘buggy’ telling me that ‘it’s our job, silly, be glad’, but… I still have that good versus bad fight inside of me. It is good that I find something bad which means I work pretty well, however, I work for a company, for that specific project, for the specific software. Is it bad if the software that I work on (our product) is bad? 

I am not the only one with questions like that. Understanding how common this ‘crisis’ is between testers, Cem Kaner, Jack Falk, Hung Q. Nguyen in their book ‘Testing Computer Software’ gave a lovely introduction which even had a few psychology notes there. I am going to share some of my findings. 

You get what you expect. 

Imagine that you’re a scientist and you just discovered a new wonderful theory. You have a lot of methods which you could apply to prove that it’s correct. However, take a minute, think about it… Would you choose methods which could make your theory fail? 
There actually has been a research about how intelligent experimenters unconsciously avoid test experiments which show that their ideas are wrong (Rosenthal, 1966). 
Similar example showing how expectations rule our mind is proof reading. We expect words to be written with no typos and we manage to raed wdors the way we expect them to be.
Exactly the same thing happens with a software tester…. If you have an attitude that your software is good – you won’t find any bugs, you will miss the ones that actually are there and take them as details or accidents.

You have to want software to fail. 

This sounds rough. I know. It is your software, you work on its quality and you want it to be bug-free. But your attitude must be very strict and judging – in order to make your software really good, you must put high standards on it.
It just reminded of a quote which I liked way before I was a software tester (maybe it’s a sign!) by Baltasar Gracian: 

Attempt easy tasks as if they were difficult, and difficult as if they were easy; in the one case that confidence may not fall asleep, in the other that it may not be dismayed.

You can do your job well (even if it will never be perfect). 

There are always bugs left. This is a one more ‘sore’ point for testers. You will never catch them all. Therefore, you will never be a perfect software tester. You will never do your job completely, but… you can do it really well. 

Sometimes it’s hard, but hey… Being a software tester is way more than catching bugs, it teaches you… life. It may be difficult at times, but noticing problematic areas in software is actually a path to a better software, and, even if testing does not win you any popularity contests, but secretly, everyone is grateful that you point out the defects which could have caused a lot of trouble.