Non-tester, come to testing meetups! – Day 26 of 30 Days of Testing


In one of previous challenges I created a post on how to find testing events. Today’s challenge is half done knowing which event you’d like to invite people to.

So, to any of non-testers reading this, I would like to kindly invite you to come to Budapest’s QA meetup’s palinQA events! Upcoming one will happen in September.

Great part about this meetup is that each time we have some non-testers joining us. A lot of topics are very interesting even if you’re not a tester. A great example of this is the latest meetup we had on Making a QA Career. Not only that the audience had testers who wanted to know more about job opportunities, but also people who are interested in the QA career, or, even non-testers (who possibly won’t change their career) come to listen to what qualities should testers have and how it feels to start a career as a tester.

Join a testing meetup and come to get to know the breed of testers: how they feel, what challenges they face and it will definitely give some insight to their work. The more insight there is – the better team we can create.


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. 

In the land of bugs or why you shouldn’t blame yourself for missing a bug

2 months that I’m a software tester. I have learned a lot, but there is a lot of other things to be learned. 

In the previous post I was talking about the relationship between developers and testers. Now, I think it’s time to talk about problems with other testers, and, inner hurricanes of emotions. 

You won’t catch all bugs. It may sound sad, it may break your perfectionist’s heart, and, on some level, you realize that you will never be perfect at your job… However, this is the beauty of being a tester – there is no comfort zone. The learning is constant and sometimes it does hurt. Sometimes you do shout on yourself and regret not checking something. 

There are pluses and minuses of working in a team of testers with testing cycles. I must admit that some testers make me bitter by skipping quite important bugs. They just seem to ‘float on the surface’ of the test plan and don’t put too much of attention in actually finding bugs. But… it’s good to work in a team and get the same thing tested by several people. This prevents possible major bugs of being unnoticed. 

It breaks my heart when the test plan I did before and all its bugs got fixed, fails for some other tester. I feel like I did not notice something, or, did not put too much of importance to something. However, there are a few main things to remember why you shouldn’t be angry on yourself for letting the bug pass unnoticed:

New builds may cause trouble.
You shouldn’t blame yourself for not finding something that was not even alive in a previous build. Things happen, and, sometimes, by trying to fix something – we ruin something else. 

Importance of the bug is subjective. 
Of course, you should write down everything. However, at times the bug seems so tiny, that you consider it as a feature. You simply take it that it works this way. For example, you may think that in that application hyperlink does not get created automatically. Then after a while someone else tests the same thing and files the bug about it. It gets fixed. The feeling is not too good as you were aware of it, but thought that it’s not important (as there was an obvious workaround and manual creation). 

In conclusion, bugs are everywhere. There are lots of bugs, but you must know which ones are the most important and must be fixed for this release. And, I found this lovely quote in a book called Testing Computer Software by Cem Kaner, Jack Falk,and, Hung Q. Nguyen: 

Love Story between Software Testers and Developers

It has been a pretty hectic period of time in my life: loads of bugs, and, experience. I’ve been thinking what I should write this post about as at the same time I have so little, but so much to tell that I don’t know where to start. After work, I decided that this day and my feelings about it would be best described in a post about a relationship… Between testers and developers…

The Love and Hate Relationship Between Testers and Developers

From my first day, developers for me were an object of investigation. I would try to get what kind of relationship I should expect us to have (sounds serious, doesn’t it?). I am a pretty funny and silly person at times and my contact with developers has been somehow… awkward. I would talk about my beloved bugs with lots of inner passion, love, and, laugh… I guess this may be called a bit unprofessional, but it’s me, and, I love my job with all its problems which I take as simple challenges, and, allow myself to joke around. However, this sometimes creates misunderstandings and developers are not used to see someone fight for their bug so much. 

1. Developers may hate testers only in two cases: 
    a) bug was found
    b) bug was not found
To sum this up: no outcome is good enough. 

Of course, we are a team. We try to create bug-free software and seek for the best product possible.

However, in the case a) usual scenario is like this: a developer writes to the tester asking whether it really is our problem. Maybe we could blame something else? Maybe it was there before, not only in this release. Check this, and, that, and, this also more.
While dev leader also always asks us how many bugs we are going to find in the future, how many they should expect – my answer was very simple: as many as you have done in your code (he is always very confident, but that time he blushed and got silent). 
In general, developers are lazy. They try to avoid work as much as possible. Sometimes testers have to explain 5 times and share screen to make them fix bugs. Also, it happens that they don’t bother to read notes, details, comments, on bugs we give them. Just reads the start and assumes. Afterwards, marks it as cannot reproduce without even trying. Or, another possibility is, that they blindly follow steps and don’t even waste time to try to get the same result in a different way which is quite obvious, but it’s not written down. 
I must admit that in a case, I hate developers a little bit, too (I love them more, though!). 

In the case b) as I mentioned before… Testers are going to be blamed for leftover bugs. Developers may just put all responsibility on our tiny shoulders by saying: your fault that you did not see that obvious bug and now users suffer, bad tester.

2. Developers and testers actually silently love each other: for finding bugs, fixing them, and, making a good product together.

Today I got so amazed by our developers as they fixed so many new defects quickly. Of course, my happiness did not last too long as some of their fixes had to be rejected and did not work properly. However, I really feel that it’s magical that they manage to fix those bugs that we just write down. Some bugs are very tricky, and, developers get to know them, understand them, find their reasons, and, fix them. I feel happy when my bugs get attention, are taken seriously, and, are taken care of!

And, even if they will never admit that because of 1 a), but… I believe that they secretly love testers back. A little bit. For helping them improve and giving a lot of interesting riddles (aka bugs) to solve. 

I am not sure whether any film company will buy a script for a movie about a relationship like that, but, I find it fascinating. 

Responsibility in Software Testing

After people hear what I actually do, they somehow start thinking that maybe they should change their field and go into testing as it seems so easy:
Seriously, how come this job needs no pre-requirements, no degrees, anyone can do it, and, yet, it gets paid pretty well?

No. Not everyone can be a software tester. Not only you have to think constantly and be technology-friendly, but the main thing a tester has to deal with is… responsibility. 

I got this developer lunch buddy. We somehow synchronized our patterns and meet during the lunch break. Being all so curious, I asked him what he thinks of testers in general. Is it true that some developers look to testers from high above? Of course, he was not as emotional as a female and said that he does not feel any hard feelings on testers. However, to be honest, there are only a few good testers. Most of the testers just work… to work. Not to name the teams of countries (somehow he got bad experience with certain nationalities), but as he says “I don’t understand, how come for them everything passes, and, whatever I run – it does not work?”. 

If you want an easy life, you could just write pass on every single test case and act that everything works fine, or, as it worked in a previous release. Then you would just sit in the office, maybe playing solitaire or sitting on facebook, mark test plans as pass, and, live happily ever after. Not forever, though. Product gets released, users notice bugs, and… it comes back to you. 

Passing every test plan is somehow an extreme case. However, it can be also the case, that a tester bumps into just main and obvious bugs, or, sticks to the test plan if there is one. The scariest part is that:

Tester is responsible for a bug he did not notice. 

Even if a developer is the one who created the software, but… When it comes to testing and getting paid for that – everyone hopes for the best job possible. Then developers just take reported bugs one by one and fix them. Developers do not report new bugs as they trust testers. This means that all bugs that are left in the software first of all are because of lousy testers. 

When I started out, I would just blindly get stuck to the test plan. I was scared to play around. Last week, my manager wrote to me about a project I worked on my first week. It figures there was a test plan on 2014 version of software installed together with version of 2013. I did that smoke test and it passed, nothing new. And now support says that users say that integration for 2013 stops working when 2014 is installed! Manager is like “Did you check 2013? It was not written but I take it as kind of a common sense to do that.”. My answer was really simple “My common sense was non-existent at the very start. I did what was written, not something more.”. After a day he made me redo that test on 2013. It passed. It figures that I was lucky this time: users themselves did something wrong (later reported that it works again). I said to my manager that “oh well, magic happens”. And his reply was: “There is no magic in software.”.

After all this we come to a one more important thing. Managers just plan things, developers just fix things, and, well…

Testers need to have a big picture of the software and work for it to be bug-free themselves.

This means that a tester cannot just be stuck with a test plan. A tester needs to look around and think what he’s testing, what else could be somehow complicated. Even if test plans have a time limit, but… We work for a bug-free software and have to work hard to achieve it.  

One more thing is that only testers are like users pre-release. Usually, the bosses are so high above that they don’t even write requirements what they hope from the software. Developers don’t know themselves what bosses want. Manager just makes sure that we all are getting along. 

Testers have to decide how software is going to be. 

Of course, it comes with discussions with management and developers. However, we write bugs about changes that need to be made, we make suggestions, and, we get asked even by developers – how should it work. This is a difficult task at times as we would like just to work and not to think too much. However, creation of software is a long process. 

To sum everything up, there is no easy life in testing. If you want to be a good tester, sometimes you will spend hours trying to figure out something that may not be working. And, you cannot trust previous testers – maybe they are one of those always pass people who live comfortable lives. 

Bugs come in through open Windows

Today I’m in a deep sorrow. I lost those two my beloved weirdo bugs which have magical powers.

I think it’s time for me to tell you all their beauty and my silliness. I was testing integration with Microsoft Excel, and, our product has its own ribbon when add-in is installed. In that add-in there is special Insert Object button. That’s the place where bugs decided to live and prosper. After inserting an object which is also an Excel file a blank Excel document would open up, and, cause a lot of trouble: closing it you would close all the file and file’s window would become blank, closing that blank window would end up in Excel not responding. The beauty was that not with all files this would happen. It would just be sort of random!

The second bug was with another part of files who usually did not have the first bug effecting them. So, it seems that everything works great: object is inserted and no blank window appeared. Dream on. Dragging the object Excel’s blank window would open up and flash. Creepy, right?

As a noob software tester, I checked the previous release with Excel 2010, and, of course, there were no bugs like that. I got so happy  and filed them even if later on I was confused several times when bugs did not reproduce. 

Today software developer writes to me and breaks my heart (of course, he is young, smart, and, cute… what else guys like that can do than break hearts?). It figures out that non-integrated Excel cannot handle its own Excel files inserted as objects. So, at least one bug, is not our problem, but Excel’s. Another bug is sort of a “son” of the previous one. Our add-in even solves the problem somehow for some files. So, that blank page does not show up, but flashing appears. Our guess is that it’s just an effect of this “father” bug. 

Of course, I wouldn’t be me if I did not say to a developer that he made me sad, and, I feel like a mother who just figured out that her two kids are actually not hers.  Our scrum calls are more than formal, but today that developer could not hold himself and started laughing when telling about discussing the bugs with me. 

To sum up, the lesson I’ve learned today:
It’s not always your products fault, check the native application, because Bugs come in through open Windows, and, well, everything else that’s made by Microsoft. 

It’s raining bugs… Hallelujah?

After a long wait, my first bug was discovered. First bug filed. Though, this made me have mixed feelings.

Of course, I am very happy, indeed, to have found it. However, our new build is so buggy, that it even hurts a bit for me to file a new bug. What a pain it is for developers, and, I want our product to work perfectly. I shared those mixed happiness/sadness feelings with my fellow colleagues just to make them burst from laughter: “Oh, new software testers, they are so naive and still thinking about developers… Be happy that you found a bug. It’s your job. You do that, and, you’ll never be friends with developers.” 

After that first bug I found 4 more undiscovered ones… And, there is no light at the end of the tunnel yet! This build is very buggy and some bugs are parents to others… One tiny bug can go a long way!

I feel like today was my first real working day. I am tired, it was a busy day and lots of bugs are still waiting to be put in their tiny cages… I’ve learned a lot.

My last today’s bug was such a beautiful one! It was basically that all integrated dialogs, for example, open a file, had it… Imagine you press on open, a dialog appears asking you to select a file. There is a quick search field. You enter something, for example, ‘*.doc’ and by pressing run search, your documents with .doc should be nicely put in that window. I wrote it in, and, all the software got unresponsive. It just got all disabled. Even the red exit cross was unresponsive and disabled. What a wonderful bug! Made all the application somehow crash. Brilliant. I am truly proud that I found it. 

Housekeeping in testing

During my first job interview, I was overly-excited and happy. I wanted to become a software tester. I liked the tasks given, the questions asked. Then I decided that even if job market is not for me – I at least enjoy going to job interviews! I wish it was paid… 

One of the questions was about monotony at work. They asked me whether I think the job is going to be boring. Of course, I said no way and told them how cool it is to be a software tester! What kind of monotony are we talking about? It’s exciting, it’s out-of-the-box, it’s dynamic. My then-interviewer (now-boss) calmly replied that some days can actually be boring… Now I get it!

We finished our old-project and had to start another integration with different software. Excitingly, I prepared my fresh Windows 8 virtual machine… I turned on the software, and… integration is not there. Hmm, I try re-installing the build – same thing. Then, we figure out, that the build is not working. With no integration in software – we cannot do any integration testing… 

Now it has been 2 days with no build (writing this I feel as sad as if it was ‘2 days with no food…’). This means it’s a nightmare for software developers who are struggling to create a new one, and… It’s a nightmare for testers, too. We are working as secretaries now! Sooner or later this had to be done, but, at least it could have been between the breaks of testing. We do… housekeeping.

Housekeeping in testing basically means that we are updating old test plans according to the new release of the software (GUI changes). Also, most of the test plans are from 2006 and just shout for a make-over to our new test format. It’s a lot of copy-paste, formatting and document creating in Excel…. I dislike it sooo much, and, want to test things again!

Oh, God… Wait, no…. Oh, developers, please develop the new, working build…